- Test - lists.nanog.org

AS3303 customer under attack
by Andre Chapuis 24 Sep '02

24 Sep '02

Dear NOC /Nanog, We (Swisscom, AS3303) have a customer that is being attacked for about 5 days now. It is a DOS attack with spoofed source IP addresses. The destination network is: 193.77.0.0/16 , as-path 3303 8437 5603 2610 The attack is (at least !) 100Mb/s, and is coming from different peers. Yesterday it was on our peerings with AS7018 and AS6453 in Palo-Alto, today seems to be more on the AADS in Chicago. I applied the following packet filter (access-list 19 below) to all our external links, and there is a huge amount of packet with those source IP coming in. Although we drop these packets at our ingress, may i ask everyone peering with us (and others if you feel concerned) to configure that packet filter in output ? Thanks a lot for your help (or feedback if you are also experiencing such problems) and have a nice day André ----------------------------------------------------------------------- access-list 19 deny 0.0.0.0 0.255.255.255 access-list 19 deny 1.0.0.0 0.255.255.255 access-list 19 deny 2.0.0.0 0.255.255.255 access-list 19 deny 5.0.0.0 0.255.255.255 access-list 19 deny 7.0.0.0 0.255.255.255 access-list 19 deny 10.0.0.0 0.255.255.255 access-list 19 deny 14.0.0.0 0.255.255.255 access-list 19 deny 23.0.0.0 0.255.255.255 access-list 19 deny 31.0.0.0 0.255.255.255 access-list 19 deny 36.0.0.0 0.255.255.255 access-list 19 deny 37.0.0.0 0.255.255.255 access-list 19 deny 39.0.0.0 0.255.255.255 access-list 19 deny 41.0.0.0 0.255.255.255 access-list 19 deny 42.0.0.0 0.255.255.255 access-list 19 deny 58.0.0.0 1.255.255.255 access-list 19 deny 60.0.0.0 0.255.255.255 access-list 19 deny 70.0.0.0 1.255.255.255 access-list 19 deny 72.0.0.0 7.255.255.255 access-list 19 deny 82.0.0.0 1.255.255.255 access-list 19 deny 84.0.0.0 3.255.255.255 access-list 19 deny 88.0.0.0 7.255.255.255 access-list 19 deny 96.0.0.0 31.255.255.255 access-list 19 deny 169.254.0.0 0.0.255.255 access-list 19 deny 172.16.0.0 0.15.255.255 access-list 19 deny 176.0.0.0 15.255.255.255 access-list 19 deny 192.0.0.0 0.0.0.255 access-list 19 deny 192.0.2.0 0.0.0.255 access-list 19 deny 192.168.0.0 0.0.255.255 access-list 19 deny 222.0.0.0 1.255.255.255 access-list 19 deny 224.0.0.0 31.255.255.255 access-list 19 permit any --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

1 0

RE: Cogent service
by Frank Scalzo 23 Sep '02

23 Sep '02

This was a totally bogus reason from the very beginning. Given that real backbones carry no prefixes longer than 24 bits the "long" lookup in Last numbers I saw put 701 at over 100k prefixes in the /25-/32 range. The more correct statement is backbones carry no external prefixes longer then /24. The point is there can be a HUGE number of internal prefixes that can make a difference. I will admit 701 route bloat, is not a typical example.

1 0

Security Practices question
by John M. Brown 23 Sep '02

23 Sep '02

I have question for the security community on NANOG. What is your learned opinion of having host accounts (unix machines) with UID/GID of 0:0 otherwords jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh The argument is that way you don't hav to give out the root password, you can just nuke a users UID=0 equiv account when the leave and not have to change the real root account. Now, don't flame me over the question, but provide valid pro's or con's for this practice from your experience. thank you. the reason I'm asking is important. john brown

9 9

Re: Wireless insecurity at NANOG meetings
by Huopio Kauto 23 Sep '02

23 Sep '02

How about just plainly blocking the most obvious holes, that is telnet and POP? If someone wants a direct telnet connection to a route server or something similar - open a hole with a web-based tool? Ok, then you say all unencrypted www traffic with plain username/pw.. SSH'ing everything back to home base is quite useful :) --Kauto

2 1

Re: Wireless insecurity at NANOG meetings
by Steven M. Bellovin 23 Sep '02

23 Sep '02

In message <006a01c2630a$19725020$ab876540(a)amer.cisco.com>, "Stephen Sprunk" wr ites: > >I can't say without a sniffer, but I'd bet that most NANOG participants are >doing the same: SSH or IPsec VPN's back to home (wherever that is). Experience doesn't support this, I fear. How many passwords were captured last time? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

2 1

Re: Wireless insecurity at NANOG meetings
by Steven M. Bellovin 23 Sep '02

23 Sep '02

In message <Pine.GSO.4.40.0209221641250.23761-100000(a)clifden.donelan.com>, Sean Donelan writes: > >On Sun, 22 Sep 2002, Randy Bush wrote: >> - the users need to be told how to operate more safely, use >> end-to-end authentication and privacy, etc. it's a matter of >> education. and the education will stand them in good stead >> when they use 802.11 at starbucks, airports, etc. we do this >> at ietf, but it is not allowed at nanog. > >Sunday afternoon is full of tutorials on lots of different subjects. >Has anyone volunteed to conduct a Sunday tutorial on wireless security >for users of "public" wireless networks? > >Although I think it is a mistake to think a wireless network security >is different than using any other network you don't control. Most >wireless security tutorials tend to concentrate on "securing" the >wireless network instead of how to communicate over an untrusted >network. > Precisely -- and it's precisely why I'm not a big fan of "wireless security" as a discipline: my threat model for the wired network has never been any different than for wireless... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

