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.
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
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.
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.