Fail2Ban with Systemd Journal.

ewaller · 2012-10-27 21:45:38

For a variety of reasons, I maintain a ssh server that is exposed to the Internet that allows the use of password authentication. I use sshkeys for some connections and I fully understand them. I also fully understand the risks of allowing password authentication.

To mitigate that risk, I have used fail2ban to keep the script kiddies at bay. It has always caught several brute force attempts per day.

I have recently changed over to systemd, and have changed to a pure journal for logging and have disabled and removed syslog-ng. This, of course, means there is no longer a /var/log/auth.log file.

The wiki article for fail2ban indicates that there are service files for fail2ban, and it starts just dandy.
I've looked at the wiki article for sshguard, but it seems to have the same dependency on /var/log/auth.log as does fail2ban.

There is not a lot on Google about this combination. Has anyone any suggestions? Unless I've missed something, I am considering taking a crack ot one of those two programs to patch them to look at the journal. Or perhaps to write a small daemon that watches the journal and creates an auth.log to drive either fail2ban or sshguard. I just don't want to invest my time on a wild goose chase.

Strike0 · 2012-10-28 20:09:19

I'm not a user of those, but that is definetely a heads-up. Tricky that the service starts just fine but may not actually be able to do its task without the old journal. I wonder if it throws an error on startup, if you purge the old auth journals.

Not a solution but a workaround may be to just use iptables with an IP-blocker after a number of consecutive failing attempts. Setting something like a 5 minute ban after 4 false attempts should make brute-forcing pretty tiring for most scripts. The way that works a fifth attempt after 4 minutes 50 sec would renew the 5 minutes. Figuring that out alone takes a while.

I used ufw to setup iptables as it provides default rules, incl a default deny. A limit rule is then setup with a

ufw limit log 22/tcp

After I set everything up, I save them to /etc/iptables/ with iptables-save, modify the rules as needed (e.g. for this example changing the default seconds and attempts until it blocks) and enable the iptables.service. But also keeping the ufw default should be fine to block scripts (thats 6 tries in 30 seconds before block in default - long way for a rainbow table/dictionary).
For the above example, this results in four rules:

-A ufw-user-input -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A ufw-user-input -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable

The first sets the track for the new IPs trying to connect to the port, the second enforces the ban and the third and fourth log and reject ongoing attempts. I am sure you have something similar already, but maybe it is useful for someone (to comment also of course).

Looking forward if someone has a solution already for the original issue you identified.

ewaller · 2012-10-29 15:59:39

Strike0: Thank you. I was not familiar with ufw. Since your post, I have looked into it and I think that tool will fill my immediate need. I will be setting it up this evening.

As to the other two, I think I will submit upstream feature/bug reports rather than take them on myself. I'll come back and mark this solved once it is working and the reports filed.

Thanks again

Strike0 · 2012-10-30 21:03:43

Great, I'm glad, if it proves useful for you!
I like ufw for its simplicity to get working iptables rulesets swiftly, as the above command shows. Now if you are setting ufw up first time, let me add a note, since I am not aware of the network & services setup of your box running the sshd. Plus this is not on our wiki yet:

When you enable ufw with a default deny policy, it still has some few built-in rules to accept traffic for infrastructure services, namely for upnp, avahi and dhcp replies. Also it has useful defaults for icmp flow control (rather than dropping everything).
These open infrastructure ports I do not consider a problem (good router firmwares have explicit options for them as well), but in a case where the box is permanently available to the internet -and perhaps no router filtering any traffic before it- one wants to be aware of them.

Using the "ufw status" commands just shows the rules you setup yourself. To see the whole lot you have to use "ufw show [reportname]". "ufw show raw" shows everything but you need a wide terminal to read it... With ufw enabled (not iptables enabled at the same time then) I prefer to use "iptables -S" which is more readable rules-wise.

iptables -S |grep ACCEPT

helps to focus on the ones I note on here by looking for the --dport parameters.

Obviously an open port does not mean there is a service listening behind it, but you know yourself the good practises & what you deem necessary. To get rid of them is just as quick as modifying the defaults for the connection limit example I briefly described in above post.

yarikoptic · 2012-11-02 01:00:38

Please have a look/try https://github.com/fail2ban/fail2ban/pull/82

Cheers

jrussell · 2013-03-14 17:45:56

Strike0 wrote:

I'm not a user of those, but that is definetely a heads-up. Tricky that the service starts just fine but may not actually be able to do its task without the old journal. I wonder if it throws an error on startup, if you purge the old auth journals.
Not a solution but a workaround may be to just use iptables with an IP-blocker after a number of consecutive failing attempts. Setting something like a 5 minute ban after 4 false attempts should make brute-forcing pretty tiring for most scripts. The way that works a fifth attempt after 4 minutes 50 sec would renew the 5 minutes. Figuring that out alone takes a while.
I used ufw to setup iptables as it provides default rules, incl a default deny. A limit rule is then setup with a
ufw limit log 22/tcp
After I set everything up, I save them to /etc/iptables/ with iptables-save, modify the rules as needed (e.g. for this example changing the default seconds and attempts until it blocks) and enable the iptables.service. But also keeping the ufw default should be fine to block scripts (thats 6 tries in 30 seconds before block in default - long way for a rainbow table/dictionary).
For the above example, this results in four rules:
-A ufw-user-input -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A ufw-user-input -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
The first sets the track for the new IPs trying to connect to the port, the second enforces the ban and the third and fourth log and reject ongoing attempts. I am sure you have something similar already, but maybe it is useful for someone (to comment also of course).
Looking forward if someone has a solution already for the original issue you identified.

Does this distinguish between a failed login attempt and just a new connection? Ive just started fiddling around with iptables

Strike0 · 2013-03-14 18:03:44

New connection attempts make it count up, a successful one counts as 1 too ;-) It works implicitly. you can't distinguish a failed from a successful connection attempt like that.

Arch Linux

#1 2012-10-27 21:45:38

Fail2Ban with Systemd Journal.

#2 2012-10-28 20:09:19

Re: Fail2Ban with Systemd Journal.

#3 2012-10-29 15:59:39

Re: Fail2Ban with Systemd Journal.

#4 2012-10-30 21:03:43

Re: Fail2Ban with Systemd Journal.

#5 2012-11-02 01:00:38

Re: Fail2Ban with Systemd Journal.

#6 2013-03-14 17:45:56

Re: Fail2Ban with Systemd Journal.

#7 2013-03-14 18:03:44

Re: Fail2Ban with Systemd Journal.

Board footer