Re: Identifying DoS-attacked IP address(es)
Chris, I often see the input-interface load is 100%. André At 16:35 16.12.2002 +0000, Christopher L. Morrow wrote:
On Mon, 16 Dec 2002, Andre Chapuis wrote:
Hi, How do you identify a DoS-attacked IP address(es) on your ingress border router, assuming the latter is a Cisco 12000 ? I used to use ip accounting but they removed it from the S-code.
What info do you have when you are trying to accomplish this mission?
Thanks, André
--------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 ----------------------
--------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 ----------------------
On Mon, 16 Dec 2002, Andre Chapuis wrote:
Chris, I often see the input-interface load is 100%. Andr�
Ok, check the link Barry sent, there is some good info there... Input from the customer is 100%? If this is the case the customer can tell you what is being attacked, no? :) Alternately, you can trim down what you log by first filtering like this: access-l 100 permit tcp any any access-l 100 permit icmp any any access-l 100 permit udp any any access-l 100 permit ip any any int blah1/1 ip access-g 100 in Check the counters to see what protocol is being flooded, then just log or drop it, your choice. A 12000 puts all logging functionality on the line card CPU, not the GRP CPU so the worst you'll do is overload the linecard CPU and drop some packets on the other interfaces of that linecard (only while you are logging that is)... So long as you don't log for an extended period of time no one should notice, and you'll get the info you require. Keep in mind how the syslog functions on a cisco: One entry for an acl match then 5 min packet count updates to that if the matches are the same. This means if hostA is udp flooding hostB on distinct ports only one log entry will be seen for the first 5 mins, OR until you remove the acl which clears out the log entries :) So, sometimes if nothing stands out as being flooded you can remove the acl see a new log entry with 700000 packets matched :)
At 16:35 16.12.2002 +0000, Christopher L. Morrow wrote:
On Mon, 16 Dec 2002, Andre Chapuis wrote:
Hi, How do you identify a DoS-attacked IP address(es) on your ingress border router, assuming the latter is a Cisco 12000 ? I used to use ip accounting but they removed it from the S-code.
What info do you have when you are trying to accomplish this mission?
Thanks, Andr�
--------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 ----------------------
--------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 ----------------------
Sampled netflow, or look at the traceback stuff in later IOS 12.0S versions. Avoid filter lists as the GSR engine cards have a statically limited number of entries. Regards, Neil.
On Mon, 16 Dec 2002, Neil J. McRae wrote:
Sampled netflow, or look at the traceback stuff in later IOS 12.0S versions. Avoid filter lists as the GSR engine cards have a statically limited number of entries.
if something is being attacked it'll show in the 'statically limited' listing, trust me... this is how we do it all day, every day...
if something is being attacked it'll show in the 'statically limited' listing, trust me... this is how we do it all day, every day...
Yes as have we, however you run out of memory/list entries quickly and when that happens CEF gets disabled and it get pretty ugly. This is more an issue for engine 0 and 2 -- Neil J. McRae - Alive and Kicking neil@DOMINO.ORG
On Mon, 16 Dec 2002, Neil J. McRae wrote:
if something is being attacked it'll show in the 'statically limited' listing, trust me... this is how we do it all day, every day...
Yes as have we, however you run out of memory/list entries quickly and when that happens CEF gets disabled and it get pretty ugly. This is more an issue for engine 0 and 2
Hmm, this we have not seen...
FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates a model using the cross-product of: 1) source/destination address distributions 2) packet rate 3) protocol This works very well to detect floods and does not require messing with routers.. Livio. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Neil J. McRae Sent: Monday, December 16, 2002 9:38 AM To: Andre Chapuis Cc: Christopher L. Morrow; nanog@nanog.org Subject: Re: Identifying DoS-attacked IP address(es) Sampled netflow, or look at the traceback stuff in later IOS 12.0S versions. Avoid filter lists as the GSR engine cards have a statically limited number of entries. Regards, Neil.
On Mon, 16 Dec 2002, Livio Ricciulli wrote:
FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates a model using the cross-product of: 1) source/destination address distributions 2) packet rate 3) protocol
But I can't field deploy this 2 continents away at 4am with 10 mins notice...
This works very well to detect floods and does not require messing with routers..
Livio.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Neil J. McRae Sent: Monday, December 16, 2002 9:38 AM To: Andre Chapuis Cc: Christopher L. Morrow; nanog@nanog.org Subject: Re: Identifying DoS-attacked IP address(es)
Sampled netflow, or look at the traceback stuff in later IOS 12.0S versions. Avoid filter lists as the GSR engine cards have a statically limited number of entries.
Regards, Neil.
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 jamesh@cybermesa.com 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
On Mon, 16 Dec 2002, James-lists wrote:
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,
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)
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.
it may vary, but there really should be an expected minimum standard.
James Edwards jamesh@cybermesa.com 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
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 jamesh@cybermesa.com 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
AT&T also does the basics. ACL's, null routes, tracking back to ingress. -james On Mon, 16 Dec 2002, James-lists wrote:
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 jamesh@cybermesa.com 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
On Mon, 16 Dec 2002, Feger, James wrote:
AT&T also does the basics. ACL's, null routes, tracking back to ingress.
as does sprint and C&W. MFN can sometimes help, depends on who you talk to as I recall, and Verio is quick to fix problems... L3 had some problems in the past, my last experience with them was 'ok' though not stellar. I'm having a bit of trouble getting more off the top of my head, aside from the George Mason Computer group that just unplugged a machine in a dorm for me :)
-james
On Mon, 16 Dec 2002, James-lists wrote:
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 jamesh@cybermesa.com 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
On Mon, 16 Dec 2002 21:17:07 GMT, "Christopher L. Morrow" said:
On Mon, 16 Dec 2002, Livio Ricciulli wrote:
FYI, we developed a system that sniffs FE,GE,DS3,OC3-48 POS and creates a model using the cross-product of: 1) source/destination address distributions 2) packet rate 3) protocol But I can't field deploy this 2 continents away at 4am with 10 mins notice...
But that's OK, since you deployed it in last week's maintenance window, to comply with the upper management requirement that they be given advance notice of all unscheduled outages. ;) But seriously - if you had a HandWave 2100 already installed 2 continents away, would interrogating/tweaking/etc the model at 4AM with 10 minutes notice be feasible? (And yes, I know Chris probably has some tools in place before the fact - the question is how many of the REST of you do?) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
participants (7)
-
Andre Chapuis -
Christopher L. Morrow -
Feger, James -
James-lists -
Livio Ricciulli -
neil＠DOMINO.ORG -
Valdis.Kletnieks＠vt.edu