Re: Al Jazeera DOSed or just lots of traffic
- Original Message - From: Sean Donelan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 9:17 AM Subject: Re: Al Jazeera DOSed or just lots of traffic : : On Mon, 24 Mar 2003, james wrote: : : It was DDoSed even the nameservers routes were null due to the DDoS huge : : size. : : I noticed today that a traceroute to this host from my network exited : at 4 or 5 hops on west coast at a major providers network. : : Its common for popular web sites to locate their major servers : topologically in the network away from their organization's geographic : location. For example, the BBC (a UK organization) has web servers : in New York City. So it doesn't surprise me to see Al Jezeera's web : servers connected through New Jersey. : : Al Jazeera's main web site (64.106.198.10) is still very slow, but I can : get to their english language web site on the same subnet (64.106.198.16). : So its acting more like a overloaded web server than a DDOS. But I don't : have any special insight into Al Jazeera's network. I tried to traceroute it from Level3 looking Glass yesterday when it was down http://www.l3.com/LookingGlass/ and I got this: Traceroute From Traceroute To New York, NY www.aljazeera.net Domain name lookup for 'www.aljazeera.net' failed. Exiting. Beside I called the Tech guys in AlJazeera and told me they are working with opentransit and DataPipe to stop the attack ASAP. I tried to did nslookup using ALJNS1SA.NAV-LINK.NET217.26.193.15 ALJNS1HB.DATAPIPE.COM64.106.198.4 But none did work, and the route to 217.26.193.15 was nulled and I couldn't run traceroute to 64.106.198.4 maybe DataPipe was filtering the ICMP And the UDP to that IP it was dieing within DataPipe network. route-servertraceroute 64.106.198.4 Type escape sequence to abort. Tracing the route to aljns1hb.datapipe.com (64.106.198.4) 1 white_dwarf.cbbtier3.att.net (12.0.1.1) [AS 7018] 0 msec 200 msec 4 msec 2 ar3.n54ny.ip.att.net (12.126.0.30) [AS 7018] 204 msec 200 msec 204 msec 3 gbr1-a30s10.n54ny.ip.att.net (12.127.5.142) [AS 7018] 204 msec 204 msec 4 msec 4 tbr1-p013202.n54ny.ip.att.net (12.122.11.1) [AS 7018] 204 msec 204 msec 200 msec 5 gar4-p300.n54ny.ip.att.net (12.123.3.2) [AS 7018] 200 msec 200 msec 204 msec 6 att-gw.ny.qwest.net (192.205.32.170) [AS 7018] 200 msec 204 msec 200 msec 7 jfk-core-02.inet.qwest.net (205.171.230.22) [AS 209] 200 msec 4 msec 200 msec 8 ewr-core-01.inet.qwest.net (205.171.8.245) [AS 209] 200 msec 204 msec 204 msec 9 ewr-cntr-01.inet.qwest.net (205.171.17.146) [AS 209] 204 msec 200 msec 208 msec 10 msfc-24.ewr.qwest.net (63.146.100.66) [AS 209] 208 msec 200 msec 204 msec 11 * * * 12 vlan11.aggr2.ewr.datapipe.net (64.106.128.6) [AS 14492] 0 msec 4 msec 0 msec 13 * * * 14 * * * Thanks, -A
Anyone using Finisar OC-n GBICS?
http://www.finisar.com/product/product.php?product_id=165product_category_id=150 CWDM GBIC OC48 Transceiver with APD Receiver (FTR-1621) Seems nifty. Anyone using this? Also, me making my once-a-year request; anyone know of GBICs based on ITU-Grid frequencies that would work with Cisco 15216, for example? Thanks.. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Gifts for a CTO who has everything ...
How does one convey to a CTO who has everything that nmap 10.0.0.0/8 has side effects? Sorry - I didn't expect it to be running for such a long time. I apologize for any consternation it may have caused. I ran it because I couldn't get into the system larceny that night. I thought that a map of our network might help me find it. After having run the nmap on a smaller subnet, I decided to re-run it on the larger address space to provide documentation about our network. Seriously. Does life get any better than this? Eric
Using Policy Routing to stop DoS attacks
Looking for advice. I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. Has anyone else tried this successfully on ciscos and junipers? Is it easier on the CPU than access-lists? Is there a link I cannot find on cisco or google? Thanks Christian Liendo
Re: Using Policy Routing to stop DoS attacks
I dunno how you want to implement this; but as far as I know, the way most people generally do policy routing on cisco thru routemap is they define the source IP's via access-list... Does that make a huge difference than regular access lists? I dunno... I've kinda tested it in the lab with two 7206's and CPU load seems to be about the same when done with regular access-list and done with policy routing.. But, I don't have the true real data to back up my claims.. -hc On Tue, 25 Mar 2003, Christian Liendo wrote: Looking for advice. I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. Has anyone else tried this successfully on ciscos and junipers? Is it easier on the CPU than access-lists? Is there a link I cannot find on cisco or google? Thanks Christian Liendo
Re: Using Policy Routing to stop DoS attacks
## On 2003-03-25 09:06 -0500 Christian Liendo typed: [snip] CL CL Depending on the router and the code, if I implement an access-list then CL the CPU utilization shoots through the roof. CL What I would like to try and do is use source routing to route that traffic CL to null. I figured it would be easier on the router than an access-list. CL CL Has anyone else tried this successfully on ciscos and junipers? CL Is it easier on the CPU than access-lists? Details ? Which Cisco router ? IOS ? HW/SW/CEF/netflow/whatver IP switching ? As you seem to have noticed these little details matter ... -- Rafi
Re: Using Policy Routing to stop DoS attacks
At 09:21 AM 3/25/2003 -0500, Haesu wrote: I dunno how you want to implement this; but as far as I know, the way most people generally do policy routing on cisco thru routemap is they define the source IP's via access-list... Does that make a huge difference than regular access lists? I dunno... Well yes, It seems that an IP deny is more process intensive than an IP permit. I do not claim to know why. I have just seen it myself. Anyway depending on the attack with large numbers of packets sometimes the CPU is so high you can get knocked off the router. I wanted to see if policy routing is less taxing on the router. With the access-list for a policy route map you have a access-list permit, so I figured it might be less taxing. Which Cisco router ? IOS ? HW/SW/CEF/netflow/whatver IP switching ? While I have had this problem on different routers the ones I constantly have it on are Cisco Cat 5000s with RSMs(RSP4). I have tried different codes, I am currently at 12.04. But it's not a code issue. It's just a limitation of the router. I just need something less taxing on the router. I just need to know if anyone has already done this.
Re: Using Policy Routing to stop DoS attacks
On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
Re: Using Policy Routing to stop DoS attacks
uRPF will certainly save a bit of CPU cycles than access-lists or policy routing.. it would be intertesting to know any kind of 'common practice' ways people use to fool the router so that it will think such offensive source IP's are hitting uRPF. i am not really sure what kind of traffic we are talking about, but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1) -hc On Tue, 25 Mar 2003, John Kristoff wrote: On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
Re: Using Policy Routing to stop DoS attacks
uRPF will certainly save a bit of CPU cycles than access-lists or policy routing.. it would be intertesting to know any kind of 'common practice' ways people use to fool the router so that it will think such offensive source IP's are hitting uRPF. null route? even with a loose check, if you implement some kind of blackhole system, send the miscreant source adress to say, 172.1.1.1 and have 172.1.1 routed to null 0, uRPF should kill any src/dst packets for the host/block if i'm not mistaken.
RE: Using Policy Routing to stop DoS attacks
If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. However you'd also risk loosing any traffic that was asymmetric in nature. -Jim
ASN allocation update
Hi, NANOGers. As of 24 March 2003 IANA has allocated a new block of ASNs to ARIN. The ASN range changes are: Was 29696 - 32767 Held by the IANA Now 29696 - 30719 Allocated by ARIN (March 2003) Now 30720 - 32767 Held by the IANA The bogus ASN monitoring has been updated to reflect this change. You should update any filters you have. The bogus ASN report, which shows ASNs leaking private, unallocated, and reserved ASNs, is located here: http://www.cymru.com/BGP/asnbogusrep.html Thanks, Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Using Policy Routing to stop DoS attacks
On Tue, 25 Mar 2003, Christian Liendo wrote: Looking for advice. I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. you can null route it also. In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. if you know the source, walk back to the source ingress and stop it there? Unless its a large number of sources in which case the null route should be applied. If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. if the destination changes? Can you clarify that? You have attacks in which the destination changes inside a /24 or inside some larger netblock? Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. Given your description of the problem so far I'm going to say you are using router vendor !J so policy routing (source routing) is guaranteed to do more harm than a simple acl would. Additionally, how large an acl are you trying to implement for this attack scenario? 'less is more' especially with DoS attack filtering. What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. How so? The same basic processing must be done for each packet if you policy route or acl... each packet must be pushed through an acl to an unnatural next-hop (null in the case of an acl or 'wrong interface' for policy routing) Has anyone else tried this successfully on ciscos and junipers? you theoretically COULD do this on a juniper, its making the problem much harder though.. .the juniper could just as easily filter it. POlicy routing on the cisco gear I've tried it on doesn't work well for high packetrate streams. Is it easier on the CPU than access-lists? no, not in anyway is it better than an acl. Is there a link I cannot find on cisco or google? for policy routing sure... http://smlnk.com/?MTAQBMRI there were a bunch more links as a result of: Policy route entered in the cisco.com search tool. Thanks Christian Liendo
Re: Using Policy Routing to stop DoS attacks
On Tue, 25 Mar 2003, Haesu wrote: uRPF will certainly save a bit of CPU cycles than access-lists or policy that is HIGHLY dependent on the platform in question. For the stated 'router' (5500+rsm) I'd think the impact would be about the same as for an acl. 7500+RSP or 5500+RSM (which is pretty much a 7500+RSP) has to process switch all acl'd traffic, this includes uRPF traffic. There isn't the hardware processing available for this in these platforms. The 12000 or 6500 both (among others) have hardware acceleration for forwarding and route lookups. These are harnessed to make the uRPF work 'better' in said platforms. routing.. it would be intertesting to know any kind of 'common practice' ways people use to fool the router so that it will think such offensive source IP's are hitting uRPF. you could hold blackhole routes for these destinations in your route table (local or bgp) So long as the destination for the source is bad (null for instance) the traffic would get dropped. I believe the proper terms from cisco for this are: So long as the adjacency is invalid ... i am not really sure what kind of traffic we are talking about, but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1) most likely the pps would kill the 5500 long before the bps :( especially if you want to route/acl it. -hc On Tue, 25 Mar 2003, John Kristoff wrote: On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
RE: Using Policy Routing to stop DoS attacks
On Tue, 25 Mar 2003, Jim Deleskie wrote: If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. However you'd also risk loosing any traffic that was asymmetric in nature. not necessarily, implement uRPF 'loose check' so long as the source wasn't rfc1918 or had an invalid adjacency things should work... BUT keep in mind how the uRPF is processed on the platform in question :) just turning it on might tip the 5500 over.
Re: Using Policy Routing to stop DoS attacks
i am not really sure what kind of traffic we are talking about, but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1) most likely the pps would kill the 5500 long before the bps :( especially if you want to route/acl it. yea you're right.. for that 100Mbits/sec bps i mentioned, the pps at that rate was around 20,000 pps inbound as well as 18,000 pps outbound. -hc -hc On Tue, 25 Mar 2003, John Kristoff wrote: On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
Re: Using Policy Routing to stop DoS attacks
Haesu wrote: I dunno how you want to implement this; but as far as I know, the way most people generally do policy routing on cisco thru routemap is they define the source IP's via access-list... Does that make a huge difference than regular access lists? I dunno... I've kinda tested it in the lab with two 7206's and CPU load seems to be about the same when done with regular access-list and done with policy routing.. But, I don't have the true real data to back up my claims.. On a live production network under DOS attack, access-lists applied to the inbound interfaces is less CPU load than switching the packet on a 7206 running 12.0(x)S code. Policy routing, even with ip route-cache policy is an increase in load. This is especially true when using extended access lists for say port 80 redirects. This was noted when doing special caching policies before our load exceeded what the ArrowPoint and the 7206 cpu's could handle. FYI: one of my DOS attacks was a PPS attack, and since the packets were small and not using bandwidth, blocking via access-list recovered the network completely with little notice of CPU load over normal traffic. Apparently a 7206 can block more PPS than it can switch. -- Jack Bates Network Engineer BrightNet Oklahoma
Domain oddity - possibly early warning...
Hello, We've noticed something we've never noticed before that became evident at 14:00 today... and which could be an isolated glitch at Verisign/Netsol, or it could be a sign of a larger problem looming. The domain utclassifieds.com is answered as NXDOMAIN in the gtld-servers. [EMAIL PROTECTED] rjoffe]$ dig @a.gtld-servers.net utclassifieds.com ns ; DiG 8.3 @a.gtld-servers.net utclassifieds.com ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; utclassifieds.com, type = NS, class = IN ;; AUTHORITY SECTION: com.2D IN SOA a.gtld-servers.net. nstld.verisign-grs.com. ( 2003032500 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ); minimum ;; Total query time: 96 msec ;; FROM: layer9.com to SERVER: a.gtld-servers.net 192.5.6.30 ;; WHEN: Tue Mar 25 16:15:26 2003 However it has a whois record at networksolutions, but it has no nameservers in the whois record. And the domain is valid and expires in July 2003. http://www.networksolutions.com/cgi-bin/whois/whois?STRING=utclassifieds.comSearchType=doSTRING2.x=31STRING2.y=8 If anyone else has a similar domain problem, I'd appreciate a note offline... Meantime we're trying to get an answer from NSI. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com Technology so advanced, even we don't understand it!(SM)
Syn Flood
I have a problem on a home PC of all things. Every once in a while it bursts into life and syn floods an IP address on port 80. The IP addresses it chooses are random and varied. The network counters ratchet up alarmingly (as viewed in the connections window). I am running winXP Pro on this box. I have zone alarm, an SMC Barricade firewall, and Norton anti virus. I dont seem to be able to catch the computer at it, I just have the evidence after the event. I dont like the anti social behavior that this is exhibiting and am wondering if the collective wisdom of this group might have any ideas how to track the issue down. According to virus checkers, I am clean. Thanks in advance Chris Bird
Re: Syn Flood
I would look for something like an IRC bot. Zonealarm may not catch it if it is on there for a while and some user 'permitted' it at some point. Usually, these bots have names to sound like system binaries. Anti virus software may not catch the agent. Do you have any full packet captures from the system? Any traffic that could be control traffic (doesn't have to go to port 6667) On Tue, 25 Mar 2003 21:55:41 -0600 Christopher Bird [EMAIL PROTECTED] wrote: I have a problem on a home PC of all things. Every once in a while it bursts into life and syn floods an IP address on port 80. The IP addresses it chooses are random and varied. The network counters ratchet up alarmingly (as viewed in the connections window). I am running winXP Pro on this box. I have zone alarm, an SMC Barricade firewall, and Norton anti virus. I don't seem to be able to catch the computer at it, I just have the evidence after the event. I don't like the anti social behavior that this is exhibiting and am wondering if the collective wisdom of this group might have any ideas how to track the issue down. According to virus checkers, I am clean. Thanks in advance Chris Bird -- [EMAIL PROTECTED] Collaborative Intrusion Detection join http://www.dshield.org
RE: Syn Flood
I had success on several computers catching IRC Bots with SwatIT, which is free. http://www.lockdowncorp.com/ Ron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Christopher Bird Sent: Tuesday, March 25, 2003 8:56 PM To: [EMAIL PROTECTED] Subject: Syn Flood I have a problem on a home PC of all things. Every once in a while it bursts into life and syn floods an IP address on port 80. The IP addresses it chooses are random and varied. The network counters ratchet up alarmingly (as viewed in the connections window). I am running winXP Pro on this box. I have zone alarm, an SMC Barricade firewall, and Norton anti virus. I dont seem to be able to catch the computer at it, I just have the evidence after the event. I dont like the anti social behavior that this is exhibiting and am wondering if the collective wisdom of this group might have any ideas how to track the issue down. According to virus checkers, I am clean. Thanks in advance Chris Bird
Re: Syn Flood
Christopher Bird wrote: I have zone alarm, an SMC Barricade firewall, and Norton anti virus. Ahhh, but do you have Ad-Aware? -- -Jack
Re: Syn Flood
- Original Message - From: Christopher Bird [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 5:55 PM Subject: Syn Flood I have a problem on a home PC of all things. Every once in a while it bursts into life and syn floods an IP address on port 80. The IP addresses it chooses are random and varied. The network counters ratchet up alarmingly (as viewed in the connections window). I am running winXP Pro on this box. You might want to let a prog. such as TCP View (free) run while you're idle. Beats trying to get netstat to capture it, imo. http://www.sysinternals.com/ntw2k/source/tcpview.shtml Also, close everything you can and look at what Processes are running. Some of these things are hard to spot...I was infected and the offender was named Iexplorer.exe, while the real IE is named IEXPLORE.exe and the real Explorer is named Explorer.exe. Here's another free prog. which aids in tying a process to what's running it. http://www.xmlsp.com/pview/prcview.htm These trojans don't seem to be caught by some Anti-Virus programs...at least AVG didn't catch mine. I ended up searching google for Iexplorer.exe and found (5 pages deep a year ago) an obscure thread which had part of the solution for removal. I then searched the HD for any files created at the same time and found the rest of the (by then morphed) creature. Good luck. --Michael I have zone alarm, an SMC Barricade firewall, and Norton anti virus. I don't seem to be able to catch the computer at it, I just have the evidence after the event. I don't like the anti social behavior that this is exhibiting and am wondering if the collective wisdom of this group might have any ideas how to track the issue down. According to virus checkers, I am clean. Thanks in advance Chris Bird
Lock Down (was Re: Syn Flood)
Ron Harris wrote: I had success on several computers catching IRC Bots with SwatIT, which is free. http://www.lockdowncorp.com/ I would recommend that anyone who considers using Lock Down's software be aware of the content here: http://www.pc-help.org/www.nwinternet.com/pchelp/lockdown/index.html In short, the owner of pc-help.org was sued by Lock Down when he exposed their false advertising claims. Lock Down lost their suit: http://www.pc-help.org/suit/ Mike
