Dan Hollis <goemon@sasami.anime.net> wrote:
The best penalty of all - simply pulling customer's plug till they fix their network, with a repeat offense resulting in permanent disconnection.
Heh. Engineering guys who try to do that very quickly find very irate sales and management types screaming abuse at them :( The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side. --vadim
On Tue, 8 Feb 2000, Vadim Antonov wrote:
The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side.
Unfortunately I suspect its going to take some high profile lawsuits before this gets widely enough deployed by providers to be effective. There just isnt the financial incentive for providers to be bothered with it, so its going to have to end up being a legal liability if they dont, before they will take action. Really, I think things like RPF and other *basic* filters should be a contractual requirement before allowing customers to connect to the network. Hell, im thinking Cisco and others should make it a *default*. ;) -Dan
At 02:56 AM 02/09/2000 -0800, Dan Hollis wrote:
eally, I think things like RPF and other *basic* filters should be a contractual requirement before allowing customers to connect to the network. Hell, im thinking Cisco and others should make it a *default*. ;)
Well, we _do_ have a unicast RPF knob, but changing defaults is tough, due to the Principle of Least Astonishment. ;-) Education is key here. - paul
On Wed, 9 Feb 2000, Paul Ferguson wrote:
Well, we _do_ have a unicast RPF knob, but changing defaults is tough, due to the Principle of Least Astonishment. ;-)
Sorry, this may be low, but... It would help if we could actually turn on CEF and not have it break weird and interesting things. This week it seems to have broken frame relay adaptive traffic shaping (it always "adapts"), which I need to contact the TAC about finding/submitting a bug. (CEF is required at least on "lower end" routers for RPF) - 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 ----------------------------------------------------------------------
On Wed, 9 Feb 2000, Paul Ferguson wrote:
eally, I think things like RPF and other *basic* filters should be a contractual requirement before allowing customers to connect to the network. Hell, im thinking Cisco and others should make it a *default*. ;)
Well, we _do_ have a unicast RPF knob, but changing defaults is tough, due to the Principle of Least Astonishment. ;-)
Even though the RPF knob is there, there's lots of gear running code that either doesn't have it or blows up when it's pulled. ---------------------------------------------------------------------- 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__________
The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side.
nope, won't work. well...it might, but you also might find very irate customers jumping up and down screaming about the filtering. the provider simply cannot know what is and what is not a broadcast address, simply because the customer gets to set up their own networks. i, for one, am using what is "technically" a broadcast address as a unicast address (think point to point). others may be doing the same. just because an address is an one end or another of a cidr block (or c or b block), doesn't mean that it's broadcast. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
Andrew Brown wrote:
The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side.
nope, won't work. well...it might, but you also might find very irate customers jumping up and down screaming about the filtering. the provider simply cannot know what is and what is not a broadcast address, simply because the customer gets to set up their own networks.
i, for one, am using what is "technically" a broadcast address as a unicast address (think point to point). others may be doing the same. just because an address is an one end or another of a cidr block (or c or b block), doesn't mean that it's broadcast.
You're correct. Directed broadcast can only be properly identified in the equipment on the specific subnet. In other words, EVERYONE has to fix this, from end users to ISPs. To Vadim's main point, though, where to place protections: the answer I normally give to clients (whether ISPs or end users) is do it everywhere. There's no reason NOT to filter the egress from a corporate network, and then at the provider side filter the ingress from that same corporate network. There is plenty of router gear which can handle the needed filtering. Dialup pools should also be protected. No sense in permitting problems to originate on a dialup modem or ISDN line. I know the Lucent/Ascend MAX product accepts an attribute Ascend-Source-IP-Check, which can be applied as a part of the RADIUS authentication. Have the large dialup wholesalers implemented this? There'll be no magic cure for this issue. It will take a lot of measures from everyone. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side.
nope, won't work. well...it might, but you also might find very irate customers jumping up and down screaming about the filtering. the provider simply cannot know what is and what is not a broadcast address, simply because the customer gets to set up their own networks.
i, for one, am using what is "technically" a broadcast address as a unicast address (think point to point). others may be doing the same. just because an address is an one end or another of a cidr block (or c or b block), doesn't mean that it's broadcast.
You're correct. Directed broadcast can only be properly identified in the equipment on the specific subnet. In other words, EVERYONE has to fix this, from end users to ISPs.
yep.
To Vadim's main point, though, where to place protections: the answer I normally give to clients (whether ISPs or end users) is do it everywhere. There's no reason NOT to filter the egress from a corporate network, and then at the provider side filter the ingress from that same corporate network. There is plenty of router gear which can handle the needed filtering.
right, and there *are* things that providers *can* do in the way of egress filtering. for customers that are either (a) not multi-homed or (b) not providing transit to their peers, they can do source filtering.
Dialup pools should also be protected. No sense in permitting problems to originate on a dialup modem or ISDN line. I know the Lucent/Ascend MAX product accepts an attribute Ascend-Source-IP-Check, which can be applied as a part of the RADIUS authentication. Have the large dialup wholesalers implemented this?
probably not. i'd be willing to be that a majority of the equipment that's in use these days for providing dialup service doesn't have that sort of capability. one simple "cure", then, would be to place something (a facket pilfering router) in between the dialup servers and *their* means of internet connectivity. a small separate lan for your dialup pool.
There'll be no magic cure for this issue. It will take a lot of measures from everyone.
yep. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dialup pools should also be protected. No sense in permitting problems to originate on a dialup modem or ISDN line. I know the Lucent/Ascend MAX product accepts an attribute Ascend-Source-IP-Check, which can be applied as a part of the RADIUS authentication. Have the large dialup wholesalers implemented this?
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering. -Dan
Funny. On an as5300 with compression turned on, and 96 56K users dialed up and active, I've never seen the CPU load go above 15% On Wed, 9 Feb 2000, Dan Hollis wrote: | | On Wed, 9 Feb 2000, Daniel Senie wrote: | > Dialup pools should also be protected. No sense in permitting problems | > to originate on a dialup modem or ISDN line. I know the Lucent/Ascend | > MAX product accepts an attribute Ascend-Source-IP-Check, which can be | > applied as a part of the RADIUS authentication. Have the large dialup | > wholesalers implemented this? | | When I asked a couple dialup wholesalers this question point blank last | year, the answer was no - because their routers/term servers didn't have | enough CPU to do filtering. | | -Dan | | | --- Gates' Law: Every 18 months, the speed of software halves.
On Wed, 9 Feb 2000, Chris Cappuccio wrote:
Funny. On an as5300 with compression turned on, and 96 56K users dialed up and active, I've never seen the CPU load go above 15%
And we have anti-spoofing filters on for all of the 3com TC's that we own, and we don't see any performance hit. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
On Wed, 9 Feb 2000, Brandon Ross wrote:
On Wed, 9 Feb 2000, Chris Cappuccio wrote:
Funny. On an as5300 with compression turned on, and 96 56K users dialed up and active, I've never seen the CPU load go above 15% And we have anti-spoofing filters on for all of the 3com TC's that we own, and we don't see any performance hit.
Maybe its time for a spoofing-source registry similar to the smurf-amp registry. Eg networks which allow spoofing to originate from them -Dan
You're forgetting a key point... an as5300 or a MAX is not a generic box. They're well supported (toungue in cheek) boxes. But how about other boxes from less established vendors.. The ones that barely know how to do do PPP, much less packet filtering. These are going to be a constant problem. Some of these will never care about this stuff and others will end up being put in use before they get this stuff and never get upgraded.
Funny. On an as5300 with compression turned on, and 96 56K users dialed up and active, I've never seen the CPU load go above 15%
On Wed, 9 Feb 2000, Dan Hollis wrote:
| | On Wed, 9 Feb 2000, Daniel Senie wrote: | > Dialup pools should also be protected. No sense in permitting problems | > to originate on a dialup modem or ISDN line. I know the Lucent/Ascend | > MAX product accepts an attribute Ascend-Source-IP-Check, which can be | > applied as a part of the RADIUS authentication. Have the large dialup | > wholesalers implemented this? | | When I asked a couple dialup wholesalers this question point blank last | year, the answer was no - because their routers/term servers didn't have | enough CPU to do filtering. | | -Dan | | |
--- Gates' Law: Every 18 months, the speed of software halves.
---------------------------------------------------------------------- Wayne Bouchard [Immagine Your ] web@typo.org [Company Name Here] Network Engineer ----------------------------------------------------------------------
Dan Hollis wrote:
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dialup pools should also be protected. No sense in permitting problems to originate on a dialup modem or ISDN line. I know the Lucent/Ascend MAX product accepts an attribute Ascend-Source-IP-Check, which can be applied as a part of the RADIUS authentication. Have the large dialup wholesalers implemented this?
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering.
I don't buy this. The wholesalers are allowing (requiring?) filters be added to block port 25 to all but the retail ISP's mail servers. Seems to me if the box can handle that filter, adding one for source IP is isn't significant additional load. The nice thing with the Ascend attribute is the ability to apply it generically, and without the Radius server having to know the IP address being assigned to the user. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Wed, 9 Feb 2000, Daniel Senie wrote:
I don't buy this. The wholesalers are allowing (requiring?) filters be added to block port 25 to all but the retail ISP's mail servers.
I dont buy it either, but when youre not their customer they dont have much incentive to lift a finger to stop denial of service attacks. Its also the excuse they gave me why they couldnt be bothered to disable directed broadcasts, by the way. "We dont have enough cpu to filter them". I think all the tier1 networks need to seriously clean out the complacent dead wood and dust off the clue by four. -Dan
On Wed, Feb 09, 2000 at 12:20:22PM -0800, Dan Hollis wrote:
On Wed, 9 Feb 2000, Daniel Senie wrote:
I don't buy this. The wholesalers are allowing (requiring?) filters be added to block port 25 to all but the retail ISP's mail servers.
I dont buy it either, but when youre not their customer they dont have much incentive to lift a finger to stop denial of service attacks.
Its also the excuse they gave me why they couldnt be bothered to disable directed broadcasts, by the way. "We dont have enough cpu to filter them".
This is a total shield these days if anyone claims that. they either don't know how to manage their equipment, or have other serious issues. The only exceptions would be people who are entireley at the OCn speed, and then it gets more dificult to filter. Everyone comes down to at least 100M/sec (i guess, unless they're talking gig e) and more likeley down to 45M or 10M at some point. It's not that dificult to filter traffic. The problem becomes deploying it in an existing infrastructure. You don't want to break your existing customers. That's why it can sometimes take a few days to shut down an open relay. You have to determine who is allowed to use it and who is not. There is no excuse for directed broadcasts these days though.
I think all the tier1 networks need to seriously clean out the complacent dead wood and dust off the clue by four.
I agree, but I also understand that the job is not quite as simple as you state. I'm sure it would take a group of people a day or two to just do a single POP at a large provider. Many people would be easy to take care of because they have a single t1 or something, but once you're multihomed things become extremeley painful. My rule of thumb is that if you're not speaking bgp though, you can source filter easily, using the existing cisco knobs. (with your customer that is). I recommend that the contracts that the tier 1 providers write require that the people who they provide access to run a secure network, and list a 'security contact' before they will turn on services. it's fairly simple. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
Hello NANOG folks...(this is rather long, sorry) In light of those new attacks i decided to demonstate that some NSPs are as clueless as those DoS monkies. lets take a look at 206.251.5.238 [noc:/usr3/staff/basil/work/security/DoS-attacks/jan30-2000/2nd]: ll total 64 -rw-r--r-- 1 basil staff 1614 Jan 30 16:27 amps -rw-r--r-- 1 basil staff 62058 Jan 30 16:23 jan30-smurf -rw-r--r-- 1 basil staff 68 Jan 30 17:23 possible-idiots let me demonstate: from jan30-smurf file. icmp 207.204.18.146 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 12.2.79.2 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 132.248.1.27 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 146.64.123.161 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet icmp 194.52.223.39 (Serial1/0 *HDLC*) -> 207.152.95.11 (0/0), 1 packet etc... full list of amps/logs are available upon request.. during the attack there was 2 traceroutes, probably to see our "network performance" ;) Jan 30 15:46:20 gw 748: *Jan 30 15:46:00: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33462), 1 packet Jan 30 15:46:25 gw 749: *Jan 30 15:46:06: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33463), 1 packet etc... Jan 30 15:46:20 gw 748: *Jan 30 15:46:00: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33462), 1 packet Jan 30 15:46:25 gw 749: *Jan 30 15:46:06: %SEC-6-IPACCESSLOGP: list 110 denied udp 206.251.5.238(40711) (Serial1/0 *HDLC*) -> 207.152.95.11(33463), 1 packet 202.216.31.97 webserv1.dlinx.co.jp 206.251.5.238 www3.galttech.com route-views.oregon-ix.net>traceroute 206.251.5.238 Type escape sequence to abort. Tracing the route to www3.galttech.com (206.251.5.238) 1 nero-eugene-hub.oregon-ix.net (198.32.162.2) [AS 2914] 4 msec 0 msec 0 msec 2 eugene-isp.nero.net (207.98.64.41) [AS 3701] 0 msec 4 msec 0 msec 3 xcore2-serial0-1-0.SanFrancisco.cw.net (204.70.32.5) [AS 3561] 16 msec 16 msec 8 msec 4 bordercore1.SanFrancisco.cw.net (166.48.12.1) [AS 3561] 16 msec 12 msec 12 msec 5 frontier-communications.SanFrancisco.cw.net (166.48.13.242) [AS 3561] 536 msec 508 msec 560 msec 6 pos1-0-0-155M.hr3.SNV.gblx.net (206.251.0.113) [AS 3549] 552 msec 448 msec 436 msec 7 www3.galttech.com (206.251.5.238) [AS 3549] 436 msec 388 msec 404 msec XX pos0-0-0-155M.hr3.SNV.gblx.net (206.132.150.210) | 13 Mb/s, 433 us (86.3 ms), +q 19.5 ms (31.7 KB) *2 <--Ethernet! XX www3.galttech.com (206.251.5.238) Now lets get on that box, virtually of course, and see what is going on there - http://www.thebigboss.com/opt/ (don't ask where we got this info from, lets just say we have an informant, note: he/she is not one of those DoS kiddies) According to the same person, *.jp proxies are being used to access that box, to run those atacks. 9 hours before that smurf we were under another one of those Distributed DoSes, [noc:/usr3/staff/basil/work/security/DoS-attacks/jan30-2000/]: ll total 90 drwxr-xr-x 2 basil staff 512 Jan 30 17:23 2nd/ -rw-r--r-- 1 basil staff 4003 Jan 30 11:59 acl-110 -rw-r--r-- 1 basil staff 65796 Jan 30 11:42 jan30-2000 Jan 30 09:45:07 gw 93: *Jan 30 09:44:48: %SEC-6-IPACCESSLOGP: list 110 denied tcp 195.42.93.14(1671) (Serial1/0 *HDLC*) -> 207.152.95.11(7), 1 packet Jan 30 09:45:09 gw 95: *Jan 30 09:44:49: %SEC-6-IPACCESSLOGP: list 110 denied tcp 158.117.186.23(1545) (Serial1/0 *HDLC*) -> 207.152.95.11(9), 1 packet Jan 30 09:45:10 gw 96: *Jan 30 09:44:51: %SEC-6-IPACCESSLOGP: list 110 denied tcp 146.158.235.55(1893) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet Jan 30 09:45:10 gw 97: *Jan 30 09:44:52: %SEC-6-IPACCESSLOGP: list 110 denied tcp 158.54.158.117(1289) (Serial1/0 *HDLC*) -> 207.152.95.11(7), 1 packet Jan 30 09:45:12 gw 99: *Jan 30 09:44:53: %SEC-6-IPACCESSLOGP: list 110 denied tcp 160.137.84.13(1982) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet Jan 30 09:45:13 gw 101: *Jan 30 09:44:54: %SEC-6-IPACCESSLOGP: list 110 denied tcp 147.128.16.56(1527) (Serial1/0 *HDLC*) -> 207.152.95.11(53), 1 packet etc..i suspect the same kiddies did it 206.251.5.238... The box is still up and running and kiddies are still [d]DoSing from that server. ---- Lessons to be learned (?) * ip verify unicast reverse-path, works and works quite nicely. * if you can't do unicast reverse-path for some reason, do this deny ip 0.0.0.0 255.255.255.0 any log-input deny ip 0.0.0.255 255.255.255.0 any log-input deny ip any 0.0.0.0 255.255.255.0 log-input deny ip any 0.0.0.255 255.255.255.0 log-input * i think it is time for some ISPs/NSPs to re-think their network policies for example: how about CARing ICMP and related crap at MAEs/NAPs as well as at private interconnections? How about putting nice filters for every non-BGP/singlehomed customer to prevent them from spoofing? Ever try calling Sprint, Level3, @HOME/@WORK, UUnet, Qwest/Iconnet, Corecomm, Savvis etc.. etc.. [with few exceptions, BBNPlanet/ISPDirect and C&W], asking them to shutdown their amps or to track down those [d]DoSes? And how about releasing phone numbers for Security Departments, and not those free-toll dialup support monkies who has no clue wtf is going on. besides they won't transfer you to the real NOC or Security because you're not a customer/peer. Another excuse "our policy states that you have to send logs to abuse/security @ company... and they will take a look at it in the morning." Sometimes you just can't wait, and blackholing isn't really an option. Sometimes we get telephone calls in the middle of a night, "why is your X.X.X.X flooding our entire network?" Guess what, moron, you're the one who's flooding.. go fix it.. and they quickly hung up, 90% of the time they don't know how to fix [http://www.quadrunner.com/~chuegen/smurf.cgi] nor care "its only affecting our network at night...who cares.. we're fine during the day!" To summarize: How about taking those [d]DoSes seriously? Educate your NOCs, impliment new policies, new ACLs/CAR. Force your downstreams & peers to do the same. oh and by the way: *for all those stock holders* If i'm not mistaken, Exodus and few others cannot put ACLs/CAR for their customers (policies.. policies... politics, apparantely DoSes are good for their stock ;) X0 Mbps attack tcp/udp attack for Y number of hours and poor customer will end up paying couple more Ks than he/she usually does. Now lets multiple those X/Y... flood those non high-profile sites and you will get nice check every month. even better, just flood your competition out of business, some people just can't afford Flat 100Mbps/Gigabit pipes. -Basil Kruglov My current ratio is 1.5:1 (one, sometimes two DoS[es]:daily), whats yours?
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering.
i am rather amused at folk who fear dialup systems being used as ddos slaves. randy
On Wed, 9 Feb 2000, Randy Bush wrote:
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering. i am rather amused at folk who fear dialup systems being used as ddos slaves.
An ascend TNT makes a rather nice smurf amp -Dan
Dan Hollis wrote:
On Wed, 9 Feb 2000, Randy Bush wrote:
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering. i am rather amused at folk who fear dialup systems being used as ddos slaves.
An ascend TNT makes a rather nice smurf amp
funny... there is a "Forward Directed Broadcast" option in the config. Turning this off does seem to work. Of course that doesn't mean folks HAVE turned it off... Such an option typically adds no extra overhead to a router, as it's handled as part of the route lookup. Overhead isn't the issue. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dan Hollis wrote:
An ascend TNT makes a rather nice smurf amp funny... there is a "Forward Directed Broadcast" option in the config. Turning this off does seem to work. Of course that doesn't mean folks HAVE turned it off...
Yup, makes you wonder why they havent done it Doubly confusing if ascend hasnt made it default Which term server vendors have RPF? -Dan
On Wed, Feb 09, 2000 at 03:14:48PM -0800, Dan Hollis wrote:
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dan Hollis wrote:
An ascend TNT makes a rather nice smurf amp funny... there is a "Forward Directed Broadcast" option in the config. Turning this off does seem to work. Of course that doesn't mean folks HAVE turned it off...
Yup, makes you wonder why they havent done it
Doubly confusing if ascend hasnt made it default
Which term server vendors have RPF?
I believe you can do it with cisco and USR TC, along with the mentioned Ascend. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
On Wed, 9 Feb 2000, Dan Hollis wrote:
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dan Hollis wrote:
An ascend TNT makes a rather nice smurf amp funny... there is a "Forward Directed Broadcast" option in the config. Turning this off does seem to work. Of course that doesn't mean folks HAVE turned it off...
Yup, makes you wonder why they havent done it
Ignorance is usually the problem here.
Doubly confusing if ascend hasnt made it default
The last time I installed a TNT it wasn't even an option. The last time I worked with any piece of Ascend gear (pipeline 85), the Forward Directed Broadcast option was set to yes by default. This may have changed since then. -- Joseph W. Shaw - jshaw@insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am."
Joe Shaw wrote:
On Wed, 9 Feb 2000, Dan Hollis wrote:
On Wed, 9 Feb 2000, Daniel Senie wrote:
Dan Hollis wrote:
An ascend TNT makes a rather nice smurf amp funny... there is a "Forward Directed Broadcast" option in the config. Turning this off does seem to work. Of course that doesn't mean folks HAVE turned it off...
Yup, makes you wonder why they havent done it
Ignorance is usually the problem here.
To be fair, Router Requirements (RFC 1812) required directed broadcast be on by default. RFC 2644/BCP 34 was only published in August 1999, changing the requirement to be OFF by default. Some router vendors, notably Cisco and Proteon (a.k.a. OpenROUTE, now NxNetworks) made the change prior to that new BCP, recognizing that melting down the Internet was the logical result of leaving directed broadcast turned on.
Doubly confusing if ascend hasnt made it default
The last time I installed a TNT it wasn't even an option. The last time I worked with any piece of Ascend gear (pipeline 85), the Forward Directed Broadcast option was set to yes by default. This may have changed since then.
The gear I recently installed was a MAX 6000, running software rev. 7.0.3. I suggest folks give consideration to upgrading to versions which support these features. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Wed, 9 Feb 2000, Dan Hollis wrote:
Which term server vendors have RPF?
USR on the HiPER platform as of some 4.1-x version: ENABLE IP SOURCE_ADDRESS_FILTER Global switch to set SAA for all calls. Default is DISABLED. SET NET USER <name> PPP_SOURCE_IP_FILTER [DISABLED | ENABLED] Sets SAA for a specific local user. 3Com VSA for RADIUS implementation of SAA IP_SAA_FILTER 0x9870 integer Disabled (0) Enabled (1) This is for non-routed dial connections. Charles
-Dan
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering. i am rather amused at folk who fear dialup systems being used as ddos slaves. An ascend TNT makes a rather nice smurf amp
which is utterly irrelevant to the discussion. <sigh> randy
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering.
i am rather amused at folk who fear dialup systems being used as ddos slaves.
it rather depends on whether you consider dsl to be dialup. and they don't have to be slaves. i could be a ddos *controller* over a 2400 baud modem. :) -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
it rather depends on whether you consider dsl to be dialup. and they don't have to be slaves. i could be a ddos *controller* over a 2400 baud modem. :)
for which source filtering would do squat. <sigh^2>
...except force the controller to use its real IP address and thus make it more traceable. Most ICMP- and UDP-triggered flooders on this campus get their control messages from nonsense IP addresses. /cvk
On Wed, 9 Feb 2000, Dan Hollis wrote:
When I asked a couple dialup wholesalers this question point blank last year, the answer was no - because their routers/term servers didn't have enough CPU to do filtering.
It certainly makes you wonder what exactly it is you're paying for when shelling out tens to hundreds of thousands of dollars for term servers. One would think CPU power would at least get some attention. -- Joseph W. Shaw - jshaw@insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am."
participants (17)
-
Andrew Brown -
Basil Kruglov -
Brandon Ross -
Charles Sprickman -
Charley Kline -
Chris Cappuccio -
Dan Hollis -
Daniel Senie -
Forrest W. Christian -
Jared Mauch -
jlewis＠lewis.org -
jmalcolm＠uraeus.com -
Joe Shaw -
Paul Ferguson -
Randy Bush -
Vadim Antonov -
Wayne Bouchard