Good Morning
are you running an ssh daemon on non standard ports to avoid some of the drive-by-scanning ? we have been doing that for quite some time now with great reduction of scanning noise ... since yesterday this has changed ... we are getting a lot of connection attempts ...
are you seeing this too ? is someone actively looking for ssh across the whole port range or is this 'personal' ?
cheers tobi
On 2018-07-02 11:25, Tobias Oetiker wrote:
Good Morning
are you running an ssh daemon on non standard ports to avoid some of the drive-by-scanning ? we have been doing that for quite some time now with great reduction of scanning noise ...
I suggest running SSH always behind white-list only firewalls.
That, and otherwise use a VPN to get in to a fixed-IP so that one is in the whitelist.
Providing an 'open over IPv6 only', or "SSH via Tor" is also a reasonable technique there.
If you have to run a jumpbox style host: For SSH, it is also heavily suggested to disable any form of password-auth, that way, only public key authentication is accepted and guess what the scanner scripts do not support as they do not have a key which thus makes guessing impossible...
for OpenSSH: UsePAM no PasswordAuthentication no ChallengeResponseAuthentication no
Do have working pubkeys on the box first :)
since yesterday this has changed ... we are getting a lot of connection attempts ...
are you seeing this too ? is someone actively looking for ssh across the whole port range or is this 'personal' ?
There are more and more "Internet scanning" services, especially since people realized the amount of data that Shodan shows, every company is having their own scanning boxes.
Next to that of course, there are thousands of kiddies running the default scripts just trying random username/passwords.
Whitelisting is the best trick in the toolchest.
Greets, Jeroen
Hey Tobi
Not seeing what you are seeing, but I can really recommend Fail2Ban if you are not using it already.
It's as simple as:
*** snip 8< ***
# Install fail2ban apt install fail2ban
# Set log level to VERBOSE in sshd daemon to catch failed logins for existing accounts as well cat >> /etc/ssh/sshd_config <<EOF
LogLevel VERBOSE EOF
systemctl restart sshd
*** >8 snap ***
Failed attempts will now be logged and source IPs will be banned after several failed attempts.
Cheers, Manuel
On 2018-07-02 12:25, Manuel Schweizer wrote:
Hey Tobi
Not seeing what you are seeing, but I can really recommend Fail2Ban if you are not using it already.
[..]
Failed attempts will now be logged and source IPs will be banned after several failed attempts.
Which is quite useless with the distributed scanners that exist have existed for the last few years.
A single IP will only hit you a few times... typically below the threshold of standard fail2ban or other alarm bells. The distributed scanner will keep on trying by using another IP from their vast botnet...
The big question: Why is that SSH port open to the world ? :)
Greets, Jeroen
Hey Jeroen
A single IP will only hit you a few times... typically below the threshold of standard fail2ban or other alarm bells. The distributed scanner will keep on trying by using another IP from their vast botnet...
Well, from experience I cannot confirm that at all. Apparently, there are still a lot of script kiddies out there or less sophisticated attacks going on. Fail2Ban sure helps with those.
If you want to use it in a more aggressive way you can also combine port knocking with fail2ban and ban source IPs the first time they "misbehave".
The big question: Why is that SSH port open to the world ? :)
Depends on the use case. I second your opinion when it comes to best-practices but I am also running a couple servers with SSH open to the world because I don't have, need or want an extra jump host at that location to access a single system for example. So there are reasons.
Cheers, Manuel
Good morning,
Manuel Schweizer manuel@cloudscale.ch writes:
Hey Tobi
Not seeing what you are seeing, but I can really recommend Fail2Ban if you are not using it already.
while the idea of fail2ban is good, I would actually recommend sshguard instead of fail2ban. If you are not using a recent version of fail2ban, it does not handle IPv6 at all and thus does not throttle IPv6 based attacks.
For that reason we switched to sshguard, a smaller and leaner dynamic blocker that fully supports IPv6 and has a variety of backends, including nftables.
Best,
Nico
-- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.
Hi,
On Mon, Jul 02, 2018 at 12:25:13PM +0200, Manuel Schweizer wrote:
Not seeing what you are seeing, but I can really recommend Fail2Ban if you are not using it already.
Seconded. Even if we do not allow "plain password" authentication on the Jumphost (it's using PIN + LinOTP tokens), if only to keep the noice in the logs down and to annoy the brute-forcers a bit :-)
Gert Doering -- NetMaster
On 2 Jul 2018, at 11:42, Jeroen Massar jeroen@massar.ch wrote: If you have to run a jumpbox style host: For SSH, it is also heavily suggested to disable any form of password-auth, that way, only public key authentication is accepted and guess what the scanner scripts do not support as they do not have a key which thus makes guessing impossible...
+1 for "jumphosts" as an alternative to VPNs.
I can highly recommend Teleport - https://gravitational.com/teleport/ - as a potential jumphost. It is an SSH CA with 2FA out of the box, and if you need it the enterprise (paid for) version will integrate with various authentication endpoints (SAML, etc). There are other features which are very suitable to out-of-band management (e.g. run Teleport as as node on a Raspberry Pi behind NAT on an OOB connection from a third party; it will connect out to your Teleport jumphost, allowing you to "get behind the NAT").
Disclosure: I gave a ~10 minute "lightning talk" at UKNOF about Teleport, but I am not getting paid by them ;)
Slides: http://faelix.link/uknof40 Video: https://www.youtube.com/watch?v=l-fYg0B7c00&index=9&list=PLjzK5ZtLlc...
fail2ban on a jumphost is an excellent idea - lock your bastion down as much as you can.
Marek Isalski Technical Director, Faelix Limited, https://faelix.net/
another way of protection is throttling down TCP SYN attempt rate per IP address. At least it will save you some CPU, as the SSH daemon won't have to process every request:
https://txlab.wordpress.com/2013/06/29/protecting-a-vpbx-from-dos-attacks/
On Mon, Jul 2, 2018 at 11:25 AM, Tobias Oetiker tobi@oetiker.ch wrote:
Good Morning
are you running an ssh daemon on non standard ports to avoid some of the drive-by-scanning ? we have been doing that for quite some time now with great reduction of scanning noise ... since yesterday this has changed ... we are getting a lot of connection attempts ...
are you seeing this too ? is someone actively looking for ssh across the whole port range or is this 'personal' ?
cheers tobi
-- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi@oetiker.ch +41 62 775 9902
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Gert Doering -
Jeroen Massar -
Manuel Schweizer -
Marek Isalski -
Nico Schottelius -
Stanislav Sinyagin -
Tobias Oetiker