1

I wanted to know what efficient way is there to handle malicious attempts to connect to my server by single IPs. The attempts show up logged in /var/log/auth.log as Connection closed by IPaddress port XXX [preauth].

Additional info about sshd_config:

  • Password login is disabled
  • MaxAuthTries 3
  • PubkeyAuthentication yes
  • PasswordAuthentication no
  • PermitEmptyPasswords no
  • DenyUsers pi admin ubuntu

The question's first part is: should I even bother to block these attempts?

There is a different IP attempting a single connection every few seconds. I can handle the ones that try to login multiple times I think, but the sheer number of single connection attempts seems to be a bit of a pain in the neck.

One condition would be that I don't want to whitelist only certain IPs for ssh connection to the server.

Now if I should block these attempts, I'd love to have some suggestions about how to handle that (apart from fail2ban please).

Server Use:

The server is used in two ways:

  1. I run scripts on it that don't necessitate internet connection (basically I'm just offloading the work that I could do on a local machine to the server to run in 24/7) - i.e.: Data Analysis scripts
  2. I run some scripts that actually use internet connection. These connections are made to some APIs, but can also involve scraping websites.

What I intend to clarify about this is that, there is no website/API/etc hosted on this server, so connections should really not be made to it. That is connections except for me. I usually connect through the terminal to edit files that is : scp or ssh connections.

Why not whitelist my IP? I travel a bit, or at least move around, so it would be a bit too difficult to add all the IPs, keep track of them etc. (Or knowing them in advance could be impossible or too burdensome.)

Improve this question
5
  • 1
    The use case of your server is not clear enough to make suggestions which best fit its actual use. But you could for example limit the number of connections to the server per time with an iptables rule, you could use SSH on an alternative port which does not get scanned, you could use port knocking to limit access to the port, you could blacklist IP with fail2ban or similar, restrict access based on GeoIP ... . All of these suggestions mean usability changes though, so it is not clear if they are applicable in your specific case. – Steffen Ullrich Jan 7 at 11:06
  • Hey @schroeder ! thank you for the comment, that's true. There are two things, first, I don't want to add another set of firewall type applications to my server (I have csf installed, plus as the connections seem to come from many different IPs not the same one multiple times I don't think fail2ban would be a solution), and second, I'd rather either solve it with IPtables or some other already there application in case I need to actually do something about it. – David Jan 7 at 12:36
  • 1
    @Hollossy: Based on this edit all of the options I proposed would in theory be possible, right? It is not clear though why you explicitly exclude fail2ban from an answer. Because you already know about it and don't need this recommendation? Because you find out ineffective? Or why? – Steffen Ullrich Jan 7 at 12:52
  • @SteffenUllrich sorry for not making that clear! I know some of it, and I don't reckon it would help. The IPs / Machines the connection attempts are made from are each used only once basically (as I'm using more than one server, I see that they don't even match among these servers), so fail2ban would no be able to handle this properly (based on the fact that it uses a pattern recognition). – David Jan 7 at 12:59
  • 1
    I second all of Steffen's suggestions. They all will have an effect. You are correct that fail2ban is only going to be useful against multiple attempts from a single IP. – schroeder♦ Jan 7 at 13:24
3

... should I even bother to block these attempts?

If you are sure that none of these attempts will ever succeed (for example because password based authentication is not allowed anyway, only key based is active) then it is not strictly necessary to block these. In the spirit of defense in depth it would be nice though to limit or even stop the attempts.

I'd love to have some suggestions about how to handle that

In general: everything you do to harden the access might impact your own usability and their is also some costs (time is money) associated with setting it up and maintaining it. So you need to find the personal balance between security measures and usability and costs. That said, here some suggestions:

  • Limit the connection attempts per time to reduce how much connections SSH has to handle in the first place. This might slow down the attempts. See Limit max connections per IP address and new connections per second with iptables.
  • Setup the SSH server on a non-standard port. The common scanners will focus on port 22 and will not check every possible port for an SSH server. It is still possible to additionally listen on the default port 22 but with a strict limit on connections per time to confuse scanners.
  • Use something like port knocking to enable access to the port only after some secret port sequence was "touched". A similar concept is Single Packet Authorization where access to the SSH port is only enabled after some "magic" packet was send.
  • One can explicitly blacklist certain IP addresses or ranges (like Tor exit nodes) or use a more generic blocking based on the geographic location of the sender.
Improve this answer
6
  • Good list, but I'd add OTP/2FA like Google Authenticator. – gowenfawr Jan 7 at 14:58
  • @gowenfawr: Hardening access of the own login is from my understanding not part of the question. It is more about how to efficiently dealing with known malicious logins. I've made therefore "you are sure that none of these attempts will ever succeed" as a basic assumption at the beginning of my answer. There are also other questions here which focus on hardening SSH access. – Steffen Ullrich Jan 7 at 15:06
  • RE: "block" you should also add that "logging" is very important for such events. – Todd Jan 7 at 16:12
  • @Todd: I'm not sure if everything needs be logged and if these events are really important. If the account is well protected against such brute-forcing, then logging every blocking does not add much value (its just the usual expected "noise") but still has its costs. Of course, it depends on the specific environment - some might want to log all unwelcomed data (even if such noise is expected) but most place value probably only in preserving selected events. – Steffen Ullrich Jan 7 at 16:23
  • yeah, it's up to you. Trends in isolated failed connection attempts are good for executive management to know. If you are hacked, and you have logs like this that help you identify the intrusion, then that will be desirable. If you are logging for multiple login attempts - brute force password attacks; then you are probably already logging the single-attempts implicitly. Managing the logs is just an engineering detail (summarise the logs, then discard the data beyond X days). – Todd Jan 7 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.