Re: Limit the number of erroneous logins of root from the same IP

On Wed, 16 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
<ja11al$spf$1@xxxxxxxxxxxxxxxxxx>, dold@xxxxxxxxxxxxxxxx wrote:

Moe Trin <ibuprofin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

No, if you're trying to pretend you don't exist, you need to use
the firewall with the "DROP" rules.

I thought that not existing at all was a good thing, but "connection
refused" would be sufficient to deter an ssh script-kiddie, as if
they had maybe reached a windows server with no sshd.

Trying to keep this on the simple side but still give an explanation.

Let's do a quick check of what happens to an IP connection attempt to
port 22/tcp (or similar). IP (RFC0791) is an "unreliable" protocol.
Packets are not guaranteed to be delivered to the destination. So,
the sending host throws an IP packet out there trying to make a
connection. Assume it (and the reply) doesn't get lost between source
and destination. Without a firewall in the way, the packet goes up
the network stack on the destination host. Two ways to go here - no
server on this port (or a firewall with a "REJECT" rule) and an IP
'RST' packet (or maybe an ICMP Type 3 Code 3 "The number you have
reached is not in service...") is sent back. If there IS a server on
this port (and 'tcp_wrappers' counts as a server in this regard) the
stack sends back a TCP/IP packet with the SYN and ACK flags set (the
second part of a three-way handshake). Back at the remote sender, they
receive a packet - either answering the phone or in essence saying
"nobody listening". In the latter case, even the dumbest skript
kiddie or zombie knows further attempts at this port are fruitless.
Move on - nothing here to see - yada, yada, yada. (If tcp_wrappers or
libwrap is running and denying you, at the completion of the three-way
handshake, it MAY return a failure code and close the connection, or
it may just close it with no message at all. In theory the open/close
is detectable as a blocking function, but it's not letting you in the
door either. "Let's try an easier target somewhere else.")

Now, what happens if there is a firewall that is dropping the packet
at the destination? Source waits a second or so, and the network
stack starts swearing at the b0rk3n Internet - the packet must have
made that wrong turn in Albuquerque[1] and gotten lost. So it sends
another. This may be repeated a second time. The stack then reports
to the application that there was no response. That application MAY
attempt to try the connection again, or may not. It says here that
this is wasting CPU cycles on the ``attacking'' host, but the effect
is minimal. The difference on the target? Receive/reply to one
verses receive three (or more). If you're making a fine enough
measurement, returning a RST to the initial connection attempt is a bit
less work than passing repeated packets to the bit-bucket. And don't
forget that you've got to firewall all ports and all protocols (there
is more to the world than TCP, UDP or ICMP). 'tcp_wrappers' and/or
'libwrap' doesn't do that.

But, my first exposure to this was a dual boot server, and I noticed
the slowdown while booted in Windows, so it was passing back
"connection refused", I suppose.

There would be little difference between same conditions on either O/S.
No server/firewall, and both return the RST or ICMP 3/3. Firewall
that is DROPing packets rather than replying - exactly the same.
About the only (minor) difference is the windoze ``personal firewall''
applications (examples: Black Ice or ZoneAlarm) that waste additional
CPU cycles writing crap to the logs about how they thwarted "an
attack" from this address at that time - I suppose that's meant to make
the windoze user feel good. Certainly has no other useful function.
Both at work and at home, we rarely bother logging failed connection
attempts. The firewall worked - what more do I need to know or do?

Maybe the attempts would have died off by themselves in a day or two.

From a single zombie? Probably finish in a few hours. Of course,
there are probably 2.999 billion other zombies who will be calling
soon enough. Every once in a while, I'll turn on logging for a while
to try to gauge how much noise is out there - but for the most part I
simply don't bother. ISP abuse desks rarely do anything to control
the problem, so I'm not going to waste any more effort on it.

Old guy

[1] Bugs Bunny was right - there were a couple of turns on US Route 66
in down-town Albuquerque, and if you didn't make that turn... This
was fixed when Interstate 40 (the Coronado Freeway) replaced US-66.
Fourteen exit ramps and big signs, but no turns to miss.