Government scrutiny is headed our way http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html The feds are worried that it is too hard to track down cyber attackers. Although the article doesn't say this explicitly I expect that it won't be long before we see politicians calling for some sort of mandated tracing capabilities between network providers And since IOPS http://www.iops.org/ is hosted by a government funded agency located on the outskirts of DC, I expect that it will be involved in this whole thing. If we could track attacks to their source more quickly, then government would not feel the need to intervene. This may require some changes to router software but unless network operators ask for the changes, the manufacturers will not do it. We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting. We have seen that when misconfigured equipment can be quickly identified, such as the smurf amplifiers, then we can apply pressure and get things fixed. Similarly if we can quickly identify the source of a spoofed source address attack then we can apply pressure to get filters in place and have people arrested or secure an insecure machine as the case may be. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
On Tue, Jun 16, 1998 at 10:44:47AM -0700, Michael Dillon wrote:
Government scrutiny is headed our way http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html
The feds are worried that it is too hard to track down cyber attackers. Although the article doesn't say this explicitly I expect that it won't be long before we see politicians calling for some sort of mandated tracing capabilities between network providers
And since IOPS http://www.iops.org/ is hosted by a government funded agency located on the outskirts of DC, I expect that it will be involved in this whole thing.
If we could track attacks to their source more quickly, then government would not feel the need to intervene. This may require some changes to router software but unless network operators ask for the changes, the manufacturers will not do it.
We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting.
We have seen that when misconfigured equipment can be quickly identified, such as the smurf amplifiers, then we can apply pressure and get things fixed. Similarly if we can quickly identify the source of a spoofed source address attack then we can apply pressure to get filters in place and have people arrested or secure an insecure machine as the case may be.
-- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
It is about goddamn time, and I hope the government DOES get involved. Try calling ANY of the major NOCs to get a smurf traced. Good luck. I have yet to have even attacks going on for more than an hour successfully traced back to their source. -- -- 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 Tue, Jun 16, 1998 at 01:14:18PM -0500, Karl Denninger wrote:
It is about goddamn time, and I hope the government DOES get involved.
Obviously you're out of meds, Karl. :-)
Try calling ANY of the major NOCs to get a smurf traced. Good luck. I have yet to have even attacks going on for more than an hour successfully traced back to their source.
Didn't say there wasn't a problem. Just don't let's go _there_, ok? -- j -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Tue, Jun 16, 1998 at 02:45:06PM -0400, Jay R. Ashworth wrote:
On Tue, Jun 16, 1998 at 01:14:18PM -0500, Karl Denninger wrote:
It is about goddamn time, and I hope the government DOES get involved.
Obviously you're out of meds, Karl. :-)
Try calling ANY of the major NOCs to get a smurf traced. Good luck. I have yet to have even attacks going on for more than an hour successfully traced back to their source.
Didn't say there wasn't a problem. Just don't let's go _there_, ok?
No, we need to go there. "Voluntary" cooperation isn't working, because the major NOCs don't cooperate. Like ever. I've given up reporting these and just block the amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a NOC person on the phone who either refuses assistance or refuses to escalate the matter to someone who knows what to do. Since they don't cooperate, the only two defenses are: 1. Black-hole detected amplifier networks (what we're doing here). 2. Government intervention to slap penalties on those who don't cooperate with such reports, and vendors who don't make it possible for NOCs to cooperate *reasonably*. I'd really like it if this didn't have to happen. Seriously. But as long as network operators decide to play stupid when they are hit with these requests, and/or just tell you to bite it (and I've heard both) then the two above steps are both reasonable and necessary. -- -- 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 Tue, Jun 16, 1998 at 02:10:29PM -0500, Karl Denninger wrote:
Didn't say there wasn't a problem. Just don't let's go _there_, ok?
No, we need to go there.
"Voluntary" cooperation isn't working, because the major NOCs don't cooperate. Like ever. I've given up reporting these and just block the amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a NOC person on the phone who either refuses assistance or refuses to escalate the matter to someone who knows what to do.
Since they don't cooperate, the only two defenses are:
1. Black-hole detected amplifier networks (what we're doing here).
Indeed. And what I think is the best approach. Kick 'em in the nads^Wnets.
2. Government intervention to slap penalties on those who don't cooperate with such reports, and vendors who don't make it possible for NOCs to cooperate *reasonably*.
Governments have a demonstrated habit of not building such constraints so as to incent (I hate that word, but can't think of an acceptable synonym just now) the _right_ changes in behavior patterns -- this is the same discussion as was just had about Usenet cancel messages a couple hours ago.
I'd really like it if this didn't have to happen. Seriously. But as long as network operators decide to play stupid when they are hit with these requests, and/or just tell you to bite it (and I've heard both) then the two above steps are both reasonable and necessary.
I think that the approach here is to find the executive level people to whom those people report, and explain to _them_ that if they don't get their houses in order, the government is likely to do it for them. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Tue, Jun 16, 1998 at 03:21:11PM -0400, Jay R. Ashworth wrote:
On Tue, Jun 16, 1998 at 02:10:29PM -0500, Karl Denninger wrote:
Didn't say there wasn't a problem. Just don't let's go _there_, ok?
No, we need to go there.
"Voluntary" cooperation isn't working, because the major NOCs don't cooperate. Like ever. I've given up reporting these and just block the amplifiers, because it is POINTLESS to spend 30 minutes on hold to get a NOC person on the phone who either refuses assistance or refuses to escalate the matter to someone who knows what to do.
Since they don't cooperate, the only two defenses are:
1. Black-hole detected amplifier networks (what we're doing here).
Indeed. And what I think is the best approach. Kick 'em in the nads^Wnets.
Not really. The best approach is to nail a few of these folks with felony indictments for the denial of service attacks, and the theft of the amplifier network's services. That would stop this practice cold.
2. Government intervention to slap penalties on those who don't cooperate with such reports, and vendors who don't make it possible for NOCs to cooperate *reasonably*.
Governments have a demonstrated habit of not building such constraints so as to incent (I hate that word, but can't think of an acceptable synonym just now) the _right_ changes in behavior patterns -- this is the same discussion as was just had about Usenet cancel messages a couple hours ago.
I'd really like it if this didn't have to happen. Seriously. But as long as network operators decide to play stupid when they are hit with these requests, and/or just tell you to bite it (and I've heard both) then the two above steps are both reasonable and necessary.
I think that the approach here is to find the executive level people to whom those people report, and explain to _them_ that if they don't get their houses in order, the government is likely to do it for them.
That's not my (or your) job. If they're not on notice by now, they deserve what they get. Frankly, I hope that the government does their job for them due to the simple fact that I'm getting tired of taking defensive postures on this thing. Its time for network operators to get aggressive. We already filter on our dial connections (including ISDN) to prevent out-of-range addresses from being spoofed. THIS IS SIMPLE TO DO ON ALL MODERN HARDWARE. Yet we're one of the VERY few ISPs who bother with this. We're looking into implementing filtering on ALL ingress paths, including dedicated line, as soon as we can come up with a tool to manage it automatically. The dial side is trivial and as such I can't understand how ANYONE can have an excuse for not doing that - at this point. -- -- 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 Tue, 16 Jun 1998, Karl Denninger wrote:
We're looking into implementing filtering on ALL ingress paths, including dedicated line, as soon as we can come up with a tool to manage it automatically. The dial side is trivial and as such I can't understand how ANYONE can have an excuse for not doing that - at this point.
For those who don't bother filtering "because it's too hard or too complicated", if you don't want or can't afford to put the work into tight ingress filtering on all interfaces, it's really easy to just say "our IP blocks are A, B, and C. Allow input with source addresses in A, B, or C, deny everything else." That will at least protect the rest of the internet from your lusers. On IOS, aren't packets going through ip access-group filters (that don't do logging) fast switched as of some point in 11.2? If ingress filtering no longer has to put a huge burdon on router CPUs, it would be nice to see ingress filtering on the routers backbone providers talk to customers with. Don't tell me it's too much of an administrative problem. None of my current backbone providers will listen to BGP advertisements that haven't been arranged in advance (either by email or phone). If I can't advertise the space, why should I be allowed to spoof source addresses from it? ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Wed, Jun 17, 1998 at 12:45:07AM -0400, Jon Lewis wrote:
On Tue, 16 Jun 1998, Karl Denninger wrote:
We're looking into implementing filtering on ALL ingress paths, including dedicated line, as soon as we can come up with a tool to manage it automatically. The dial side is trivial and as such I can't understand how ANYONE can have an excuse for not doing that - at this point.
For those who don't bother filtering "because it's too hard or too complicated", if you don't want or can't afford to put the work into tight ingress filtering on all interfaces, it's really easy to just say "our IP blocks are A, B, and C. Allow input with source addresses in A, B, or C, deny everything else." That will at least protect the rest of the internet from your lusers.
Right. That's what we do on the dial plant today, because there isn't a syntax available on our RAS hardware which says "allow anything with this RADIUS assigned or dynamic address block (depending on the account) and deny everything else". So we have to relax the filters to be "allow anything from netblocks A, B, and C, block everything else" since the syntax we really want isn't available. We do that for all dial and ISDN inbound connections today, and have been for a long time. Still, that's good enough. You can't launch a DOS attack against ANOTHER provider from our plant this way. We also have directed broadcasts shut off network-wide, so attempts to bounce pingstorms off our internal plant (even to internal targets) don't work either. That's the 95th percentile solution, and is a hell of a lot more than most other ISPs do. Most don't do ANY filtering of any kind. I've tested this against accounts on other providers, and most will happily forward packets with ANY source address from dial customers. Add throw-away accounts to that and you've just created the existing monster called "The Smurf". Wow, I wonder how that happened?
On IOS, aren't packets going through ip access-group filters (that don't do logging) fast switched as of some point in 11.2? If ingress filtering no longer has to put a huge burdon on router CPUs, it would be nice to see ingress filtering on the routers backbone providers talk to customers with. Don't tell me it's too much of an administrative problem. None of my current backbone providers will listen to BGP advertisements that haven't been arranged in advance (either by email or phone). If I can't advertise the space, why should I be allowed to spoof source addresses from it?
We've yet to have trouble traced to any of our dedicated line customers. If we had, we'd have implemented the filtering a LONG time ago, administrative pain in the ass or not! We HAVE had the alarms go off for packets which were spoofed from dial customers (and were blocked by the filters). That's a great way to get your account whacked around here (get caught attempting to launch a DOS attack at someone) Our approach on the dial plant is simple - if its not from one of our netblocks, it doesn't go out - period. Now you can still spoof, but only an address that is local to us (and thus can be traced completely on a local basis) If your dial plant is all dynamic address (ours is mixed) then the filters can be a lot tighter - if its not in the pool for that RAS device, it gets bounced. ALL RAS devices in common use today (ie: Lucent, ASCEND, CISCO, etc) have this capability, and virtually all previous-generation ones (ie: Netblazers) can do this as well. And if you're unlucky enough to have something that can't, you can STILL do the same filtering at the boundary between the RAS and the rest of your network (like the CISCO that feeds the plant that your RAS boxes sit on). There simply is no excuse for not doing ingres filtering for dial customers in today's environment. The bitrates are low enough and the RAS boxes good enough that claims that "I don't have the CPU for it" are plain bullshit, even on last-generation hardware (ie: Netblazers). I understand the CPU problems filtering ingress on a DS-3 to a customer, for example, if the box has a bunch of other interfaces. But in that case you should insist (contractually) that the *CUSTOMER* router have the filters on ITS interface which talks to you, and TEST it from time to time. -- -- 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
At 14:52 6/16/98 -0500, you wrote:
I think that the approach here is to find the executive level people to whom those people report, and explain to _them_ that if they don't get their houses in order, the government is likely to do it for them.
That's not my (or your) job. If they're not on notice by now, they deserve what they get. Frankly, I hope that the government does their job for them due to the simple fact that I'm getting tired of taking defensive postures on this thing.
It's my (probably forlorn) hope that the proposed Internet Board (or whatever they'll call the registry board proposed in the White Paper) will have some enforcement authority OR An "Internet Governing Board" would be created that would have the authority to say "You are not playing nice...no connectivity to the rest of the 'Net for you until you get your stuff together". I see a sort of informal court setup that one could complain to about offensive networks AFTER attempts to deal with the network itself have failed. The IGB would then have the authority to verify the problem and the lack of resolution and order the offender be cut off at the NSP, or blackholed at the NAPs, or whatever appropriate, until they solve their problem. Think what a nicer place the 'Net would be if there were an agency that could FORCE those who refuse to cooperate in our grand cooperative venture to play nice or not play at all. What do spammers and nails have in common? They're both intended for hammering. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]
On Wed, Jun 17, 1998 at 12:36:02PM -0400, Dean Robb wrote:
Think what a nicer place the 'Net would be if there were an agency that could FORCE those who refuse to cooperate in our grand cooperative venture to play nice or not play at all.
Paul Vixie. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
At 16:42 6/19/98 -0400, you wrote:
On Wed, Jun 17, 1998 at 12:36:02PM -0400, Dean Robb wrote:
Think what a nicer place the 'Net would be if there were an agency that could FORCE those who refuse to cooperate in our grand cooperative venture to play nice or not play at all.
Paul Vixie.
It's a good start! :) What do spammers and nails have in common? They're both intended for hammering. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]
On Tue, Jun 16, 1998 at 03:21:11PM -0400, Jay R. Ashworth put this into my mailbox:
I think that the approach here is to find the executive level people to whom those people report, and explain to _them_ that if they don't get their houses in order, the government is likely to do it for them.
Sounds good. Now we just need someone to send around a press release stating that 1 out of 3 (asshole statistic) corporations, government organizations, and educational institutions are unwittingly helping Cyber-Terrorists commit their evil deeds; and 25% of those (another asshole statistic) don't care that they're aiding and abetting these criminals. Basically, we want to shame these companies into fixing their networks. Public image is a killer. Sensationalism can be your friend, if used right }:> -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Life is anything that dies when Founder, the DALnet IRC Network you stomp on it." -Dave Barry e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Tue, 16 Jun 1998, Michael Dillon wrote:
Government scrutiny is headed our way http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html
The feds are worried that it is too hard to track down cyber attackers. Although the article doesn't say this explicitly I expect that it won't be long before we see politicians calling for some sort of mandated tracing capabilities between network providers
Since it's already difficult to track down attacks, I feel that any intervention on THIS MATTER would be welcomed by many people. What we must be cautious about is giving the goverment too much power in this matter. I fear big goverment, this often means more taxes, and inefficiency.
And since IOPS http://www.iops.org/ is hosted by a government funded agency located on the outskirts of DC, I expect that it will be involved in this whole thing.
If we could track attacks to their source more quickly, then government would not feel the need to intervene. This may require some changes to router software but unless network operators ask for the changes, the manufacturers will not do it.
I agree with you fully. I feel that few networks practice good security. Network Engineers and Operators need to be more proactive when it comes to security. In my last gig, I had a small network but we had a secure network and we prosecuted to the fullest extent of the LAW. That's what need to happen. If we can avoid government interventions to make this happen then let's do it.
We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting.
I have few questions about this. Do we run it on the router? If yes what type CPU and Memory load can we expect? We must realise that the router are usually doing full BGP with upstreams and processing many different things on locally. Anything we do cannot take way from the proformance of a router.
We have seen that when misconfigured equipment can be quickly identified, such as the smurf amplifiers, then we can apply pressure and get things fixed. Similarly if we can quickly identify the source of a spoofed source address attack then we can apply pressure to get filters in place and have people arrested or secure an insecure machine as the case may be.
-- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
Cheers Moe H.
On Tue, 16 Jun 1998, Mo wrote:
We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting.
I have few questions about this. Do we run it on the router?
At least part of this needs to be run on the router but part of it could be run on a workstation.
If yes what type CPU and Memory load can we expect?
Limited load. This tracing needs to be limited similar to the way that UNIX shells limit resource consumption with the ulimit command. And there needs to be some sort of rudimentary trust relationship set up, perhaps to only allow traces to be initiated by a router that has a BGP peering session in place.
We must realise that the router are usually doing full BGP with upstreams and processing many different things on locally. Anything we do cannot take way from the proformance of a router.
I agree. If a peer initiates too many traces in a given timeframe then extra ones should be silently ignored. A trace should start with human intervention, i.e. a NOC employee runs some trace utility on a workstation that initiates a trace probe on their own routers and the probe propogates through the network until it succeeds or fades due to too many probes at one spot at the same time. In most cases a single victim will contact a single upstream and ask for a single probe. The only time probe activity would hit its limits would be if a single attacker was simultaneously attacking a large number of sites. If even one of the probes succeeds in flushing out the attack source then it will be useful even if many probes must fail to limit the load on the routers. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
participants (7)
-
Dalvenjah FoxFire -
Dean Robb -
Jay R. Ashworth -
Jon Lewis -
Karl Denninger -
Michael Dillon -
Mo