Displaying Incoming Server Attacks By Giving Server Logs A Scoreboard

In the server world, it’s a foregone conclusion that ports shouldn’t be exposed to the greater Internet if they don’t need to be. There are malicious bots everywhere that will try and randomly access anything connected to a network, and it’s best just to shut them off completely. If you have to have a port open, like 22 for SSH, it’ll need to be secured properly and monitored so that the administrator can keep track of it. Usually this is done in a system log and put to the side, but [Nick] wanted a more up-front reminder of just how many attempts were being made to log into his systems.

This build actively monitors attempts to log into his server on port 22 and notifies him via a numerical display and series of LEDs. It’s based on a Raspberry Pi Zero W housed in a 3D-printed case, and works by interfacing with a program called fail2ban running on the server. fail2ban‘s primary job is to block IP addresses that fail a certain number of login attempts on a server, but being FOSS it can be modified for situations like this. With some Python code running on the Pi, it is able to gather data fed to it from fail2ban and display it.

[Nick] was able to see immediate results too. Within 24 hours he saw 1633 login attempts on a server with normal login enabled, which was promptly shown on the display. A video of the counter in action is linked below. You don’t always need a secondary display if you need real-time information on your server, though. This Pi server has its own display built right in to its case.

9 thoughts on “Displaying Incoming Server Attacks By Giving Server Logs A Scoreboard

  1. Back in the late 1990s I had dot matrix printer connected to syslog, Every login attempt was permanently stored on paper. It was all good until the script kiddies started scanning ports like crazy.. I still miss that sound…

  2. I don’t even run ssh on a standard port and this display would roll over in a few days. It was always pretty light until last week when many random addresses started doing brute force attempts. I shut off passwords and only allow login keys now.

      1. They have honeypot servers and docker containers you can set up, and I’ve seen cases where people replace the login bash executable with custom scripts that do all kinds of stuff, such as simulate being connected to different servers (think phishing attacks) or respond to ls and cd and hardware info commands differently to confuse, excite, or terrorize the attacker into behaving in different ways.

        Your comment has me intrigued though.. What kind of vulnerabilities do typical ssh clients have, as far as things like buffer overflows are concerned? By writing our own server application that doesn’t need to abide by the SSH protocol, how could we abuse the protocol (which hasn’t changed much in decades) to mess with people who use it for brute force attempts? Even if no permanent damage could be done, I’d love it if we could crash those automated scripts that sweep the entire ipv4 range every few minutes, and force them to be restarted either manually or automatically. Maybe we could let them time out once, so we know their timeout parameter, and then let them keep trying to break in repeatedly and return a response only a few ms before their timeout threshold kicks in? Depending on how many times they try before giving up, this could massively slow down an automated script set to try the top 100 user/pass combos, especially if their timeout was 15 or 30 seconds!

        It wouldn’t be a lot, but it would be satisfying to know we’re doing something to help this problem. Bonus points if the NSA or CIA come to you complaining that your server is interfering with their ability to collect data under the patriot act 😂😂

  3. Back in the late nineties, when I was just starting to explore Linux, I had my PC playing Seven of Nine saying “This ship is under attack” when someone was portscanning me. (PC was directly connected to a cable modem, no routers in sight yet).
    I forgot HOW I set it up though.

Leave a Reply to CyleleghornCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.