I'm currently working on a project to help reduce the impact of smurf attacks on our IRC server. Part of the plan requires a /24 of swamp space. Since I'm sure ARIN wouldn't even consider assigning anything out of the swamp or anything that small, I'm wondering if any of you might have one that you're not using and would consider transferring to me. Since I'm sure questions will arise, and this is operational related, I'll share the plan. Most smurf attacks we receive are directed at our IRC server (imagine that). We offer IRC service to both our customers and the outside world. Our customers are not only on our network, but also on several other wholesale dialup providers. To minimise the impact of a smurf attack against our IRC server we will split the server off into 2 servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this purpose only and not be part of the rest of our infrastructure (which is made up mostly of T3's to transit providers for our external connectivity). The public server will use an address assigned by the upstream. There will be a private network connection over Ethernet between the public and private servers. The private server will be connected to the rest of our infrastructure and will use an address out of swamp space. This swamp space will only be advertised to our wholesale dialup providers on a private peering setup so only machines attached to these providers will be able to reach the private irc server. So how does this work? Well, the typical attacker will launch his smurf attack against irc.mindspring.com. irc.mindspring.com resolves to an address within that swamp space I discussed. When the echo-reply from a far off network without "no ip directed-broadcast" gets sent, it has nowhere to go because their upstream doesn't have a route for it. So what happens if they attack the public server? The public server, since it's separated from the rest of our network will at least not effect our customers, only people connected to our public irc server from the outside world. So why don't you just use private IP space? That would require that we and our wholesale providers agree on a private block to use for this purpose. Even if this can be done, if/when we add another wholesaler, who's to say if they will agree to that space as well? Well, you could use NAT between private space in your network and your wholesalers, you say?. I'm trying to keep this as simple and inexpensive as possible. While I'm sure NAT would work fine, I'd like to avoid it if possible. So, any takers? Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
Hello, While IRC is just a game its an interesting game to watch and play. There are other ways to defend (successfully) your IRC server from outside attacks including smurf, fraggle and whatever other program comes from the fingers of bored kids with no lives. I've helped PSI and other providers running IRC servers to better protect their servers (and sometimes their networks), and I am happy to work with you (or anyone else on that note) on how to defend yourself against large IP based attacks. Please let me know if i can be of service. -Steve On Wed, Aug 19, 1998 at 03:18:23AM -0400, Brandon Ross wrote:
I'm currently working on a project to help reduce the impact of smurf attacks on our IRC server. Part of the plan requires a /24 of swamp space. Since I'm sure ARIN wouldn't even consider assigning anything out of the swamp or anything that small, I'm wondering if any of you might have one that you're not using and would consider transferring to me.
Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
-- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Land:408.346.2333 Beep:408.925.8141 Wire:408.221.6417 -- All my love to the Canadian Mooing Frog.
On Wed, 19 Aug 1998, Brandon Ross wrote:
I'm currently working on a project to help reduce the impact of smurf attacks on our IRC server. Part of the plan requires a /24 of swamp space. Since I'm sure ARIN wouldn't even consider assigning anything out of the swamp or anything that small, I'm wondering if any of you might have one that you're not using and would consider transferring to me.
*SNIP*
So what happens if they attack the public server? The public server, since it's separated from the rest of our network will at least not effect our customers, only people connected to our public irc server from the outside world.
So why don't you just use private IP space? That would require that we and our wholesale providers agree on a private block to use for this purpose. Even if this can be done, if/when we add another wholesaler, who's to say if they will agree to that space as well?
Personally, I would go with this option. That's what the space is for. I can't imagine it being that terribly difficult to negotiate this with your upstream(s), and if you need to change, it should be fairly trivial. Otherwise, why not just get real space from your upstream(s) and have them blackhole the route at their borders? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v Systems Administrator (925) 377-1212 v NameSecure (925) 377-1414 f \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Wed, 19 Aug 1998, Patrick Greenwell wrote:
So why don't you just use private IP space? That would require that we and our wholesale providers agree on a private block to use for this purpose. Even if this can be done, if/when we add another wholesaler, who's to say if they will agree to that space as well?
Personally, I would go with this option. That's what the space is for. I can't imagine it being that terribly difficult to negotiate this with your upstream(s), and if you need to change, it should be fairly trivial.
One of the wholesaler's we use in particular will probably make this next to impossible. I feel no need to mention names here, but they have been very uncooperative in the past and I don't expect them to act any differently in this situation.
Otherwise, why not just get real space from your upstream(s) and have them blackhole the route at their borders?
That's an interesting idea, and perhaps I'm missing something, but the only way I can think of that this could be done would be for the provider who has assigned this space to put a static route in every single one of their border routers. That is assuming that they assign me a block out of a larger announcement which would almost certainly be the case (unless they happened to have some swamp space they could give me). I doubt they'd be willing to do that since it's certainly not very scalable. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this
OK, tell me where this falls down. Set up two IP addresses for your IRC server on the same machine. On the router upstream from the machine, allow only your customers to connect to one IP address, and anyone else to connect to the other IP. Now go to your border routers, enable CEF and configure something like: ! impose limits access-list 100 permit ip any host public-irc.my.net access-list 100 permit ip any host public-irc.my.net access-list 101 deny ip any host private-irc.my.net ! i/f config for borders interface myinterface ip access-group 101 in rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs). If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem. -- Alex Bligh GX Networks (formerly Xara Networks)
I too have a similar setup for my network since we as well run an Efnet irc server, however, CAR really won't do much if you set it up inside your own network. The smurf will still enter and saturate your pipes. The best thing to do is to have your upstreams setup rate-limits on their side of your pipes so the feed coming into your router is limited before it even hits your router. Here is a question though, what kind of CPU drain does rate-limiting cause on the CPU of the routers running it? I flipped through CCO and couldn't find any information regarding this... Alex Bligh wrote:
servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this
OK, tell me where this falls down. Set up two IP addresses for your IRC server on the same machine. On the router upstream from the machine, allow only your customers to connect to one IP address, and anyone else to connect to the other IP. Now go to your border routers, enable CEF and configure something like:
! impose limits access-list 100 permit ip any host public-irc.my.net access-list 100 permit ip any host public-irc.my.net access-list 101 deny ip any host private-irc.my.net ! i/f config for borders interface myinterface ip access-group 101 in rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop
Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs).
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
-- Alex Bligh GX Networks (formerly Xara Networks)
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
Steve,
I too have a similar setup for my network since we as well run an Efnet irc server, however, CAR really won't do much if you set it up inside your own network. The smurf will still enter and saturate your pipes. The best thing to do is to have your upstreams setup rate-limits on their side of your pipes so the feed coming into your router is limited before it even hits your router.
Here is a question though, what kind of CPU drain does rate-limiting cause on the CPU of the routers running it? I flipped through CCO and couldn't find any information regarding this...
My limited experience is that if you run CEF on the interface concerned, life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA where fast discards and routes to null0 were introduced, life is disastrous. Alex Bligh GX Networks (formerly Xara Networks)
Alex Bligh wrote:
servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this
OK, tell me where this falls down. Set up two IP addresses for your IRC server on the same machine. On the router upstream from the machine, allow only your customers to connect to one IP address, and anyone else to connect to the other IP. Now go to your border routers, enable CEF and configure something like:
! impose limits access-list 100 permit ip any host public-irc.my.net access-list 100 permit ip any host public-irc.my.net access-list 101 deny ip any host private-irc.my.net ! i/f config for borders interface myinterface ip access-group 101 in rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop
Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs).
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
-- Alex Bligh GX Networks (formerly Xara Networks)
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
That's Odd, because with my experience with it, the destination (for example, irc.lightning.net) gets the committed access rate you set, however, the pipes are still flooded and connectivity to the outside world is poor to nil. You would still have to agree that by having the upstream providors set the rate-limits is the safest and most effective interim solution until something can be done permanently about this oh so wonderful attack :-) Alex Bligh wrote:
My limited experience is that if you run CEF on the interface concerned, life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA where fast discards and routes to null0 were introduced, life is disastrous.
Alex Bligh GX Networks (formerly Xara Networks)
Alex Bligh wrote:
servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this
OK, tell me where this falls down. Set up two IP addresses for your IRC server on the same machine. On the router upstream from the machine, allow only your customers to connect to one IP address, and anyone else to connect to the other IP. Now go to your border routers, enable CEF and configure something like:
! impose limits access-list 100 permit ip any host public-irc.my.net access-list 100 permit ip any host public-irc.my.net access-list 101 deny ip any host private-irc.my.net ! i/f config for borders interface myinterface ip access-group 101 in rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop
Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs).
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
-- Alex Bligh GX Networks (formerly Xara Networks)
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
Jeff, Sorry I thought you were talking about router load. Yeah, if you discard at the end of your upstream provider's link, then that link will get saturated if you are smurfed enough. Last time we had a really bad one, we were looking at 6-10Mb/s which was not enough to saturate transit DS-3s, but enough to saturate a few bits of internal network (us international providers have the odd small line here and there). Obviously the further upstream you put it the better. One of the problems here is lack of interest from peers and upstreams. If you catch their interest at sales time rather than at abuse time (i.e. you configure something similar into their router on setup), that would be optimal. Alex Bligh GX Networks (formerly Xara Networks)
That's Odd, because with my experience with it, the destination (for example, irc.lightning.net) gets the committed access rate you set, however, the pipes are still flooded and connectivity to the outside world is poor to nil. You would still have to agree that by having the upstream providors set the rate-limits is the safest and most effective interim solution until something can be done permanently about this oh so wonderful attack :-)
Alex Bligh wrote:
My limited experience is that if you run CEF on the interface concerned, life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA where fast discards and routes to null0 were introduced, life is disastrous.
Alex Bligh GX Networks (formerly Xara Networks)
Alex Bligh wrote:
servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this
OK, tell me where this falls down. Set up two IP addresses for your IRC server on the same machine. On the router upstream from the machine, allow only your customers to connect to one IP address, and anyone else to connect to the other IP. Now go to your border routers, enable CEF and configure something like:
! impose limits access-list 100 permit ip any host public-irc.my.net access-list 100 permit ip any host public-irc.my.net access-list 101 deny ip any host private-irc.my.net ! i/f config for borders interface myinterface ip access-group 101 in rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop
Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs).
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
-- Alex Bligh GX Networks (formerly Xara Networks)
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
-- \\|// -(@ @)- ==========================oOO==(_)==OOo================================= Steven Nash uin: 9021398 Cisco Certified Design Specialist em: snash@lightning.net Network Engineer Lightning Internet Services LLC http://www.lightning.net -=+===================================================================+-
Try using CAR to rate-limit ICMP or UDP to the IRC server to 256k or a comfortable norm with 8k or 10k of burstability. Your upstreams will die, but your internal network will be fine as any excess of the limited protocols will be dropped before they hit the lan interface. On Wed, 19 Aug 1998, Alex Bligh wrote: :Jeff, : :Sorry I thought you were talking about router load. : :Yeah, if you discard at the end of your upstream provider's link, then :that link will get saturated if you are smurfed enough. Last time we :had a really bad one, we were looking at 6-10Mb/s which was not enough :to saturate transit DS-3s, but enough to saturate a few bits of internal :network (us international providers have the odd small line here and :there). Obviously the further upstream you put it the better. : :One of the problems here is lack of interest from peers and upstreams. If :you catch their interest at sales time rather than at abuse time :(i.e. you configure something similar into their router on setup), :that would be optimal. : :Alex Bligh :GX Networks (formerly Xara Networks) :> That's Odd, because with my experience with it, the destination (for example, :> irc.lightning.net) gets the committed access rate you set, however, the pipes are :> still flooded and connectivity to the outside world is poor to nil. You would still :> have to agree that by having the upstream providors set the rate-limits is the safest :> and most effective interim solution until something can be done permanently about :> this oh so wonderful attack :-) :> :> Alex Bligh wrote: :> :> > My limited experience is that if you run CEF on the interface concerned, :> > life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA :> > where fast discards and routes to null0 were introduced, life is :> > disastrous. :> > :> > Alex Bligh :> > GX Networks (formerly Xara Networks) :> > :> > > :> > > :> > > Alex Bligh wrote: :> > > :> > > > > servers, one for the outside world and one for our customers only. The :> > > > > public server will be connected via a T1 to a smurf tracing friendly :> > > > > transit provider for external connectivity. This T1 will be used for this :> > > > :> > > > OK, tell me where this falls down. Set up two IP addresses for your :> > > > IRC server on the same machine. On the router upstream from the machine, :> > > > allow only your customers to connect to one IP address, and anyone else :> > > > to connect to the other IP. Now go to your border routers, enable CEF :> > > > and configure something like: :> > > > :> > > > ! impose limits :> > > > access-list 100 permit ip any host public-irc.my.net :> > > > access-list 100 permit ip any host public-irc.my.net :> > > > access-list 101 deny ip any host private-irc.my.net :> > > > ! i/f config for borders :> > > > interface myinterface :> > > > ip access-group 101 in :> > > > rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop :> > > > :> > > > Effectively this means that if your public IP gets smurfed, it's b/w :> > > > usage internally on your network is limited. If your private IP gets :> > > > smurfed, it all gets dropped (thinking about it if you made exceptions :> > > > for IRC peering you could do the whole thing on one IP if your customers :> > > > never use border router i/fs). :> > > > :> > > > If you are paying per bit, you'll still pay for smurfs, but they'll have :> > > > to be 45Mb/s in size to cause any real damage. You'll probably find BGP :> > > > flapping up and down as your T1 saturates is more of a problem. :> > > > :> > > > -- :> > > > Alex Bligh :> > > > GX Networks (formerly Xara Networks) :> > > > :> > > > :> > > :> > > -- :> > > \\|// :> > > -(@ @)- :> > > ==========================oOO==(_)==OOo================================= :> > > Steven Nash uin: 9021398 :> > > Cisco Certified Design Specialist em: snash@lightning.net :> > > Network Engineer :> > > Lightning Internet Services LLC :> > > http://www.lightning.net :> > > -=+===================================================================+- :> > > :> > > :> > > :> > :> > :> :> -- :> \\|// :> -(@ @)- :> ==========================oOO==(_)==OOo================================= :> Steven Nash uin: 9021398 :> Cisco Certified Design Specialist em: snash@lightning.net :> Network Engineer :> Lightning Internet Services LLC :> http://www.lightning.net :> -=+===================================================================+- :> :> :> : : -- Regards, Jason A. Lixfeld Network Engineer, iDirect Network Operations --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) --------------------------------------------------------------------- jlixfeld@idirect.ca | jlixfeld@torontointernetxchange.net ---------------------------------------------------------------------
On Wed, 19 Aug 1998, Alex Bligh wrote:
Yeah, if you discard at the end of your upstream provider's link, then that link will get saturated if you are smurfed enough. Last time we had a really bad one, we were looking at 6-10Mb/s which was not enough to saturate transit DS-3s, but enough to saturate a few bits of internal network (us international providers have the odd small line here and there). Obviously the further upstream you put it the better.
See that's the beauty of using either the swamp space or, if I have to and can negotiate it, private space. The echo-replies get dropped right at their source since there's no route back to me.
One of the problems here is lack of interest from peers and upstreams. If you catch their interest at sales time rather than at abuse time (i.e. you configure something similar into their router on setup), that would be optimal.
This is exactly what I'm doing going forward with new external connectivity. One of the questions I will have of all future transit negotiations will be to ask if they are willing to trace spoofed traffic and to ask if they will commit to a reasonable turnaround time to get their customer's amplifying networks fixed once reported. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
I've got it up on 3 7206s as global options (meaning it is automatically introduced to all interfaces) and it dropped my CPU by 3 points. On Wed, 19 Aug 1998, Alex Bligh wrote: :Steve, : :> I too have a similar setup for my network since we as well :> run an Efnet irc server, however, CAR really won't do much if :> you set it up inside your own network. The smurf will still enter :> and saturate your pipes. The best thing to do is to have your upstreams :> setup rate-limits on their side of your pipes so the feed coming into your :> router is limited before it even hits your router. :> :> Here is a question though, what kind of CPU drain does rate-limiting cause :> on the CPU of the routers running it? I flipped through CCO and couldn't find :> any information regarding this... : :My limited experience is that if you run CEF on the interface concerned, :life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA :where fast discards and routes to null0 were introduced, life is :disastrous. : :Alex Bligh :GX Networks (formerly Xara Networks) : :> :> :> Alex Bligh wrote: :> :> > > servers, one for the outside world and one for our customers only. The :> > > public server will be connected via a T1 to a smurf tracing friendly :> > > transit provider for external connectivity. This T1 will be used for this :> > :> > OK, tell me where this falls down. Set up two IP addresses for your :> > IRC server on the same machine. On the router upstream from the machine, :> > allow only your customers to connect to one IP address, and anyone else :> > to connect to the other IP. Now go to your border routers, enable CEF :> > and configure something like: :> > :> > ! impose limits :> > access-list 100 permit ip any host public-irc.my.net :> > access-list 100 permit ip any host public-irc.my.net :> > access-list 101 deny ip any host private-irc.my.net :> > ! i/f config for borders :> > interface myinterface :> > ip access-group 101 in :> > rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop :> > :> > Effectively this means that if your public IP gets smurfed, it's b/w :> > usage internally on your network is limited. If your private IP gets :> > smurfed, it all gets dropped (thinking about it if you made exceptions :> > for IRC peering you could do the whole thing on one IP if your customers :> > never use border router i/fs). :> > :> > If you are paying per bit, you'll still pay for smurfs, but they'll have :> > to be 45Mb/s in size to cause any real damage. You'll probably find BGP :> > flapping up and down as your T1 saturates is more of a problem. :> > :> > -- :> > Alex Bligh :> > GX Networks (formerly Xara Networks) :> > :> > :> :> -- :> \\|// :> -(@ @)- :> ==========================oOO==(_)==OOo================================= :> Steven Nash uin: 9021398 :> Cisco Certified Design Specialist em: snash@lightning.net :> Network Engineer :> Lightning Internet Services LLC :> http://www.lightning.net :> -=+===================================================================+- :> :> :> : : -- Regards, Jason A. Lixfeld Network Engineer, iDirect Network Operations --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) --------------------------------------------------------------------- jlixfeld@idirect.ca | jlixfeld@torontointernetxchange.net ---------------------------------------------------------------------
On Wed, 19 Aug 1998, Alex Bligh wrote:
Effectively this means that if your public IP gets smurfed, it's b/w usage internally on your network is limited. If your private IP gets smurfed, it all gets dropped (thinking about it if you made exceptions for IRC peering you could do the whole thing on one IP if your customers never use border router i/fs).
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage. You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
I believe the major point was that the smurfed traffic shouldnt be routed at all outside of the provider that hasnt fixed their smurf-relays, bringing down the impact on transit providers as well...? ----- Mikael Abrahamsson email: swmike@swm.pp.se
On Thu, 20 Aug 1998, Mikael Abrahamsson wrote:
I believe the major point was that the smurfed traffic shouldnt be routed at all outside of the provider that hasnt fixed their smurf-relays, bringing down the impact on transit providers as well...?
That's exactly it, this is the most net-friendly design I could come up with. Sure, there are several other options. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
On Wed, 19 Aug 1998, Alex Bligh wrote:
If you are paying per bit, you'll still pay for smurfs, but they'll have to be 45Mb/s in size to cause any real damage.
That's just the problem, the smurf attacks we have been receiving lately have been big enough to completely fill our transit T3's causing a negative impact on all of our other services.
You'll probably find BGP flapping up and down as your T1 saturates is more of a problem.
I wasn't planning on running BGP over that link at all, since there will be only a /24 on our end of it, a simple static route on the upstream's side is sufficient. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
participants (7)
-
Alex Bligh -
Brandon Ross -
Jason Lixfeld -
Mikael Abrahamsson -
Patrick Greenwell -
steveļ¼ altrina.exodus.net -
Steven nash