Stateful firewall and sshguard

Foucault · 2013-06-24 16:31:47

I was trying to setup some iptables rules using the wiki page for stateful firewall. Everything seems to work as expected however I am a bit baffled as to where the sshguard rule should be placed. This is what I have so far (the relevant part of course)

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [335:37963]
:TCP - [0:0]
:UDP - [0:0]
:sshguard - [0:0]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

-A INPUT -p tcp -j sshguard

-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP

I can't seem to understand whether the sshguard rule should be prior to or after the TCP/UDP conntrack rules. I believe that when the packet reaches the TCP/UDP conntrack lines is assigned to either the TCP or the UDP chain. So should the sshguard filtering be before or after this distinction? I would like some advice on that. Thanks in advance!

Last edited by Foucault (2013-06-24 16:33:16)

Strike0 · 2013-06-24 19:57:37

It will work where you have it now, but it is not the best place at the same time.
The reason for this is that it only has to do the filtering task on NEW packets (connection attempts) to your ssh port. So, if you place it right above the ssh accept rules (not shown in partial rules above) it has to process less packets, i.e. not those rejected between where the rule is now and your ssh accept.

According to the wiki sshguard parses auth.log. If still so, you need to run syslog-ng for that (journalctl does not populate the log). Another way to implement a basic ssh protection can be achieved with iptables easily itself btw. Have a look here for a howto explanation (syntax of the rules has changed slightly, but you will figure that). Maybe that suits your needs just as well (with less running services - which can also have a security relevance).

roentgen · 2013-06-24 20:10:52

A simpler idea (for me) is to run shh on another port and drop and ban everyone trying port 22.
I have no "auth failed" in logs with such setup in quite some time.

Some rules to get you started.

# Drop bad input
iptables -A INPUT -m recent --name badin --update --seconds 60 -j DROP
# ssh to port 22
iptables -A INPUT -p tcp --dport 22 -m recent --name badin --set -j LOG --log-prefix "BadIN 22 "
iptables -A INPUT -p tcp --dport 22 -m recent --name badin --set -j DROP

Foucault · 2013-06-24 21:32:11

roentgen wrote:

A simpler idea (for me) is to run shh on another port and drop and ban everyone trying port 22.
I have no "auth failed" in logs with such setup in quite some time.

I already do drop traffic arriving at port 22. Blacklisting the attempts on it seems nice as well. I will try it, thanks!

Strike0 wrote:

The reason for this is that it only has to do the filtering task on NEW packets (connection attempts) to your ssh port. So, if you place it right above the ssh accept rules (not shown in partial rules above) it has to process less packets, i.e. not those rejected between where the rule is now and your ssh accept.

If that is the case should the rule be on the INPUT (-A INPUT) chain though or on the TCP (-A TCP) one? The rest of the script is basically this block

-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

followed by the port opening through the TCP/UDP chains like so

-A TCP -p tcp -m tcp --dport whatever -j ACCEPT

If I understand correctly the sshguard rule should be put on the TCP chain but before the rule that opens up the port. Is that correct?

Strike0 wrote:

If still so, you need to run syslog-ng for that

I do that alright!

WonderWoofy · 2013-06-24 21:56:57

The sshguard package now comes with a script in /usr/lib/systemd/scripts that allows for parsing of the journal. So all you have to do is enable the service (and implement the iptables rules of course).

Strike0 · 2013-06-25 20:16:27

I think you should do it just like WonderWoofy suggests. There is nothing wrong with your questions, but it is important to get a hands-on understanding of how the chains link into each other. Otherwise the next rule you add on another Monday will break them.
So, why not set the ruleset and service up as you plan to, test that it works (blacklists), then switch sshguard to the other position, reload the rules on-the-fly, confirm whether those works too or not and share your results.

Foucault · 2013-06-25 21:36:58

I replaced the sshguard rule with a -j LOG to see if it reaches the logs and indeed it seems to do so if I put it in the TCP chain but not if I put it in the INPUT chain after the REJECT, which makes sense, really. I also tried hammering at the port through a different IP and packets seem to be dropped after a while so I suppose sshguard filters them out.
Thank you all for your help and advices; reading about it here and there cleared up a bit my understanding of iptables. Feel free to add more suggestions if you have.

Last edited by Foucault (2013-06-25 21:40:35)

Strike0 · 2013-06-27 09:41:14

Ok, good you seem to get it working. You mentioning yourself that you use your log chain to see it is working. One suggestion would be to check the logs for the actual blacklisting/filtering taking place. Not having used sshguard myself, it made me curious that you write "I suppose sshguard filters them". Looking at the docs there reveals nice related features of it, but I did not see much of a mention of a plain logging of the action interestingly.
You might want to check (in your logs) whether it does that. If you read up again in roentgen's rules it is done simply within the blacklist rule, so that a grep of "Badin 22" shows it is working.

