As Alex said earlier, we have experienced(?) a few ping floods recently, and it is very difficult to use technology to trace the real culprit, because you would have to follow the L2 signature (router ARP tables at every hop, show ip arp, on a Cisco) through the Internet to the source which means that you would have to have privs (or cooperate with engineers) on all the transit networks that the culprit uses. By the time this is in place the flood has usually stopped and then we are SOL >:) I would suggest that you interview the specific person targeted (if there is one) and ask, in good old Colombo style, 'Did the deceased have any enemies that you know of?' You never know! Knowing/suspecting is not enough and tangible proof is a different thing however! -----------------------------
Does anyone have any ideas from where its coming from???? We have had no luck with this at all????
On Fri, 15 Aug 1997, Alex Rubenstein wrote:
Yes. It was interesting. My understanding is that what I am about to
you is old news, but here:
Attacker sends a packet with a source address of the victim, with a dest address to the broadcast of a (pick any) network. Every machine on
network will then respond with a ICMP reply to the 'source' (the victim).
My understanding is that a 28.8 users could easily fill a T1 (or more) with this method. We have no proof, but someone did this to us from what appears to be a ISDN account from PSI, and filled 6 - 7 mb/s of our Ethernet genuity connection in doing so. It was *not* cool.
On Fri, 15 Aug 1997, Network Admin Account wrote:
Has anyone been resently attacked by massive flood pings?????? We
are
trying to locate any other ISP's or anyone else having the same
tell the problem.
There is another mitigation: everyone here should commit to filtering customer packets at the customer premesis router (or at the dial in for PPP/SLIP) such that it is not possible for a customer to send a packet into the network that has an IP source address on it that is not assigned to that customer. That is, no more lying about source addresses. Each of you should also consider (depending upon how your address allocations go - this should be cheap for a single CIDR block) filtering all packets coming at you from elsewhere that has source addresses in your assigned address space. That is, no one should be able to send you packets that you appear to have originated. This is for the terminal networks, not the transit networks. This is an old problem. It's another variant of the TCP SYN flood thing. These filters also help with that problem too. Erik Fair <fair@clock.org>
On Thu, 21 Aug 1997 13:18:34 -0700, fair@clock.org writes:
There is another mitigation: everyone here should commit to filtering customer packets at the customer premesis router (or at the dial in for PPP/SLIP) such that it is not possible for a customer to send a packet into the network that has an IP source address on it that is not assigned to that customer. That is, no more lying about source addresses.
Every time I show a customer of mine how to configure a router, I try to educate them on this. We need some kind of massive marketing effort to get this out to people though. People would do it, but nobody knows about it. Maybe we should get CyberPromo to spam all the technical contacts in Internic's database to tell them how to do filtering. :) -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
At 03:26 PM 08/21/97 -0500, Jon Green wrote:
Maybe we should get CyberPromo to spam all the technical contacts in Internic's database to tell them how to do filtering. :)
Well, at least there is an I-D to point them to: ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-02.txt Daniel Senie and I will be submitting at least on further draft before we ask that this be published as an Informational RFC. Until then, you can simply point people to the draft and say, 'Here.' - paul
On Thu, 21 Aug 1997 17:04:35 -0400, pferguso@cisco.com writes:
Well, at least there is an I-D to point them to:
That's helpful, but even as an RFC people still have to be aware that the problem exists before they do anything about it. A typical person that I deal with would be a small networking integrator that is selling Bay routers to school districts. This is not somebody who reads RFCs, and most of them don't have any idea what issues face the Internet today. I'm not sure what we can do, but this is one of the types of people that severely need the education. I guess it probably falls back on the vendors here to educate their resellers and customers. -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
On Thu, 21 Aug 1997 17:04:35 -0400, pferguso@cisco.com writes:
Well, at least there is an I-D to point them to:
And plugged his draft. :-) Jon Green replied:
That's helpful, but even as an RFC people still have to be aware that the problem exists before they do anything about it. A typical person that I deal with would be a small networking integrator that is selling Bay routers to school districts. This is not somebody who reads RFCs, and most of them don't have any idea what issues face the Internet today. I'm not sure what we can do, but this is one of the types of people that severely need the education. I guess it probably falls back on the vendors here to educate their resellers and customers.
Then, I asked:
A router knows the network number and mask of each network to which it has an interface. Does it not make sense that the default thing for that router to do would be to trash incoming packets which carry a source address not on the network associated with that interface.
Certainly, you'd have to tell the router to accept all comers (except locallly addressed packets) on the WAN interface, but you need to tell it which interface is the default route _anyway_, so that's trivial.
And for people with multiple, routed networks behind a router, well, they could probably be assumed to be bright enough to enable additional net/masks for a given interface _anyway_, so that's not really a problem either.
Jon essayed to tell me why he didn't think it was feasible, like so:
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user. No, I think the answer really is to get some sample anti-spoofing filters into the router documentation and find a good way to get people to read it. There are lots of "how to configure your router for the Internet" types of tutorials out there, and outbound filtering should be part of every one of them.
Before I ask him why "sending packets with forged source addresses through routers" is "what routers traditionally do" (:-), I want to point out to him that here he's propounding getting people to read directions on how to do it, while, above, he was noting that the customers he sells to primarily "are not the sort of people who read RFC's". If they're not interested in the technical details of how to run the routers, Jon, what makes you think that putting the info in the _manual_ will help all that much? Inasmuch as I suggested that the default port not be ingress filtered -- except to avoid spoofing in packets purportedly sourced on _the other side_ of the router, I'm wondering what you think wouldn't work there. As for the other gentlemans concern (which, damn it, I thought I got quoted in here, and didn't), in a non-static routing environment, the ports of a given router which had other routers downstream of them would indeed need to be handled specially, but interfacing with the routing protocol would be unnecessary, because _somewhere_ thee's a boundary router with static ports... and it's _that_ router that would be doing the ingress filtering, anyway. Stipulated, turning off non-adaptive IF on a given router port would require that that network only contain router interfaces, rather than also containing hosts, but is that _really_ too high a price to pay, people? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
On Thu, Aug 21, 1997 at 03:26:50PM -0500, Jon Green wrote:
On Thu, 21 Aug 1997 13:18:34 -0700, fair@clock.org writes:
There is another mitigation: everyone here should commit to filtering customer packets at the customer premesis router (or at the dial in for PPP/SLIP) such that it is not possible for a customer to send a packet into the network that has an IP source address on it that is not assigned to that customer. That is, no more lying about source addresses.
Every time I show a customer of mine how to configure a router, I try to educate them on this. We need some kind of massive marketing effort to get this out to people though. People would do it, but nobody knows about it.
Ok, here's a question: A router knows the network number and mask of each network to which it has an interface. Does it not make sense that the default thing for that router to do would be to trash incoming packets which carry a source address not on the network associated with that interface. Certainly, you'd have to tell the router to accept all comers (except locallly addressed packets) on the WAN interface, but you need to tell it which interface is the default route _anyway_, so that's trivial. And for people with multiple, routed networks behind a router, well, they could probably be assumed to be bright enough to enable additional net/masks for a given interface _anyway_, so that's not really a problem either. Someone tell me, from either a technical or marketing standpoint, why this idea is infeasible, no? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
On Thu, 21 Aug 1997 17:39:53 -0400, jra@scfn.thpl.lib.fl.us writes:
A router knows the network number and mask of each network to which it has an interface. Does it not make sense that the default thing for that router to do would be to trash incoming packets which carry a source address not on the network associated with that interface.
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user. No, I think the answer really is to get some sample anti-spoofing filters into the router documentation and find a good way to get people to read it. There are lots of "how to configure your router for the Internet" types of tutorials out there, and outbound filtering should be part of every one of them. -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
[ On Thu, August 21, 1997 at 17:18:24 (-0500), Jon Green wrote: ]
Subject: Re: ICMP Attacks???????
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user.
Wait just one minute there. You're saying that Corporate America *relies* on being able to to IP source address spoofing through the routers it builds its commercial private networks with? Please don't say it's so. Maybe the Internet is *more* secure than the average corporate network! ;-) -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, 21 Aug 1997 23:55:57 -0400 (EDT), woods@most.weird.com writes:
[ On Thu, August 21, 1997 at 17:18:24 (-0500), Jon Green wrote: ]
Subject: Re: ICMP Attacks???????
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user.
Wait just one minute there.
You're saying that Corporate America *relies* on being able to to IP source address spoofing through the routers it builds its commercial private networks with?
Well, I wasn't quite thinking here. The original post had said something about making a router check to see if a packet came from a locally configured interface, which I said would not be a good idea. Obviously, though, for non-local networks the router would have a route table entry to get back to it, even if it jumps through three other routers. That being said, we *could* have a configuration option that makes a router check its routing table to make sure a packet coming in an interface has a route back out that same interface. This should not be a default option, though, since there are often two paths to a destination and the routing table may not match where the packet came from. That's not the best English, but you get it.. What would doubling the number of route table lookups do from a performance standpoint? Since I would envision this as an edge-router type thing, I would assume the impact would not be that great. -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
[ On Fri, August 22, 1997 at 12:39:52 (-0500), Jon Green wrote: ]
Subject: Re: ICMP Attacks???????
That being said, we *could* have a configuration option that makes a router check its routing table to make sure a packet coming in an interface has a route back out that same interface. This should not be a default option, though, since there are often two paths to a destination and the routing table may not match where the packet came from. That's not the best English, but you get it..
I was thinking more of the case of local networks (i.e. from the ethernet interfaces), esp. since for small LAN segments the "edge" router would probably have a default route out a WAN interface, even in a corporate network and as such the anti-spoofing rules are (at least in my mind) rather trivial to figure out and implement. Darren Reed's ip-filter package even comes with a little perl script that attempts to write anti-spoof rules given a list of interfaces and their networks. It didn't work perfectly in all the situations I've tried it, but it seemed as if it should be fixable. The output of that script, including rules to block the RFC-1918 private nets as appropriate, for a 5-ethernet box is about 80 lines of ip-filter rules. Having a single configuration switch that turned these all on automaticaly would certainly help out a lot of the network admins I know who don't have the luxury of using ip-filter on their routers. ;-) That reminds me -- does anyone know of any semi-professional (but freeware) tools that might be used to actually test anti-spoof rules by injecting spoofed packets? Does/can SATAN do this test? I'd like to find some code I'd have a chance of trusting more than the average cracker tool -- i.e. something designed for testing, not abuse. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user.
You're saying that Corporate America *relies* on being able to to IP source address spoofing through the routers it builds its commercial private networks with?
<sigh> No, I believe he's saying that corporate america comes in two flavors. 1) that isn't terribly clueful, and don't know how their packets route (scary how often you see this .. RIP-based networks that "just work") 2) Multi-path, decentralized network administration. So any given router will not be aware of all paths in the topology, and may route packets that it doesn't know how to return. Deliberately. Trust me, you don't know how your peer routes their traffic. Neither does sales know how the engineering department does in some cases. Or the backbone group knows all, and the department routers know nothing. In any case, this logic used for this would have to be very complex. ..which would cause complex problems. I prefer simple manual editing. Actually, on the End-Of-Branch routers you could implement functions which say not to route anything coming through a given interface unless it is from that network. But this won't work on most branch router configurations. It's simply not that simple. -- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services PGP keys and contact information: http://www.navigist.com/Staff/JRhett
On Fri, Aug 22, 1997 at 02:42:42PM -0700, Joe Rhett wrote:
I don't think that's a good idea. The vast majority of routers that I sell to customers are not used in Internet applications, and to add another configuration step to enable the router to do what routers traditionally do by default would be very confusing to the end user.
You're saying that Corporate America *relies* on being able to to IP source address spoofing through the routers it builds its commercial private networks with?
<sigh> No, I believe he's saying that corporate america comes in two flavors.
1) that isn't terribly clueful, and don't know how their packets route (scary how often you see this .. RIP-based networks that "just work")
2) Multi-path, decentralized network administration. So any given router will not be aware of all paths in the topology, and may route packets that it doesn't know how to return. Deliberately.
Trust me, you don't know how your peer routes their traffic. Neither does sales know how the engineering department does in some cases. Or the backbone group knows all, and the department routers know nothing.
So far, so good.
In any case, this logic used for this would have to be very complex. ..which would cause complex problems. I prefer simple manual editing.
No, not really.
Actually, on the End-Of-Branch routers you could implement functions which say not to route anything coming through a given interface unless it is from that network. But this won't work on most branch router configurations.
This was what I originally proposed, in the posting from which this thread descended. Did everyone miss it? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
A router knows the network number and mask of each network to which it has an interface. Does it not make sense that the default thing for that router to do would be to trash incoming packets which carry a source address not on the network associated with that interface.
Given the predominance of Ascend in the marketplace, and their general configuration style, it would be cool to see an option "AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes associated with each interface. If a packet arrives that doesn't have a route to get it back to the interface it came from, it would be dropped. Sure, this may not always be what you want, but in 99% of the cases it would be. Implementation via Radius would permit this to be removed from people you wish to allow to spoof. :) Josh Beck jbeck@connectnet.com ---------------------------------------------------------------------- CONNECTNet INS, Inc. Phone: (619)450-0254 Fax: (619)450-3216 6370 Lusk Blvd., Suite F-208 San Diego, CA 92121 ----------------------------------------------------------------------
Given the predominance of Ascend in the marketplace, and their general configuration style, it would be cool to see an option "AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes associated with each interface. If a packet arrives that doesn't have a route to get it back to the interface it came from, it would be dropped. Sure, this may not always be what you want, but in 99% of the cases it would be. Implementation via Radius would permit this to be removed from people you wish to allow to spoof. :)
This won't work on anything with multiple diverse paths. And I don't know many companies with their own WANs that don't have such. So, yes, the idea is nice but the logic would have to be much more comprehensive than that. And I honestly don't know how you could safely do it, that won't break half the routing topologies out there. (if you assume multipath OSPF for the IGP... maybe. But that's one hell of an assumption.) -- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services PGP keys and contact information: http://www.navigist.com/Staff/JRhett
Given the predominance of Ascend in the marketplace, and their general configuration style, it would be cool to see an option "AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes associated with each interface. If a packet arrives that doesn't have a route to get it back to the interface it came from, it would be dropped. Sure, this may not always be what you want, but in 99% of the cases it would be. Implementation via Radius would permit this to be removed from people you wish to allow to spoof. :)
This won't work on anything with multiple diverse paths. And I don't know many companies with their own WANs that don't have such.
So, yes, the idea is nice but the logic would have to be much more comprehensive than that. And I honestly don't know how you could safely do it, that won't break half the routing topologies out there.
(if you assume multipath OSPF for the IGP... maybe. But that's one hell of an assumption.)
-- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services
PGP keys and contact information: http://www.navigist.com/Staff/JRhett
True, but there are a lot of small ISPs whom something like this could help. Granted, perhaps you should know enough of filters and routes to run an ISP, but there are those who don't, and their numbers will only increase as the involved equipment and technologies become more accessible to more people, and more PC shops and small businesses decide to become their own ISPs. Josh Beck jbeck@connectnet.com ---------------------------------------------------------------------- CONNECTNet INS, Inc. Phone: (619)450-0254 Fax: (619)450-3216 6370 Lusk Blvd., Suite F-208 San Diego, CA 92121 ----------------------------------------------------------------------
On Fri, Aug 22, 1997 at 02:59:40PM -0700, Josh Beck wrote:
Given the predominance of Ascend in the marketplace, and their general configuration style, it would be cool to see an option "AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes associated with each interface. If a packet arrives that doesn't have a route to get it back to the interface it came from, it would be dropped. Sure, this may not always be what you want, but in 99% of the cases it would be. Implementation via Radius would permit this to be removed from people you wish to allow to spoof. :)
This won't work on anything with multiple diverse paths. And I don't know many companies with their own WANs that don't have such.
Are those companies connecting their LANs to the net through _dialup_ ports on Ascend Boxen? Come _on_ folks; pay attention.
So, yes, the idea is nice but the logic would have to be much more comprehensive than that. And I honestly don't know how you could safely do it, that won't break half the routing topologies out there.
True, but there are a lot of small ISPs whom something like this could help. Granted, perhaps you should know enough of filters and routes to run an ISP, but there are those who don't, and their numbers will only increase as the involved equipment and technologies become more accessible to more people, and more PC shops and small businesses decide to become their own ISPs.
I'd venture to speculate that the _vast_ majority of ports on routing devices in the work have networks connected to them which contain only hosts -- no other routers. Remember, that description includes dialup PPP ports. I think if Ascend, Livingston, and USR -- just those 3 -- put filters on their dialup ports to prevent source address spoofing, the problem would probably drop in half. Adding it to the boundary routers on college campuses would cut another 40% The remaining 10% comes from AGIS. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
Joe Rhett writes...
Given the predominance of Ascend in the marketplace, and their general configuration style, it would be cool to see an option "AllowIpSpoofing=Yes/No" or the like. The boxes already carry routes associated with each interface. If a packet arrives that doesn't have a route to get it back to the interface it came from, it would be dropped. Sure, this may not always be what you want, but in 99% of the cases it would be. Implementation via Radius would permit this to be removed from people you wish to allow to spoof. :)
This won't work on anything with multiple diverse paths. And I don't know many companies with their own WANs that don't have such.
As long as _one_ _of_ _the_ _routes_ would go back on the interface the packet arrived on, not necessarily the best route, then the logic would work in the majority of cases that I know of. But this could require a more extensive route lookup, which would do more than just double the CPU time looking up routes. OTOH, you could cut out a LOT of spoofing if all dialup routers were to restrict source addresses to just the network range specified in the user account data (for static with LAN) or the port address (for dynamic). Any packet coming in on the port would be discarded with optional logging. For example: AllowSourceNet=10.0.0.0/8:172.16.0.0/12:192.168.0.0/16
So, yes, the idea is nice but the logic would have to be much more comprehensive than that. And I honestly don't know how you could safely do it, that won't break half the routing topologies out there.
Doing this on backbone routes would be of little to no benefit and very expensive. Doing this on dialup routers is where the greatest benefit is, and can always be turned off on a per-user basis where things do break for some reason. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Make them read the 'ingress/egress filtering' by Paul Fergusson et. al. Apologies to Paul if I spelled his name incorrectly. Jon Green wrote:
On Thu, 21 Aug 1997 13:18:34 -0700, fair@clock.org writes:
There is another mitigation: everyone here should commit to filtering
customer packets at the customer premesis router (or at the dial in for PPP/SLIP) such that it is not possible for a customer to send a packet into the network that has an IP source address on it that is not assigned to that customer. That is, no more lying about source addresses.
Every time I show a customer of mine how to configure a router, I try to educate them on this. We need some kind of massive marketing effort to get this out to people though. People would do it, but nobody knows about it.
Maybe we should get CyberPromo to spam all the technical contacts in Internic's database to tell them how to do filtering. :)
-Jon
-----------------------------------------------------------------
* Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * - -----------------------------------------------------------------------
On Thu, 21 Aug 1997, Peter E. Giza wrote:
Make them read the 'ingress/egress filtering' by Paul Fergusson et. al. Apologies to Paul if I spelled his name incorrectly.
Short of fixing every network on the internet, does anyone have any useful advice for what to do when smurfed? This happened to an FDT customer last night, and it had our T1 (according to uunet) at about 500% capacity. Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
< close to just asking uunet to block all icmp echo replies from coming into FDT...but I know customers will complain.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Short of fixing every network on the internet, does anyone have any useful advice for what to do when smurfed? This happened to an FDT customer last night, and it had our T1 (according to uunet) at about 500% capacity. Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
< close to just asking uunet to block all icmp echo replies from coming into FDT...but I know customers will complain.
Then they will start blasting UDP at you. Trust me, T1 is not that bad. We periodically have DS-3s eaten up completely but it happens for such a short time that it cannot really be traced :( Alex
On Thu, 21 Aug 1997, Alex "Mr. Worf" Yuriev wrote:
Short of fixing every network on the internet, does anyone have any useful advice for what to do when smurfed? This happened to an FDT customer last night, and it had our T1 (according to uunet) at about 500% capacity. Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
< close to just asking uunet to block all icmp echo replies from coming into FDT...but I know customers will complain.
Then they will start blasting UDP at you. Trust me, T1 is not that bad. We periodically have DS-3s eaten up completely but it happens for such a short time that it cannot really be traced :(
Perhaps. The trouble is, when we get smurfed, our T1 becomes totally useless. While talking to UUNet and Cisco about the problem, Cisco suggested traffic shaping on the UUNet 7500 we connect to. If they did that, and told the 7500 not to send >1.5mb/s for us to the cascade, then would the 7500 be smart enough to prioritize the packets such that the icmp get dropped and tcp and udp go through? The main problem, AFAICT, is that the cascade deals very badly with the situation where it has 7mb/s of traffic for a 1.5mb/s pipe. UUNet did not seem terribly receptive to the idea. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
uunet won't (can't) block those echo replies. It will KILL their routers. BUT that will all change when the fast-drop code goes mainstream.. uunet and other networks are going to have to help their customers out, by loading this code and doing some filtering for their customers. Will you do so? Big networks for North America? -- On Thu, Aug 21, 1997 at 09:23:35PM -0400, Jon Lewis said:
Short of fixing every network on the internet, does anyone have any useful advice for what to do when smurfed? This happened to an FDT customer last night, and it had our T1 (according to uunet) at about 500% capacity. Obviously, until the attack stopped, our T1 wasn't too useful. I'm about
< close to just asking uunet to block all icmp echo replies from coming into FDT...but I know customers will complain.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Maybe it should be a pre-defined filter that the manufactures include in the basic software configuration. If we put some pressure on Cisco/Bay/Ascend/Livingston etc....... maybe we can get it done there, so that we don't have to educate new people. Alex P On Thu, 21 Aug 1997, Jon Green wrote:
On Thu, 21 Aug 1997 13:18:34 -0700, fair@clock.org writes:
There is another mitigation: everyone here should commit to filtering customer packets at the customer premesis router (or at the dial in for PPP/SLIP) such that it is not possible for a customer to send a packet into the network that has an IP source address on it that is not assigned to that customer. That is, no more lying about source addresses.
Every time I show a customer of mine how to configure a router, I try to educate them on this. We need some kind of massive marketing effort to get this out to people though. People would do it, but nobody knows about it.
Maybe we should get CyberPromo to spam all the technical contacts in Internic's database to tell them how to do filtering. :)
-Jon
----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
On Fri, Aug 22, 1997 at 02:21:12PM -0400, Alex Przekupowski wrote:
Maybe it should be a pre-defined filter that the manufactures include in the basic software configuration. If we put some pressure on Cisco/Bay/Ascend/Livingston etc....... maybe we can get it done there, so that we don't have to educate new people.
Didn't I just say something like this? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
participants (14)
-
Alex "Mr. Worf" Yuriev -
Alex Przekupowski -
Edward Henigin -
Erik E. Fair -
Jay R. Ashworth -
Joe Rhett -
Jon Green -
Jon Lewis -
Josh Beck -
Paul Ferguson -
Peter E. Giza -
Phil Howard -
Steve Carter -
woods＠most.weird.com