RE: Network Operators and smurf
All, Given the contributions to this thread have been mostly theoretical in nature, I'd like to share an experience of mine that in some ways negates some of the propsed solutions to smurf attacks in the context of smaller ISPs. Recently, one of our downstream customers was subject to a smurf attack, and we placed an access-list on our egress interface to the customers network. The customer hangs of an SMDS cloud - our link to the cloud is at 34 Mbps, his T1. We were blocking echo replies destined for his network. We are connected upstream at 45Mbps. As the attack intensified, router CPU Utilization jumped to 99%, and the input queue on our inbound HSSI was at 75/75. We started dropping packets at a rate of about 7000/sec. The attacks were coming in from all over the world. The NetFlow cache was growing at an alarming rate, and, after a while the HSSI just DIED. As the HSSI bounced, our BGP session bounced with it, causing some mild route flapping (Not vaccilating enough to be damped, but enough nonetheless). Eventually the attack subsided, and all went back to normal, but for a period of time, say 10 minutes, we had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees. We decided that parsing NetFlow logs would give us a better idea of who was amplifying the attacks, and with a simple shell script, we were able to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. We are planning on sending emails to these customers to ask them to stop amplifying smurfs (script does that too), because this is unacceptable. My point, then is this: Filtering echo replies is/can be a futile attempt at preventing this type of attack. I watched a 7507 die defending against one attack. More recently, we got hit so hard that the router was screaming without ANY access-lists blocking ICMP echo-replies, perhaps because there was no real fast-switching taking place (each source is different, so the first packet is process switched. Our NetFlow cache went from 3900 flows to 27000 flows in about 4 mins.) And, as we were not amplifying the smurfs, source address verification is a moot point. I am all for allowing these netblocks time to implement this type of filtering (layer3 to layer2 broadcast translation prevention), but not for very long. It appears the best way to light a fire under someones rear end is to publicly shame them into acting. For those who don't act quickly enough, there can be no quarter. If I appear hostile, I am... PS If anyone has similar experiences, please share them, as there has already been enough rhetoric filling this thread, and it is clear that everyone knows the solution lies at edge and beyond, not in the core. -Christian Martin
On Sun, 26 Apr 1998, Martin, Christian wrote: ==>network. We are connected upstream at 45Mbps. As the attack ==>intensified, router CPU Utilization jumped to 99%, and the input queue ==>on our inbound HSSI was at 75/75. We started dropping packets at a rate ==>of about 7000/sec. The attacks were coming in from all over the world. Have you read the smurf document found at http://www.quadrunner.com/~chuegen/smurf.txt? I'd be interested to know what version of code you were running. I've seen a provider drop over 120 Mbps of smurf traffic in access-lists for over an hour and the routers weren't affected one bit. IOS CA & CC code 11.1(13.5) and later have a fix to the code which handles access-list drops--called "fast drop"--which fixes some inefficiencies in packet handling. ***READ*** the document at the URL above. It's amazing how much that URL has been advertised, through all the advisories, through the NOCs, etc., but with the ongoing thread over the last few weeks it almost appears that a lot of people either haven't heard about it or haven't read it. Of course, it's been put into mail messages 9 times on NANOG already: chuegen@quad:3:~>grep "quadrunner.com" mail/nanog | grep "smurf" | wc -l 9 /cah
Since I have started blacklisting people, the list has grown to more than 40 netwroks. However, only ONE, and that one was very short (< 5 minutes) smurf has taken down a customer circuit or our IRC server since the last edits were made to the amplifier list over a week ago. I'm going to try to post a web page on this tonight. What we're doing here WORKS. It inconveniences a few people (those who amplify smurfs), but it WORKS and it STOPS the smurf attacks from burying your connections. Our core routers don't even get mildly bothered doing the discards. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Sun, Apr 26, 1998 at 02:08:04AM -0400, Martin, Christian wrote:
All,
Given the contributions to this thread have been mostly theoretical in nature, I'd like to share an experience of mine that in some ways negates some of the propsed solutions to smurf attacks in the context of smaller ISPs.
Recently, one of our downstream customers was subject to a smurf attack, and we placed an access-list on our egress interface to the customers network. The customer hangs of an SMDS cloud - our link to the cloud is at 34 Mbps, his T1. We were blocking echo replies destined for his network. We are connected upstream at 45Mbps. As the attack intensified, router CPU Utilization jumped to 99%, and the input queue on our inbound HSSI was at 75/75. We started dropping packets at a rate of about 7000/sec. The attacks were coming in from all over the world. The NetFlow cache was growing at an alarming rate, and, after a while the HSSI just DIED. As the HSSI bounced, our BGP session bounced with it, causing some mild route flapping (Not vaccilating enough to be damped, but enough nonetheless). Eventually the attack subsided, and all went back to normal, but for a period of time, say 10 minutes, we had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees.
We decided that parsing NetFlow logs would give us a better idea of who was amplifying the attacks, and with a simple shell script, we were able to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. We are planning on sending emails to these customers to ask them to stop amplifying smurfs (script does that too), because this is unacceptable.
My point, then is this: Filtering echo replies is/can be a futile attempt at preventing this type of attack. I watched a 7507 die defending against one attack. More recently, we got hit so hard that the router was screaming without ANY access-lists blocking ICMP echo-replies, perhaps because there was no real fast-switching taking place (each source is different, so the first packet is process switched. Our NetFlow cache went from 3900 flows to 27000 flows in about 4 mins.) And, as we were not amplifying the smurfs, source address verification is a moot point. I am all for allowing these netblocks time to implement this type of filtering (layer3 to layer2 broadcast translation prevention), but not for very long. It appears the best way to light a fire under someones rear end is to publicly shame them into acting. For those who don't act quickly enough, there can be no quarter.
If I appear hostile, I am...
PS
If anyone has similar experiences, please share them, as there has already been enough rhetoric filling this thread, and it is clear that everyone knows the solution lies at edge and beyond, not in the core.
-Christian Martin
What config options/access-lists are you using. If Martin says his routers choked, and you say yours don't, I'd like to know (as would anyone, I think) what you are running and how you are running it. I assume you are using access-lists. Are you using NetFlow? On which interfaces? Are you blocking inbound echo-reply? To where? Everywhere or just your core network? The problem I'm faced with, is I'm currently blocking ICMP to my core networks, NOT to customers or dialup ports. They will REALLY bitch if I start doing that. I'm going to change it to block echo-reply to those networks only. Currently, the measures "I" am taking is: o outbound access-list permitting ONLY networks which source on our router. o inbound access-list denying ICMP (which will be modifiec to block ICMP echo-reply only) to core networks along with .0 and .255 address blocks. o no ip directed-broadcast on ALL interfaces o ip route-cache flow (so I can get some information on these *ssholes) What else do I need?! What am I doing wrong with the above (if anything) TiA... On Sun, 26 Apr 1998, Karl Denninger wrote: :Since I have started blacklisting people, the list has grown to more than 40 :netwroks. : :However, only ONE, and that one was very short (< 5 minutes) smurf has taken :down a customer circuit or our IRC server since the last edits were made to :the amplifier list over a week ago. : :I'm going to try to post a web page on this tonight. What we're doing here :WORKS. It inconveniences a few people (those who amplify smurfs), but it :WORKS and it STOPS the smurf attacks from burying your connections. : :Our core routers don't even get mildly bothered doing the discards. : :-- :-- :Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin :http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV : | NEW! Corporate ISDN Prices dropped by up to 50%! :Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS :Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost : :On Sun, Apr 26, 1998 at 02:08:04AM -0400, Martin, Christian wrote: :> All, :> :> Given the contributions to this thread have been mostly theoretical in :> nature, I'd like to share an experience of mine that in some ways :> negates some of the propsed solutions to smurf attacks in the context of :> smaller ISPs. :> :> Recently, one of our downstream customers was subject to a smurf attack, :> and we placed an access-list on our egress interface to the customers :> network. The customer hangs of an SMDS cloud - our link to the cloud is :> at 34 Mbps, his T1. We were blocking echo replies destined for his :> network. We are connected upstream at 45Mbps. As the attack :> intensified, router CPU Utilization jumped to 99%, and the input queue :> on our inbound HSSI was at 75/75. We started dropping packets at a rate :> of about 7000/sec. The attacks were coming in from all over the world. :> The NetFlow cache was growing at an alarming rate, and, after a while :> the HSSI just DIED. As the HSSI bounced, our BGP session bounced with :> it, causing some mild route flapping (Not vaccilating enough to be :> damped, but enough nonetheless). Eventually the attack subsided, and :> all went back to normal, but for a period of time, say 10 minutes, we :> had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees. :> :> We decided that parsing NetFlow logs would give us a better idea of who :> was amplifying the attacks, and with a simple shell script, we were able :> to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. :> We are planning on sending emails to these customers to ask them to stop :> amplifying smurfs (script does that too), because this is unacceptable. :> :> My point, then is this: Filtering echo replies is/can be a futile :> attempt at preventing this type of attack. I watched a 7507 die :> defending against one attack. More recently, we got hit so hard that :> the router was screaming without ANY access-lists blocking ICMP :> echo-replies, perhaps because there was no real fast-switching taking :> place (each source is different, so the first packet is process :> switched. Our NetFlow cache went from 3900 flows to 27000 flows in :> about 4 mins.) And, as we were not amplifying the smurfs, source :> address verification is a moot point. I am all for allowing these :> netblocks time to implement this type of filtering (layer3 to layer2 :> broadcast translation prevention), but not for very long. It appears :> the best way to light a fire under someones rear end is to publicly :> shame them into acting. For those who don't act quickly enough, there :> can be no quarter. :> :> If I appear hostile, I am... :> :> PS :> :> If anyone has similar experiences, please share them, as there has :> already been enough rhetoric filling this thread, and it is clear that :> everyone knows the solution lies at edge and beyond, not in the core. :> :> -Christian Martin : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
I block *ALL* packets from any netblock which is implicated as a smurf amplifier, on the first offense. I will remove those blocks when I can PROVE that they can no longer be used as a smurf amplifier. To date, NOBODY on the list has come forward and said "we've audited and fixed, please remove the block". PSU (which is on the list) said "we're looking into it" but that was more than two weeks ago! How long does it take to telnet into your routers and check the ethernet interfaces for the correct configuration? A day or so? Perhaps, even if you have a HUGE netwokr. It does not require two weeks. Blocking just ICMP is pointless - block EVERYTHING. The only way we ever get this fixed is to make it HURT to be on the blacklist. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Sun, Apr 26, 1998 at 12:29:19PM -0400, Jason Lixfeld wrote:
What config options/access-lists are you using. If Martin says his routers choked, and you say yours don't, I'd like to know (as would anyone, I think) what you are running and how you are running it. I assume you are using access-lists. Are you using NetFlow? On which interfaces? Are you blocking inbound echo-reply? To where? Everywhere or just your core network? The problem I'm faced with, is I'm currently blocking ICMP to my core networks, NOT to customers or dialup ports. They will REALLY bitch if I start doing that. I'm going to change it to block echo-reply to those networks only.
Currently, the measures "I" am taking is:
o outbound access-list permitting ONLY networks which source on our router.
o inbound access-list denying ICMP (which will be modifiec to block ICMP echo-reply only) to core networks along with .0 and .255 address blocks.
o no ip directed-broadcast on ALL interfaces
o ip route-cache flow (so I can get some information on these *ssholes)
What else do I need?! What am I doing wrong with the above (if anything)
TiA...
On Sun, 26 Apr 1998, Karl Denninger wrote:
:Since I have started blacklisting people, the list has grown to more than 40 :netwroks. : :However, only ONE, and that one was very short (< 5 minutes) smurf has taken :down a customer circuit or our IRC server since the last edits were made to :the amplifier list over a week ago. : :I'm going to try to post a web page on this tonight. What we're doing here :WORKS. It inconveniences a few people (those who amplify smurfs), but it :WORKS and it STOPS the smurf attacks from burying your connections. : :Our core routers don't even get mildly bothered doing the discards. : :-- :-- :Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin :http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV : | NEW! Corporate ISDN Prices dropped by up to 50%! :Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS :Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost : :On Sun, Apr 26, 1998 at 02:08:04AM -0400, Martin, Christian wrote: :> All, :> :> Given the contributions to this thread have been mostly theoretical in :> nature, I'd like to share an experience of mine that in some ways :> negates some of the propsed solutions to smurf attacks in the context of :> smaller ISPs. :> :> Recently, one of our downstream customers was subject to a smurf attack, :> and we placed an access-list on our egress interface to the customers :> network. The customer hangs of an SMDS cloud - our link to the cloud is :> at 34 Mbps, his T1. We were blocking echo replies destined for his :> network. We are connected upstream at 45Mbps. As the attack :> intensified, router CPU Utilization jumped to 99%, and the input queue :> on our inbound HSSI was at 75/75. We started dropping packets at a rate :> of about 7000/sec. The attacks were coming in from all over the world. :> The NetFlow cache was growing at an alarming rate, and, after a while :> the HSSI just DIED. As the HSSI bounced, our BGP session bounced with :> it, causing some mild route flapping (Not vaccilating enough to be :> damped, but enough nonetheless). Eventually the attack subsided, and :> all went back to normal, but for a period of time, say 10 minutes, we :> had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees. :> :> We decided that parsing NetFlow logs would give us a better idea of who :> was amplifying the attacks, and with a simple shell script, we were able :> to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. :> We are planning on sending emails to these customers to ask them to stop :> amplifying smurfs (script does that too), because this is unacceptable. :> :> My point, then is this: Filtering echo replies is/can be a futile :> attempt at preventing this type of attack. I watched a 7507 die :> defending against one attack. More recently, we got hit so hard that :> the router was screaming without ANY access-lists blocking ICMP :> echo-replies, perhaps because there was no real fast-switching taking :> place (each source is different, so the first packet is process :> switched. Our NetFlow cache went from 3900 flows to 27000 flows in :> about 4 mins.) And, as we were not amplifying the smurfs, source :> address verification is a moot point. I am all for allowing these :> netblocks time to implement this type of filtering (layer3 to layer2 :> broadcast translation prevention), but not for very long. It appears :> the best way to light a fire under someones rear end is to publicly :> shame them into acting. For those who don't act quickly enough, there :> can be no quarter. :> :> If I appear hostile, I am... :> :> PS :> :> If anyone has similar experiences, please share them, as there has :> already been enough rhetoric filling this thread, and it is clear that :> everyone knows the solution lies at edge and beyond, not in the core. :> :> -Christian Martin :
-- Regards,
Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net
--------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
I block *ALL* packets from any netblock which is implicated as a smurf amplifier, on the first offense.
I will remove those blocks when I can PROVE that they can no longer be used as a smurf amplifier. To date, NOBODY on the list has come forward and said "we've audited and fixed, please remove the block".
PSU (which is on the list) said "we're looking into it" but that was more than two weeks ago! How long does it take to telnet into your routers and check the ethernet interfaces for the correct configuration? A day or so? Perhaps, even if you have a HUGE netwokr.
It does not require two weeks.
First, I am not speaking for Penn State, although I am a member of the University's CERT team. Second, I am not asking that any block be removed. Such a request would have to come from others at PSU. It may require two weeks when you have to deal with the multiple domains of control one finds at this University. This means that you can not just walk up to some machines and pull the plug without have large quantities of excrement start flowing rapidly down hill from on high and sweeping everything in it's path away. The security office been very active in checking out which routers are still vulnerable. Unfortunately there are a number of `routers' (read multi-homed UNIX systems) that are not directly connected to the university's backbone that have not been secured. These machines usually are being administered by a grad student who is more interested in study for comprehensive exams than in installing the necessary patches to fix the problem. In that case the security office will usually offer to assist in securing these systems. Sometimes that offer will not be accepted, or it may take a week for everyone to come to an agreement as to what needs to be done. So, yes, it may very well take more that two weeks to complete. But, I believe that all routers that make up the University backbone and are maintained by the Office of Telecommunication have been secured. -- Dan Ehrlich
Blocking just ICMP is pointless - block EVERYTHING. The only way we ever get this fixed is to make it HURT to be on the blacklist.
-- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Sun, Apr 26, 1998 at 12:29:19PM -0400, Jason Lixfeld wrote:
What config options/access-lists are you using. If Martin says his routers choked, and you say yours don't, I'd like to know (as would anyone, I think) what you are running and how you are running it. I assume you are using access-lists. Are you using NetFlow? On which interfaces? Are you blocking inbound echo-reply? To where? Everywhere or just your core network? The problem I'm faced with, is I'm currently blocking ICMP to my core networks, NOT to customers or dialup ports. They will REALLY bitch if I start doing that. I'm going to change it to block echo-reply to those networks only.
Currently, the measures "I" am taking is:
o outbound access-list permitting ONLY networks which source on our router.
o inbound access-list denying ICMP (which will be modifiec to block ICMP echo-reply only) to core networks along with .0 and .255 address blocks.
o no ip directed-broadcast on ALL interfaces
o ip route-cache flow (so I can get some information on these *ssholes)
What else do I need?! What am I doing wrong with the above (if anything)
TiA...
On Sun, 26 Apr 1998, Karl Denninger wrote:
:Since I have started blacklisting people, the list has grown to more than 4
0
:netwroks. : :However, only ONE, and that one was very short (< 5 minutes) smurf has take n :down a customer circuit or our IRC server since the last edits were made to :the amplifier list over a week ago. : :I'm going to try to post a web page on this tonight. What we're doing here :WORKS. It inconveniences a few people (those who amplify smurfs), but it :WORKS and it STOPS the smurf attacks from burying your connections. : :Our core routers don't even get mildly bothered doing the discards. : :-- :-- :Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin :http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/D OV : | NEW! Corporate ISDN Prices dropped by up to 50%! :Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUN TS :Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no co st : :On Sun, Apr 26, 1998 at 02:08:04AM -0400, Martin, Christian wrote: :> All, :> :> Given the contributions to this thread have been mostly theoretical in :> nature, I'd like to share an experience of mine that in some ways :> negates some of the propsed solutions to smurf attacks in the context of :> smaller ISPs. :> :> Recently, one of our downstream customers was subject to a smurf attack, :> and we placed an access-list on our egress interface to the customers :> network. The customer hangs of an SMDS cloud - our link to the cloud is :> at 34 Mbps, his T1. We were blocking echo replies destined for his :> network. We are connected upstream at 45Mbps. As the attack :> intensified, router CPU Utilization jumped to 99%, and the input queue :> on our inbound HSSI was at 75/75. We started dropping packets at a rate :> of about 7000/sec. The attacks were coming in from all over the world. :> The NetFlow cache was growing at an alarming rate, and, after a while :> the HSSI just DIED. As the HSSI bounced, our BGP session bounced with :> it, causing some mild route flapping (Not vaccilating enough to be :> damped, but enough nonetheless). Eventually the attack subsided, and :> all went back to normal, but for a period of time, say 10 minutes, we :> had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees. :> :> We decided that parsing NetFlow logs would give us a better idea of who :> was amplifying the attacks, and with a simple shell script, we were able :> to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. :> We are planning on sending emails to these customers to ask them to stop :> amplifying smurfs (script does that too), because this is unacceptable. :> :> My point, then is this: Filtering echo replies is/can be a futile :> attempt at preventing this type of attack. I watched a 7507 die :> defending against one attack. More recently, we got hit so hard that :> the router was screaming without ANY access-lists blocking ICMP :> echo-replies, perhaps because there was no real fast-switching taking :> place (each source is different, so the first packet is process :> switched. Our NetFlow cache went from 3900 flows to 27000 flows in :> about 4 mins.) And, as we were not amplifying the smurfs, source :> address verification is a moot point. I am all for allowing these :> netblocks time to implement this type of filtering (layer3 to layer2 :> broadcast translation prevention), but not for very long. It appears :> the best way to light a fire under someones rear end is to publicly :> shame them into acting. For those who don't act quickly enough, there :> can be no quarter. :> :> If I appear hostile, I am... :> :> PS :> :> If anyone has similar experiences, please share them, as there has :> already been enough rhetoric filling this thread, and it is clear that :> everyone knows the solution lies at edge and beyond, not in the core. :> :> -Christian Martin :
-- Regards,
Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net
--------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
-- Dan Ehrlich - Systems Analyst - PSU Computer Science and Engineering "Universities should be safe havens where ruthless examination of realities will not be distorted by the aim to please or inhibited by the risk of displeasure." - Kingman Brewster
On Sun, Apr 26, 1998 at 04:50:11PM -0400, Daniel R Ehrlich put this into my mailbox:
First, I am not speaking for Penn State, although I am a member of the University's CERT team. Second, I am not asking that any block be removed. Such a request would have to come from others at PSU.
It may require two weeks when you have to deal with the multiple domains of control one finds at this University. This means that you can not just walk up to some machines and pull the plug without have large quantities of excrement start flowing rapidly down hill from on high and sweeping everything in it's path away.
You may already know this, but it doesn't hurt to reiterate. I've had to deal with this to a certain extent at a local university. What you need to do is to draft a security policy that explains what action you can take when a machine connected to the campus network is used in some sort of hack/DoS attempt. The policy should say something like, "We will attempt to contact the maintainer of the box. If we cannot contact the maintainer or the maintainer cannot repair the box within 6 hours, we will disconnect the box from the network." Modify as required for your site. Then, go to the highest level of management you can, without pissing too many folks off (yes, university politics suck). Get them to sign off on it, and keep going all the way up to the chancellor, or whoever the Big Guy is. Make sure that you explain that every time someone uses a University box to hack or DoS, the university is wide-open for lawsuits and such - especially if folks knew about the problem and didn't take action. Then, you have the ammunition you need to disconnect problem boxes when they crop up. If the Whiny Researcher In Question throws a fit, wave the policy in their face and explain that they should have thought of that before putting an insecure box on the net. (You might also discuss with the researcher the fact that anyone hacking into their box can steal their data; I understand research types are very protective of their data, and paranoid that someone else might get ahold of it. This might at least encourage them to secure their boxes better.) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Aristotle was not Belgian. The central Founder, the DALnet IRC Network message of Buddhism is not 'every man for himself.' And the London Underground e-mail: dalvenjah@dal.net is not a political movement." WWW: http://www.dal.net/~dalvenjah/ -- Wanda, "A Fish Called Wanda" whois: SN90 Try DALnet! http://www.dal.net/
Thus spake Karl Denninger
I will remove those blocks when I can PROVE that they can no longer be used as a smurf amplifier. To date, NOBODY on the list has come forward and said "we've audited and fixed, please remove the block".
I have got one site to fix their routers. It's the DISA Information Systems Center on netblock 131.80.0.0. I explained the situation and gave them a few pointers. A few days laterthey had fixed it and they no longer act as an amplifier. Very satisfying. Another one, 142.21.0.0, bounced my email but they seem to have fixed their routers anyway. Perhaps someone local called them up and harrassed them about it.
PSU (which is on the list) said "we're looking into it" but that was more than two weeks ago! How long does it take to telnet into your routers and check the ethernet interfaces for the correct configuration? A day or so? Perhaps, even if you have a HUGE netwokr.
Perhaps when pointing at problem networks, just mention the netblock. That way we can compare it with our own lists. Here's one that seems particularly troublesome and I know it is in your list as well. ----129.115.255.255 PING Statistics---- 2 packets transmitted, 2 packets received, +110 duplicates, 0% packet loss In Karl's list route: 129.115.0.0/16 descr: University of Texas at San Antonio descr: 7000 NW Loop 1604 descr: San Antonio descr: TX 78285, USA origin: AS3354 comm-list: COMM_NSFNET advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS3354 changed: selina@ans.net 951010 source: RADB University of Texas at San Antonio (UTSA-DOM) Computing Resources 7000 NW Loop 1604 San Antonio, TX 78285 Domain Name: UTSA.EDU Administrative Contact: Massey, John (JM828) CRJWM@UTSA86.UTSA.EDU (512) 691-4555 Technical Contact, Zone Contact: Dominguez, Joaquin (JD386) 3CRJXD@UTSA86.UTSA.EDU (512) 691-4555 Record last updated on 09-Sep-93. Record created on 14-Dec-90. Database last updated on 15-Apr-98 03:43:36 EDT. Domain servers in listed order: JULIET.UTSA.EDU 129.115.102.150 NS1.OAR.NET 192.88.193.144 Looks to me like they have been running on autopilot for 5 years. I sent email to the contact addresses and, since I had doubts that they were valid addresses, I copied root and hostmaster. Root and hostmaster bounced and the others seem to have been completely ignored. Perhaps someone closer to them can poke around and see what the situation is. This is great because each success has a significant overall effect. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Sun, 26 Apr 1998, D'Arcy J.M. Cain wrote:
Here's one that seems particularly troublesome and I know it is in your list as well.
----129.115.255.255 PING Statistics---- 2 packets transmitted, 2 packets received, +110 duplicates, 0% packet loss In Karl's list
Look on the bright side, it could have been 64,000 duplicates. ;-}
descr: University of Texas at San Antonio descr: San Antonio descr: TX 78285, USA
Perhaps someone closer to them can poke around and see what the situation is.
I am closer (we share the same backbone). I forwarded your note to my contact over there. Your good net neighbor, -bryan hostmaster@capnet.state.tx.us
On Mon, Apr 27, 1998 at 11:33:26AM -0500, Bryan Bradsby wrote:
On Sun, 26 Apr 1998, D'Arcy J.M. Cain wrote:
Here's one that seems particularly troublesome and I know it is in your list as well.
----129.115.255.255 PING Statistics---- 2 packets transmitted, 2 packets received, +110 duplicates, 0% packet loss In Karl's list
Look on the bright side, it could have been 64,000 duplicates. ;-}
Aieeeeeeeee! :-)
descr: University of Texas at San Antonio descr: San Antonio descr: TX 78285, USA
Perhaps someone closer to them can poke around and see what the situation is.
I am closer (we share the same backbone). I forwarded your note to my contact over there.
Your good net neighbor, -bryan hostmaster@capnet.state.tx.us
Well, I don't expect much. On the other hand, it appears that at least a few of the networks on my "hall of shame" list are cleaning up their acts. If you're one of those folks, please contact our NOC and let them know so we can take you off the router block and web listing. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Thus spake Bryan Bradsby
----129.115.255.255 PING Statistics---- 2 packets transmitted, 2 packets received, +110 duplicates, 0% packet loss In Karl's list
Look on the bright side, it could have been 64,000 duplicates. ;-}
Well, I don't know that that little test is completely accurate. As soon as the first packet from the second ping arrives it stops reporting on the first packet. That's why you do the test with the -c2 flag in the first place.
descr: University of Texas at San Antonio descr: San Antonio descr: TX 78285, USA
Perhaps someone closer to them can poke around and see what the situation is.
I am closer (we share the same backbone). I forwarded your note to my contact over there.
Great. See if you can get them to update their whois record to include someone who can respond to email while you are at it. Thanks. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Sun, 26 Apr 1998, Jason Lixfeld wrote:
Since I have started blacklisting people, the list has grown to more than 40
Currently, the measures "I" am taking is: . . . What else do I need?! What am I doing wrong with the above (if anything)
One obvious thing missing from your strategy is that you aren't blacklisting the SMURF amplifiers by publicly announcing who they are on this list and by not blocking the entire netblock in which they reside. That is what Karl is doing. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
participants (9)
-
Bryan Bradsby -
Craig A. Huegen -
Dalvenjah FoxFire -
Daniel R Ehrlich -
darcy＠druid.net -
Jason Lixfeld -
Karl Denninger -
Martin, Christian -
Michael Dillon