Re: Problems on internet today ?
Thanks Sean. Sorry for the general fishing and vagueness of my post. Finally I have gotten some answers from my upstreams so I have a better idea of which gateways to prefer my traffic in & out. James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa
Problems on internet today ?
Are others seeing latency and slow or stalled web pages today ? I opened a ticket with my provider, who indicates they are seeing problems with many of their peers. I am seeing very increased RTT to all the points I usually trace to. The latency does start past my provider, after they hand off to others, and is not specific to one major provider. james
Re: 69/8...this sucks -- Centralizing filtering..
> I'm not trying to start a flame war here, just pointing out > that a variety of feeds meet many more requirements, and that there > are several types of data feeds available now. This includes the > recently added pure text bogon files, suitable for easy parsing. > > http://www.cymru.com/Bogons/ I have been using Rob's Bogon Route Server peering for several months. I love this service. The Bogon Route Server peers with my Zebra Route Server, which is in full mesh with all my iBGP routers. This allows me more chances to filter and make sanity checks. I was home sick when the last address space was allocated & my routers updated themselves. James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa
Snort rules for "Sapphire" Worm
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"HELL-SQL Worm Scan";content:"|684765745466b96c6c|";classtype:attempted-admin;) alert udp $HOME_NET any -> $EXTERNAL_NET 1434 (msg: "SQLSLAMMER"; content:"dllhel32hkernQhounthickChGetTf"; classtype:bad-unknown;) alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Slammer Worm Activity";content:"|04 01 01 01 01 01 01 01|"; classtype:bad-unknown; sid:9994; rev:1;) alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"W32.SQLEXP.Wormpropagation"; content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|";content:"|04|"; offset:0; depth:1;) alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Slammer WormActivity";content:"|81f10301049b81f101|"; classtype:bad-unknown; sid:9994; rev:1;) Swap external and home net to see both vectors for this worm. james
Dutch translation needed
I am not getting through to speed.planet.nl in English, can anyone give me a decent translation of in Dutch (The Netherlands): "Here are our logs, indicating your host is attempting to access formmail on our web servers. We have been seeing at least 1,000 attempts a day for weeks from this host. Please look into this matter. The logs are in Mountain US time zone and sync'ed to NTP. Thank you for your attention to this matter" James Edwards Routing and Security [EMAIL PROTECTED]
Cisco IOS EIGRP Network DoS
- Original Message - From: "FX" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 19, 2002 10:06 AM Subject: Cisco IOS EIGRP Network DoS Hi there, please find attached an advisory about an issue with the Cisco IOS Enhanced IGRP implementation that can be used to cause a network segment wide denial of service condition. Regards FX -- FX <[EMAIL PROTECTED]> Phenoelit (http://www.phenoelit.de) 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564 Attached text moved here: Phenoelit Advisory [ Title ] Cisco Systems IOS EIGRP Network Denial of Service [ Authors ] FX <[EMAIL PROTECTED]> Phenoelit Group (http://www.phenoelit.de) Advisory http://www.phenoelit.de/stuff/CiscoEIGRP.txt [ Affected Products ] Cisco IOS Tested on: IOS 11.3 IOS 12.0(19) IOS 12.2 Cisco Bug ID: CERT Vu ID: [ Vendor communication ] 10/08/02Initial Notification, [EMAIL PROTECTED] 10/08/02 - 11/14/02 Communication with [EMAIL PROTECTED] about the issue, fixes and timelines. 12/18/02 Final advisory going public as coordinated release *Note-Initial notification by phenoelit includes a cc to [EMAIL PROTECTED] by default [ Overview ] Cisco Systems IOS is vulnerable to a denial-of-service attack using Cisco's proprietary routing protocol Enhanced IGRP (EIGRP). When flooding a Cisco router with spoofed EIGRP neighbor announcements, the router will cause an Address Resultion Protocol (ARP) storm on the network segment while trying to find the MAC addresses for the newly discovered neighbors, effectively using all available bandwidth. [ Description ] EIGRP uses automatic discovery of neighboring routers. An EIGRP router announces it's existence via multicast on the enabled interfaces. If two routers discover each other, they try to exchange information about the current topology in unicast. On Ethernet, both sides need to obtain the MAC address of the other router. When generating EIGRP neighbor announcements with random source IP addresses and flooding a Cisco router (unicast, only possible in 11.x) or an entire network (multicast), all receiving Cisco routers will try to contact the sender(s). The source IP addresses have to be in the subnet(s) enabled via the "network" statement in the config of the victim router. A bug in Cisco IOS causes the router to continiously try to obtain the MAC address of the sender. This process does not time out unless the EIGRP neighbor holdtimer expires. This value is supplied by the sender of the neighbor announcement and has a maximum of over 18 hours. Multiple neighbor announcements with not existing source IP addresses will cause the router to use all available CPU power and bandwidth on the segment for ARP request - creating a segment-wide denial of service condition. The possible use of IP multicast poses a high risk for larger corporate networks using EIGRP. Cisco IOS versions below 12.0 also accept EIGRP neighbor announcements as unicast packets, which makes the attack possible via the Internet. [ Example ] None provided at this time. [ Solution ] Implement EIGRP authentication using MD5 hashes - which should have been done in the first place. Where MD5 can not be implemented, use extended access lists to match expected neighbors. The obvious workaround of using fixed neighbor entries in the configuration does not work due to another bug in IOS that makes it ignore the command (Cisco Bug ID CSCdv19648). [ end of file ($Revision: 1.5 $) ] Cisco comments on Bug traq: -BEGIN PGP SIGNED MESSAGE- We can confirm the statement made by FX from Phenoelit in his message "Cisco IOS EIGRP Network DoS" posted on 2002-Dec-19. The EIGRP implementation in all versions of IOS is vulnerable to a denial of service if it receives a flood of neighbor announcements. EIGRP is a Ciscos' extension of IGP routing protocol used to propagate routing information in internal network environments. The workaround for this issue is to apply MD5 authentication that will permit the receipt of EIGRP packets only from authorized hosts. You can find an example of how to configure MD5 authentication for EIGRP at the following URL (possibly wrapped): http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/ np1_c/1cprt1/1ceigrp.htm#xtocid18 If you are using EIGRP in the unicast mode then you can mitigate this issue by placing appropriate ACL which will block all EIGRP packets from illegitimate hosts. In the following example the EIGRP neighbor has IP address of 10.0.0.2 and the local router has address 10.0.0.1. Router#config t Router(config)#access-list 111 permit eigrp host 10.0.0.2 host 10.0.0.1 Router(config)#access-list 111 deny eigrp any host 10.0.0.1 The previous example will permit all EIGRP packet throughout the router and into the rest
Re: Identifying DoS-attacked IP address(es)
> I'm sure you can look in the archives of this list for messages from me > about this very thing... :) In short: "Every ISP should have 24/7 security > support for customers under attack." That support should include, acls, > null routes, tracking the attack to the ingress. Rarely do rate-limits do > any good in the case of DoS attacks... (this part is a debate for another > thread) Yes, we have those ready to go. And tools like Snort/Spade and Net Flow to identify the problem and suggest ACL's and null routes, ect. My question is more about an upstream provider for an ISP (I was calling this backbone). Clearly UU has a system well in place but I would like to hear others experiences with their upstream providers and DoS's. I know what kind of help me upstreams will provide, as I have asked, I am just trying to get a feel for others experiences. James Edwards [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday Phone support 365 days till 10 pm via the Santa Fe office: 505-988-9200
Re: Identifying DoS-attacked IP address(es)
I am wondering how much help backbone providers give in identifying sources of a DoS and deciding what ACL's or rate-limits need to be placed to bring a DoS under control, for their downstream clients. (Assuming it is their downstream clients that are being DoS'ed). I realize this will vary from provider to provider, I am just seeking peoples experiences with this issue. James Edwards [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday Phone support 365 days till 10 pm via the Santa Fe office: 505-988-9200
Input from list on McLeodusa
Dear Nanog list members, We are considering buying transit from McLeod and I would like to get any input, opinions, or experience list members might have about this provider. We are a state wide ISP, seeking to add another DS 3 to our present multi-homed network. Please reply off list and thanks in advance for this and all the great information this list provides. James Edwards [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday Phone support 365 days till 10 pm via the Santa Fe office: 505-988-9200
