How to Run High Capacity Tor Relays (stateless iptables filtering)

[tor_ml]

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

Ok, I see.
Do you actually see many ssh login attempts (by simple stupid ssh bots) 
on randomized ssh ports?


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

You are right, on my host (linux) it wouldn't be a problem because it 
useses the 4way connection termination where no packet would match the rule:
FIN, ACK ->
<- ACK
<-FIN,ACK
ACK ->

but in general there is also another way (or many other ways) to close a 
connection:
"
It is also possible to terminate the connection by a 3-way handshake, 
when host A sends a FIN and host B replies with a FIN & ACK (merely 
combines 2 steps into one) and host A replies with an ACK. This is 
perhaps the most common method.
"

https://secure.wikimedia.org/wikipedia/en/wiki/Transmission_Control_Protocol#Connection_termination

I agree with Olaf and would only use the -p tcp --syn rule to filter new 
connection to the server on unwanted ports.