This past weekend I was contacted by several groups ranging from NASA to a small service provider in the Bay area regarding one of our hosts port scanning their networks using RESET packets. In each of these cases the machine seemed to be scanning random addresses in their networks on random, non-reserved (+1024), ports. After investigating these claims it appears as if someone is sending SYN packets to this machine (which serves ftp, which explains why the ports are open through the cisco) with a spoofed source address causing the machine to send RESET packets back to the spoofed host and setting off their firewalls. I cannot seem to get past level-1 or level-2 support from my upstream, GTE/BBN to find out where these packets are coming from to track this down. So, I come to you... Two currently on-going attacks are using the spoofed source addresses from the networks 134.50.x.x and 130.221.x.x. If you see activity from these networks inside of your borders, but the networks are not inside of your borders please contact me off of the list. Oh yeah, and filter this stuff out people, this is unacceptible. -- Bryan C. Andregg * <bandregg@redhat.com> * Red Hat, Inc. 1024/625FA2C5 F5 F3 DC 2E 8E AF 26 B0 2C 31 78 C2 6C FB 02 77 1024/0x46E7A8A2 46EB 61B1 71BD 2960 723C 38B6 21E4 23CC 46E7 A8A2
On Mon, 26 Jul 1999 bandregg@redhat.com wrote:
Oh yeah, and filter this stuff out people, this is unacceptible.
On the topic of unacceptable stuff. A number of backbones are STILL transporting rfc1918-sourced packets. This is getting really old, really fast. The last attack we saw included 127.0.0.0/24 sourced packets along with rfc1918 sourced and other garbage (255.255.255.255 for example). The first mistake is accepting this crap from customers. The second mistake is tranporting this crap to the other side of the globe. Get with the program, people. -Dan
Perhaps if you were to NAME these networks, they may be shamed into doing something about the problem. Then again, they should be ashamed to begin with for passing RFC1918 traffic, let alone loopback space. At 11:23 AM 7/26/99 -0700, Dan Hollis wrote:
On Mon, 26 Jul 1999 bandregg@redhat.com wrote:
Oh yeah, and filter this stuff out people, this is unacceptible.
On the topic of unacceptable stuff.
A number of backbones are STILL transporting rfc1918-sourced packets. This is getting really old, really fast.
The last attack we saw included 127.0.0.0/24 sourced packets along with rfc1918 sourced and other garbage (255.255.255.255 for example).
The first mistake is accepting this crap from customers. The second mistake is tranporting this crap to the other side of the globe.
Get with the program, people.
-Dan
------------ John Fraizer ------------ mailto:john.fraizer@EnterZone.Net http://www.EnterZone.Net http://www.EZ-Hosting.Net http://www.EZ-IP.Net ------------------------------------------ | __ _ | | | / / (_)__ __ ____ __ | The choice | | / /__/ / _ \/ // /\ \/ / | of a GNU | | /____/_/_//_/\_,_/ /_/\_\ | Generation | | | | ------------------------------------------
Any provider who allows the passing of address space that isn't his own (beyond whatever transit they may provide to their peers) is shameful. How hard is it really to put a filter on your outbound links that says drop all ip traffic heading out these links that isn't from my IP space? It's just like martian filters for your inbound links, and we'd see a significant decrease in spoofing based attacks if it was more widely adopted. Not to mention it'll keep peers from dumping traffic on you. -- Joseph W. Shaw - jshaw@insync.net Freelance Computer Security Consultant and Perl Programmer Free UNIX advocate - "I hack, therefore I am." On Wed, 28 Jul 1999, John Fraizer wrote:
Perhaps if you were to NAME these networks, they may be shamed into doing something about the problem. Then again, they should be ashamed to begin with for passing RFC1918 traffic, let alone loopback space.
Joe Shaw wrote:
Any provider who allows the passing of address space that isn't his own (beyond whatever transit they may provide to their peers) is shameful.
How hard is it really to put a filter on your outbound links that says drop all ip traffic heading out these links that isn't from my IP space? It's just like martian filters for your inbound links, and we'd see a significant decrease in spoofing based attacks if it was more widely adopted. Not to mention it'll keep peers from dumping traffic on you.
When RFC 2267 was a draft, and since its publication, there have been a variety of comments that the routers in place couldn't do ingress filtering at an acceptable rate without impacting traffic flows. The hope was that vendors would consider this in future designs, and some appear to have done so. I suspect most deployed routers do at least some filtering of packets on most or all interefaces. In the past, some routers couldn't do these lookups efficiently on source addresses, but that's really an implementation issue. It's *possible* to design hardware that can handle it, if there's a business case for doing so. ISPs should be interested in doing such filtering. Dialup server vendors have implemented the ability to push filters into dialup ports. This facility should be used by those offering dialup pools to ensure packets arriving on a dialup port have a source IP address that matches the address the server gave to the user in the PPP IPCP exchange. There are exceptions (LAN dialup) where this won't work, which is why control of these filters must be available from a Radius (or equivalent) server, and applied or not on a per-user basis. Cisco implemened a feature called "Unicast RPF" That disallows forwarding of packets on an interface where a reverse path is not present. The command to activate it is: ip verify unicast reverse-path and according to Paul Ferguson (co-author of RFC 2267) it's in use by many ISPs. Apparently this is very-low overhead. Paul has also indicated the use of extended access lists on Cisco routers is very low overhead, especially on routers using distributed express forwarding. Perhaps RFC 2267 should at some point be promoted to a BCP. There was some discussion about this a few months ago. Whether promotion to BCP status would entice more network providers to use the facilities or not is unclear. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
% ip verify unicast reverse-path % % and according to Paul Ferguson (co-author of RFC 2267) it's in use by % many ISPs. Apparently this is very-low overhead. Paul has also indicated % the use of extended access lists on Cisco routers is very low overhead, % especially on routers using distributed express forwarding. while i hate to question mr. ferguson, it's my understanding that many isps have found this feature to be unusable due to network design. ----------------------------------------------------------------------------- bryan s. blank bryan@supernet.net (443)394-9529 tele (410)995-2191 page (410)802-6998 emer
On Wed, Jul 28, 1999 at 11:54:03AM -0400, bryan s. blank wrote:
% ip verify unicast reverse-path % % and according to Paul Ferguson (co-author of RFC 2267) it's in use by % many ISPs. Apparently this is very-low overhead. Paul has also indicated % the use of extended access lists on Cisco routers is very low overhead, % especially on routers using distributed express forwarding.
while i hate to question mr. ferguson, it's my understanding that many isps have found this feature to be unusable due to network design.
You can't use this in the core, but you can use it on cpe facing interfaces. eg: the interface that faces your dial lan, or colocate lan, etc.. and on single ckt connections. You get into some cases where you have a customer that is doing more complicated things than just pointing default at you... (ie: they're multihomed, or have various netblocks, and do not announce them all to you or do policy routing inside their network). What problems are you seeing, as I've not had problems with this deployed in my network. I know that there have been ECM bugs in the past (equal cost multipath), and it not doing the rpf check correctly, but those problems should not affect most of the customers in the world. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. | "Waste Management Consultant" VOYN
On Wed, 28 Jul 1999, bryan s. blank wrote:
% ip verify unicast reverse-path % % and according to Paul Ferguson (co-author of RFC 2267) it's in use by % many ISPs. Apparently this is very-low overhead. Paul has also indicated % the use of extended access lists on Cisco routers is very low overhead, % especially on routers using distributed express forwarding.
while i hate to question mr. ferguson, it's my understanding that many isps have found this feature to be unusable due to network design.
I just took out a 7206 by applying ip verify unicast reverse-path to a T3 link on a PA2T3 and attempting to spoof packets from the POP on the other end of that T3. The 7206 is running c7200-inu-mz.111-25.CC. Fortunately, it rebooted after it crashed. System restarted by bus error at PC 0x605F88CC, address 0x10024 at 20:29:49 UTC Wed Jul 28 1999 This router had been up over 8 weeks without a crash (ever since Cisco replaced the previous 7206 in this POP that was either posessed or a lemon). The memory is Cisco memory. All the parts came directly from Cisco. Is this known to be unstable in 111-25.CC? Is it known to be stable in some other release that supports the PAT3, PA2T3, and PA-MCT3? ----don't waste your cpu, crack rc5...www.distributed.net team enzo--- Jon Lewis *jlewis@lewis.org*| Spammers will be winnuked or System Administrator | nestea'd...whatever it takes Atlantic Net | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________
jlewis@lewis.org wrote:
On Wed, 28 Jul 1999, bryan s. blank wrote:
% ip verify unicast reverse-path % % and according to Paul Ferguson (co-author of RFC 2267) it's in use by % many ISPs. Apparently this is very-low overhead. Paul has also indicated % the use of extended access lists on Cisco routers is very low overhead, % especially on routers using distributed express forwarding.
while i hate to question mr. ferguson, it's my understanding that many isps have found this feature to be unusable due to network design.
I just took out a 7206 by applying ip verify unicast reverse-path to a T3 link on a PA2T3 and attempting to spoof packets from the POP on the other end of that T3.
The 7206 is running c7200-inu-mz.111-25.CC. Fortunately, it rebooted after it crashed.
System restarted by bus error at PC 0x605F88CC, address 0x10024 at 20:29:49 UTC Wed Jul 28 1999
This router had been up over 8 weeks without a crash (ever since Cisco replaced the previous 7206 in this POP that was either posessed or a lemon). The memory is Cisco memory. All the parts came directly from Cisco.
Is this known to be unstable in 111-25.CC? Is it known to be stable in some other release that supports the PAT3, PA2T3, and PA-MCT3?
In a note off-list, Jack Crowder said: "Actually there was a bug in 11.1.26CC. Supposedly, 11.1.27CC has the fix incorporated." I suspect the version of IOS (.25) you're trying to use has whatever bug is referenced as being in .26. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Wed, 28 Jul 1999, Daniel Senie wrote:
In a note off-list, Jack Crowder said:
"Actually there was a bug in 11.1.26CC. Supposedly, 11.1.27CC has the fix incorporated."
I suspect the version of IOS (.25) you're trying to use has whatever bug is referenced as being in .26.
I guess it's time to upgrade again then. ----don't waste your cpu, crack rc5...www.distributed.net team enzo--- Jon Lewis *jlewis@lewis.org*| Spammers will be winnuked or System Administrator | nestea'd...whatever it takes Atlantic Net | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________
On Wed, 28 Jul 1999 jlewis@lewis.org wrote:
On Wed, 28 Jul 1999, bryan s. blank wrote:
% ip verify unicast reverse-path % % and according to Paul Ferguson (co-author of RFC 2267) it's in use by % many ISPs. Apparently this is very-low overhead. Paul has also indicated % the use of extended access lists on Cisco routers is very low overhead, % especially on routers using distributed express forwarding.
while i hate to question mr. ferguson, it's my understanding that many isps have found this feature to be unusable due to network design.
I just took out a 7206 by applying ip verify unicast reverse-path to a T3 link on a PA2T3 and attempting to spoof packets from the POP on the other end of that T3.
The 7206 is running c7200-inu-mz.111-25.CC. Fortunately, it rebooted after it crashed.
See: CSCdm34439 - "configuring ip verify unicast return-path causes crash." Found in 11.1(25)CC, fixed in 11.1(26.1)CC. Release-note is --------------- Configuring 'ip verify unicast return-path' on many interfaces may cause crash. --------------- As I recall, it gets tickled if there's multi-path stuff going on, ie. multiple paths to a given destination, though it may not need that to crash. Just one other note: This feature is NOT "unsuable due to network design". True, it's isn't useful for multihomed destinations (eg. where a customer is multihomed to different routers), but it is useful in other cases which is typically the vast, vast majority. Somewhat like Lojack, it's not crucial that it be absolutely ubiquitous, every little bit helps the community at large. Tony
On Wed, 28 Jul 1999, Tony Tauber wrote:
See:
CSCdm34439 - "configuring ip verify unicast return-path causes crash." Found in 11.1(25)CC, fixed in 11.1(26.1)CC.
Actually, Cisco's Bug By ID search shows that CSCdm34439 is fixed in 11.1(27)CC 11.1(27)CT. When I go to download software, the latest I can find is c7200-inu-mz.111-26.CC1.bin. I just ran into what appears to be another bug in 111-25.CC, which seems to have caused the 7206 to start dropping most UDP traffic (i.e. all radius packets crossing through it)...so I'd like to upgrade asap. ----don't waste your cpu, crack rc5...www.distributed.net team enzo--- Jon Lewis *jlewis@lewis.org*| Spammers will be winnuked or System Administrator | nestea'd...whatever it takes Atlantic Net | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________
[ On Wednesday, July 28, 1999 at 11:21:35 (-0400), Daniel Senie wrote: ]
Subject: Re: SYN spoofing
I suspect most deployed routers do at least some filtering of packets on most or all interefaces. In the past, some routers couldn't do these lookups efficiently on source addresses, but that's really an implementation issue. It's *possible* to design hardware that can handle it, if there's a business case for doing so. ISPs should be interested in doing such filtering.
In fact it's easy to buy off-the-shelf hardware today that can do wire-speed filtering, assuming one has worked such costs into the budget of building a network backbone.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Wed, 28 Jul 1999, Greg A. Woods wrote:
[ On Wednesday, July 28, 1999 at 11:21:35 (-0400), Daniel Senie wrote: ]
Subject: Re: SYN spoofing
In fact it's easy to buy off-the-shelf hardware today that can do wire-speed filtering, assuming one has worked such costs into the budget of building a network backbone....
It is possible to do access filtering on the edges. Then comes the operational aspects of actually making such a thing scale across many many edge devices, especially when there are customers with their own space, and who may have customers behind them with _their_ own space. If a promising local isp is providing transit to a bunch of other local isps, changing every access-list on every edge node every time one of the customer isp's adds or deletes a customer, becomes a logistical nightmare. Some promising local isp's are then faced with blowing out huge access-lists virtually every hour of the day, and this becomes harder to manage when you take into accounts and now you have several tens of promising local isps all trying to match access-lists all around. Not to mention the actual physical limits on current hardware regarding the size of configurations. /vijay
Right, but ISPs can still filter on the corporate networks and at the aggregation points for DSL and dial and any non-bgp customer. Those talking BGP to you should be encouraged to do similarly. The full thing is like next to impossible to maintain but doing these kinds of relatively stady-state bits and pieces can help.
On Wed, 28 Jul 1999, Greg A. Woods wrote:
[ On Wednesday, July 28, 1999 at 11:21:35 (-0400), Daniel Senie wrote: ]
Subject: Re: SYN spoofing
In fact it's easy to buy off-the-shelf hardware today that can do wire-speed filtering, assuming one has worked such costs into the budget of building a network backbone....
It is possible to do access filtering on the edges. Then comes the operational aspects of actually making such a thing scale across many many edge devices, especially when there are customers with their own space, and who may have customers behind them with _their_ own space. If a promising local isp is providing transit to a bunch of other local isps, changing every access-list on every edge node every time one of the customer isp's adds or deletes a customer, becomes a logistical nightmare.
Some promising local isp's are then faced with blowing out huge access-lists virtually every hour of the day, and this becomes harder to manage when you take into accounts and now you have several tens of promising local isps all trying to match access-lists all around. Not to mention the actual physical limits on current hardware regarding the size of configurations.
/vijay
---------------------------------------------------------------------- Wayne Bouchard Frontier GlobalCenter web@globalcenter.net Network Engineer (602) 416-6290 800-373-2499 x6290 FAX: (602) 416-6111 http://www.globalcenter.net ----------------------------------------------------------------------
Wayne Bouchard wrote:
Right, but ISPs can still filter on the corporate networks and at the aggregation points for DSL and dial and any non-bgp customer. Those talking BGP to you should be encouraged to do similarly. The full thing is like next to impossible to maintain but doing these kinds of relatively stady-state bits and pieces can help.
And especially filtering out stuff like RFC 1918 source addresses and such. That kind of thing should be possible on all routers (core and edge) rather than adding to the pollution on the 'net. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Wed, 28 Jul 1999, Daniel Senie wrote:
Cisco implemened a feature called "Unicast RPF" That disallows forwarding of packets on an interface where a reverse path is not present. The command to activate it is:
ip verify unicast reverse-path
This only works if you have CEF turned on. And... Turning CEF on in a 4500 series router w/64mb ram & 2 BGP views just plain isn't good. Now, if we could get CEF to only cache non BGP routes.... - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
While it is easy, it is not always practical because you often have customers who advertise thousands of prefixes. Or, in the simpler case, if you transit 500,000 pps on a single outbound link/router, it becomes very expensive to do per packet filtering outbound. At our ingress points, for example, (from peers and customers) we do filter bogus traffic so we in turn, do not pass undesirable traffic on. At ingress points where you are only seeing 150,000 pps its not so bad doing per packet filtering. Just an opinion, Deepak Jain AiNET On Wed, 28 Jul 1999, Joe Shaw wrote:
Any provider who allows the passing of address space that isn't his own (beyond whatever transit they may provide to their peers) is shameful.
How hard is it really to put a filter on your outbound links that says drop all ip traffic heading out these links that isn't from my IP space? It's just like martian filters for your inbound links, and we'd see a significant decrease in spoofing based attacks if it was more widely adopted. Not to mention it'll keep peers from dumping traffic on you.
-- Joseph W. Shaw - jshaw@insync.net Freelance Computer Security Consultant and Perl Programmer Free UNIX advocate - "I hack, therefore I am."
On Wed, 28 Jul 1999, John Fraizer wrote:
Perhaps if you were to NAME these networks, they may be shamed into doing something about the problem. Then again, they should be ashamed to begin with for passing RFC1918 traffic, let alone loopback space.
On Wed, 28 Jul 1999, Deepak Jain wrote:
While it is easy, it is not always practical because you often have customers who advertise thousands of prefixes.
Why would this have any impact on filtering rfc1918 and other invalid nets like 127.0.0.0/8 and 255.255.255.255? Or perhaps someone could explain a valid reason to route these addresses. -Dan
On Wed, 28 Jul 1999, Joe Shaw wrote: :Any provider who allows the passing of address space that isn't his own :(beyond whatever transit they may provide to their peers) is shameful. : :How hard is it really to put a filter on your outbound links that says :drop all ip traffic heading out these links that isn't from my IP space? :It's just like martian filters for your inbound links, and we'd see a :significant decrease in spoofing based attacks if it was more widely :adopted. Not to mention it'll keep peers from dumping traffic on you. As far as I can tell, if the RST packets are hitting their firewall, it isn't just a case of filtering packets with a dst of an rfc1918 addr. If someone is spoofing a scan from 10/8, and the responses are hitting an interface on a firewall, that means that there is a route for 10/8 somewhere in that AS pointing to that firewall, which also means that someone is allowing their customers to leak that route to them. This is much worse problem than simply not filtering individual packets. I think that most of the net knows not to announce rfc1918 addrs via bgp, it just seems that some providers are allowing these routes to pollute their IGP which, depending on the size of the AS, is just as bad. -- batz Chief Reverse Engineer Superficial Intelligence Research Division Defective Technologies
How hard is it really to put a filter on your outbound links that says drop all ip traffic heading out these links that isn't from my IP space?
trivial. only one gotcha. if it is a backbone router, it will fall over dead. beyond that, not a problem. backbone level traffic can not be packet filtered by current real routers. but we've had this discussion a few times already. randy
On Wed, 28 Jul 1999, John Fraizer wrote:
Perhaps if you were to NAME these networks, they may be shamed into doing something about the problem.
Anyone for a weekly 'bogons transit list'?
Then again, they should be ashamed to begin with for passing RFC1918 traffic, let alone loopback space.
You would think so. But somehow these packets still show up. -Dan
In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr ites:
On Wed, 28 Jul 1999, John Fraizer wrote:
Perhaps if you were to NAME these networks, they may be shamed into doing something about the problem.
Anyone for a weekly 'bogons transit list'?
The problem being, that you would need to know where these packets originated, and if you knew that, you could probably get the problem fixed in the first place. Lack of a soci-technological solution for interprovider backtracing limits the utility of this, and since you can't really pin point the 10 ten bogon transit providers you don't have much ability to shame people into fixing their stuff.
Then again, they should be ashamed to begin with for passing RFC1918 traffic, let alone loopback space.
You would think so. But somehow these packets still show up.
-Dan
--- jerry@fc.net Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net #include <sys/machine/wit/fortune.h>
On Wed, 28 Jul 1999, Jeremy Porter wrote:
In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr ites:
Anyone for a weekly 'bogons transit list'? The problem being, that you would need to know where these packets originated, and if you knew that, you could probably get the problem fixed in the first place.
You really think so? Some of us have tried to persuade the 'big names' to filter completely bogus source addresses, and were blown off.
Lack of a soci-technological solution for interprovider backtracing limits the utility of this, and since you can't really pin point the 10 ten bogon transit providers you don't have much ability to shame people into fixing their stuff.
You can at least conclusively show who is transporting the invalid-source-address-packets to the endpoint. That is, conclusively show that the next-to-last-hop isnt properly filtering. -Dan
In message <Pine.LNX.4.10.9907281413230.19707-100000@anime.net>, Dan Hollis wr ites:
On Wed, 28 Jul 1999, Jeremy Porter wrote:
In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr ites:
Anyone for a weekly 'bogons transit list'? The problem being, that you would need to know where these packets originated, and if you knew that, you could probably get the problem fixed in the first place.
You really think so? Some of us have tried to persuade the 'big names' to filter completely bogus source addresses, and were blown off.
I was talking about the source of the problem. The upstream transit providers that "blew you off" were not the source of the problem. They only contributed to it.
Lack of a soci-technological solution for interprovider backtracing limits the utility of this, and since you can't really pin point the 10 ten bogon transit providers you don't have much ability to shame people into fixing their stuff.
You can at least conclusively show who is transporting the invalid-source-address-packets to the endpoint. That is, conclusively show that the next-to-last-hop isnt properly filtering.
But that doesn't really do any good. They have valid reasons for not running IP verify unicast reverse path on their backbone routers due to asymetric routing. Maybe we should ask Cisco for a "no ip bogons" command. If we start now it might be ready for release 13.0 of IOS. Its doesn't scale for transit providers to filter, the only solution is to filter at the source, which is not feasable with your suggestions, as the source has not been identified. Yes it would be good to filter. Maybe it should even be a BCP. Maybe the next router requirements should require routers to filter bogons at wire rate. Interprovider cooperation to track and filter the packets is the correct solution, however difficult it might be.
-Dan
--- jerry@fc.net Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net #include <sys/machine/wit/fortune.h>
On Wed, 28 Jul 1999, Jeremy Porter wrote:
You can at least conclusively show who is transporting the invalid-source-address-packets to the endpoint. That is, conclusively show that the next-to-last-hop isnt properly filtering. But that doesn't really do any good. They have valid reasons for not running IP verify unicast reverse path on their backbone routers due to asymetric routing.
Note I wasnt talking about RPF I was talking about bogons. The last few smurf attacks I saw, bogons were a large percentage of total smurf volume.
Maybe we should ask Cisco for a "no ip bogons" command.
Would be nice especially if it defaulted to on (like current 'no directed-broadcast').
Yes it would be good to filter. Maybe it should even be a BCP. Maybe the next router requirements should require routers to filter bogons at wire rate.
Well for terminal servers this should certainly be a reasonable requirement. An option to disconnect any port which is found to be sourcing invalid addresses would be excellent. It would certainly be a deterrent to the script kiddies if they knew each time they fired up the smurfer, that they automatically lose their connection.
Interprovider cooperation to track and filter the packets is the correct solution, however difficult it might be.
And how many years have we been screaming about this with no progress. There seems to be zero incentive for interprovider cooperation. We need to give them incentive. But what? -Dan
At 12:45 PM 7/28/99 -0700, Dan Hollis wrote:
Anyone for a weekly 'bogons transit list'?
Sounds like a good idea. The Hall of Shame. ------------ John Fraizer ------------ mailto:john.fraizer@EnterZone.Net http://www.EnterZone.Net http://www.EZ-Hosting.Net http://www.EZ-IP.Net ------------------------------------------ | __ _ | | | / / (_)__ __ ____ __ | The choice | | / /__/ / _ \/ // /\ \/ / | of a GNU | | /____/_/_//_/\_,_/ /_/\_\ | Generation | | | | ------------------------------------------
participants (18)
-
bandregg＠redhat.com -
batz -
bryan s. blank -
Dan Hollis -
Daniel Senie -
Deepak Jain -
Forrest W. Christian -
Jared Mauch -
Jeremy Porter -
jlewis＠lewis.org -
Joe Shaw -
John Fraizer -
John Fraizer
-
Randy Bush -
Tony Tauber -
Vijay Gill -
Wayne Bouchard -
woods＠most.weird.com