SSH brute force breakin attempts

8 views
Skip to first unread message

S.K.R. de Jong

unread,
Apr 12, 2021, 8:17:07 PM4/12/21
to
I have a system with an SSH server accessible from the Internet.
For the last few years, I have been monitoring a steady flow of brute
force breakin attempts, at an average rate of at least one attempt per
minute, significantly more during peak hours.

Remarkably, starting a few weeks ago, this rate has fallen
dramatically, to less than one per hour, even during those times of the
day when I would usually register several attempts per minute.

Have you guys noticed something similar in your logs? I am
curious because this decrease more or less has coincided with a change of
ISP on my side, which implies that the Internet-visible static IP address
that my SSH daemon is listening at has changed. The actual domain name is
the same though.

I just wonder whether it is the case that would-be crackers are
scanning static IP addresses pools corresponding to some ISPs, while
leaving other ISPs more or less alone, perhaps because they are not quite
as well-known - my previous ISP has a much higher profile than my new
one, although the service from the new one is (so far) just as reliable,
while being much faster and cheaper.

Anyway, I would appreciate it if you guys could share your
experiences on these issues.

William Unruh

unread,
Apr 13, 2021, 12:21:26 AM4/13/21
to
Change the port on which sshd listens. (in /etc/ssh/sshd_config) and
then on your various machines that you log into your machine from place

place
Host donald.duck.com # Or whatever the name of your machine is
Port 12345 # Or whatever port you told your sshd to listen on

Then ssh will use that port instead of 22 and your attackers will all be
switched off. Of course if you try to log in via ssh from some other
machine where you have not installed that stuff into ssh_config, you
will have to remember that port number
ssh -P12345 donald.duck.com



Marc Haber

unread,
Apr 13, 2021, 3:27:08 AM4/13/21
to
"S.K.R. de Jong" <SK...@nowhere.net> wrote:
> I have a system with an SSH server accessible from the Internet.
>For the last few years, I have been monitoring a steady flow of brute
>force breakin attempts, at an average rate of at least one attempt per
>minute, significantly more during peak hours.
>
> Remarkably, starting a few weeks ago, this rate has fallen
>dramatically, to less than one per hour, even during those times of the
>day when I would usually register several attempts per minute.
>
> Have you guys noticed something similar in your logs? I am
>curious because this decrease more or less has coincided with a change of
>ISP on my side, which implies that the Internet-visible static IP address
>that my SSH daemon is listening at has changed. The actual domain name is
>the same though.

The frequency of those brute-force attacks varies dramatically by
target network. I have servers in various hosting networks and some of
those get tenfold the amount of ssh probes than others. So, it is just
different characteristics of background noise in different parts of
the Internet.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Chris Green

unread,
Apr 13, 2021, 4:03:04 AM4/13/21
to
S.K.R. de Jong <SK...@nowhere.net> wrote:
> I have a system with an SSH server accessible from the Internet.
> For the last few years, I have been monitoring a steady flow of brute
> force breakin attempts, at an average rate of at least one attempt per
> minute, significantly more during peak hours.
>
These aren't really 'brute force' attempts surely? A brute force
attempt is one that sequences through every possible password
combination sequentially, often starting with shorter ones and moving
on to longer ones until a match is obtained. A brute force attempt to
break a password depends on having fast and unlimited access to the
encoded string you're attempting to guess.

What you're seeing I would call 'opportunistic' attempts where the
attacker tries the obvious default passwords like 'passw0rd',
'abcdefgh' and so on. If they're attacking an ssh login they're only
going to get two or three tries before the delays become very long
indeed.

--
Chris Green
·

Marc Haber

unread,
Apr 13, 2021, 6:29:05 AM4/13/21
to
Chris Green <c...@isbd.net> wrote:
>If they're attacking an ssh login they're only
>going to get two or three tries before the delays become very long
>indeed.

Why? Has sshd implemented such a scheme lately? Or do you assume that
everybody is using fail2ban or a network rate limit mechanism?

Chris Green

unread,
Apr 13, 2021, 7:03:04 AM4/13/21
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Chris Green <c...@isbd.net> wrote:
> >If they're attacking an ssh login they're only
> >going to get two or three tries before the delays become very long
> >indeed.
>
> Why? Has sshd implemented such a scheme lately? Or do you assume that
> everybody is using fail2ban or a network rate limit mechanism?
>
Well all my ssh logins, by default (i.e. as installed xubuntu systems),
have a several second delay after even the first failed login and I
think it gets longer after further failures. This is even for logins
across my LAN where I'm certainly not running fail2ban or anything
like that.

Even a 1 second delay would prevent any sort of brute force attack
from working, you surely need millions of attempts for it to have any
hope of success.

--
Chris Green
·

S.K.R. de Jong

