Re: request for help w/ ATT and terminology
multi-homed. ATT says they'll give us a temporary ASN, and want us to do eBGP for our netblock. They sent the technical information over today, and they want two distinct routers to act as the bgp peers... Two different Quagga instances running on different loopback addresses on the same machine, and that machine being also one of your servers, would satisfy their demands for two distinct routers and yours for low budget. Rubens
Re: ARPANet Co-Founder Predicts An Internet Crisis (slashdot)
When we start migrating to IPv6, wouldn't state-aware forwarding be required for a good part of the traffic that is being translated from customer IPv6 to a legacy IPv4 ? I'm a personal fan of topology-based forwarding, but this is limited to the address space of the topology we currently use, which is running out of space in a few years (few meaning whatever version of the IPv4 RIRs deadline you believe in). Rubens On 10/25/07, Jason Frisvold [EMAIL PROTECTED] wrote: On 10/25/07, Paul Vixie [EMAIL PROTECTED] wrote: an economic crisis. Of course, Roberts has an agenda. He's now CEO of Anagran Inc., which makes a technology called flow-based routing that, Roberts claims, will solve all of the world's routing problems in one go. Anyone have any experience with these Anagran flow routers? Are they that much of a departure from traditional routing that it makes a big difference? I haven't done a lot of research into flow-based routing at this point, but it sounds like this would be similar to the MPLS approach, no? How about cost per port versus traditional routers from Cisco or Juniper? It seems that he cites cost as the main point of contention, so are these Anagran routers truly less expensive? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
SLA monitoring and reporting to customers
What open-source or low-budget tools are operators using for SLA monitoring when the reports (current state and historical) should be available to customers ? Looking at NANOG archives, NAGIOS is the most prevalent tool, but its authorization mechanisms are somewhat below I would like so customers could not change anything both in configuration and in SLA software state. I'm looking for something more like Cacti, where customers can be contained to only see some of the generated graphs. Thanks for any input, Rubens
Re: Refusing Pings on Core Routers??? A new trend?
template response -- I hear is Well, you can't rely on traceroute because of ICMP prioritisation. When you start to explain how traceroute actually works (both ICMP-based and UDP-based (which still relies on ICMP responses, of course!)), and that ICMP prio should only affect the IP of which the router listens on (and not hops beyond or at the dest), most NOCs fire back with another If I recall well, Cisco GSRs impose low priority and/or limits for all ICMP traffic flowing thru the box, not just packets to/from router itself, and there's not a knob to adjust that. Also of notice is that packets that expire TTL needs some kind of low-path processing, and will be subject to increased latency or loss compared to normal ones, and this affects every tool to trace packets thru the network I've seen.
Re: Open Letter to D-Link about their NTP vandalism
GPS.dix.dk service is described as: DK Denmark GPS.dix.dk (192.38.7.240) Location: Lyngby, Denmark Geographic Coordinates: 55:47:03.36N, 12:03:21.48E Synchronization: NTP V4 GPS with OCXO timebase Service Area: Networks BGP-announced on the DIX Access Policy: open access to servers, please, no client use Contacts: Poul-Henning Kamp ([EMAIL PROTECTED]) Note: timestamps better than +/-5 usec. I think he should use dns views to answer the queries to gps.dix.dk and either: ( a ) answer 127.0.0.1 to all queries from outside his service area ( b ) answer a D-Link IP address to all queries from outside his service area (which could lead to getting their attention; dunno if from their engineers or from their lawyers). Rubens On 4/7/06, Etaoin Shrdlu [EMAIL PROTECTED] wrote: Well, this is at least marginally on topic, and I think it deserves a wider audience. It is written by Poul-Henning Kamp (the affected party). Please read it. http://people.freebsd.org/~phk/dlink/ It ends with the following: Didn't something like this happen before? Yes, D-Link is not the first vendor to make a hash of the NTP protocol. Some years back NetGear products blasted University of Wisconsin off the net. I have repeatedly pointed D-Link's lawyer at this case. Fortunately, in my case it is not that bad. The NetGear incident caused the NTP protocol designers to add a kiss of death option to the Latest (S)NTP standard but D-Links devices does not respect that option. I have tried. -- You can't have in a democracy various groups with arms - you have to have the state with a monopoly on power, Condoleeza Rice, the US secretary of state, said at the end of her two-day visit to Baghdad yesterday. ...No Comment
Re: Open Letter to D-Link about their NTP vandalism
I think he should use dns views to answer the queries to gps.dix.dk and either: ( a ) answer 127.0.0.1 to all queries from outside his service area ( b ) answer a D-Link IP address to all queries from outside his service area (which could lead to getting their attention; dunno if from their engineers or from their lawyers). Neither of which would solve the problem of his bandwidth being used by these, although (b) might actually serve to get their attention. This reduces the bandwidth, as instead of dropping NTP packets, they would never come to him in the first place. Perhaps as a thanks to him for the public service he provides the DIX, all of the users at DIX could set their external routers to reject incoming NTP packets from networks other than their own? Or even combine Which still would require him to answer DNS requests for gps.dix.de. that with (b), although it might be more effective if it targeted, oh, www.dlink.com instead of an IP address. Answering with CNAME instead of A is a good enhancement of the original idea... :-) Then at least it would not be taking up internal DIX bandwidth capacity. It still would require him to answer the DNS requests. Only way to addres that is everybody outside DIX declare gps.dix.de as www.dlink.com in their resolvers. By no means am I encouraging legally actionable activity, however, and as noted, (b) just might be. Motion granted. Rubens
Re: Welcome back, Ma Bell
What are people worried about here exactly? The same lack of competition in telecommunications that we had in the 1980s? Granted, it won't ever be quite *that* bad again, but we're slowly moving back towards one monolithic ILEC, and that does worry me. To worry most is the fact that a single company has all services on a given area: fixed, wireless, long-distance. I don't think that having a single fixed-only company throughout the country would be such a big issue... but having the customer first mile (which some people call last mile, although saying customer comes first) and be allowed to offer LD and wireless is something to be afraid. Be very afraid. Rubens
Re: On the inoc-dba subject
Please make sure that your spam filters allow email from pch.net before you sign up, since we will need to automatically verify your email address. Since we all know that whitelisting and blacklisting by in-band stated from email address is quite wrong-headed, from a clue standpoint. Perhaps something like this? Please make sure that your spam filters allow email sent from ip-addresses with a from address of pch.net before you sign up, since we will need to automatically verify your email address. Where ip-addresses is the output of a dig command against the outgoing smtp servers sending the notifications? pch.net publishes a SPF record: v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org a:ghosthacked.net ~all Besides going from soft-fail (~all) to fail (-all), they are already giving you the tools you need to validate a MAIL FROM: claim. Rubens
Re: Worm?
See story below from isc.sans.org (now on cover page, article on http://isc.sans.org/diary.php?storyid=1042) Rubens --- TippingPoint IPS DoS (High CPU load) (NEW) Published: 2006-01-14, Last Updated: 2006-01-14 05:57:28 UTC by Swa Frantzen (Version: 3(click to highlight changes)) We are getting multiple reports of a DoS attack (causing high CPU load that prevents normal use) against TippingPoint IPS devices. We got a call from TippingPoint, stating that in their opinion this is not a DoS, but a high load issue. For more details we'd like to urge customers to contact TippingPoint directly. They are working on a patch and advisory which should be available shortly. Edit: We've received a report that TippingPoint has now released a patch for this issue. The patch version is TOS 2.1.4.6324. -- Swa Frantzen On 1/13/06, Byrne, David [EMAIL PROTECTED] wrote: Anyone know about a new worm going around? Our IPS vendor says that they have a number of customers affected by traffic volume, but I don't know any details. Thanks, David Byrne Corporate IT Security EchoStar Satellite L.L.C. 720-514-5675 [EMAIL PROTECTED]
Re: Destructive botnet originating from Japan
The first rule of nsp-sec is, you do not talk about nsp-sec The second rule of nsp-sec is, you DO NOT talk about nsp-sec Rubens On 12/25/05, Hannigan, Martin [EMAIL PROTECTED] wrote: What's nsp-sec? -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED] Sent: Sun Dec 25 04:25:15 2005 To: Gadi Evron Cc: Rob Thomas; NANOG Subject:Re: Destructive botnet originating from Japan On Sun, Dec 25, 2005 at 02:06:38AM -0600, Gadi Evron wrote: It is difficult to hear something important that one invested much in is doing harm, but that is the only conclusion I and others can come up with after years of study, and NSP-SEC, as amazing as it has been, has been of a negative impact other than to cause a community to form and act together. Which is amazing by itself and which is why I believe it can do so much more.. even if it is relatively young it has proven itself time and time again... I am straying from the subject here. Could have told you that a long time ago. NSP-SEC became useless the day it became so bogged down in its own self-aggrandizing paranoia that no one could possibly be bothered to actually tell anyone outside of the secret handshake club about security issues they've spotted. On the other hand, if you ARE going to sit around pissing and moaning about botnets you are too sekure to tell anyone else about, thus assuring they never get fixed, at least it's nice to do it in one secret place so I don't have to hear it. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: ASN database files from LACNIC or AFRINIC?
ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest has IP space and ASN allocations. ASN lines look like this: lacnic|MX|asn|278|1|19890331|allocated lacnic|AR|asn|676|1|19900523|allocated lacnic|BR|asn|1251|1|19910405|allocated lacnic|MX|asn|1292|1|19910524|allocated They mirror similar information from other RIRs: ftp://ftp.lacnic.net/pub/stats/afrinic/delegated-afrinic-latest ftp://ftp.lacnic.net/pub/stats/arin/delegated-arin-latest My guess is the other RIRs mirror LACNIC's info as well... and it would be nice to have an all merged delegated-latest, wouldn't it ? I'll try to find one, or ask LACNIC folks if they can do one. Rubens On 10/28/05, Andreas Ott [EMAIL PROTECTED] wrote: Hello, I am currently looking for ASN databases from LACNIC and AFRINIC the same way they are provided at ftp://ftp.arin.net/pub/rr/arin.db ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz ftp://ftp.apnic.net/apnic/whois-data/APNIC/apnic.RPSL.db.gz I've traversed their respective ftp.[lacnic|afrinic].net servers to no avail. I would appreciate any hints where to download this data if it exists. NB: we do know that looking up from a dowloaded file might not be up-to-date anymore the older the file gets. However, the application usually does more lookups than the online queries permit us to do. We will keep this updated asynchronously. Thanks, andreas -- Andreas Ott[EMAIL PROTECTED]
Re: ASN database files from LACNIC or AFRINIC?
You could take every asn out of the delegated list, and query whois.lacnic.net for each one... just rate-limit the queries (1/min is ok, I think) and after a few hours you'll have pairs like this: aut-num: AS1251 owner: Fundacao de Amparo a Pesquisa do Estado de Sao Pau But I guess that was already your plan B... Rubens On 10/29/05, Andreas Ott [EMAIL PROTECTED] wrote: Hi, On Sat, Oct 29, 2005 at 01:30:23AM -0200, Rubens Kuhl Jr. wrote: ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest has IP space and ASN allocations. ASN lines look like this: lacnic|MX|asn|278|1|19890331|allocated ... I found that one, but this is less helpful for what I need. I'd like to get a db record that has the AS number and the AS name. You know, for pretty printing things to screen in reports I was asked to name things with a name and not a number. If they instead had lacnic|MX|asn|278|1|19890331|EXAMPLE-CORPORATION that would be great and I could adjust the parser. Well, we might have to settle for telling in which country the AS is allocated. -andreas -- Andreas Ott[EMAIL PROTECTED]
Re: Scalability issues in the Internet routing system
likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. IPv6 will someday account for as many IPv4 networks as would exist then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs 32 bits prefix+address, remainder 64 bits addresses on IPv6 are strictly local), so despite a 3x cost increase (1 32 bit table for IPv4, 2 for IPv6) on memory structures and 2x increase on lookup engine(2 engines would be used for IPv6, one for IPv4), the same techonology that can run IPv4 can do IPv6 at the same speed. As this is not a usual demand today, even hardware routers limit the forwarding table to the sum of IPv4 and IPv6 prefixes, and forward IPv6 at half the rate of IPv4. Rubens
Re: Scalability issues in the Internet routing system
IPv6 will someday account for as many IPv4 networks as would exist
then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs
32 bits prefix+address, remainder 64 bits addresses on IPv6 are
strictly local), so despite a 3x cost increase (1 32 bit table for
IPv4, 2 for IPv6) on memory structures and 2x increase on lookup
engine(2 engines would be used for IPv6, one for IPv4), the same
techonology that can run IPv4 can do IPv6 at the same speed. As this
is not a usual demand today, even hardware routers limit the
forwarding table to the sum of IPv4 and IPv6 prefixes, and forward
IPv6 at half the rate of IPv4.
s/64/128/
...and total, complete, non-sense. please educate yourself more on reality
of inet6 unicast forwarding before speculating. Thank you.
From RFC 3513(Internet Protocol Version 6 (IPv6) Addressing Architecture):
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
If Interface ID is 64 bits large, prefix would be 64 bits max,
wouldn't it ? Usually it will be somewhere between 32 bits and 64
bits.
As for 000 addresses:
Unassigned (see Note 1 below) 1/256
Unassigned 0001 1/256
Reserved for NSAP Allocation 001 1/128 [RFC1888]
Unassigned 011/64
Unassigned 1 1/32
Unassigned0001 1/16
1. The unspecified address, the loopback address, and the IPv6
Addresses with Embedded IPv4 Addresses are assigned out of the
binary prefix space.
Embedded IPv4 can be forwarded using IPv4 lookup, and all other 000
cases can be handled in slow-path as exceptions. IANA assignment
starts at 001 and shouldn't get to any of the 000 sections.
One interesting note though is Pekka Savola's RFC3627:
Even though having prefix length longer than /64 is forbidden by
[ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127
prefix length has gained a lot of operational popularity;
Are you arguing in the popularity sense ? Is RFC 3513 that apart from
reality ? An October 2005(this month) article I
found(http://www.usipv6.com/6sense/2005/oct/05.htm) says Just as a
reminder, IPv6 uses a 128-bit address, and current IPv6 unicast
addressing uses the first 64 bits of this to actually describe the
location of a node, with the remaining 64 bits being used as an
endpoint identifier, not used for routing., same as RFC 3513.
Limiting prefix length to 64 bits is a good thing; it would be even
better to guarantee that prefixes are always 32 bits or longer, in
order to use exact match search on the first 32 bits of the address,
and longest prefix match only on the remaining 32 bits of the prefix
identifier.
Rubens
Re: Scalability issues in the Internet routing system
Assume you have determined that a percentage (20%, 80%, whatever) of the routing table is really used for a fixed time period. If you design a forwarding system that can do some packets per second for those most used routes, all you need to DDoS it is a zombie network that would send packets to all other destinations... rate-limiting and dampening would probably come into place, and a new arms race would start, killing operator's abilities to fast renumber sites or entire networks and new troubleshooting issues for network operators. Isn't just simpler to forward at line-rate ? IP look ups are fast nowadays, due to algorithmic and architecture improvements... even packet classification (which is n-tuple version of the IP look up problem) is not that hard anymore. Algorithms can be updated on software-based routers, and performance gains far exceed Moore's Law and projected prefix growth rates... and routers that cannot cope with that can always be changed to handle IGP-only routes and default gateway to a router that can keep up with full routing. (actually, hardware-based routers based on limited size CAMs are more vulnerable to obsolescence by routing table growth than software ones) Let's celebrate the death of ip route-cache, not hellraise this fragility. Rubens On 10/24/05, Alexei Roudnev [EMAIL PROTECTED] wrote: One question - which percent of routing table of any particular router is REALLY used, say, during 1 week? I have a strong impression, that answer wil not be more than 20% even in biggerst backbones, and will be (more likely) below 1% in the rest of the world. Which makes a hige space for optimization. - Original Message - From: Daniel Senie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 18, 2005 9:50 AM Subject: Re: Scalability issues in the Internet routing system At 11:30 AM 10/18/2005, Andre Oppermann wrote: I guess it's time to have a look at the actual scalability issues we face in the Internet routing system. Maybe the area of action becomes a bit more clear with such an assessment. In the current Internet routing system we face two distinctive scalability issues: 1. The number of prefixes*paths in the routing table and interdomain routing system (BGP) This problem scales with the number of prefixes and available paths to a particlar router/network in addition to constant churn in the reachablility state. The required capacity for a routers control plane is: capacity = prefix * path * churnfactor / second I think it is safe, even with projected AS and IP uptake, to assume Moore's law can cope with this. Moore will keep up reasonably with both the CPU needed to keep BGP perking, and with memory requirements for the RIB, as well as other non-data-path functions of routers. 2. The number of longest match prefixes in the forwarding table This problem scales with the number of prefixes and the number of packets per second the router has to process under full or expected load. The required capacity for a routers forwarding plane is: capacity = prefixes * packets / second This one is much harder to cope with as the number of prefixes and the link speeds are rising. Thus the problem is multiplicative to quadratic. Here I think Moore's law doesn't cope with the increase in projected growth in longest prefix match prefixes and link speed. Doing longest prefix matches in hardware is relatively complex. Even more so for the additional bits in IPv6. Doing perfect matches in hardware is much easier though... Several items regarding FIB lookup: 1) The design of the FIB need not be the same as the RIB. There is plenty of room for creativity in router design in this space. Specifically, the FIB could be dramatically reduced in size via aggregation. The number of egress points (real or virtual) and/or policies within a router is likely FAR smaller than the total number of routes. It's unclear if any significant effort has been put into this. 2) Nothing says the design of the FIB lookup hardware has to be longest match. Other designs are quite possible. Again, some creativity in design could go a long way. The end result must match that which would be provided by longest-match lookup, but that doesn't mean the ASIC/FPGA or general purpose CPUs on the line card actually have to implement the mechanism in that fashion. 3) Don't discount novel uses of commodity components. There are fast CPU chips available today that may be appropriate to embed on line cards with a bit of firmware, and may be a lot more cost effective and sufficiently fast compared to custom ASICs of a few years ago. The definition of what's hardware and what's software on line cards need not be entirely defined by whether the design is executed entirely by a hardware engineer or a software engineer. Finally, don't
Re: Spyware becomes increasingly malicious
Try booting into safe mode before running software to detect or remove spyware; some of them fight to survive if they are running, dunno if it is the case with CoolWebSearch. Rubens - Original Message - From: Michel Py [EMAIL PROTECTED] To: Sean Donelan [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 12, 2004 12:24 AM Subject: RE: Spyware becomes increasingly malicious Sean Donelan wrote: Spyware isn't the best term for what is happening, but it is quickly exceeding (or contributing) to all the other problems associated with the online (not just Internet) world. Indeed. Lately, I have not been able to clean a very annoying piece of crud named CoolWebSearch. Spybot will not always detect and never remove; Ad-aware will likely detect but not remove either. None of the other crapware removers I have tried could clean the machine either. I have instructed helpdesk not to waste any time with it and systematically re-image the infected PC :-( Fortunately, re-imaging a PC is now a matter of minutes. Michel.
Re: real-time DDoS help?
Is there any place where people with experience dealing with DDoS attacks hang out? I'm getting very little assistance from my upstream beyond call whomever is in charge of each IP attacking and make them stop, and even though we null route the destination IP being attacked, this traffic will be billed. It seems that you should look somewhere else for your next bandwidth contract... I've got a nice snippet of flows, so I can mostly see where everything is coming from, and it's obvious what the target is, but my flow-stat/flow-report skills are pretty weak. Fake or real source IPs ? TCP SYNs, ICMPs, UDPs ? Rubens
Re: SSH on the router - was( IT security people sleep well)
I'd rather use IPSEC than SSH to connect to routers or to a secure gateway and then to routers. Flaw history in IPSEC is much better than SSH, IPSEC can easily be used to move files with FTP or TFTP (does your router/client suport SCP ? SFTP ?)... Unfortunately, IOS costs more to have IPSEC. Rubens - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 7:39 AM Subject: SSH on the router - was( IT security people sleep well) complaining that cisco charges extra for such a critical component is exactly the right thing to do; it is fucking scary. every damn network device which used to have telnet should ship with ssh, it's free. Why? The typical network architecture of an ISP sees routers located in large clusters in a PoP or on a customer's site directly connected to a PoP. Since it is dead simple to place a 1U Linux box or similar SPARC server in a PoP to act as a secure gateway, why should router vendors encourage laziness and sloppiness? IMHO routers should not have SSH at all and should not accept any packets directed to them unless they are coming from a small set of known addresses on the network operator's management network. Once you open the router to SSH from arbitrary locations on the Internet you also open the router to DDoS from arbitrary locations and to attacks from people with inside info (SSH keys stolen or otherwise). It makes more sense to funnel everything through secure gateways and then use SSH as a second level of security to allow staff to connect to the secure gateways from the Internet. Of course these secure gateways are more than just security proxies; they can also contain diagnostic tools, auditing functions, scripting capability, etc. Now there is nothing fundamentally wrong with ADDING to that type of architecture by enabling SSH between the routers and the security gateways. But I believe that it is fundamentally wrong to consider SSH on the router to be equivalent to opening the router to any staff member, anytime, anywhere on the Internet. There are still possible man in the middle attacks that cannot be protected against by SSH. Consider the case of a staff member lounging in the backyard on a lazy Saturday afternoon with their iBook. They have an 802.11 wireless LAN at home so they telnet to their Linux box in the kitchen and run SSH to the router. Ooops! The only way to protect against that sort of situation is to encourage everyone to be security-minded and not take risks where the network is concerned. Funneling all access to routers through a secure gateway is part of that security-mindedness and is just plain good practice. --Michael Dillon
Re: Routing issues
I'm seeing the same thing: works from 80.*, doesn't work from 83.*. Note that www.mercer.com seems to suffer from a bad case of paranoia, they filter traceroute and ping, so probably a misconfigured firewall there. hk.yahoo.com traceroutes just fine from a 212.* address: TCP port 80 can also be used to traceroute... hping is your friend. http://www.hping.org (or apt-get install hping2 on apt-friendly distributions) Rubens
Bagle, not that smart
This is a bagle sample I've received; it seems they have somewhat to learn about ccTLDs (there is no org.br domain), and to what FROM to choose (an address for university adminissions wouldn't send you a support message). Rubens - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 3:50 PM Subject: [blacklist] Notify about using the e-mail account. Dear user, the management of Org.br mailing system wants to let you know that, We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For details see the attached file. In order to read the attach you have to use the following password: 46742. Kind regards, The Org.br teamhttp://www.org.br [As partes desta mensagem que não continham texto foram removidas] Enviar mensagens: mailto:[EMAIL PROTECTED] Sair do grupo : mailto:[EMAIL PROTECTED] eGroups : http://br.egroups.com/group/pataquada/ Links do Yahoo! Grupos Para visitar o site do seu grupo, acesse: http://br.groups.yahoo.com/group/pataquada/ Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: Possibly yet another MS mail worm
I'm not aware of any mail scanner that does this without running an external anti-virus or something alike, although is not that intensive to follow the zip headers (as they already do with the MIME headers in order to drop external attachments). Most scanners can accept an anti-virus plugin and them scan inside zip files, but that requires more processing power, more queue disk space, more RAM, more administration to update virus patterns, and so on. The cost/benefit usually pays off, but more complexity means less people will adopt the solution, thus making worm spreading easier. Rubens - Original Message - From: Michael Wiacek [EMAIL PROTECTED] To: Rubens Kuhl Jr. [EMAIL PROTECTED] Cc: Todd Vierling [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, February 29, 2004 11:16 PM Subject: Re: Possibly yet another MS mail worm I believe the point is, your mail scanner should be able to scan something as simple as zip compressed attachments. If it can't, you may want to rethink which program you use. Most open source and commercial scanners can scan inside zip files. mike On Sat, 28 Feb 2004, Rubens Kuhl Jr. wrote: It's annoying how easily these things spread even though they don't rely on a specific OS vulnerabililty -- hell, it's an executable *in a zipfile*, so it requires opening the zipfile and then running the program inside it. Of course everyone will run it, even though it's named dygfwefuih.exe (random characters before .exe). grumble Being in a zipfile is exactly why these things work: most mail systems nowadays drop executable attachments without mercy, but a zipfile may be a compressed document. Not every mail system screen incoming messages with anti-virus. People writing this worms don't know just a bit about human behaviour, they seem to keep up with trends in mail systems administration as well. Rubens !DSPAM:404137ae74191246918873!
Re: Possibly yet another MS mail worm
I'm not aware of any mail scanner that does this without running an external anti-virus or something alike, although is not that intensive to follow the zip headers (as they already do with the MIME headers in order to drop external attachments). Most scanners can accept an anti-virus plugin and them scan inside zip files, but that requires more processing power, more queue disk space, more RAM, more administration to update virus patterns, and so on. The cost/benefit usually pays off, but more complexity means less people will adopt the solution, thus making worm spreading easier. your description makes it all sound quite complicated, possibly because you are passing all the processing down to the end-user's machine. I was talking about central anti-virus processing... although it's easier on administration than updating hundreds or thousands of machines, it establishes a central bottleneck. Doing decompression and extensive pattern matching on a high volume server is not an easy task. we have anti-virus (clamav) and anti-spam (spamassassin) running at the server level, and thus save the end-user alot of cycles. Even on low volume servers, this task is not something one would do without some thinking; on high volume, this is achievable but would require a good systems design to cope with the higher latency between mail receive and mail delivery. clamav will look inside zip files, and automatically updates its signature database. spamassassin uses both global rules and per-user rules to rate incoming email and reduce the impact of spam. Been there at many installations of MailScanner (http://www.mailscanner.info). we even run in-line scans of MIME headers during the SMTP process and reject specific attachments (.exe, .pif, etc) without even bothering the end-user. That kind of filtering is much easier to configure, administer and goes low on resources. Extending this to verify filenames inside zip files would not be difficult to do, and is simple and not intensive enough to lots of people to turn such filters on. Rubens
Re: Possibly yet another MS mail worm
It's annoying how easily these things spread even though they don't rely on a specific OS vulnerabililty -- hell, it's an executable *in a zipfile*, so it requires opening the zipfile and then running the program inside it. Of course everyone will run it, even though it's named dygfwefuih.exe (random characters before .exe). grumble Being in a zipfile is exactly why these things work: most mail systems nowadays drop executable attachments without mercy, but a zipfile may be a compressed document. Not every mail system screen incoming messages with anti-virus. People writing this worms don't know just a bit about human behaviour, they seem to keep up with trends in mail systems administration as well. Rubens
Re: [IP] VeriSign prepares to relaunch Site Finder -- calls technologists biased
|Is there concern to be raised by network operators over such schemes if |deployed at the individual ISP level, particularly if such technology |becomes widespread? Yes: the DNS structure is a scalable way to locate IP addresses for names, but it needs trust as people can bypass it and go directly to root servers, gtld servers, cctld servers. The more non-standard hacks the structure get, the more distrust it will have; if it becomes widespread, off-the-shelf operating systems with internal recursive DNS will also become widespread. Revenue from DNS redirection will go towards zero, and load at the central servers will go to the sky and never come down ever again. Rubens
Re: Verizon clients DOS own site?
Or add a 127.0.0.1 supportcenter.verizon.net entry to the remotes hosts file. If and when they solve this or the software is removed, remove the entry; traffic will be killed locally before entering your VPN. Rubens - Original Message - From: William Warren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 6:48 PM Subject: Re: Verizon clients DOS own site? this is part of the autodiag software installed by the VZ cdyou will need to go through your remotes and uninstall that stuffe.. [EMAIL PROTECTED] wrote: Anyone else seeing this, it started up a few weeks ago. We have a number of home users that VPN to our corporate network who are using Verizon DSL as their Internet provider. While they are connected to the corporate network they are generating tons of hits to 'supportcenter.verizon.net' (206.46.187.54) Here's a basic trace: host.on.my.net - 206.46.187.54 TCP 49980 HTTP [ACK] host.on.my.net - 206.46.187.54 HTTP GET /sbconfigservlet/sbconfigservlet HTTP/1.1 206.46.187.54 - host.on.my.net HTTP HTTP/1.1 404 Not found Here's the text of the transaction: host.on.my.net GET /sbconfigservlet/sbconfigservlet HTTP/1.1 Accept: */* Accept-Language: en If-Modified-Since: Mon, 09 Feb 2004 22:49:47 GMT User-Agent: Motive HTTP Client Host: supportcenter.verizon.net Connection: Keep-Alive Cache-Control: no-cache reply from 206.46.187.54 HTTP/1.1 404 Not found Server: Netscape-Enterprise/6.0 Date: Tue, 10 Feb 2004 19:37:05 GMT Content-type: text/html Content-length: 292 HEADMETA HTTP-EQUIV=Content-Type CONTENT=text/html;charset=ISO-8859-1TITLENot Found/TITLE/HEADH1Not Found/H1 The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. This repeates over and over again many times a second while the client is connected. My guess is that these client files are the ones that initiate the conversation from the client: C:\program files\verizon\online\supportcenter\bin\matcli.exe C:\program files\verizon\online\supportcenter\bin\mpbtn.exe I'm seeing millions of hits to this site from just our ~100 users using Verizon per week. I have to think that world wide, Verizon clients are generating enough traffic to DOS themselves. I've tried contacting Verizon via email but I haven't received a response and their tech support had no information on this. Although we're now blocking this site and trying to clean up the clients, this is still generation a lot of noise on our network. Any ideas on how to get Verizon to take a look at this? Any input is welcome. Thanks, Rob Elkind Information Security Engineer EMC² where information lives Email: [EMAIL PROTECTED] -- May God Bless you and everything you touch. My foundation verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
Re: Are SW upgrades needed in MPLS core networks?
- Original Message - Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance. Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets; may be accelerated forwarding by tag switching, the idea that originated MPLS, is a good thing ? Rubens
Re: Are SW upgrades needed in MPLS core networks?
Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets; we call that crappy hardware Based on such point of view, non-crappy hardware would be: (blank) and crappy hardware would be (blank), could you fill the blanks ? As with so many other situations, the blanks can be filled in with Juniper and Cisco, in that order. I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route. Just to be sure, my point here is not where the effective IPv6 performance suits one needs or not, but wether a router that can forward amount Mpps of IPv4/MPLS packets can also forward the same amount of IPv6 packets per second. Rubens
Re: Are SW upgrades needed in MPLS core networks?
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route. ahhh. you have been watching marketing architecture presentations. Usually it's a good way to learn about the architecture of the competitor's(i.e, not the company of the presenter) router; watch both of them and you get a pretty good image of what they are. otoh, we have been using real routers. Those real routers have real architetures with what behaviour regarding prefix-length ? Rubens
Re: Are SW upgrades needed in MPLS core networks?
There is another factor at play here which is memory bandwidth at the lookup engine. If you have to look deeper into the packet than you can accomplish by using single spin trough the thing that fetches x bit wide words from the packet, you´ll effectively half your packet rate. Yes, that might explain the performance halving in some architetures (may be it's what happens with Sup 720, may be not), instead of longer lookup cycle. Doing 8+1+1+1+1+... would seem wasteful for IPv6 with the current address allocation scheme, are you sure that´s what´s used for IPv6 too? I'm not. Juniper isn't very open about this matter, and I only got confirmation of that for IPv4. Rubens
Re: Are SW upgrades needed in MPLS core networks?
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route. Uhh.. One trie lookup is fully supported in ASIC, the other is not. That probably would not yield half the performance, but a really crappy performance according to my standards (not so tight as Randy's). Just to be sure, my point here is not where the effective IPv6 performance suits one needs or not, but wether a router that can forward amount Mpps of IPv4/MPLS packets can also forward the same amount of IPv6 packets per second. Personally I'd say the routing protocol functionality and stability is as important if not more important. I don't see the point in implementing a v6 network consisting of seperate 7206vxrs (to contain the ios crashes) and tunnels, if you're going to bother with it at least do it native and do it right. In a ground-up design, yes. Upgrading an existing network in low capex times is not that easy to do. Rubens
Re: Monumentous task of making a list of all DDoS Zombies.
You probably want to make a list of vulnerable hosts that fall to exploits like this:http://server-ip-here/scripts/../../winnt/system32/ping.exe MostDDoS zombies will use spoofed IP packets to attack its victim, so filtering the source will not relief your pain. Rubens - Original Message - From: Drew Weaver To: [EMAIL PROTECTED] Sent: Friday, February 06, 2004 7:15 PM Subject: Monumentous task of making a list of all DDoS Zombies. Is there a list maintained anywhere of all hosts that have been identified as a DDoS zombie? Or attack box? We got hit with an attack from more than 60 IPs last night and I'd like to add them to any list that anyone has started. Thanks, -Drew
Re: Stopping open proxies and open relays
Force all SMTP outbound connections from users thru a SMTP proxy. On that proxy, force users to do SMTP Authentication; I've heard only once of a spam code that will use the user's configuration info or dispatch e-mail thru them. Even if they do, you can rate-limit messages/hour, unique mail to/hour, disable mail service after a threshold, whatever sounds a good policy to you. Rubens - Original Message - From: Adi Linden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 07, 2004 2:43 AM Subject: Stopping open proxies and open relays I am looking for ideas to stop the spam created by compromised Windows PC's. This is not about the various worms and viruses replicating but these boxes acting as open relays or open proxies. There are valid reasons not to run antivirus software, coupled with clueless users, this results in machines that SPAM again just a few hours after having been cleaned. Adi
Re: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1
Checkpoint Firewall-1 HTTP Parsing Format String Vulnerabilities Vendor Notification Schedule: Vendor notified - 2/2/2004 Checkpoint patch developed and made available - 2/4/2004 ISS X-Force Advisory released - 2/4/2004 Checkpoint VPN-1/SecureClient ISAKMP Buffer Overflow Vendor Notification Schedule: Vendor notified - 2/2/2004 Checkpoint patch developed and made available - 2/4/2004 ISS X-Force Advisory released - 2/4/2004 Isn't it curious that two unrelated issues have been reported to CheckPoint at the same day and the patches came out on the same day ? Am I too paranoid, or it seems that CheckPoint had previous knowledge of the bugs and they agreed with ISS which date would be stated as notification to CP to make it appears that a quick response (two days) has been achieved on those issues ? Rubens - Original Message - From: Ingevaldson, Dan (ISS Atlanta) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:32 AM Subject: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1 Nanog- ISS X-Force release two X-Force Security Advisories this evening detailing high-risk issues in Checkpoint Firewall-1 and VPN-1. Please refer to the following URLs for more information: http://xforce.iss.net/xforce/alerts/id/162 http://xforce.iss.net/xforce/alerts/id/163 -- Daniel Ingevaldson Director, X-Force RD [EMAIL PROTECTED] 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net
Re: ISS X-Force Security Advisories on Checkpoint Firewall-1 and VPN-1
My point is that is very unlikely that both bugs had been discovered by ISS within the same time frame. Two days is also little time do develop and test, which raises the suspicion on this issue. I'm not against notification before disclosure, but it seems that the dates on this announcement might have been changed in order to make the solution appear to be developed in very little time. (See ma, I'm damn fast) Rubens Why is that bad? I have no objection to giving vendors a reasonable amount of time to fix problems before announcing the whole. Or is your point that two days hardly seems like enough time to develop -- and *test* -- a fix? --Steve Bellovin, http://www.research.att.com/~smb
Re: Strange public traceroutes return private RFC1918 addresses
Using real but announced IPs for routers will make their packets fail unicast-RPF checks, dropping traceroute and PMTUD responses as happens with RFC1918 addresses. Rubens - Original Message - From: Matthew Crocker [EMAIL PROTECTED] To: Brian (nanog-list) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 02, 2004 9:25 PM Subject: Re: Strange public traceroutes return private RFC1918 addresses Search the archives, Comcast and other cable/DSL providers use the 10/8 for their infrastructure. The Internet itself doesn't need to be Internet routable. Only the edges need to be routable. It is common practice to use RFC1918 address space inside the network. Companies like Sprint and Verio use 'real' IPs but don't announce them to their peers on customer edge routes. -Matt On Feb 2, 2004, at 6:01 PM, Brian (nanog-list) wrote: Any ideas how (or why) the following traceroutes are leaking private RFC1918 addresses back to me when I do a traceroute? Maybe try from your side of the internet and see if you get the same types of responses. It's really strange to see 10/8's and 192.168/16 addresses coming from the public internet. Has this phenomenon been documented anywhere? Connectivity to the end-sites is fine, it's just the traceroutes that are strange. (initial few hops sanitized) [EMAIL PROTECTED] /]# traceroute www.ibm.com traceroute: Warning: www.ibm.com has multiple addresses; using 129.42.17.99 traceroute to www.ibm.com (129.42.17.99), 30 hops max, 38 byte packets 1 (---.---.---.---) 2.481 ms 2.444 ms 2.379 ms 2 (---.---.---.---) 17.964 ms 17.529 ms 17.632 ms 3 so-1-2.core1.Chicago1.Level3.net (209.0.225.1) 17.891 ms 17.985 ms 18.026 ms 4 so-11-0.core2.chicago1.level3.net (4.68.112.194) 18.272 ms 18.109 ms 17.795 ms 5 so-4-1-0.bbr2.chicago1.level3.net (4.68.112.197) 17.851 ms 17.859 ms 18.094 ms 6 so-3-0-0.mp1.stlouis1.level3.net (64.159.0.49) 23.095 ms 22.975 ms 22.998 ms 7 ge-7-1.hsa2.stlouis1.level3.net (64.159.4.130) 23.106 ms 23.237 ms 22.977 ms 8 unknown.level3.net (63.20.48.6) 24.264 ms 24.099 ms 24.154 ms 9 10.16.255.10 (10.16.255.10) 24.164 ms 24.108 ms 24.105 ms 10 * * * [EMAIL PROTECTED] /]# traceroute www.att.net traceroute: Warning: www.att.net has multiple addresses; using 204.127.166.135 traceroute to www.att.net (204.127.166.135), 30 hops max, 38 byte packets 1 (---.---.---.---) 2.404 ms 2.576 ms 2.389 ms 2 (---.---.---.---) 17.953 ms 18.170 ms 17.435 ms 3 500.pos2-1.gw10.chi2.alter.net (63.84.96.9) 18.077 ms * 18.628 ms 4 0.so-6-2-0.xl1.chi2.alter.net (152.63.69.170) 18.238 ms 18.321 ms 18.213 ms 5 0.so-6-1-0.BR6.CHI2.ALTER.NET (152.63.64.49) 18.269 ms 18.396 ms 18.329 ms 6 204.255.169.146 (204.255.169.146) 19.231 ms 19.042 ms 18.982 ms 7 tbr2-p012702.cgcil.ip.att.net (12.122.11.209) 20.530 ms 20.542 ms 23.033 ms 8 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 26.904 ms 27.378 ms 27.320 ms 9 tbr1-cl2.sl9mo.ip.att.net (12.122.9.141) 27.194 ms 27.673 ms 26.677 ms 10 gbr1-p10.bgtmo.ip.att.net (12.122.4.69) 26.606 ms 28.026 ms 26.246 ms 11 12.122.248.250 (12.122.248.250) 27.296 ms 28.321 ms 28.997 ms 12 192.168.254.46 (192.168.254.46) 28.522 ms 30.111 ms 27.439 ms 13 * * * 14 * * *
Re: Did Wanadoo, French ISP, block access to SCO?
And by blackholing that IP they've also blackholed www.caldera.com, which is currently not a DDoS target but is also not respondig to requests. Rubens - Original Message - From: James Edwards [EMAIL PROTECTED] To: Sean Donelan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, February 01, 2004 7:20 PM Subject: Re: Did Wanadoo, French ISP, block access to SCO? Here is a view from the west coast, This is via Opentransit, which is my limited understanding of French indicates is owned/part of FranceTelecom: trace 216.250.128.12 Type escape sequence to abort. Tracing the route to www.sco.com (216.250.128.12) 1 P12-0.PALBB2.Palo-alto.opentransit.net (193.251.240.26) 0 msec 0 msec 0 msec 2 * * p5-0.IR1.PaloAlto-CA.us.xo.net (207.88.250.29) [AS 2828] !H From Pastourelle, via Opentransit: trace 216.250.128.12 Type escape sequence to abort. Tracing the route to www.sco.com (216.250.128.12) 1 P12-0.NYKCR3.New-york.opentransit.net (193.251.241.134) 144 msec 216 msec 212 msec 2 P7-0.NYKBB3.New-york.opentransit.net (193.251.241.242) 76 msec 76 msec 76 msec 3 * * *
Re: Did Wanadoo, French ISP, block access to SCO?
Just drop the www.sco.com DNS record, as they did... this particular worm goes after the URL, not the IP it usually had. nslookup www.sco.com *** can't find www.sco.com: Non-existent domain nslookup www.caldera.com Non-authoritative answer: Name:www.caldera.com Address: 216.250.128.12 Rubens - Original Message - From: [EMAIL PROTECTED] To: Rubens Kuhl Jr. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, February 01, 2004 9:09 PM Subject: Re: Did Wanadoo, French ISP, block access to SCO? On Sun, 01 Feb 2004 20:00:40 -0200, Rubens Kuhl Jr. [EMAIL PROTECTED] said: And by blackholing that IP they've also blackholed www.caldera.com, which is currently not a DDoS target but is also not respondig to requests. Umm,, I'll bite. If www.sco.com and www.caldera.com are on the same IP, how do you create a DDoS that wouldn't take out the Caldera site as well? A sheer-traffic DDoS will hurt both. A synflood will hurt both. The webserver that's listening on port 80 doesn't know which site is being connected to until it actually reads in the HTTP/1.1 headers and looks at the Host: tag - and if there's enough things arriving with 'Host: www.sco.com', it will require some *very* creative filtering/limiting to keep one website working while the other is down
Re: CIsco 7206VXR w/NPE-G1 Question
* The 7206VXR prior to the NPE-G1 could only do around 560Mbps per bus typically, due to PCI limitations. Which usually was not a problem with i-mix traffic or ddos-traffic, because pps limitation would hit sooner. * Compiled ACLs on 12.2S perform very well on NPE-G1s. I saw no mention of PXF on NPE-G1; it seemed the path 7200 would take after NSE-1. What happened ? interface but does use a lot of features (netflow, policing, NBAR, shaping, etc) with no performance hit. Features was indeed to focus of PXF, wasn't it ? Rubens
Re: CIsco 7206VXR w/NPE-G1 Question
No. While I was at my former employer, we took our edge ACL into the Juniper POC lab, and verified that an M40 stuffed full of OC48 linecards could sustain just over 85% of line rate with our edge ACL applied before sustaining packet loss; the POC lab engineers double checked and verified that there was nothing wrong with the test, that was simply the most the IPII processors could handle with that particularly hairy ACL. Was that in the limits of the FPC ? It seems it does, just checking out. Was this a test with smallest possible packets ? Do you remember aggregate pps being routed ? It seems you could hit some of the real IP2 pps limits with ACLs, which is definitively not 40 Mpps. In one test I saw it hitted top at 12.5 Mpps, but it may be due to hitting FPC limits. Other people tests showed something in the 20-25 Mpps range. Rubens
Re: Nachi/Welchia Aftermath
T( Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) T( Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with T( Sup2(A), Sup3(A/BXL) T( T( The 2948G-L3 and the 4908G-L3 I believe are Prefix/ASIC based. T( I believe the 3550-EMI is as well, but I'm not familiar with that T( equipment. T( T( Anyone know about the: Cisco Catalyst 3750 ? Nortel Passport 8600/1600 ? Nortel Passport 8600 is flow-based according to a description I saw once; it might have changed. As for the 3550-EMI real life experience as a 10/100 BT aggregation switch wasn't affected(CPU 5%) at all by rather aggressive scanning but did generate around 11 Mb/sec of ARP requests on all the 100Mb/sec ports in the same VLAN and totally killed connectivity to legacy equipment connected at 10 Mb/s ... Cisco Cat6k/Sup2+ has some throttling mechanisms that are worth testing to see if it also happens on that architeture. Rubens
Re: Nachi/Welchia Aftermath
Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Rubens - Original Message - From: [EMAIL PROTECTED] To: Brent Van Dussen [EMAIL PROTECTED] Cc: NANOG [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 9:46 PM Subject: Re: Nachi/Welchia Aftermath lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core -J On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of remaining infected hosts were rebooted and the worm removed itself. Network traffic has finally returned to normal. What kind of effects did everyone see from this devastating worm and what lessons did we learn for preventing network downtime in the future? -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Where do the Extreme and Juniper fit into this? Private and public answers to my question indicate that both Summit 48i and Black Diamond from Extreme are flow-based; Juniper doesn't make layer 3 switches, but their routers also do prefix-based forwarding; Cisco routers also do prefix-based forwarding at usual configurations. Also of notice, flow-based forwarding is not the only thing that makes a L3 device suffer at worm attacks. If a directly connected interface is an Ethernet (or any other medium that is not point to point), ARPing for a lot of new addresses per second can also do harm. Rubens - Original Message - From: [EMAIL PROTECTED] To: Brent Van Dussen [EMAIL PROTECTED] Cc: NANOG [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 9:46 PM Subject: Re: Nachi/Welchia Aftermath lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core
Re: sniffer/promisc detector
That is a battle that was lost at its beginning: the Ethernet 802.1d paradigm of don't know where to send the packet, send it to all ports, forget where to send packets every minute is the weak point. There are some common mistakes that sniffing kits do, that can be used to detect them (I think antisniff implements them all), but a better approach is to make to promisc mode of no gain unless the attacker compromises the switch also. In Cisco-world, the solution is called Private VLANs. Nortel/Bay used to have ports that could belong to more than one VLAN, probably every other swith vendor has its own non-IEEE 802 compliant way of making a switched network more secure. Rubens - Original Message - From: Gerald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 16, 2004 8:35 PM Subject: sniffer/promisc detector Subject says it all. Someone asked the other day here for sniffers. Any progress or suggestions for programs that detect cards in promisc mode or sniffing traffic? Gerald
Re: Good network sniffer?
According to this paper http://luca.ntop.org/Ring.pdf, you may be the lucky one, instead of unfortunate users of out-of-the-box *nix libpcap implementations. The good thing with open-source is the room to improve, as the solution presented on the paper shows. Rubens - Original Message - From: Sean McPherson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 5:56 PM Subject: Re: Good network sniffer? I'm amazed no one mentioned Etheral works just fine under Windows (well, at least it runs as well as any OTHER Windows software seems to, let's put it like that). I guess those of use lucky enough to use Linux/Unix/*BSD etc forget there are other, less fortunates out there :) You can install PCAP for Win32, as well as Ethereal for Win32. Try http://www.ethereal.com/distribution/win32/ Sean McPherson
Re: GSR, 7600, Juniper M?, oh my!
I'm faced with a difficult decision. I work for a large multi-node regional ISP (and Cisco shop). In our largest nodes we've found the Cisco 7500 series routers to be at the end of their useful life due to the throughput generated by POS OC-3 feeds and 10,000+ broadband users whose traffic needs to be moved out of the node. Short of building a farm of 7500's the need to upgrade seems clear. Will the interfaces likely continue to be POS OC-3 ? What is the growing path for this: POS OC-12, GigE ? But where to go? The Cisco GSR platform seems a logical choice, but their new 7600 series units are attractive for their cost. Juniper may also have a place at this end of the processing spectrum. I'd also like to ensure that the new platform supports doing CAR and ACLs at line rate, given the client base. The GSR line-cards to what you want would need to be the edge ones, based on either Engine 3 or Engine 4+. 7600 requires WAN cards to support POS, I think GSR and Juniper M are more likely candidates for this design. Rubens
Re: pon's and ethernet to the home
Having heard no answer, I will take a shot : I actually think that EPONs have a good chance to be the future method of distributing video from the cable provider to the home. As they are passive, it minimizes the amount of equipment out there. A May be not... all xPON systems have a wavelength window reserved for DWDM broadcast, that seems more suited to the task. 10-Gigabit Ethernet running multicast IP (probably with some form of packet tagging like MPLS) could more than support all of the video and data needs of a typical cable head-end customer base. EPON/IEEE 802.3ah is a 1-Gigabit system (actually a 1.25 Gbps but 20% is used by the 8B10B encoding); I haven't seen any spec for a 10-Gig PON; even recently standardized GPON is limited to 2.5 Gbps downlink, 1.25 Gbps uplink. You might look at alloptic as a equipment provider here http://www.alloptic.com/ Or http://www.alcatel.com/fttu http://www.flexlight-networks.com/ http://www.broadlight.com http://www.teknovus.com Rubens
Re: pon's and ethernet to the home
As far as I have understood, the idea is to use the fiber as it was coax, doing some kind of FDM (frequency division multiplexing) with the lambdas (somehow the same). This would give us the capability In the optics field it is usually called WDM (Wavelenght Division Multiplexing). to move at leat n x 10mbps ethernet on the same fiber using diferent lambdas for each customer, until power budget goes down. Nope; PON works by sharing the same channel among the users. There is a WDM use of the fiber only because the uplink and downlink use different wavelenghts, but the downlink is shared with TDM (Time Division Multiplexing) and the uplink with TDMA (TDM/Multiple Access). If the idea is correct, this would mean next jump on bandwidth. Who would be making this ethernet/lambda multiplexors right now? Is it feasible to do it today? or should we wait a little more? PONs are feasible today; the CO equipment is called OLT (Optical Line Terminator), and the CPE is a ONT/ONU (Optical Network Terminator/Unit). The only external device is a passive star coupler. Check out www.ponforum.org, www.fsanweb.org and www.efma.org I mean, there are solutions using packet over sonet or alike, but pure ethernet? PON has three flavors: APON/BPON, EPON (IEEE 802.3ah) and GPON. APON uses ATM framing, EPON uses Ethernet framing and GPON uses GFP (Generic Framing Protocol). GFP can also be used on top of SONET to make Ethernet-over-SONET, Rubens
Re: Web hijacking by router - a new method of advertisement by Belkin
May be they simply flag your router to not redirect to any web site, but the router still goes every x hours to their site to verify the current redirect status of your product. This wouldn't require admin privileges on your box to be done... but could make every router with such firmware DoS'able; just blackhole the Belkin site and every such request would need to timeout before the router resumes normal behaviour. Rubens - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 08, 2003 11:44 AM Subject: Re: Web hijacking by router - a new method of advertisement by Belkin In message [EMAIL PROTECTED], [EMAIL PROTECTED] an.net writes: Would be interesting to see if their current advertisement (every 8 hours) page would now be replaced with We're so sorry that you're seeing this page, please make sure to download our latest patch so your router never bother you again and would keep us out of legal trouble message... The Belkin posting reproduced on Slashdot indicates that when you unsubscribe via their Web page, it modifies the configuration of your router. Say, what? There are ways in which an external Web server can change things on my box? How is that secured? I can think of lots of bad answers to that question, and not very many good ones. --Steve Bellovin, http://www.research.att.com/~smb
Re: Openwave Opinions
Anyone have any openwave mail MX opinions or experience good or bad? Every mail product that costs lots of money will yield a worse overall solution that using a good free/open-source mail software (postfix, qmail, exim... pick one) and spending money on people with good technical skills to tune and adapt the system. Unless, of course, your financial resources are unlimited... Design question: Is it better to have integrated or seperate Anti-spam and Anti-virus built into the mail platform? There are some design mistakes (such as trying to do these time-consuming process synchronously) that both integrated and isolated anti-spam/virus solutions have shown... the interesting thing with separate solutions is that you can see the architeture from the configuration instructions, so someone can quickly tell if that solution will scale or not. Using monolithic or separate solutions will have some strategic consequences, but design issues can arise in both. Rubens
Re: Openwave Opinions
Every mail product that costs lots of money will yield a worse overall solution that using a good free/open-source mail software (postfix, qmail, exim... pick one) and spending money on people with good technical skills to tune and adapt the system. Unless, of course, your financial resources are unlimited... It is not just financial resources - it is also a factor of time to build a filter / set of filters from scratch (even with spamassasin + bogofilter you need to train it extensively, and tweak its rulesets to suit your mail flow). I think this part of question was referring only to MTAs, not MTA + anti-spam/virus tools. Anti-spam tuning is really a bit slower to do than general performance tuning (MTA or MTA + anti-virus), but this will be true to whatever MTA software and anti-spam one might buy. Sometimes outsourcing corporate / isp mail handling to a provider like us, criticalpath, postini etc might be a good way to go. Outsourcing is usually a good way to get a solution with expertise instead of a next-next-finish software installation and license to use it... but for ISP use, integration with internal OSS (billing, tech-support etc.) seems to be a challenge. Outsourcing costs also keeps most ISPs from using such a solution, unless time-to-market is the one and only criteria. Rubens
Cisco exploit and Huawei
It would be interesting to know if Huawei routers also falls to the Cisco IOS exploit... Rubens
Re: Cisco exploit and Huawei
As listed on the advisory, e-maiing [EMAIL PROTECTED] A show tech and the chassis S/N on the front mail will help expedite the process... Rubens - Original Message - From: Vincent Poy [EMAIL PROTECTED] To: Rubens Kuhl Jr. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 18, 2003 12:01 PM Subject: Re: Cisco exploit and Huawei | Speaking about the patches, how does one get the patches if they | don't have a support contract with Cisco? | | | Cheers, | Vince - [EMAIL PROTECTED] - Vice President __ | Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / [__ ] | WurldLink Corporation / / / / | / | __] ] | San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] | HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] | [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin |
Re: Backbone Infrastructure and Secrecy
Managing security perception can sometimes reduce security risks or the security TCO, by reducing the number of low-risk attackers. Die-hards will only stop for real security controls, but you may find easier to impose such controls without a lot of noise from your security alarms. The real issue is when you start believing that you are as safe as the sheep think you are. Rubens - Original Message - From: Peter Galbavy [EMAIL PROTECTED] To: E.B. Dreger [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:16 PM Subject: Re: Backbone Infrastructure and Secrecy | | E.B. Dreger wrote: | Perhaps some security measures have a different purpose -- as | you say, LOOKS great (emphasis added). | | Just like 99% of all recent airport security measures... reassure the sheep, | then they might stop bleating and march to order instead. Baauy | McDonalds, Bauy Gas, Bauy SUV. | | This is OT. Obviously. | | Peter | |
Re: NAT for an ISP
ISPs that provide RFC1918 space should also provide recursive DNS services that would stop all RFC1918 in-addrs before hitting root-servers and guidance to their users so they do the same on their servers if they don't forward requests to the ISP recursive resolver. Rubens - Original Message - From: William S. Duncanson [EMAIL PROTECTED] To: 'Christopher J. Wolff' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 5:45 PM Subject: RE: NAT for an ISP | | | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | My first hop beyond my border for my home connection is a 10-net | address. Provider is RoadRunner. So, yes, ISP's are using RFC1918 | space for access networks, which probably also has some bearing on | the recent thread regarding the frequency of attempted lookups of | RFC1918 in-addrs. | | - -- | William S. Duncanson[EMAIL PROTECTED] | The driving force behind the NC is the belief that the companies who | brought us things like Unix, relational databases, and Windows can | make an appliance that is inexpensive and easy to use if they choose | to do that. | - -- Scott Adams | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Christopher J. Wolff | Sent: Wednesday, June 04, 2003 14:52 | To: [EMAIL PROTECTED] | Subject: NAT for an ISP | | | | Hello, | | I would like to know if any service providers have built their | access networks out using private IP space. It certainly would | benefit the global IP pool but it may adversely affect users with | special | applications. At any rate, it sounds like good fodder for a | debate. | | Regards, | Christopher J. Wolff, VP CIO | Broadband Laboratories, Inc. | http://www.bblabs.com | | | | | -BEGIN PGP SIGNATURE- | Version: PGP 7.0.4 | | iQA/AwUBPt5aTfNxJ1tT9oUNEQLSuwCfRl2sFrhG2pcIHBzdFhx4HIGRtW4AnicE | s3gaDBd3H5XdBtSW6lW3otU+ | =qa/s | -END PGP SIGNATURE- |
Re: State Super-DMCA Too True
Probably because of blocking at the origin point, such as corporate net-mgrs trying to prevent bandwidth hogs or liability issues. Rubens - Original Message - From: Petri Helenius [EMAIL PROTECTED] To: Stephen Sprunk [EMAIL PROTECTED]; Jack Bates [EMAIL PROTECTED] Cc: Richard A Steenbergen [EMAIL PROTECTED]; Peter Galbavy [EMAIL PROTECTED]; Mike Lyon [EMAIL PROTECTED]; Simon Lyall [EMAIL PROTECTED]; Tony Rall [EMAIL PROTECTED]; North American Noise and Off-topic Gripes [EMAIL PROTECTED] Sent: Monday, March 31, 2003 6:08 PM Subject: Re: State Super-DMCA Too True | | Well, most p2p apps live on well-known ports, and Cisco's QOS mechanism | allows easy classification on ports. Yes, most of the p2p apps are | port-agile -- but only if they are completely blocked. My experience is | that if you let the p2p stuff through, it'll stick to its default port and | you can police with impunity. | | Our data shows that between 30% and 50% of p2p data flows on non-standard | ports if you run an unblocked environment. | | Pete |
Re: State Super-DMCA Too True
| If you price your product on the assumption that the average customer only | uses 5% of their bandwidth then it doesn't take many customers using 50% | or 100% of it to really spoil your economics. Turn this assumption a part of the service: place a monthly transfer limit of some gigabytes. This will also scare p2p heavy-users and leave you with the high-margin low-usage customers. | Banning NAT and servers is a simple way to filter out most of the power | users without scaring the mom and pop customers with bandwidth and | download quotas. NAT doesn't always imply simultaneous users. Many people use it for security, I personally use for a 2-computer network with my desktop and my notebook, but never use both at the same time... Rubens
Re: Cascading Failures Could Crash the Global Internet
BGP flap limiting may be correlated to this action... the good thing about packets is that they don't require energy to be dropped; electricity needs to be consumed somewhere, probably generating heat. Rubens - Original Message - From: N. Richard Solis [EMAIL PROTECTED] To: Sean Donelan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 7:09 PM Subject: Re: Cascading Failures Could Crash the Global Internet | I don't know of too many electrical distribution networks that use DC interconnection to limit AC failures from propogating. | | The main cause of AC disruption is a power plant getting out of phase with the rest of the power plants on the grid. When that happens, the plant trips of goes off-line to protect the entire grid. You lose some generating capacity but you dont fry everything on the network either. | | http://www.nerc.com/ | | There are some states that operate their own grids. Texas, for example. | | -Richard | | | Sean Donelan wrote: | | | | Sigh, there are differences between tightly coupled networks, such as | the electric power grid and loosely couple networks like the Internet. | But there are also some similarities, such as electric grids use DC | interconnections to limit how far AC disturbances propagate; the | Internet uses AS interconnections to limit IGP disturbances from | propagating. | | http://sci.newsfactor.com/perl/story/20686.html | | The actual article requires payment to read | http://ojps.aip.org/getabs/servlet/GetabsServlet?prog=normalid=PLEEE866 0606510201idtype=cvipsgifs=Yes | | |
Re: Shuttle Columbia - not necessarily nanog related
http://www.nasa.gov is responding fast, but home page has been simplified and only contain STS-107 Emergency Notice. http://spaceflight.nasa.gov seems to be suffering from the load. Rubens - Original Message - From: Darin Wayrynen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Darin Wayrynen [EMAIL PROTECTED] Sent: Saturday, February 01, 2003 12:42 PM Subject: Shuttle Columbia - not necessarily nanog related | | | The Space Shuttle Columbia seems to have broken up during re-entry | over Texas. | | You might need to check your connections to the major news sources and | NASA as your users start looking for information. | | :-( | | Darin | | |
Re: Bell Labs or Microsoft security?
Any opinion on Inferno ? It seems more suited to build a packet-eating-machine (router, firewall, vpn, choose your favorite flavour)... Rubens Kuhl Jr. - Original Message - From: Vadim Antonov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 12:14 AM Subject: Re: Bell Labs or Microsoft security? | | | On Thu, 30 Jan 2003, Daniel Karrenberg wrote: | | PPS: Plan 9 anyone? | | Anything but _THAT_! At some period of my life I was paid to make | something resembling production system out of Plan 9... it has all the | quality features of v6 Unix, and looks like some student's course project. | There were some interesting ideas, but the coding style was totally | atrocious. Like, fixed size tables everywhere (oh, you run out of 100 | open files, t bd), little charmers like TCP ACKs being sent in | 20ms timer call-backs (so it works awfully great over 100Mbps ethernet :), | text-based interfaces requiring padding with spaces to some fixed-length | strings, and a zillion other quick hacks. | | You are in a maze or little twisting cross-mounts, all alike :) | | To summarize original Unix design coding style very very concisely: | | % ed | s/a/b/ | ? | | That ? says all. As a matter of fact, 30 years later ed still says ?. | | --vadim |
Re: mSQL Attack/Peering/OBGP/Optical exchange
- Original Message - | One other considerations is that optical IXs will have a greater | impact on the internet, possibly good and bad. With larger circuit | sizes of OC48 and OC192 for peering. An attack would have a greater | ability to flood more traffic. A failure of a peering session here | would cause a reroute of greater traffic. A possible benfit might be | that larger circuit sizes might mean that an attack might not be able | to overwhelm the larger capacities especially if backbone sizes are | the constricting factor, not peering circuits or optical VPN circuits | at the optical IX. Although this MS-SQL worm used a lot of bandwidth because of the embedded exploit code, usually worms scan first and try exploiting after. Such scan requires few bytes, so even a T-3 would carry a lot of host scans per second, and could case many routers to die on the receiving end because of packets-per-second or news-arps-per-second or syslogs-per-second limitations. I think the worst danger of large circuits would be the uplink capacity; a bunch of infected hosts would easily fill up a T-3 trying to scan for new hosts to attack, limiting the worm propagations speed, but an OC-192 might end up carrying all of the scan traffic and infect more hosts faster. Rubens
Re: uunet
Someone might read this as inflation of customer base numbers... has this company been involved in scandals recently ? :-) Rubens - Original Message - From: Vadim Antonov [EMAIL PROTECTED] To: Scott Granados [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 10:36 PM Subject: Re: uunet | | | I have a suggestion for UUNET's backbone engineering folks: | | Please, create a fake customer ID and publish it, so outside folks could | file trouble reports regarding routing issues within UUNET. | | --vadim | | | On Sat, 18 Jan 2003, Scott Granados wrote: | | | What's interesting is that I just tried to call the noc and was told | We have to have you e-mail the group | | my response, I can't I have no route working to uunet | | Well you have to | | my response, ok I'll use someone elses mail box where do I mail? | | We can't tell you your not a customer | | My response its a routing issue do you have somewhere I can e-mail you. | | Your not my customer I really don't care *click* | | Nice. professional too. | | Anyone have a number to the noc that someone with clue might answer? | | - Original Message - | From: David Diaz [EMAIL PROTECTED] | To: Scott Granados [EMAIL PROTECTED]; [EMAIL PROTECTED] | Sent: Saturday, January 18, 2003 4:35 PM | Subject: Re: uunet | | | Im not seeing anything coming from qwest. | | | | At 16:55 -0800 1/18/03, Scott Granados wrote: | Is something up on uunet tonight? | | It looks to me that dns is broken forward and reverse but more likely it | looks like a bad bogan fiilter popped up suddenly. I have issue as soon | as | I leave mfn's network and hit uunet. | | -- | | David Diaz | [EMAIL PROTECTED] [Email] | [EMAIL PROTECTED] [Pager] | www.smoton.net [Peering Site under development] | Smotons (Smart Photons) trump dumb photons | | | | |
Re: DC power versus AC power
| Not to mention additional cost of wasted electricity (which does add up | significantly when it is anything but a spot solution) and pitfalls of | inverters (like their imperfect sine waves). And if you're putting spot | solution UPS units out into the bottom of a particular rack, be ware their | canny ability to catch fire when the price is right. Switched power supplies really don't care about the quality of the sine waves that feeds them, as long as they have energy to put into the tank. On the other hand, video monitors like sine waves, and they may not get along with DC inverters/rectifiers (or even portable AC no-breaks, which usually generates AC from DC). Rubens Kuhl Jr.
Re: Cisco IOS EIGRP Network DoS
And including the SSH bug that also has been published today(http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml.), it seems that a lot of networks will have a very happy xmas. - Original Message - From: James-lists [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 6:50 PM Subject: Cisco IOS EIGRP Network DoS | | - Original Message - | From: FX [EMAIL PROTECTED] | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Sent: Thursday, December 19, 2002 10:06 AM | Subject: Cisco IOS EIGRP Network DoS | | | Hi there, | | please find attached an advisory about an issue with the Cisco IOS | Enhanced | IGRP implementation that can be used to cause a network segment wide | denial of | service condition. | | Regards | FX | | -- | FX [EMAIL PROTECTED] |Phenoelit (http://www.phenoelit.de) | 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564 | | Attached text moved here: | | | Phenoelit Advisory wir-haben-auch-mal-was-gefunden #0815 +++- | | [ Title ] | Cisco Systems IOS EIGRP Network Denial of Service | | [ Authors ] | FX [EMAIL PROTECTED] | | Phenoelit Group (http://www.phenoelit.de) | Advisory http://www.phenoelit.de/stuff/CiscoEIGRP.txt | | [ Affected Products ] | Cisco IOS | | Tested on: IOS 11.3 |IOS 12.0(19) |IOS 12.2 | | Cisco Bug ID: not assigned | CERT Vu ID: not assinged | | [ Vendor communication ] | 10/08/02Initial Notification, |[EMAIL PROTECTED] | 10/08/02 | - | 11/14/02 Communication with [EMAIL PROTECTED] about the issue, |fixes and timelines. | 12/18/02 Final advisory going public as coordinated release | *Note-Initial notification by phenoelit | includes a cc to [EMAIL PROTECTED] by default | | [ Overview ] | Cisco Systems IOS is vulnerable to a denial-of-service attack using | Cisco's proprietary routing protocol Enhanced IGRP (EIGRP). When | flooding a Cisco router with spoofed EIGRP neighbor announcements, | the router will cause an Address Resultion Protocol (ARP) storm on | the network segment while trying to find the MAC addresses for the | newly discovered neighbors, effectively using all available bandwidth. | | [ Description ] | EIGRP uses automatic discovery of neighboring routers. An EIGRP router | announces it's existence via multicast on the enabled interfaces. If | two routers discover each other, they try to exchange information | about the current topology in unicast. On Ethernet, both sides need | to obtain the MAC address of the other router. | | When generating EIGRP neighbor announcements with random source IP | addresses and flooding a Cisco router (unicast, only possible in 11.x) | or an entire network (multicast), all receiving Cisco routers will try | to contact the sender(s). The source IP addresses have to be in the | subnet(s) enabled via the network statement in the config of the | victim router. | | A bug in Cisco IOS causes the router to continiously try to obtain the | MAC address of the sender. This process does not time out unless the | EIGRP neighbor holdtimer expires. This value is supplied by the sender | of the neighbor announcement and has a maximum of over 18 hours. | | Multiple neighbor announcements with not existing source IP addresses | will cause the router to use all available CPU power and bandwidth on | the segment for ARP request - creating a segment-wide denial of | service condition. | | The possible use of IP multicast poses a high risk for larger | corporate networks using EIGRP. Cisco IOS versions below 12.0 also | accept EIGRP neighbor announcements as unicast packets, which makes | the attack possible via the Internet. | | [ Example ] | None provided at this time. | | [ Solution ] | Implement EIGRP authentication using MD5 hashes - which should have | been done in the first place. Where MD5 can not be implemented, use | extended access lists to match expected neighbors. | | The obvious workaround of using fixed neighbor entries in the | configuration does not work due to another bug in IOS that makes it | ignore the command (Cisco Bug ID CSCdv19648). | | [ end of file ($Revision: 1.5 $) ] | | | Cisco comments on Bug traq: | | -BEGIN PGP SIGNED MESSAGE- | | We can confirm the statement made by FX from Phenoelit in his message | Cisco IOS EIGRP Network DoS posted on 2002-Dec-19. The EIGRP | implementation in all versions of IOS is vulnerable to a denial of | service if it receives a flood of neighbor announcements. EIGRP is a | Ciscos' extension of IGP routing protocol used to propagate routing | information in internal network environments. | | The workaround for this issue is to apply MD5 authentication that will | permit the receipt of EIGRP packets only from authorized hosts. | You can find an example of how to configure MD5 authentication for | EIGRP at the following URL (possibly wrapped): |
Re: Arbor Networks DoS defense product
| The attacks I have been able to detect represent around | 10-15% of my traffic on an on-going basis. | | I'm curious about the business case for investing in DoS | defense mechanisms. DoS traffic is boosting service provider | revenues through increased customer bandwidth usage. So the If and when (a) customers don't get exemption for attack traffic (b) the DoS traffic occurs more than 5% (or 1 - your percentile level) of the month per customer circuit (c) the DoS increases bytes transferred like large ICMP packet flood; this is not the case for all DoS traffic, which can be a bunch of small packets that actually decreases traffic | investment in defense mechanisms like Arbor would have to | replace or increase that revenue. Will these issues inhibit | wide-spread implementation of DoS defenses? I think a network that profits from client suffering doesn't keep its contracts for much time. Rubens Kuhl Jr.
Re: Effective ways to deal with DDoS attacks?
Do you mind sharing with us the 4 things that exists only in DoS packets ? Rubens Kuhl Jr. - Original Message - They CAN filter on anything in the headers, it's just a matter of convincing them that the specific filter you want is something they should add to their software language and microcode. I'm sure as a core router vendor they must hear every feature request imaginable and not know which ones to follow up on. If anyone from Juniper is listening, I can tell you 4 things to add which will stop all existing packet kiddie tools in their tracks. But then again, I'd rather just have a language for bitmatching at any offset. :)