1 0

Re: Wireless insecurity at NANOG meetings
by Steven M. Bellovin 23 Sep '02

23 Sep '02

In message <Pine.GSO.4.40.0209211957580.21971-100000(a)clifden.donelan.com>, Sean Donelan writes: > >On Sat, 21 Sep 2002, Martin J. Levy wrote: >> >I agre security is sadly lacking, but it is probably impossible to >> >implement in a conference environment. >> >> Look this is a very simple issue. Sean's first post really pointed out >> that it's "bad form" for a set of operators to run an insecure network. >> I would believe that it's "good form" to at least try. It was stated >> that the network was not run by the "operators". OK, I accept that, but >> it's run by people with great (actually fantastic) connections to real >> operators (ie: us). > >I feel like a Rorschach Test. > >Is the Nanog confernce network really insecure for its purpose? > This is the real question -- what are you trying to protect? Apart from its (many) other problems, WEP is useful for protecting a single hop at layer 2. It does not protect against attacks at higher layers. (That's true of virtually all security mechanisms, I might add -- and I say "virtually" because I don't really trust my reasoning at at an hour when I really should be asleep, but I think that "all" is correct.) Apart from the problem of attacks from the Internet -- surely we don't want NANOG to run a firewall for us -- there are easy attacks that can bypass WEP. For example, someone could use ARP-spoofing to launch an active attack on even non-sensitive Web traffic. Btw -- that has happened on the wireless network at at least two conferences I've been to in the last few years. And no, these weren't black hat or grey hat conferences. If it weren't for the cryptanalytic attack on RC4 -- the one attack on WEP that wasn't foreseeable -- and if it had been done properly in other respects (i.e, if it had per-user keying, key management, and no "IV" collisions), WEP could provide access control. We could even imagine an AES-based WEP with key management, etc. -- and *all* it would buy us is access control. Is that worth it for NANOG? Again, what are you trying to protect? Is access to the conference net a resource that needs to be protected? Maybe it is, if you're concerned about drive-by spammers. But there's another resource, and that's the reputation of NANOG, or at least of its members, as folk who know how to run a network. Wide-open 802.11 networks are often a bad idea, precisely because access is a resource that needs to be protected. Beyond that, there's sometimes a "good neighbor" issue -- you don't want to accidentally attract folks who want to be on some local net of their own. Maybe a closed net is reasonable for that purpose -- but that's about it. If you want to protect yourself, make sure that your software is fully patched, you expose as few services as possible to the outside, and that you don't send anything unencrypted if it's at all sensitive if intercepted or modified. Beyond that, make sure that you're lucky, because new holes can be found at any time. Note, btw, that I didn't say "do that at conferences", or "do that for 802.11 hosts".... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

1 0

Re: [nanog]software routers
by Vadim Antonov 23 Sep '02

23 Sep '02

On Sun, 22 Sep 2002, Koji Hino wrote: > From: Vadim Antonov <avg(a)exigengroup.com> > Date: Sat, 21 Sep 2002 03:06:56 -0700 (PDT) > :> The CPUs are quite faster nowadays, and you can get things like _quad_ > :> 300MHz PPC core on an FPGA plus 20+ 3.2Gbps serdes I/Os - all on one chip. > :> So building multigigabit software router is a no-brainer. > > Usual PCs don't have such fancy hardware... They have quite fancier stuff inside, actually, from a technology point of view. Your run-of-the-mill Pentium IV requires a lot more advanced technology for design and manufacturing than the "platform FPGA" I referred to. The enormous design costs for those marvels of engineering are only bearable because of high volume. > If you call it software router, then all "network processor based > router" should also be called software router, right? "Software router" in my book is something which relies on programmable general-purpose devices for implementing packet routing functions. Network processors do not qualify (though they're nice, when they are actually available, which is not often - because chip vendors tend to drop niche products pronto when in a bind). One thing I learned well is to keep exotic stuff out of designs, because it never seems to be available w/o high-volume commitments, and even then tends to come a year later and full of "design features". --vadim

4 3

Re: Wireless insecurity at NANOG meetings
by Tony Rall 22 Sep '02

22 Sep '02

On Sunday, 2002-09-22 at 17:06 AST, Sean Donelan <sean(a)donelan.com> wrote: > Although I think it is a mistake to think a wireless network security > is different than using any other network you don't control. Most > wireless security tutorials tend to concentrate on "securing" the > wireless network instead of how to communicate over an untrusted > network. There is no way to make the NANOG wireless setup "trusted"; you'd be better off putting effort into securing communications on an untrusted net. Tony Rall

1 0

Re: Wireless insecurity at NANOG meetings
by Dave Crocker 22 Sep '02

22 Sep '02

At 05:06 PM 9/22/2002 -0400, Sean Donelan wrote: >Has anyone volunteed to conduct a Sunday tutorial on wireless security >for users of "public" wireless networks? > >Although I think it is a mistake to think a wireless network security >is different than using any other network you don't control. In fact, why not make the tutorial oriented towards operators, and be one of designing and providing service for mobile users (no matter what media are used)? In reality, most or all of the "service" that results is run on the end-points, but ISPs can help greatly by providing documentation and, sometimes, software to support this. They also can learn what mechanisms provide real security and what mechanisms do not. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0