On Fri, 11 Jul 1997, Jon Lewis wrote:
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening.
Its not feasible to filter packets on customer gateway routers. When you impose a packet filter on a GW router customer interface, all packets destined to that customer have to be matched to an access-list and then forwarded down the pipe or dropped. This increases the load on the router CPU, because it is used to switching the packets. Now you have to analyze each packet which takes up CPU time. This is not a nice thing to do to a router, especially while the router is trying to keep up with 50 other customers... And if more than 1 customer wants this type of service, you start really feeling the load. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ice9@paranoia.com http://www.paranoia.com/~ice9 My opinion may not reflect that of any living person, but its the only one that counts!! main() {for(;;fork());} =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Its not feasible to filter packets on customer gateway routers. When you impose a packet filter on a GW router customer interface, all packets destined to that customer have to be matched to an access-list and then forwarded down the pipe or dropped. This increases the load on the router CPU, because it is used to switching the packets. Now you have to analyze each packet which takes up CPU time.
This is not a nice thing to do to a router, especially while the router is trying to keep up with 50 other customers... And if more than 1 customer wants this type of service, you start really feeling the load.
It isn't, or shouldn't be, an issue of whether the customer wants this kind of service. This is protection FROM that customer. The principle reason to not do this is the load it causes on the router. Should it be discovered that source forged packets are coming from a given customer, then you could apply this to that customer if they are not going to just be summarily cut off. Perhaps, in time, security demands may require doing more of this. Or they may require more kinds of traceability of where the bad packets are coming from (also costly). -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
On Sat, 12 Jul 1997, Phil Howard wrote:
It isn't, or shouldn't be, an issue of whether the customer wants this kind of service. This is protection FROM that customer. The principle reason to not do this is the load it causes on the router.
Should it be discovered that source forged packets are coming from a given customer, then you could apply this to that customer if they are not going to just be summarily cut off.
The trouble is, unless you are silly enough to attack your own provider, it seems unlikely that they will know you are spoofing. i.e. In my current situation, I doubt UUNet's ability or willingness to track these packets to their source. How are the source's provider supposed to find out? The attack is now into its 3rd day and can be seen in our traffic graph at http://gnv.fdt.net/~fubar/cgi-bin/uunet.cgi The attacker seems to be taking short breaks every 30-90 minutes. I captured a few hundred packets last night for UUNet's security people to look at (so they will believe me) and of the 225 packets captured, all were from unique source addresses. Here's a breif snippit from just a minute ago: 12:19:13.494446 49.0.94.105.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31674) 12:19:13.504446 12.206.160.94.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31675) 12:19:13.524446 11.80.252.52.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31676) 12:19:13.544446 253.81.121.106.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31677) 12:19:13.564446 159.83.60.97.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31678) 12:19:13.594446 122.164.93.95.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31679) 12:19:13.604446 182.2.169.126.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31680) 12:19:13.624446 160.95.105.78.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31681) 12:19:13.644446 83.18.225.93.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31682) ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
The one or two times we have had interactions with UUNet's security guy/group have been very positive. Norm over there was especially helpful and in the case of an emergency their security types are on-call (directly, by pager if necessary). They are MUCH more likely to contact an offending provider and ask that the circuit be turned down rather than filter in their own network, which isn't always the quickest process in the world. -Deepak. On Sat, 12 Jul 1997, Jon Lewis wrote:
On Sat, 12 Jul 1997, Phil Howard wrote:
It isn't, or shouldn't be, an issue of whether the customer wants this kind of service. This is protection FROM that customer. The principle reason to not do this is the load it causes on the router.
Should it be discovered that source forged packets are coming from a given customer, then you could apply this to that customer if they are not going to just be summarily cut off.
The trouble is, unless you are silly enough to attack your own provider, it seems unlikely that they will know you are spoofing. i.e. In my current situation, I doubt UUNet's ability or willingness to track these packets to their source. How are the source's provider supposed to find out? The attack is now into its 3rd day and can be seen in our traffic graph at http://gnv.fdt.net/~fubar/cgi-bin/uunet.cgi
The attacker seems to be taking short breaks every 30-90 minutes.
I captured a few hundred packets last night for UUNet's security people to look at (so they will believe me) and of the 225 packets captured, all were from unique source addresses.
Here's a breif snippit from just a minute ago:
12:19:13.494446 49.0.94.105.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31674) 12:19:13.504446 12.206.160.94.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31675) 12:19:13.524446 11.80.252.52.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31676) 12:19:13.544446 253.81.121.106.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31677) 12:19:13.564446 159.83.60.97.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31678) 12:19:13.594446 122.164.93.95.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31679) 12:19:13.604446 182.2.169.126.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31680) 12:19:13.624446 160.95.105.78.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31681) 12:19:13.644446 83.18.225.93.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31682)
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
On Sat, 12 Jul 1997, Jon Lewis wrote:
On Sat, 12 Jul 1997, Phil Howard wrote:
It isn't, or shouldn't be, an issue of whether the customer wants this kind of service. This is protection FROM that customer. The principle reason to not do this is the load it causes on the router.
Should it be discovered that source forged packets are coming from a given customer, then you could apply this to that customer if they are not going to just be summarily cut off.
The trouble is, unless you are silly enough to attack your own provider, it seems unlikely that they will know you are spoofing. i.e. In my current situation, I doubt UUNet's ability or willingness to track these packets to their source.
Hi, On Friday our network was suffering an identical attack as yours. We are a UU-NET customer. Once I had traced the exact neture of the attack, port numbers etc, I contacted UU-NET who *did* trace the source of the attack to one of their customers - I think inside AS701. I was pretty impressesed - took them about an hour - I didn't overly think that they would find the source but they located it down - with some help from the source customer to the individual machine. I doubt it is the same person doing the attacks as the source port for us was 13 (?) and the size of udp packet was 1000 - but both attacks probably from the same program. Is there any way to put the originating AS into the (options part?) header of all ip packets as they leave one's border routers? If tcpdump could then extract this informaton (which could only be forged by a very small minority of people on the network) tracing such attacks woukd a be a lot easier... I suppose adding that info into teh ip header would cause far too much load on the exit routers though? Regards, aid
Here's a breif snippit from just a minute ago:
12:19:13.494446 49.0.94.105.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31674) 12:19:13.504446 12.206.160.94.666 > 205.229.58.133.7: udp 1450 (ttl 244, id 31675)
On Sat, 12 Jul 1997, ice9 wrote:
This is not a nice thing to do to a router, especially while the router is trying to keep up with 50 other customers... And if more than 1 customer wants this type of service, you start really feeling the load.
I'm not saying UUNet should install whatever filters I want on their routers. I'm just saying the net would be a MUCH nicer place if NSP's all did ingress filtering on their customer connections. If current routers can't handle the load this would create, then NSP's need to find vendors willing to deliver the necessary power, or they need to rethink the way they design their networks. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
I'm not saying UUNet should install whatever filters I want on their routers. I'm just saying the net would be a MUCH nicer place if NSP's all did ingress filtering on their customer connections. If current routers can't handle the load this would create, then NSP's need to find vendors willing to deliver the necessary power, or they need to rethink the way they design their networks.
Most of my customers have customers who in turn have customers, not a few of whom are multi-homed. Same for UUNET, ... So, at POP X, I take in maybe 100 prefixes, with maybe 1000 at some POPs. How do I build and maintain that filter list, and how long does it take each packet to get through it with a router that also does real routing? randy
On Sat, 12 Jul 1997, Randy Bush wrote:
routers. I'm just saying the net would be a MUCH nicer place if NSP's all did ingress filtering on their customer connections. If current routers can't handle the load this would create, then NSP's need to find vendors willing to deliver the necessary power, or they need to rethink the way they design their networks.
Most of my customers have customers who in turn have customers, not a few of whom are multi-homed. Same for UUNET, ...
So, at POP X, I take in maybe 100 prefixes, with maybe 1000 at some POPs. How do I build and maintain that filter list, and how long does it take each packet to get through it with a router that also does real routing?
I've got this big pile of money and hardware. How do I turn it into an international internet backbone? A certain minimal level of network security should be a part of any responsible network. Perhaps its not practical to run with filters on every router...especially core and big exchange routers. But you can strongly encourage (perhaps require) that all your customers enforce sane filters where applicable. Somewhere in the internet food chain, it is very much practical to install filters, and someone needs to make sure they are in place. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
On Sun, 13 Jul 1997, Jon Lewis wrote:
A certain minimal level of network security should be a part of any responsible network. Perhaps its not practical to run with filters on every router...especially core and big exchange routers. But you can strongly encourage (perhaps require) that all your customers enforce sane filters where applicable. Somewhere in the internet food chain, it is very much practical to install filters, and someone needs to make sure they are in place.
Given that ISP market is differentiated by the lowest common denominator at this point, this is unlikely to happen. Customers and potential customers vote with their money, and so far, it is very unclear whether doing the "right things" in this regard give any network a competitive advantage. In fact, it could be argued that this constitutes a competitive disadvantage since engineering for filtering and other such niceties tend to drive up the cost. I suppose that things would be different if we had an educated consumer base, but that seems unlikely to happen any time soon. Furthermore, for many, their connection model of customers makes it impractical for them to filter. The best we can do is for each individual sites/networks to do what they can. Given the current enviroment, something like universal ingress/egress filter deployment is an impossible task. However, I'm not saying that since things are impossible, don't bother doing anything. For those of us who have the customer connection model to support ingress/egress filtering, this should be done at the edges. Also, once we are able to buy real routers that can perform these tasks as part of their aggregation functionality, I'd argue that ingress/egress filtering _should_ become the norm. (not that I'd bet on that happening) For those who maintain a CPE, it's trivial to integrate ingress/egress filtering to the automated process that's part of installation. This has been done in various different places in the past, the most familiar example to me being CICNet. -dorian
participants (7)
-
Adrian J Bool -
Deepak Jain -
Dorian R. Kim -
ice9 -
Jon Lewis -
Phil Howard -
randy＠psg.com