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_terminationI agree with Olaf and would only use the -p tcp --syn rule to filter new connection to the server on unwanted ports.