Large scale Internet SSH brute force attacks seem to have stopped here
1–10 of 127 posts
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#2I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening.
[Edit]: I forgot to add that if testing the ssh hardening from that site, be sure to do this locally where one has console access and the same version of sshd or if on remote nodes make sure that remote consoles are working first to avoid being locked out of the remote nodes. Modifying the client ciphers first and testing remote connections prior to modifying the servers is the lowest risk.
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#3Did someone record which username/passwords those bots try? I never bothered with that.
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#4Did someone record which username/passwords those bots try? I never bothered with that.
Hm, that's probably pretty run-of-the-mill default user/password combinations, unless someone specifically targets you?
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#5I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…
> Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening.
why?
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#6Funny - I had noticed something similar in the last couple of months, but hadn't though to look in to it more. I was seeing 30,000 to 50,000 attempts a day, but over the last two weeks, it's around 10,000.
Perhaps it's like mining cryptocurrency - all the low hanging fruit has been found, so there's hardly much sense in continuing to waste resources looking for more.
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#7I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…
> Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening. why?
Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#8I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…
> [after] hardening steps [...] most of the bots can't even negotiate a connection
Yep, same here, except I'm using [tinyssh], which organically does not support password-based auth, or any ciphers other than ssh-ed25519, curve25519-sha256, and chacha20-poly1305@openssh.com.
[tinyssh] https://tinyssh.org/
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#9On a related note, set up a website a few days ago. Brand new domain, newly opened port. But I've rented this VPS for a while so I guess its IP is already on a few lists.
But anyways, it's interesting watching the logs for what I assume are tests of known exploits.
GET /.gitconfig HTTP/1.0" 422 Unprocessable Entity
GET /.git/config HTTP/1.0" 404 Not Found
GET /owa/auth/x.js HTTP/1.0" 404 Not Found
GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application HTTP/1.0" 404 Not Found
GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.0" 404 Not Found
GET /system_api.php HTTP/1.0" 404 Not Found
GET /c/version.js HTTP/1.0" 404 Not Found
GET /streaming/clients_live.php HTTP/1.0" 404 Not Found
GET /stalker_portal/c/version.js HTTP/1.0" 404 Not Found
GET /stream/live.php HTTP/1.0" 404 Not Found
GET /flu/403.html HTTP/1.0" 404 Not Found
POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.0" 404 Not Found
GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.0" 404 Not Found
GET /backups-dup-lite/dup-installer/main.installer.php HTTP/1.0" 404 Not Found
GET /%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22whoami%22%29.getInputStream%28%29%2C%22utf-8%22%29%29.%28%40com.opensymphony.webwork.ServletActionContext%40getResponse%28%29.setHeader%28%22X-Cmd-Response%22%2C%23a%29%29%7D/
Re: Large scale Internet SSH brute force attacks seem to have stopped here
#10Earlier quoted context omitted.
> Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening. why?
Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.
Initially it sounded implausible that a small size increase could noticably raise connection establishment, but it's possible the small size increase causes MTU to be exceeded, and thus an additional roundtrip.