Thus spake tor_ml (tor_ml@xxxxxxxxx): > >However, this obviously doesn't cover udp. Also, my secondary goal is > >to slow down port scanning of the machine. I'm guessing a simple SYN > >filter rule like this might still allow other scan types to work > >without issue. What else can be done to eliminate those? > > I'm not sure why would you want to do that, as this gives no additional > security, but if you want to block FIN and XMAS scan without connection > tracking: I believe it actually does. There are tons of ssh scanning worms that probe for ssh ports and try to log into them. Sure, disabling passwords and/or enforcing strong ones will stop these scans from succeeding, but they won't stop them if their zombies are repurposed for an (admittedly unlikely) actual ssh exploit, or if one of the users decides to upload a weak debian ssh key. Causing such scans to take 2 days to find my (randomized) ssh port instead of 2 seconds does makes this machine a harder target to find by worms and impatient/shotgun attackers. If nothing else, it rids my logs of a ton of distracting noise, which can make other intrustion attempts harder to notice. > -A INPUT -p tcp --tcp-flags ALL FIN -m comment --comment "FIN Scan > filtering" -j DROP > > -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m comment --comment "XMAS > Scan filtering" -j DROP Won't the first rule cause some connection teardown conditions to just hang though? Causing extra tcp sockets to stay open is less desirable, too. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpTOpHcmtGhO.pgp
Description: PGP signature