Re: routing sniffed traffic
On Fri, 8 Oct 2004, Nils Ketelsen wrote: On Thu, Oct 07, 2004 at 09:43:47PM +0100, Stephen J. Wilcox wrote: [switching/routing traffic from a passive tap] Hi Peter, if you are feeding this into a switch you should be able to switch it just like the real traffic.. ie plug your fibers into gbics on whatever switch you want to use, i dont see any special requirements for this application I have no practical experience on that, I always used the monitor directly on the Tap, but I see a theoretical problem: Where does the switch switch it to? The Target MAC of the packet coming from the Tap will be still pointing to the device in the production network. statically configure your mac to spoof that of the real interface. If you want to route it you will run into the same problem: The copied ethernet frame is not addresses to the router in the monitoring network, so it will not accept the Ethernet frame. again just duplicate the ip address Maybe you could do something with faking the MAC on the router in the monitoring network to be the same as the MACaddress of the target in the production network, but it feels like a dirty hack. Or am I missnig something obvious here? ok so you have the same thoughts.. the key point is the original question suggested this 'copycat' network is not connected to the real net, and so long as you dont allow the packets to be routed back into the real net (and hence create dups) you should be fine. Steve Nils
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 09 Oct, 2004 Analysis Summary BGP routing table entries examined: 149020 Prefixes after maximum aggregation: 87919 Unique aggregates announced to Internet: 71042 Total ASes present in the Internet Routing Table: 18195 Origin-only ASes present in the Internet Routing Table: 15790 Origin ASes announcing only one prefix:7393 Transit ASes present in the Internet Routing Table:2405 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 26 Prefixes from unregistered ASNs in the Routing Table:58 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 16 Number of addresses announced to Internet: 1344430884 Equivalent to 80 /8s, 34 /16s and 99 /24s Percentage of available address space announced: 36.3 Percentage of allocated address space announced: 58.6 Percentage of available address space allocated: 61.9 Total number of prefixes smaller than registry allocations: 68695 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:28600 Total APNIC prefixes after maximum aggregation: 14296 Prefixes being announced from the APNIC address blocks: 26765 Unique aggregates announced from the APNIC address blocks:14304 APNIC Region origin ASes present in the Internet Routing Table:2146 APNIC Region origin ASes announcing only one prefix:641 APNIC Region transit ASes present in the Internet Routing Table:329 Average APNIC Region AS path length visible:4.8 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 164575616 Equivalent to 9 /8s, 207 /16s and 57 /24s Percentage of available APNIC address space announced: 75.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 23552-24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 85051 Total ARIN prefixes after maximum aggregation:51403 Prefixes being announced from the ARIN address blocks:65114 Unique aggregates announced from the ARIN address blocks: 22973 ARIN Region origin ASes present in the Internet Routing Table: 9604 ARIN Region origin ASes announcing only one prefix:3450 ARIN Region transit ASes present in the Internet Routing Table: 931 Average ARIN Region AS path length visible: 4.4 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 233997056 Equivalent to 13 /8s, 242 /16s and 131 /24s Percentage of available ARIN address space announced: 69.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647,29695-30719, 31744-33791 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/7, 72/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 27632 Total RIPE prefixes after maximum aggregation:19190 Prefixes being announced from the RIPE address blocks:24481 Unique aggregates announced from the RIPE address blocks: 16076 RIPE Region origin ASes present in the Internet Routing Table: 5882 RIPE Region origin ASes announcing only one prefix:3169 RIPE Region transit ASes present in the Internet Routing Table:1018 Average RIPE Region AS path length visible: 5.3 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 173276096 Equivalent to 10 /8s, 83 /16s and 251 /24s Percentage
MED and community fluctuation
I understand the usage and application of MED and community attributes. But we watch some interesting policy/attribute fluctuation of MED and community. We analyze BGP updates sent out by RouteViews peers. We observed a lot of AADupType2 instabilities. We define AADupType2 event as: A route is implicitly withdrawn and replaced with a duplicate of the original route. The two messages have the same NEXTHOP and ASPATH attribute, but differ between at least one other attribute (like MED). Note that we only pair two updates from the same RouteViews' peer / neighboring AS. A fine-grained analysis revealed that most AADupType2 instabilities just change the MED or community attribute (or both), which means that MED and community values associated with prefixes are changing dynamically and frequently. We are not claiming it is a common practice of the Internet, this is just the cases observed from RouteViews peers. We are thinking of the motivation of doing this? Why the ISPs configured their network so that the MED values oscillate? Did ISPs configure MED values dynamically calculated from IGP metrics? The most strange thing to us is why the community attribute associated with prefixes also oscillate frequently. We know that community are used to simply operational complexity: group a set of prefixes to apply the same policy. It didn't make sense to me to change it dynamically. Misconfigurations? Any comments or discussions? Thanks! Zhen Wu
Re: MED and community fluctuation
On Fri, Oct 08, 2004 at 11:40:54AM -0700, Zhen Wu wrote: We are thinking of the motivation of doing this? Traffic enginneering. Why the ISPs configured their network so that the MED values oscillate? Is there actually persistant oscillation, or just frequent change with some peers at some periods of time? Did ISPs configure MED values dynamically calculated from IGP metrics? This may very well the reason. At least Cisco and Juniper offer the option to derive MED from IGP metric. The most strange thing to us is why the community attribute associated with prefixes also oscillate frequently. [...] Misconfigurations? Possibly. Routes received via different ingress points being tagged differently (e.g. country/city based scheme) and due to backbone topology changes, a different version of the route becoming best and thus announced to the looking glass. Or routes received via multiple ingress points and some missing the ingress tagging due to misconfigured route-map/policies. Same outcome. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: MED and community fluctuation
On Fri, Oct 08, 2004 at 08:49:22PM +0200, Daniel Roesen wrote: On Fri, Oct 08, 2004 at 11:40:54AM -0700, Zhen Wu wrote: We are thinking of the motivation of doing this? Traffic enginneering. I should have elaborated: to encourage the peer to perform cold-potato routing towards you. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Anyone from Hotmail listening?
If anyone responsible at Hotmail is listening, please email me off list. We have an issue that needs some work, and the usual channels are getting us nowhere. Thanks. -- Drew Linsalata The Gotham Bus Company, Inc. Colocation and Dedicated Access Solutions http://www.gothambus.com
Is there an email admin from RR.COM out there?
Not sure how applicable to NANOG this is, but the below thread has started on another list that I am on, and I thought someone listening here from RR.COM might be able to help. If you think you can assist or at least want to find out more about these issues, please contact me off list and I'll get you in touch with those effected. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace Begin forwarded message: From: Mitchell Kahn Date: October 8, 2004 3:06:22 PM EDT To: CommuniGate Pro Discussions Subject: Re: blocked for too many messages? It sounds as if your difficulties are actually worse than mine. Thanks for letting me know that I am in good company. Mitch On Oct 8, 2004, at 11:44 AM, eLists wrote: Hello, I too have had my emails to any rr.com server rejected as well. I also checked my IP address at this senderbase page and funny how a ranking of 10 equates to all internet email, and with my server sending out about 2000 emails a day, I have a rating of 2.3? Seems something is rather messed up with both senderbase and rr (not surprising that rr is messed up). In the past few days, my server has only attempted to send about 20 emails to rr.com servers. Yet all of mine are also blocked. Like you, my IP is not in any lists. Mitchell Kahn wrote: One of our clients received the following messaged when her e-mail was bounced: Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain hawaii.rr.com) reports: host orngca-01.mgw.rr.com says: 452 Too many recipients received this hour. Please see our rate limit policy at http://security.rr.com/spam.htm#ratelimit I went to the page listed to try to understand why her e-mail was rejected but this is incongruent with the facts as I understand them. I checked our logs and there was only one attempt in the last two days to send mail to this domain. My server does not appear on any of the spam lists that they show (see below), we have a static IP address on the server, and we don't have any open relays. This Road Runner process appears to render e-mail useless as a communication tool if this is the future of spam filtering. I contacted the ISP that bounced the mail but I have not had a response. (I wonder if my contact mail was bounced.) Is anyone else familiar with this experience? Does anyone know of a way around it? Thanks, Mitch_ Mitchell Kahn
[OT] Good Anti-Spam Boilerplate
Howdy, After some senseless Googling, I'm at a loss. I'm looking for a very comprehensive, up-to-date example of an AUP that covers spam. When I say modern, I mean that I want it to include not just direct spamming, but abuse of remote open-relays, abuse of remote trojaned boxes, sending through a third party that circumvents the local AUP, etc. Some good definition of requested email would be great - ie: double opt-in, or single opt-in with some documentation that the user requested the mail on a web form or similar. Some language that covers penalties would also be helpful, such as equipment seizure for non-payment of penalties. Please reply privately and I'll summarize. I do not wish to get into any debates about what qualifies as spam on this list. Thanks, Charles -- Charles Sprickman [EMAIL PROTECTED]
Re: Is there an email admin from RR.COM out there?
Forwarded to admins at RR, since I'm not 100% sure who's on here from there. -MH At 01:26 PM 10/8/2004, Jeff Wheeler wrote: Not sure how applicable to NANOG this is, but the below thread has started on another list that I am on, and I thought someone listening here from RR.COM might be able to help. If you think you can assist or at least want to find out more about these issues, please contact me off list and I'll get you in touch with those effected. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace *snip* W. Mark Herrick, Jr. Director - Data and Network Security Adelphia Communications 5619 DTC Parkway Greenwood Village, CO 80111 (O) 303-268-6440 (C) 720-252-5929 (F) 303-268-6687
RE: House Toughens Spyware Penalties
The general consensus seems to be that companies that choose to obey the law will simply disclose everything their software does in many, many paragraphs of legal language that few people will actually read. This will allow them to claim they have consent for whatever it is that they do. On the bright side, it will at least be possible for those who are sufficiently curious and diligent to determine what the software is doing by picking through the legal language. I've heard that Gator's license is 20% longer than the constitution. DS
Re: House Toughens Spyware Penalties
Scott Morris wrote: Oh, how festive. Anyone got that Bill (Gates) Blocker filter ready? :) Left to their own devices, congressmen should NOT be allowed to write bills about things they don't understand. Well... Ok, that's too restrictive. No bills would ever get written. We'll still see the same problems coming from the same non-US places where it isn't exactly feasible to prosecute. But it made someone someplace feel better, I'm sure! Sure, but as long as most spyware and spam is originated and operated by US citizens on US soil, it makes sense to make them responsible for their junk? Pete
Re: short Botnet list and Cashing in on DoS
Only when they do something about it.
Trouble? When they have 40K extra users to pay for bandwidth (easily
eats up a T1 or two), it's damage enough. Besides, would you like
someone to launch cyber A-Bombs (phaa) from your network?
1. Worrying about personal privacy of their users, not wanting to bend
too many rules to fight these drones that *appear* like regular users.
Appear? If you own one of the blocks below, please do something about it.
And I know people who mail abuse reports for hundreds of such *lists*,
something /rarely/ gets done.
One thing they focus on it taking down control web pages. For example if
the runner would give a command: 'update http://etc.com/evil.trojan.exe'
or if the drones spam themselves on irc.. then it's all about the abuse
teams. Some are really responsive, some just ignore.
Last time I took the time to inform ISP's about such a list was when it
was a 700 large army of *nix boxes. Haven't seen one of those for years
before that. It was 3 months ago or so.
It was rather funny really. Lesson learned: don't use hostnames like
securebox or secureserver1 or such.
sadsa``` [EMAIL PROTECTED] Don't Touch Me
`o`hj`h` [EMAIL PROTECTED] Don't Touch Me
TaiFrunze [EMAIL PROTECTED] Don't Touch Me
{snip}
I try and take care personally of drones and abusers I see coming from
Israel.. it's way too much work and annoyance as it is, thanks though.
Most ISP's truly don't want this as their own problem. I personally
don't blame them. Luckily the ISP I work for has no home users.
If you have any problem in Israel, whether with finding a contact or
reaching law enforcement - feel free to email me and I'd be glad to find
you a contact.
Gadi.
The Cidr Report
This report has been generated at Fri Oct 8 21:44:22 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
01-10-04145932 100119
02-10-04146075 99905
03-10-04145755 100267
04-10-04146184 100294
05-10-04146297 100252
06-10-04146316 100325
07-10-04146253 100429
08-10-04146340 100450
AS Summary
18121 Number of ASes in routing system
7375 Number of ASes announcing only one prefix
1392 Largest number of prefixes announced by an AS
AS7018 : ATTW ATT WorldNet Services
86706432 Largest address span announced by an AS (/32s)
AS721 : DNIC DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 08Oct04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 146447 1004494599831.4% All ASes
AS18566 7437 73699.1% CVAD Covad Communications
AS4134 814 178 63678.1% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4323 789 220 56972.1% TWTC Time Warner Telecom
AS7018 1392 967 42530.5% ATTW ATT WorldNet Services
AS6197 789 382 40751.6% BNS-14 BellSouth Network
Solutions, Inc
AS22773 403 21 38294.8% CXA Cox Communications Inc.
AS27364 411 37 37491.0% ARMC Armstrong Cable Services
AS6467 390 30 36092.3% ACSI e.spire Communications,
Inc.
AS701 1252 907 34527.6% UU UUNET Technologies, Inc.
AS22909 383 38 34590.1% CMCS Comcast Cable
Communications, Inc.
AS1239 953 639 31432.9% SPRN Sprint
AS17676 368 61 30783.4% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 334 33 30190.1% CNCNET-CN China Netcom Corp.
AS6478 379 79 30079.2% ATTW ATT WorldNet Services
AS4355 381 99 28274.0% ERSD EARTHLINK, INC
AS21502 2693 26698.9% ASN-NUMERICABLE NUMERICABLE is
a cabled network in France,
AS4766 529 266 26349.7% KIXS-AS-KR Korea Telecom
AS14654 2606 25497.7% WAYPOR-3 Wayport
AS9443 357 108 24969.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS6140 370 134 23663.8% IMPSA ImpSat
AS15557 334 104 23068.9% LDCOMNET LDCOM NETWORKS
AS2386 841 612 22927.2% ADCS-1 ATT Data
Communications Services
AS1221 815 587 22828.0% ASN-TELSTRA Telstra Pty Ltd
AS25844 244 16 22893.4% SASMFL-2 Skadden, Arps, Slate,
Meagher Flom LLP
AS9583 529 306 22342.2% SIFY-AS-IN Sify Limited
AS7843 488 266 22245.5% ADELPH-13 Adelphia Corp.
AS6198 432 214 21850.5% BNS-14 BellSouth Network
Solutions, Inc
AS13083 2178 20996.3% Mannesmann Datenverarbeitung
Autonomes System
AS721718 513 20528.6% DNIC DoD Network Information
Center
AS3356 647 445 20231.2% LEVEL3 Level 3 Communications
Total 16831 7286 954556.7% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax
Cable Ltd.
24.246.0.0/17AS7018 ATTW ATT WorldNet Services
24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC
24.246.128.0/18 AS7018 ATTW ATT WorldNet Services
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
64.46.27.0/24AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB
64.46.34.0/24AS3408
64.46.63.0/24AS7850 IHIGHW iHighway.net, Inc.
64.83.96.0/19AS26956 NETFR NetFree Communications
