How to Run High Capacity Tor Relays

[Mike Perry]

Thus spake tor_ml (tor_ml at ymail.com):

> >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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20100826/207198c4/attachment.pgp>