unread,
Apr 13, 2021, 12:04:17 PM4/13/21
to
On Tue, 13 Apr 2021 04:21:24 +0000, William Unruh wrote:

> Change the port on which sshd listens. (in /etc/ssh/sshd_config) and
> then on your various machines that you log into your machine from place
>
> place Host donald.duck.com # Or whatever the name of your machine is
> Port 12345 # Or whatever port you told your sshd to listen on
>
> Then ssh will use that port instead of 22 and your attackers will all be
> switched off. Of course if you try to log in via ssh from some other
> machine where you have not installed that stuff into ssh_config, you
> will have to remember that port number ssh -P12345 donald.duck.com

Thanks. I am not bothered by such attacks on port 22 - I have
defenses in place so that attackers are blocked for a few days after a
few attempts. I am just curious as to why their frequency has decreased
so dramatically in the last few weeks - as others point out, it may well
be because of my change of ISP.

S.K.R. de Jong

unread,
Apr 13, 2021, 12:08:54 PM4/13/21
to
That's right - they keep trying typical user names. I have
password authentication disabled for hosts outside my network.

Marc Haber

unread,
Apr 13, 2021, 12:09:57 PM4/13/21
to
Chris Green <c...@isbd.net> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Chris Green <c...@isbd.net> wrote:
>> >If they're attacking an ssh login they're only
>> >going to get two or three tries before the delays become very long
>> >indeed.
>>
>> Why? Has sshd implemented such a scheme lately? Or do you assume that
>> everybody is using fail2ban or a network rate limit mechanism?
>>
>Well all my ssh logins, by default (i.e. as installed xubuntu systems),
>have a several second delay after even the first failed login and I
>think it gets longer after further failures.

man sshd_config doesn't list such an option.

William Unruh

unread,
Apr 13, 2021, 12:21:32 PM4/13/21
to
On 2021-04-13, S.K.R. de Jong <SK...@nowhere.net> wrote:
The probabiliity of an attack succeeding is directly proportional to
the number of attempts they make. 0 attempts means 0 probability, no
matter what other defenses you have. It is called defense in depth. Like
the Challenger disaster-- it is when you assume that a defense line is
irrelevant, since there are other defenses, that disasters happen.

S.K.R. de Jong

unread,
Apr 13, 2021, 1:11:46 PM4/13/21
to
On Tue, 13 Apr 2021 16:21:30 +0000, William Unruh wrote:

> The probabiliity of an attack succeeding is directly proportional to
> the number of attempts they make. 0 attempts means 0 probability, no
> matter what other defenses you have. It is called defense in depth. Like
> the Challenger disaster-- it is when you assume that a defense line is
> irrelevant, since there are other defenses, that disasters happen.

True. I am not too concerned though, all the more so because I
don't allow password authentication from hosts in the Internet.

William Unruh

unread,
Apr 13, 2021, 3:24:36 PM4/13/21
to
On 2021-04-13, S.K.R. de Jong <SK...@nowhere.net> wrote:
Good idea. However, this means that the external call actually runs the
sshd daemon, which is what then decides that what it receives is an
password based request, and looks up to check that this is actually
coming from the internet. Ie, there is an opening for some bugs in sshd
to rear their ugly head and allow a niche for the remote attacker to get
in. If however, the system never actually delivers the attempt to sshd
at all, because it is coming in on a port where sshd is not listening,
then the holes in sshd are irrelevant.
>

Chris Green

unread,
Apr 13, 2021, 5:18:04 PM4/13/21
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Chris Green <c...@isbd.net> wrote:
> >If they're attacking an ssh login they're only
> >going to get two or three tries before the delays become very long
> >indeed.
>
> Why? Has sshd implemented such a scheme lately? Or do you assume that
> everybody is using fail2ban or a network rate limit mechanism?
>
On [x]ubuntu systems there is a default failed login delay of a couple
of seconds, so it's no ssh specifically but it's there alright. I'm
not sure if other distributions do the same.

--
Chris Green
·

Doug McIntyre

unread,
Apr 16, 2021, 3:24:25 PM4/16/21
to
"S.K.R. de Jong" <SK...@nowhere.net> writes:
> Have you guys noticed something similar in your logs? I am
>curious because this decrease more or less has coincided with a change of
>ISP on my side, which implies that the Internet-visible static IP address
>that my SSH daemon is listening at has changed. The actual domain name is
>the same though.

Different IP ranges get scanned at different rates.

If there is something up and longstanding, it gets probed more than
space that had been empty for months/years before you occupying it,
which gets probed less because there was nothing there before.

Also, I think all the "white-hats" scanning IP space (ie. think Shodan),
probably far outnumber the crackers scanning IP space.

So many people trying to look out for you, eating up your network
bandwidth.

Sigh.

--
Doug McIntyre
do...@themcintyres.us
Reply all
Reply to author
Forward
0 new messages