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.
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.
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.
Chris Green <cl@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?
If they're attacking an ssh login they're only
going to get two or three tries before the delays become very long
indeed.
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 <mh+usenetspam1118@zugschl.us> wrote:
Chris Green <cl@isbd.net> wrote:Well all my ssh logins, by default (i.e. as installed xubuntu systems),
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?
have a several second delay after even the first failed login and I
think it gets longer after further failures.
S.K.R. de Jong <SKRdJ@nowhere.net> wrote:
I have a system with an SSH server accessible from theThese aren't really 'brute force' attempts surely? A brute force
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.
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.
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.
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.
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.
Chris Green <cl@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?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 234:37:21 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,696 |