- Test - lists.nanog.org

Re: Is there a line of defense against Distributed Reflective attacks?
by Steven M. Bellovin 19 Jan '03

19 Jan '03

In message <20030117062954.GK61038(a)lcs.mit.edu>, "David G. Andersen" writes: > >On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed: >> >> b) Ioannidis and Bellovin proposed a mechanism called "Pushback" >> for automatically establishing router-based rate limits to >> staunch packet flows during DoS attacks. >> [NDSS 2002, "Implementing Pushback: Router-Based Defense >> Against DDoS Attacks"] > > I should have been a bit more accurate here. The proposal for >pushback is actually earlier than the implementation paper I cited above: > > "Controlling High Bandwidth Aggregates in the Network. Ratul Mahajan, > Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott > Shenker. July, 2001." > >and it also included an internet-draft: > > http://www.aciri.org/floyd/papers/draft-floyd-pushback-messages-00.txt > >I believe that Steve Bellovin gave a talk about it at NANOG 21: > > http://www.research.att.com/~smb/talks/pushback-nanog.pdf Here are the citations to the published papers: # Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth Aggregates in the Network, Computer Communications Review 32:3, July 2002, pp. 62-73. http://www.research.att.com/~smb/papers/pushback-CCR.ps # John Ioannidis and Steven M. Bellovin, "Implementing Pushback: Router-Based Defense Against DDoS Attacks", NDSS, February 2002. http://www.research.att.com/~smb/papers/pushback-impl.ps The publication dates notwithstanding, Mahajan et al. came first. As for the I-D -- we haven't had the cycles to work on it. There's reason to hope that activity will pick up. Re: I'm not sure its all that practical. I don't see that its helpful if it turns off services 'automatically' In theory, it doesn't turn off the service to all comers; it turns off the service along pipes from which the attack is coming. Just how good a job it will do at stopping collateral damage will depend on how far back there are pushback-enabled routers. If an ISP deployed it, but didn't speak pushback to its neighbors, clients on that same ISP's network should be able to access the service, as could peers who weren't the source of the garbage. But if some peer is sending an OC-12's worth of DDoS packets -- yes, all clients (or transit users) of that peer would be shut out. ICMP traceback is the subject of the IETF itrace working group. draft-ietf-itrace-03.txt just came out yesterday. The SPIE hash-based traceback is a much cooler idea, but it has some practical limitations, including the need to do the trace in more or less real-time (once the hash table fills up, it becomes useless), and the need for very large amounts of very fast memory on the tracing routers. There was an IETF BoF on it, but the folks behind it haven't been pushing it much. (Randy, do you know the status of it?) Both itrace and hash-based trace have some technical issues. itrace can handle only DoS-type attacks, since it's statistical in nature; hash-based traceback can, in theory, trace a single packet. But the real problem with either idea is this: suppose that you know, unambiguously and unequivocally, that 750 zombies are attacking you. What do you do with that information? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

3 2

Merits of purpose-built (appliance) vs. FreeBSD+ipfw firewalls
by Josh Brooks 19 Jan '03

19 Jan '03

