Logmatic.io Blog

Secure your Infrastructure with SSHD’s Logs & Fail2Ban

Coming with your syslogs, SSHD’s can bring you valuable information about intruders and their methods.
Secure Shell’s Daemon logs are available on most linux distributions and can be found into the /var/log/auth.log file.

Your logs can tell you a lot about who’s trying to get in

They tell you about:

  1. Successful logins with passwords or public keys
  2. Logouts
  3. SFTP file transfers
  4. Login attempts with revoked keys
  5. Brute force and Hail Mary Attacks

When a machine is not exposed to the Internet and is used by a couple of humans or machines everything is fine and the amount of logs can be followed by simple cat & grep methods.

However, if you work with exposed servers you need to be careful because you’ll see that a lot of people try to get in.

Sending SSHD logs to Logmatic.io

Sending SSHD’s logs to Logmatic.io is simple. A simple configuration of Rsyslog or Syslog-ng does the trick (check our documentation).

We also advise that you enable the SSHD parsing extensions so action, type of actions, IPs and entered users can be properly extracted as proper fields:

extension sshd

By doing so a typical log event will look as follows in your log analyzer user interface:

sshd example

Monitor authorized & unauthorized people

Now that your data comes in and is properly parsed you can rapidly segregate good actions from bad actions. In the following example, we got all the logs from a test machine exposed to the Internet also used by a team of developers to test various versions of a web application.

Using the Action field over a table we can quickly observe results like these:

SSHD Security

Security SSHD

On the example above if we assume that no attack succeeded, 7 accesses have been done during this period of time. They led to 7 opened sessions that were all closed up. However, Connection closed / Invalid user / Disconnect / Reverse mapping checking were all attempts to break in that have rejected by the system.

You can also rapidly obtain IP addresses of all the machines that made unsuccessful attempts by pulling the IP field:

connection sshd

Why does it matter?

  1. These kinds of log analysis are very valuable to check the vulnerability of your infrastructure.
  2. Most of the time an intrusion is detected afterwards, from these log files you can see how much time the session was opened and investigate further to understand what has been done.
  3. This is also the only proof that only authorized users have accesses and that they did what they were supposed to do.

As a piece of advice, we encourage you to close as many SSHD accesses as possible and access your critical machines through private networks only . Also do not use the port 22 which is known as the default and only use public keys authentications instead of passwords if possible. With passwords, brute force attacks can always succeed on a long run…

Keeping the bad guys out with Fail2Ban

Fail2Ban is an open source application that makes your Linux systems more resistant to attacks. Implemented as a series of Python scripts, fail2ban works by dynamically altering the firewall rules on your system in reaction to authentication or usage patterns. If you want a nice introduction to Fail2Ban, we encourage you to read to great article from Sandra Henry-Stocker on itworld.com.

By reading SSHD logs, Fail2Ban automatically ban some IP addresses for a certain period of time. You can also follow Fail2Ban decisions by using the appropriate parsing extension in Logmatic.io.

ip fail2ban

Fail2Ban comes with a predefined set of rules define in /etc/fail2ban/filter.d/sshd.conf. By looking carefully to breaking attempts and Fail2Ban actions we saw that some rules were not implemented:

  • Received disconnect from <HOST> 11: [preauth]
    • Which is usually happening when the host tries to connect with a key instead of a password
  • reverse mapping checking getaddrinfo for <URL> [<HOST>] failed – POSSIBLE BREAK-IN ATTEMPT!
    • Which is just another kind of break-in attempt…

It would be probably wise to add them into the configuration of Fail2Ban.

Security is a big subject

Fail2Ban also offer protections against DDOS attacks and over other systems as Apache, Nginx, Courrier, etc… Security of IT infrastructures is a big topic and we will post other articles in the future to cover pieces of it!

Other than the documentation, find the rest of the articles that can guide you in your log quest. See how to use a log centralizer, or how you can make use of your Java logs or of the Winston library.  

Related Posts