RE: Yahoo offline because of attack (was: Yahoo network outage)
Okay, but you've still missed the point. Even if I stipulate everything you said here, that's still 50 largish systems that are compromised. I would almost wager that the perpetrators didn't use all of their assets either. That's a shit-load of large compromised systems on the Internet. Doesn't that thought worry you in the slightest?
It worries everyone! Dave Dittrich in his analyses of DDOS tools (available from http://www.washington.edu/People/dad/) suggests: "Trinoo networks are probably being set up on hundreds, perhaps thousands, of systems on the Internet that are being compromised by remote buffer overrun exploitation. Access to these systems is probably being perpetuated by the installation of multiple "back doors" along with the trinoo daemons." CERT suggests (http://www.cert.org/incident_notes/IN-99-07.html) Prevent installation of distributed attack tools on your systems Prevent origination of IP packets with spoofed source addresses Monitor your network for signatures of distributed attack tools Should we as network operators be taking a pro-active role to police our users for DDOS running boxen? It seems to me that educating end-users is the problem here, just as educating people to use 'no ip directed-broadcast' was back in 1997. Phil Sykes, Network Engineer Cable & Wireless Europe p: +49 89 92699 204 m: +49 172 89 79 727
CERT suggests (http://www.cert.org/incident_notes/IN-99-07.html)
Prevent installation of distributed attack tools on your systems Prevent origination of IP packets with spoofed source addresses Monitor your network for signatures of distributed attack tools
That sounds like good things to do. Others have pointed to RFC 2267 which is somewhat the same. However, it doesn't seem that we're doing all that well on actually following up those suggestions? As if that isn't enough, may I also draw your collective attention to draft-ietf-grip-isp-expectations-03.txt How are we collectively doing on following up on those points? During this discussion I've seen some claim that the recent attacks were not being carried out using spoofed source IP addresses. That may be so, but still is not a valid argument for not protecting the network from source address spoofing and the effects thereof.
Should we as network operators be taking a pro-active role to police our users for DDOS running boxen?
Sounds like a good idea. However, is it a sufficiently good idea so that a sufficient number of people actually find the time to do something about it?
It seems to me that educating end-users is the problem here, just as educating people to use 'no ip directed-broadcast' was back in 1997.
Well, according to the list on http://www.powertech.no/smurf/ we're not done on that front by a long shot: 114951 networks have been probed with the SAR 19589 of them are currently broken 14682 have been fixed after being listed here May I suggest that we all get off our collective butts and do something about these items? Even by going so far as to proactively probe our customer networks and/or extracting info from the list available from the above site? Or are we once again going to hear the knee-jerk and IMHO irresponsible reaction from some ISPs (no, I don't have any particular in mind -- you know who you are) that essentially says "more packets on our networks means more business for us"? Another common claim seems to be "this is none of our business". IMHO not a very responsible reaction that either... Best regards, - Håvard
On Wed, Feb 09, 2000 at 12:02:42PM +0100, Havard.Eidnes@runit.sintef.no wrote:
May I suggest that we all get off our collective butts and do something about these items? Even by going so far as to proactively probe our customer networks and/or extracting info from the list available from the above site?
... and actively use the logs to contact peers when they're used as amplifiers against you, rather than just filtering? Does anyone have a CIDR to broadcast address script handy? (the network address is part of the CIDR format :-) -- John Payne jcapayne@att.com OpenNet Infrastructure Team, AT&T Global Network Services Mailpt C2E, c/o IBM North Harbour, PO Box 41 Portsmouth, PO6 3AU Tel - +44 (0)23 9256 1977, Fax - 23 9221 0543
On Wed, Feb 09, 2000 at 11:17:34AM +0000, John Payne wrote:
On Wed, Feb 09, 2000 at 12:02:42PM +0100, Havard.Eidnes@runit.sintef.no wrote:
May I suggest that we all get off our collective butts and do something about these items? Even by going so far as to proactively probe our customer networks and/or extracting info from the list available from the above site?
... and actively use the logs to contact peers when they're used as amplifiers against you, rather than just filtering?
Actually I had some ideas for a fairly interesting method to fight smurf attacks directly while being attacked without causing further disruption on anyone's network (just need time to finish writing it), and of course more granular information about the attackers (complete list of broadcasts unsed in an attack, the ability to track multiple attacks simultaniously for use in a span port environment, information for amount of bandwidth seen from each broadcast sorted by worst-attacker, etc) would be a part of that.
Does anyone have a CIDR to broadcast address script handy? (the network address is part of the CIDR format :-)
Yes, I used to do a fairly large smurf amplifier scanning and emailing operation back in the day (infact a lot of the netscan.org stuff was directly based off of it). Code was never (and will never) be distributed because of potential for abuse, but my scanner was quite fast (the only way to improve speeds would be to throw much more cpu/boxes at it or do some kernel land work). Almost all of this proactive work has stopped since smurf ceased to be such a "huge" problem in itself. But, depending on the size and design of your network, at least one or more of the following should be considered: #1 filter your damn customers so they can't spoof out (I really can't stress this enough, particularly if you are an educational institution with a large dorm resnet! DO IT!), "ip verify unicast reverse-path" #2 rate-limit ICMP echo/echo-replys at ingress and egress points #3 filter/rate-limit ICMP 8/0 to the most obvious natural mask broadcast addresses (.0 and .255) both ingress and egress And one of the more interesting ones... With the high packet/sec syn/ack floods, the kids have realized that attacking the upstream routers is often far more effective then a well protected downstream. All it takes is pegging the CPU (against Cisco's this isnt very hard, even GRPs fall over at extremely low (realtively speaking) rates against closed ports or under high volumes of UDP attacks) until BGP falls over and suddenly victim A is off the air (*). Consider numbering your core loopbacks and link /30s out of a single block which can then be filtered/rate-limited at network borders. * As an interesting side note, the "best" and "worst" devices in this area... The Foundry gear, in particular the BigIron series (mgmt3 card is nice), has the highest survivability rate for a layer 3 device dealing with not only attacks through it but against the box itself, that I have yet seen. The worst seems to be the Cabletron SSR series, which does switching based on src ip/port dst ip/port combinations, and can only program new flows into the ASIC at a rate of about 3000 per second. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - ISX Network Engineer, Vienna VA
On Wed, 9 Feb 2000 Havard.Eidnes@runit.sintef.no wrote:
http://www.powertech.no/smurf/
we're not done on that front by a long shot:
114951 networks have been probed with the SAR 19589 of them are currently broken 14682 have been fixed after being listed here
I had a look though this site. Problems would appear to be that no new networks have been added for several months, the ASN lookup has not been done for over a year and regular re-checks of the list do not appear to happen. I went though networks listed for ourseleves and out customers and found only one out of a dozen was still open ( the ISP with that network has been contacted ). Yesterday I setup an auto-recheck of all the networks listed (oldest first) but at one-per-minute this is going to take a couple of weeks. Out of 780 networks tested so far only 290 are still open. I have also emailed the owner to query about current status of the project. The www.netscan.org people say they are going to be another week before their list is up. In the meantime I have grepped out the AS's with the most open networks on the powertech list here: 719 AS701 570 AS174 482 AS3561 458 AS1239 396 AS7018 292 AS1270 247 AS3301 224 AS1 199 AS2914 187 AS1785 172 AS3292 164 AS5617 154 AS3215 150 AS2551 133 AS6347 128 AS568 124 AS3352 123 AS1890 117 AS2548 111 AS3303 110 AS3320 110 AS2856 107 AS3257 107 AS1221 100 AS3336 99 AS517 99 AS1257 85 AS3269 82 AS2116 81 AS5676 80 AS559 79 AS3909 78 AS2871 77 AS1290 76 AS7570 75 AS2150 74 AS5673 74 AS1717 70 AS1103 62 AS1267 61 AS2493 60 AS5089 60 AS1249 59 AS3242 59 AS3216 -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz System/Network Admin | T&C Enforcement | Home: simon@darkmere.gen.nz The Internet Group, Auck. | Asst Doorman | Web: http://www.darkmere.gen.nz
On Sat, 12 Feb 2000, Simon Lyall <simon.lyall@ihug.co.nz> wrote:
I have also emailed the owner to query about current status of the project. The www.netscan.org people say they are going to be another week before their list is up. In the meantime I have grepped out the AS's with
An update - at the current rate we'll be done on Saturday and will be integrating it with the CGIs for release next week. Results are a lot more promising than the first time we scanned, but there's still tens of thousands of amps. I don't have an exact count handy, but I'll post a summary on Monday. We plan to spend a month or two emailing netblock contacts and working with backbones who want to use the data as a filter list. It's fairly likely the whole list will be released in that timeframe, too. This incarnation of the broadcast scanner is much faster and the architecture is cleaner, so we'll be able to keep it more up-to-date. The current plan is monthly rescans and emails. Feel free to email sysop@netscan.org (from your ARIN/RIPE/APNIC/other contact or some verifiable admin address) with a list of netblocks you administer, in the format: 1.2.3.4/24 4.1.128.0/16 4.2.64/17 etc. We've automated checking data sets like that against the amp database, so it's just a matter of waiting for the new scan to finish. We're debating whether to enable searches by class B and/or announcements from a given AS. Cheers, Troy
participants (6)
-
Havard.Eidnes＠runit.sintef.no -
John Payne -
Richard Steenbergen -
Simon Lyall -
Sykes, Phil -
Troy Davis