I am looking for comments and suggestions regarding the merits of purpose-built, appliance style firewalls (like a netscreen or Cisco PIX) vs. running ipfw on a commodity server running FreeBSD. I am interested only in packet filtering and rate limiting performance - NOT in VPNs or IPsec/crypto considerations. --- Currently, I run a FreeBSD firewall running ipfw (500 mhz celeron, 256 mags ram). This machine does nothing - runs no services but ssh, and simply sits at my network border doing packet filtering. I have a lot of hosts (four /24s - about 500 active IPs) behind this firewall, and generally push 5-7 megabits/s. Sometimes it can go as high as 12. The point is, the box is always fine and I am happy with it. Recently I have started getting more and more DoS and DDoS attacks. They range from very simple syn floods to ICMP echo floods to very odd UDP floods. The problem I am running into is simply that my firewall CPU chokes. It is not because the traffic is high - the line does not become saturdated, and sometimes total traffic can be less than 5 megabits/s - BUT the packets/s count goes way up (sometimes by a factor of 50) and because all of these packets have to go through my entire ruleset, the firewalls CPU chokes. It does not crash, it simply stops forwarding any traffic, effectively blackholing my entire network. As soon as the attack is stopped, the firewall is fine. --- I have responded by doing a ton of research, testing, reading ... and so on. Blocking obviously bad packets, rate limiting ICMP echo responses, rate limiting TCP RSTs - I admit I have a long way to go before I exhaust the bags of tricks that people have to improve their FreeBSD+ipfw firewalls. But every time I improve the ruleset, something new comes along - something that gets through the nets and once again, I have some weird attack at 12-15K packets/second traversing all 400 of my firewall rules (because they don't match anything until the end when they are allowed through) and choking my firewall up. It is very frustrating because the attacks are small in terms of bandwidth - never more than 10 megabits/s. It is simply too many packets/s and not a sophisticated enough ruleset to keep the high-rate garbage from traversing every rule. --- So my questions are as follows: 1. Am I wasting my time trying to make my FreeBSD+ipfw firewall more resilient and sophisticated ? Again, I have probably only scratched the surface, but let's say I emerge from my office 12 months from now having memorized the ipfw source code and having learned _everything_ there is to learn about this problem - will I simply conclude that FreeBSD+ipfw is not good enough and I just need to go get an appliance ? 2. I happen to like a host-based firewall (a firewall running on a normal user OS like FreeBSD) better than an appliance. You get to do anything you need with it, you have a full compliment of unix tools like grep and awk and tcpdump and expect, etc. - it seems like you have more control. Assuming (for a moment) that performance were equal, does anyone else feel this way ? Does anyone else prefer a normal system for a firewall over, say, a PIX ? 3. I am not that high profile ... but what do the high profile (shell servers like foonet and EFnet irc server operators) people use ? Would any of those people consider even for a moment using a FreeBSD+ipfw system for their packet filtering and rate shaping ? I just want to know if I should give up now and shell out a few grand for an appliance, or if it is reasonable for me to attempt to protect a network of my size. Thank you very much.

12 14

The Cidr Report
by cidr-report＠potaroo.net 18 Jan '03

18 Jan '03

This report has been generated at Fri Jan 17 21:50:49 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-01-03 118118 85265 11-01-03 118137 85264 12-01-03 118098 85311 13-01-03 118022 85338 14-01-03 118150 85261 15-01-03 118309 85199 16-01-03 118188 85195 17-01-03 118250 85247 AS Summary 14387 Number of ASes in routing system 5650 Number of ASes announcing only one prefix 1586 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73080832 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Jan03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 118475 85309 33166 28.0% All ASes AS3908 1187 693 494 41.6% SUPERNETASBLK SuperNet, Inc. AS18566 430 5 425 98.8% COVAD Covad Communications AS701 1586 1176 410 25.9% ALTERNET-AS UUNET Technologies, Inc. AS7018 1442 1043 399 27.7% ATT-INTERNET4 AT&T WorldNet Services AS4323 532 189 343 64.5% TW-COMM Time Warner Communications, Inc. AS7843 609 267 342 56.2% ADELPHIA-AS Adelphia Corp. AS6197 464 151 313 67.5% BATI-ATL BellSouth Network Solutions, Inc AS1221 1137 839 298 26.2% ASN-TELSTRA Telstra Pty Ltd AS1239 963 679 284 29.5% SPRINTLINK Sprint AS6347 366 85 281 76.8% DIAMOND SAVVIS Communications Corporation AS4355 408 133 275 67.4% ERMS-EARTHLNK EARTHLINK, INC AS4151 329 58 271 82.4% USDA-1 USDA AS7046 550 282 268 48.7% UUNET-CUSTOMER UUNET Technologies, Inc. AS22927 283 22 261 92.2% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 426 186 240 56.3% ASN-ALTERNET UUNET Technologies, Inc. AS4814 251 15 236 94.0% CHINANET-BEIJING-AP China Telecom (Group) AS6198 426 202 224 52.6% BATI-MIA BellSouth Network Solutions, Inc AS1 654 433 221 33.8% GNTY-1 Genuity AS17676 225 26 199 88.4% GIGAINFRA XTAGE CORPORATION AS22291 227 29 198 87.2% CHARTER-LA Charter Communications AS690 521 326 195 37.4% MERIT-AS-27 Merit Network Inc. AS6140 319 126 193 60.5% IMPSAT-USA ImpSat AS209 517 329 188 36.4% ASN-QWEST Qwest AS4134 296 112 184 62.2% ERX-CHINALINK Data Communications Bureau AS2048 260 86 174 66.9% LANET-1 State of Louisiana AS2386 410 243 167 40.7% INS-AS AT&T Data Communications Services AS852 608 446 162 26.6% ASN852 Telus Advanced Communications AS6327 185 34 151 81.6% SHAWFIBER Shaw Fiberlink Limited AS11492 297 155 142 47.8% CABLEONE CABLE ONE AS3215 314 174 140 44.6% AS3215 France Telecom Transpac Total 16222 8544 7678 47.3% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

4 3

OT: Network Operator Humor
by Jeremy T. Bouse 17 Jan '03

17 Jan '03

Just had a co-worker pass this one one to me and thought some might find the humor in it as well... http://www.dude.ru/music/gigflapping.html

2 1

Re: Is there a line of defense against Distributed Reflective attacks?
by Mike Hogsett 17 Jan '03

17 Jan '03

> > Getting everyone to take security more seriously will most likely never > > going to happen.. :( > > If this is the case then we are screwed... I hope its not the case, I hope > that the customer service folks at ISP/NSP's and NOC and Engineering folks > all keep this in their minds and push their upper management to start > doing the right thing. It really doesn't cost that much, and its certainly > cheaper than the cost of outages or lost revenue when your business is > DoS'd, eh? When the insurrance companies get involved and charge a larger premium to corporations not implementing reasonable security policies and procedures then the situation will improve. Time and time again I have seen corporations do nothing about a problem (physical safety, physical security, network security) until it hurts the bottom line. Also, a large profile (e.g. in the mainstream media) network security incident against a large corporation would again bring attention to the problem. I think that if a network security incident had brought Enron to its knees, rather than questionable accounting, people would be taking more notice of the problem. - Michael Hogsett

1 0

Re: [Re: Less than 2% of computer attacks on military are successful]
by Joshua Smith 17 Jan '03

17 Jan '03

Randy Bush <randy(a)psg.com> wrote: > > > After last weeks spam run on Iraq, the US military and NIPC are > > concerned Iraq might be behind a rise in electronic attacks > > against government and military networks. > > and we are supposed to have sympathy for those who struck the first > blow? rofl! > > randy > of course we are - to not do so is an open invitiation to be picked up for sedition......... and yes, jnull, it is cynical friday ;) joshua "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

As-Path filtering based on ranges, not regex
by Vincent Gillet 17 Jan '03

17 Jan '03

Hi, I would like to filter bgp updates based on AS origin. I know that i can match origin with regex as : _1239$ In fact, i would like to match as-path that originate from ASes from 856 to 1239. pseudo regex would be something like : _[856..1239]$ Juniper has this feature. Cisco does not AFAIK. Purpose is try matching AS originated from Ripe/Apnic blocks. The only way to do that would be to use many as-path that match each digits :-(( This is the way i already do to match bogus ASes : ip as-path access-list 150 permit _(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9])_ ip as-path access-list 150 permit _(65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])_ This is not very nice. For Juniper : as-path PRIVATE-DENY ".* (64512-65535) .*"; This is much clearer. Does anybody heard about "as-range" feature on Cisco box ? Thanks Vincent.

3 2

Less than 2% of computer attacks on military are successful
by Sean Donelan 17 Jan '03

17 Jan '03

After last weeks spam run on Iraq, the US military and NIPC are concerned Iraq might be behind a rise in electronic attacks against government and military networks. The assessment said recent computer disruptions have included Web defacements, "denial of service" attacks that can disrupt or paralyze a network, and hacking "probes" and "scans" aimed at testing the vulnerability of a network. But the article also says less than 2% of the "attacks" resulted in a successful intrusion. http://www.nytimes.com/2003/01/17/technology/17HACK.html

5 4

FYI: Anyone seen this?
by blitz 17 Jan '03

17 Jan '03

From ISN: >http://www.theregister.co.uk/content/6/28842.html > >By Andrew Orlowski in San Francisco >Posted: 14/01/2003 > >The RIAA is preparing to infect MP3 files in order to audit and >eventually disable file swapping, according to a startling claim by >hacker group Gobbles. In a posting to the Bugtraq mailing list, >Gobbles himself claims to have offered his code to the RIAA, creating >a monitoring "hydra". > >"Several months ago, GOBBLES Security was recruited by the RIAA >(riaa.org) to invent, create, and finally deploy the future of >antipiracy tools. We focused on creating virii/worm hybrids to infect >and spread over p2p nets," writes Gobbles. > >"Until we became RIAA contracters [sic], the best they could do was to >passively monitor traffic. Our contributions to the RIAA have given >them the power to actively control the majority of hosts using these >networks." > >Gobbles claims that when a peer to peer host is infected, it catalogs >media and sends the information "back to the RIAA headquarters >(through specifically crafter requests over the p2p networks) where it >is added to their records", and also propagates the exploit to other >nodes. > >"Our software worked better than even we hoped, and current reports >indicate that nearly 95% of all p2p-participating hosts are now >infected with the software that we developed for the RIAA." > >The "hydra" is uncorroborated. > >Gobbles attached two pieces of code, one of which jinglebellz.c >details a frame header exploit for the Linux player mpg123. The code >chastises OpenBSD lead Theo de Raadt for failing to checksum the >public MP3s (written to celebrate each OpenBSD release). The group has >singled out OpenBSD in its previous exploits > >In their presentation to last year's DefCon, the group described >itself as "the largest active nonprofit security group in existence >(that favors full disclosure)," consisting of 17+ members. > >"They're real, and they're damn good. They have made what appeared to >be extremely exaggerated claims in the past, and when mocked, they >have demonstrated that they are serious," one security expert familiar >with their work, who declined to be named, told The Register. > >"He's a funny guy," De Raadt told us. "This is a buffer overflow >exploit," he confirmed. De Raadt said he was more concerned by social >engineering than by external exploits. "We had Fluffy Bunny, now we >have Gobbles. They come in waves. " > >An exploit of this nature is of dubious legality, right now, but >language in Howard Berman's "P2P Piracy Prevention" bill last year >legitimizing such exploits was backed by RIAA chief Hilary Rosen:- > >The Berman bill, ensured a copyright owner would not be liable for >"disabling, interfering with, blocking, diverting, or otherwise >impairing the unauthorized distribution, display, performance, or >reproduction of his or her copyrighted work on a publicly accessible >peer-to-peer file trading network, if such impairment does not, >without authorization, alter, delete, or otherwise impair the >integrity of any computer file or data residing on the computer of a >file trader." Berman is expected to re-introduce the bill in this >Congressional session.

8 8

Re: Scaled Back Cybersecuruty
by Avi Freedman 17 Jan '03

17 Jan '03

In article <103014.1607.23062(a)avi.netaxs.com> you wrote: : Seems to be a case of prisoners dilema. The security of any one network : is to some extent at the mercy of all other connected networks. The : overall security of the network is only as strong as it's weakest link. : In a highly competitive market place there is going to be little : incentive to invest in security if it will just be compromised by your : cost cutting competitors. Yes, but: - Shouldn't we encourage our tax $ go with preference towards good network citizens? - If only a few of the larger networks started implementing better practices that engineering groups can't get funded today, we're still getting better off. - Starting at the core, which is who the Feds buy the most IP from, still makes life a lot simpler if and when we get the "big one" in terms of cyber-attack. I think this is probably better for a BOF (maybe even the security BOF) discussion, though... Avi

3 4