My humblest appologies for my last email that was cut off. apparelenty i
forgot that majordomo does "NOT" like putting multiple "."'s on seperate
lines (i was showing formating between one of my access lists). I have
modified the email so the "."'s are removed :)
Anyway, here is the long winded message in its entirety.
Adam Wills Global 2000 Communications
Director of Networking Systems 1840 Western Ave.
sysadmin@global2000.net Albany, NY, 12203
http://www.global2000.net (518) 452-1465
- - WARNING -
Way too long winded for reading unless you are REALLY into filtering on your
pm products. 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)
(more stuff before here)
access-list 102 deny ip any 0.0.0.255 255.255.255.0 log
access-list 102 deny ip any 0.0.0.0 255.255.255.0 log
(more stuff after here)
(those not familiar with cisco filters, the portion stating 255.255.255.0 is
really just telling the filter to match only the 'last 8 bits' of the
actual address, i.e. look to see trafic is going to '.255' or '.0')
Since all this discussion on the DOS stuff under pm's specifically, i
decided to 'slap' in the outgoing ether0 filters like people were
recomending, and even toying around with the Ptrace EXTENDED features, so i
can now find out not only which portmaster specifically is originating the
spoof attacks but also find out what SERIAL port originated it (thus i know
which userid actually did it). The only thing I gained was the ability to
track who was spoofing (speficially which serial port/username) - since my
filters on the cisco at least blocked it.
The only problem I have run into here, is I can't duplicate the full
functionality of my cisco 'dialup customer gateway' filter, because i can't
seem to get the Livingston to mimick the cisco's ability to look at only
'certain' bits of the destination address (to detect the SMURF attack). The
Livinston filter system 'appears' (and i hope someone will show me im way
wrong here!) to only be able to filter on source or destination address
based on a # of bits reading from LEFT to RIGHT in the ADDRESS.
- ---
from http://www.livingston.com/Tech/Technotes/Security/filter-pmguide.html
Source_address/bits - specify the comparison with the source IP
Address contained in the packet. The number of bits (0-32) are first
extracted from the IP Address in the packet (i.e., if 24 bits is
specified, a packet with the source address of 192.9.200.1 would
become 192.9.200.0 since 24 bits are used to represent the first 3
bytes of the address). The most common bit counts would be:
0 - To match packets with any source IP Address.
16 - To look at only the network number of a class B IP Address.
24 - To look at only the network number of a class C IP Address.
32 - To look at the entire IP Address.
- ---
So simply put:
0 = dont care term
Bit Count [according to www page]
x.y.z.h 32 specific host ip
x.y.z.0 24 CLASS C network
x.y.0.0 16 CLASS B network
x.0.0.0 8 CLASS A network
0.0.0.0 0 the entire world
0.0.0.h ?? WHAT I AM looking to filter based upon
MY QUESTION (after this long and boring tirade)
- -----------------------------------------------
how would one 'trick' a pm filter into blocking and logging traffice from
'anywhere' to 'any class-c broadcast or network' address. Yes the pm DOES
work quite nicely to block the spoofing, but not all 'smurf' attacks are
spoffed so they smurf attack really should be filtered seperately if at all
possible.
i.e. I need to look ONLY at the 8 bits of the RIGHT most byte in the
address (the .h in the host ip above).
Something like this:
set filter spoof.out 3 permit 0.0.0.0/0 0.0.0.255/0.0.0.255
set filter spoof.out 4 permit 0.0.0.0/0 0.0.0.0/0.0.0.255
where the /0.0.0.255 would mean "match only the last 8 bits".
I know that doesn't work because the filter expects the /# to be the
simple # of bits to read from left to right in the address.
(tried it to death already!) the livingston just forces it to
0.0.0.0/0 0.0.0.0/0 no matter what.
So, if anyone has any suggestions on how to 'filter' smurf attacks outgoing
from the ether0 on the pm, i'd love to hear it. Of course it works fine on
the cisco side of our gateway, so no big problems- BUT there is another
reason for all this since if I get the filters 100% in the pm then the
PTRACE command will nicely find the USER responsible for the attack as well
as block the attack (the best of both worlds). Now all I do is 'block it'
and hope to catch them doing something else that I can log and eventually
find them.
Sorry for the bandwith- perhaps I need an RFE for some way to match specifc
bytes in the address rather than doing it from left to right. Or perhaps i
have stared at this WAY to long now and overlooked something obvious.
Someone feel free to straighten me out!
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNPYK3K7yaLQI4biZAQGwBQP/egsD1gz1C5cvWJrv3Qql+irbjQhQM1pL
0M7i+IMV5EbjhHTKMMwO+BB/4mR3zvxEv4zIspg7kt3n3VMvtRPkMn9Dj/YlwQjb
j4oarZj5D2zjSPwCYWAjec8Zu8SevX4VpJs66j3x7Ih0mX6o2c5XFn6ut3uJCr7f
Hpy9V1VCbis=
=G5fE
-----END PGP SIGNATURE-----
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>