- - WARNING -
Way too long winded for reading unless you are REALLY into filtering on your
pm products. You would do better to go get a beer and skip this
message. You were warned!
- - end warning-
Seeing the recent discussion on DOS filtering via the outgoing ethernet port
on the portmasters, it got me to thinking a bit more (more than I like some
times!).
We run a filter on one of our 7507's incoming 100-base-t fastethernet ports
where I place my main group of terminal servers. Basically, I run all my
anti-spoofing, and route-loop killing (for when people log out of a pm, yet
some www servers are still trying to 'push' data to the customer and thus
creating a loopback from the portmaster back to the gateway etc) in the same
filter on the 'incoming' side of the 7507's fast etherport. By doing it on
the 7507 side, i simply do it in one place, and it works on all my terminal
servers (we run 3 different vendors for terminal servers currently), and it
does the anti spoffing, kills the endless route loops, and even more..
So, thats all fine and good -it kills those loops with the pm's routes just
fine (oddly enough, my 3com/usr racks dont do this, only the pm's do it),
and it catches spoof attempts. One of the more recent attacks people know
of is the smurf attacks (simply sending directed icmp stuff from real or
forged addresses, TO a broadcast address on someons network). something like
"ping 205.247.146.255" or "ping 205.247.146.0"
Well our cisco filter's also nab customers trying this (i have yet to find
any valid reason for a dialup customer to send traffic TO a .0 or .255
address of a class-c network (no this does NOT protect other innocent 3rd
parites who have smaller block's than class-c's, but this blocks 99% of
hacker smurf attacks originating from our site, since most wanna-be-hackers
that we get don't even understand subneting!).
for those who even care, the filter 'snip' in the cisco looks like this
(applied on the incoming side of a fastethernet interface)