Fraterius · 2013-08-06 12:37:44

As sshguard seems to be working fine for you guys, maybe someone can point me to what I'm doing wrong. Generally everything seems to be working correctly except that it does not block any of my test atack. Here are my iptables rules:

# Generated by iptables-save v1.4.19.1 on Tue Aug  6 12:50:16 2013
*filter
:INPUT DROP [52829:4893190]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [166934:79877565]
:sshguard - [0:0]
-A INPUT -j sshguard
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 636 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000:10010 -j ACCEPT
-A INPUT -p udp -m udp --dport 636 -j ACCEPT
-A INPUT -p udp -m udp --dport 25 -j ACCEPT
-A INPUT -p udp -m udp --dport 110 -j ACCEPT
-A INPUT -p udp -m udp --dport 995 -j ACCEPT
-A INPUT -p udp -m udp --dport 143 -j ACCEPT
-A INPUT -p udp -m udp --dport 993 -j ACCEPT
-A INPUT -p udp -m udp --dport 587 -j ACCEPT
COMMIT
# Completed on Tue Aug  6 12:50:16 2013

Here is the output of /usr/bin/journalctl -afbp info -n1 SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 command during my atack which shows that the atack is logged properly:

sie 06 13:31:32 gil sshd[8805]: Failed password for invalid user test from 194.29.160.35 port 34877 ssh2

According to http://www.sshguard.net/docs/reference/ … ignatures/ it suppouse to be a potential atack. Sshguard and iptables are started and running properly and I can try to login without any action from the server.

Any ideas what might be the problem or what I'm doing wrong? Thx in advance.

Fraterius · 2013-08-06 17:49:08

Ok after another invetigations I'm not sure whether sshguard from latest package is working properly. When I try to debug it with log from my previous post I'm getting:

sie 06 13:31:32 gil sshd[8805]: Failed password for invalid user test from 194.29.160.35 port 34877 ssh2
Starting parse
Entering state 0
Reading a token: --accepting rule at line 220 ("sie")
Next token is token WORD ()
Cleanup: discarding lookahead token WORD ()
Stack now 0

I thought it might be the problem with date stamp so I removed it and now I get something like that:

Failed password for invalid user test from 194.29.160.35 port 34877 ssh2
Starting parse
Entering state 0
Reading a token: --accepting rule at line 220 ("Failed")
Next token is token WORD ()
Cleanup: discarding lookahead token WORD ()
Stack now 0

From what I read here: http://www.sshguard.net/docs/faqs/#debugging it doesn't work as expected. I can put as many log in the debug console and all I get is the same output as above. If someone can confirm this then I'll make a bug report on this issue.

Strike0 · 2013-08-07 05:43:39

I'm not sure about that debug output but don't take out the date/time stamp. It is needed.
Are you using enough tries in your attack test? It will only block after a number of consecutive failing tries in time x (should be specified in the conf).

Fraterius · 2013-08-07 07:37:03

Yes I do, as far as i understand it should block me after 5 attempts. I'm doing around 30 and nothing happens. Is it working with your configuration, does your debug also do not act as it is described on the link from my previous post? Thx for any report on this one.

Last edited by Fraterius (2013-08-07 07:38:38)

Strike0 · 2013-08-07 17:55:30

I've never used it and just gave Foucault some input on the iptables question in the OP. Check you are not doing your tests from a whitelisted IP.

Leaving your question below for any user of the tool to confirm.

Fraterius wrote:

Yes I do, as far as i understand it should block me after 5 attempts. I'm doing around 30 and nothing happens. Is it working with your configuration, does your debug also do not act as it is described on the link from my previous post? Thx for any report on this one.

Arch Linux

#1 2013-06-24 16:31:47

Stateful firewall and sshguard

#2 2013-06-24 19:57:37

Re: Stateful firewall and sshguard

#3 2013-06-24 20:10:52

Re: Stateful firewall and sshguard

#4 2013-06-24 21:32:11

Re: Stateful firewall and sshguard

#5 2013-06-24 21:56:57

Re: Stateful firewall and sshguard

#6 2013-06-25 20:16:27

Re: Stateful firewall and sshguard

#7 2013-06-25 21:36:58

Re: Stateful firewall and sshguard

#8 2013-06-27 09:41:14

Re: Stateful firewall and sshguard

#9 2013-08-06 12:37:44

Re: Stateful firewall and sshguard

#10 2013-08-06 17:49:08

Re: Stateful firewall and sshguard

#11 2013-08-07 05:43:39

Re: Stateful firewall and sshguard

#12 2013-08-07 07:37:03

Re: Stateful firewall and sshguard

#13 2013-08-07 17:55:30

Re: Stateful firewall and sshguard

Board footer