- Test - lists.nanog.org

Traffic Analizer
by Jeremy Furr 10 Jan '01

10 Jan '01

Was wondering if anyone here could recommend a Traffic ananlizer, one that can show us where our traffic is destined for and how much that, peer, or site is getting? Thanks Jeremy

4 3

Re: DNS requests from 209.67.50.203
by Matthew Zito 10 Jan '01

10 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 09 Jan 2001, you wrote: > I'm surprised this hasn't come up in NANOG yet... > > On a university list many sites are reporting large amounts of traffic > appearing to come from 209.67.50.203 to their DNS servers. The > administrator of the source IP (spoofed of course) is the victim of a > brutal DoS attack. The traffic is UDP/DNS queries that are appear to be > going directly to available DNS servers (as opposed to random hosts). > Most sites are reporting on the order of 6 or more packets per second to > their DNS servers. The victim has apparently seen upwards of 90 Mb/s of > traffic coming back in to them. Does anyone here have anymore > information on this attack? Hello all, 209.67.50.203 is one of our (Register.com's) ip addresses. On January 4 at approximately 5:30 pm Register.com was attacked by the large-scale DNS attack described above. The nature of the attack itself is explained in detail in CERT Incident Notes 2000-04, available at: http://www.cert.org/incident_notes/IN-2000-04.html At its peak, the attack significantly increased the amount of incoming traffic from our providers. Within a short time we had blocked the attack at our border routers, and by evening of the next day our upstreams had blocked it also. While the attack is still continuing, the impact on our upstreams has decreased, mostly due to individual ISPs who started access-listing off the incoming spoofed packets. Although we are not currently being negatively affected by the attack, the annoyance level is significant enough that the FBI has been notified - meanwhile, we are focusing our energies on 1) notifying as many of the parties that are being used as "amplifiers" as possible and 2) asking them to contact their upstreams to try to trace back the traffic to a provider. We are trying to compile a listing of all the DNS servers being used as amplifiers - unfortunately, trying to create such a list is tough to do, given the distribution of the attack. The specifics of the attack are a source address of 209.67.50.203 (futuresite.register.com) a udp destination port of 53. The dns requests themselves are MX record requests for aol.com - it looks like a 25 byte dns request yields a 500 byte response, which is not a bad ROI. If anyone is concerned about whether or not they are being used as an amplifier, they can place access-lists on their routers to block packets with the above criteria without denying any normal services - there is no reason for that ip address to be making DNS requests. For anyone who is being used as an amplifier, we would ask that you contact your upstreams and ask them to initiate a traceback, or contact me directly: Matthew Zito Systems Engineer Register.com Ph: 212-798-9205 mzito(a)register.com If anyone has any useful information or questions, please feel free to contact me. We will also be sure to notify this list as pertinent information arises. Thanks to everyone on and off this list who has been helping us over the last few days - we all appreciate it. All correspondence will be kept in strict confidence. Thanks again, Matt Zito - -- Matthew J. Zito Systems Engineer Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018 Ph: 212-798-9205 PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC D2 06 B2 B0 BF 55 68 99 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQEVAwUBOlvEtULSU8UoXSlNAQERvAgAg4B8lvQHtfw5Yth61D/BbwMBgL36AM7P QDfQZQ46fp/F8goXtbdBtpalvTUAV6tkKc4jC79AZsrrCx08xqBk/BHQHDT6/1Ru Um/eF0LYMYMj4fh9fDWYzBK4GPETWw/VgwOywe7mORM8HFOKMrV7Q+U3bdwDL73M SXGqY725QJfcuRkfd+8RJilOXzVoa3BxDcn+QxZwxL5qGdfZ1TJhmJHtLHI4mE9Y S3xzps96hH+J6jrGZIcjLYzhS12xYpcgZE7jBkhdMv2lTAQx2iQE2KPDFgYbOOgx aA90QsFM/hB1pC1zvCZD7sbQfoCj4+L4r7sdqhiC0DhV4sFtdRxLbA== =Rka3 -----END PGP SIGNATURE----- -- Matthew J. Zito Systems Engineer Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018 Ph: 212-798-9205 PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC D2 06 B2 B0 BF 55 68 99

1 0

Who is in NY ? (was: IX-'s)
by Jan-Ahrent Czmok 10 Jan '01

10 Jan '01

Hi ! Just curious: Who is at Telehouse New York and NOT at the NYIIX. Also who's present at 60 Hudson ? I am looking for people on who we can interconnect privately avoiding NYIIX or other exchanges on the east-coast. Jan

3 2

Re: OT - VPN help
by M.I. Deen 10 Jan '01

10 Jan '01

Dear Stephen, I was happy that some stuff on VPN had come my way on this mailing list. Assuming that you have a Cisco based network, do we infact need a Cisco 5008/or 3080 at each POP where the VPN's terminate. What is the minimum set of Cisco boxes you need to get a basic VPN/Dial VPN going, which obviously could be scaled later on. Cisco docs always talk about 7200 as a forwarding router. Deen Sri Lanka Telecom At 08:37 AM 1/9/01 -0500, you wrote: > >On 8 Jan, Stephen Burd wrote: >> >> Can someone who knows VPN (really well) give me a hand with a little project I'm >> working on please? >> >> The question is this: Can a customer with two office locations (several states >> away from each other) do VPN via SDSL and ISDN? I have been told those two >> services cannot work together and it makes no sense to me why not. >> >> Thanks! >> > >I think you need to file all further information from whomever fed you >that line of tripe in the circular file. A VPN can run over any type >of circuit, or even no physical circuit at all. Have a look at the new >Cisco IPSec stuff, I'm currently running VPNs to sites connected via >ISDN, dial-up, T1, Frame-Relay E1, SDSL, and Cablemodem. It's a lot >easier if you have statically assigned IP addresses, but not even that >is a requirement. > >Jeremiah > >> -Stephen >> >> >> Stephen Burd >> VP Corporate & Education Services >> Mercury Network, LLC >> Email: sburd(a)tm.net >> Toll Free: (888)866-4638 x156 >> Direct/Mobile: (517)923-0659 >> Direct Fax: (517)923-1281 >> ================================================= >> I N T E R N E T F O R B U S I N E S S >> Mercury Network, LLC http://www.tm.net >> 129 Ashman St / PO Box 117 Voice: (517)837-3790 >> Midland, MI 48640-0117 Fax: (517)837-3780 >> ================================================= >> >> >> begin 666 Stephen Burd.vcf >> M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..D)U<F0[4W1E<&AE;@T*1DXZ >> M4W1E<&AE;B!"=7)D#0I/4D<Z365R8W5R>2!.971W;W)K.T)U<VEN97-S(%-E >> M<G9I8V5S($1I=FES:6]N#0I4251,13I64"!#;W)P;W)A=&4@)B!%9'5C871I >> M;VX@4V5R=FEC97,-"E1%3#M73U)+.U9/24-%.B@U,3<I(#DR,RTP-C4Y#0I4 >> M14P[0T5,3#M63TE#13HH-3$W*2 Y,C,M,#8U.0T*5$5,.U=/4DL[1D%8.B@U >> M,3<I(#DR,RTQ,C(a)Q#0I!1%([5T]22SM%3D-/1$E.1SU154]4140M4%))3E1! >> M0DQ%.CL[,3(Y($%S:&UA;B!3="X],$0],$%03R!";W@@,3$W.TUI9&QA;F0[ >> M34D[-#@V-# [56YI=&5D(%-T871E<R!O9B!!;65R:6-A#0I,04)%3#M73U)+ >> M.T5.0T]$24Y'/5%53U1%1"U04DE.5$%"3$4Z,3(Y($%S:&UA;B!3="X],$0] >> M,$%03R!";W@@,3$W/3!$/3!!36ED;&%N9"P@34D@-#@V-# ],$0],$%5;FET >> M960@4W1A=&5S(&]F(#T-"D%M97)I8V$-"D%$4CM03U-404PZ.SM03R!";W@@ >> M,C P,3M-:61L86YD.TU).S0X-C0Q+3(P,#$[56YI=&5D(%-T871E<R!O9B!! >> M;65R:6-A#0I,04)%3#M03U-404P[14Y#3T1)3D<]455/5$5$+5!224Y404), >> M13I03R!";W@@,C P,3TP1#TP04UI9&QA;F0L($U)(#0X-C0Q+3(P,#$],$0] >> M,$%5;FET960@4W1A=&5S(&]F($%M97)I8V$-"E523#M73U)+.FAT=' Z+R]W >> M=W<N=&TN;F5T#0I%34%)3#M04D5&.TE.5$523D54.G-B=7)D0'1M+FYE= T* >> A4D56.C(P,# Q,3$V5#(P,34S,5H-"D5.1#I60T%21 T* >> ` >> end >> > > > > >

1 0

Re: DNS requests from 209.67.50.203
by Steven M. Bellovin 10 Jan '01

10 Jan '01

In message <3A5BA3C3.CEAAD37D(a)depaul.edu>, John Kristoff writes: > >I'm surprised this hasn't come up in NANOG yet... > >On a university list many sites are reporting large amounts of traffic >appearing to come from 209.67.50.203 to their DNS servers. The >administrator of the source IP (spoofed of course) is the victim of a >brutal DoS attack. The traffic is UDP/DNS queries that are appear to be >going directly to available DNS servers (as opposed to random hosts). >Most sites are reporting on the order of 6 or more packets per second to >their DNS servers. The victim has apparently seen upwards of 90 Mb/s of >traffic coming back in to them. Does anyone here have anymore >information on this attack? Yes, it's a DDoS attack, of the type that Vern Paxson has dubbed "refletor attacks". You send a forged DNS query to a DNS server; it sends its reply to the victim. Then you have lots of hosts around the net doing this, but banging on different DNS servers. --Steve Bellovin

2 1

IX's
by Roeland Meyer 10 Jan '01

10 Jan '01

> From: Vadim Antonov [mailto:avg@kotovnik.com] > Sent: Tuesday, January 09, 2001 3:32 AM > > You mean you really have any other option when you want to > interconnect > few 300 Gbps backbones? :) Both mentioned boxes are in 120Gbps range > fabric capacity-wise. If you think that's enough, i'd like > to point out > at the DSL deployment rate. Basing exchange points at > something which is > already inadequate is a horrific mistake, IMHO. All one has to do is look at PAIX. The whole system looks like it is being used at real close to max capacity. I have a client at AboveNet and my systems are on a CerfNet block. PAIX is between us. I feel their pain. > Exchange points are major choke points, given that 80% or so > of traffic > crosses an IXP or bilaterial private interconnection. > Despite the obvious > advantages of the shared IXPs, the private interconnects between large > backbones were a forced solution, purely for capacity reasons. and they aren't keeping up with the growth. This entire IX thread has been interesting. But, it appears to be one of those "good theory, implementation sux" sort of things.

3 2

Re: RFC1918 addresses to permit in for VPN?
by Sean Donelan 09 Jan '01

09 Jan '01

On Thu, 28 December 2000, "Miguel A.L. Paraz" wrote: > Our DSUA filter had to have a small hole punched in since a customer had a VPN > (I do not know yet as to what kind) which was receiving packets sourced at > 172.17.x.x. Is this a misconfiguration on the sender's end, or a "feature." > > I think there was earlier discussion on VPN's requiring ICMP (echo?) Its not a very private or virtual network if it leaks addresses into a data stream visible to your filters.

21 47

Re: IX's
by Paul Vixie 09 Jan '01

09 Jan '01

rmeyer(a)mhsc.com (Roeland Meyer) writes: > All one has to do is look at PAIX. The whole system looks like it is being > used at real close to max capacity. nope. some paix customers sometimes operate their ports at or near capacity. however, the paix ISO-L2 switch fabric is made up of switches whose backplanes have quite a bit of headroom, and trunks between those switches which have quite a bit of headroom. in spite of this ample amount of headroom, there are a LOT of private network interconnects between paix's customers, which are presumably being used for private peering. the "whole system" is being used at nowhere near its current capacity, and if we ever see a capacity limit on the horizon we will upgrade, upgrade, and then upgrade. > I have a client at AboveNet and my > systems are on a CerfNet block. PAIX is between us. I feel their pain. probably you should contact abovenet and/or cerfnet and find out why that is. it sure as hell isn't because of any capacity limits inside PAIX itself. > > Exchange points are major choke points, given that 80% or so of traffic > > crosses an IXP or bilaterial private interconnection. Despite the obvious > > advantages of the shared IXPs, the private interconnects between large > > backbones were a forced solution, purely for capacity reasons. > > and they aren't keeping up with the growth. in what way? > This entire IX thread has been interesting. But, it appears to be one of > those "good theory, implementation sux" sort of things. a lot of companies live and die according to paix's ability to carry bits or photons or electrons to from other internet companies and/or circuit providers. i like to think that if "implementation sux", i'd've heard more about it before now. but please feel free to educate me. (maybe you should educate me offline and then post a summary back to the list.) -- Paul Vixie <pvixie(a)mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX) Abovenet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.

1 0

RE: net.terrorism
by Roeland Meyer 09 Jan '01

09 Jan '01

> From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, January 09, 2001 11:36 AM > > >> ethical question like this. > > I was under the misconception the 'O' in NANOG stood for > > 'Operations' not 'Ethics'. But this would explain lots > > of other posts here which I had previously considered > > off topic. > > s/operations/orations/? That can't be; whilst I've read an awful lot, I haven't "heard" a thing <g>. Is there an aural back-channel to NANOG? <going back to configuring root servers now ...>

1 0

Re: net.terrorism
by Jerry Scharf 09 Jan '01

09 Jan '01

I can't resist trying to sum this up: Somebody wants to talk to an ORBS server and has Abovenet transit. They don't like being caught in the orbs/abovenet mess. So rather than a) getting a new provider b) getting another provider and fixing the local routing to use them to ORBS the person opted for c) send a misleading flame message to NANOG Operational issues of enforcing trafic delivery policies for customers has been discussed till it's dead. Everyone knows where they stand, and anyone who does it has is as part of their service agreement. As has been pointed out, this is not a subject that will engender any sympathy in this group. does anything else need to be said? If not, let's let this die. jerry

1 0