Need help configuring firewall for whitelist in OpenSUSE

[tojoski]

I've got a client which I built an sFTP server based on OpenSUSE..

The server has been running well for a couple of years, but recently we determined that someone from out of the country was attempting to brute-force attack the server.

How can I setup a firewall to implicitly deny all connections to the server except certain IP ranges that I specify?

I'm not a linux guru, but I don't have any trouble installing software, using VI, moving files, ect with the CL..

Thanks in advance,

 

[XOR != OR]

sFTP...we're talking about FTP over SSH, correct? If so, use this:

-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Add that to your firewall rules ( I don't know where opensuse keeps them, so you're on your own with that).

What this does is to allow 2 connections within 300 seconds. Anything more than that is rejected until the timer expires. This is a more comprehensive solution than full blocking of ip ranges as it covers hack attempts from all IPs.

 

[keenan]

It's also fucking annoying when you're trying to legitimately use the service and opens a potential and easy to exploit DOS against a critical system service. Unless you know something I don't and have a way to tie the tracking to the source IP, anyway - pretty sure the posted rule is global.

I'd just install denyhosts and enforce a reasonable password policy. The easy, though slightly less secure way to do this is to ignore the firewall and use /etc/hosts.allow and /etc/hosts.deny instead. If you have easy control of the clients you could also just change the SSH port to avoid most automated attacks; anything listening on 22 will get them constantly.

Not a SuSE user either, but I've heard it's a pretty easy to use distribution, there is probably some kind of firewall script installed by default with a configuration file somewhere (or a GUI tool, if you have the GUI on your server) that you can modify. Check the SuSE documentation for that.

 

[XOR != OR]

It's also fucking annoying when you're trying to legitimately use the service and opens a potential and easy to exploit DOS against a critical system service. Unless you know something I don't and have a way to tie the tracking to the source IP, anyway - pretty sure the posted rule is global.

Nope, it's per source IP address. I just tested it.

So no DOS exploit possible. I've been running like this for a few years now.

 

[tojoski]

Thanks for the help guys..

I think I might implement both of the above suggestions.

Tell me if this looks right for the hosts.allow and hosts.deny, again, port 22 is the only one forwarded to the server.

hosts.allow

#allow all hosts on the local subnet
ALL: 192.168.1.0

#outside connections
ALL: 123.123.123.0

hosts.deny

#the implicit deny
ALL: ALL

Can I add the whole subnet as allowed? or does it need a specific address?

 

[XOR != OR]

I think you need to specify entire subnets in CIDR notation...but I could be wrong. So it'd look like this;

ALL: 192.168.1.0/24

Also, I'd specify services individually instead of the blanket ALL. So...

sshd: 192.168.1.0/24

Note: I am not as familiar with tcp wrappers as I am with iptables. keenan would be a better person to ask.

EDIT: Speaking of iptables, I found a script to combine it with spamhaus's drop list. Maybe overkill, maybe not, but it has significantly reduced the number of ssh connection attempts. Script as follows;

#!/bin/bash

#Script to add firewall rules to a linux system to completely block
#all traffic to and from networks in the spamhaus drop list.

#Copyright 2009, William Stearns, [email protected]
#Released under the GPL.  This and other tools can be found at
#http://www.stearns.org/

#Sole (optional) command line parameter is the file location of the
#drop list, such as:

#cd /var/lib/
#wget http://www.spamhaus.org/drop/drop.lasso
# ./spamhaus-drop /var/lib/drop.lasso

#While the DROP file should be regularly updated, this should
#probably be about once per day or less frequently; do _not_
#download DROP more than once an hour.

wget http://www.spamhaus.org/drop/drop.lasso -O ./drop.lasso

if [ -n "$1" ]; then
        DropList="$1"
else
        DropList="./drop.lasso"
fi
if [ ! -s "$DropList" ]; then
        echo "Unable to find drop list file $DropList .  Perhaps do:" >&2
        echo "wget http://www.spamhaus.org/drop/drop.lasso -O $DropList"
        echo "exiting." >&2
        exit 1
fi

if [ ! -x /sbin/iptables ]; then
        echo "Missing iptables command line tool, exiting." >&2
        exit 1
fi

cat "$DropList" \
 | sed -e 's/;.*//' \
 | grep -v '^ *$' \
 | while read OneNetBlock ; do
        /sbin/iptables -I INPUT -s "$OneNetBlock" -j DROP
        /sbin/iptables -I OUTPUT -d "$OneNetBlock" -j DROP
        /sbin/iptables -I FORWARD -s "$OneNetBlock" -j DROP
        /sbin/iptables -I FORWARD -d "$OneNetBlock" -j DROP
done

rm ./drop.lasso

You'd set this to run daily ( or weekly, it doesn't change often ) via cron.

 

[keenan]

Tell me if this looks right for the hosts.allow and hosts.deny, again, port 22 is the only one forwarded to the server.

You can read man hosts.allow for more info, but basically the following are supported:

.foo.com (all hosts ending in foo.com)
192.168. (all hosts matching the first octets 192.168)
192.168.0.0/255.255.0.0 (net/mask)
192.168.0.0/16 (cidr)
192.168.*.*

DenyHosts is better than the spamhaus option. They have an upstream blacklist you can enable if you want, but even just running it from your own logs its pretty effective.

I was mistaken about that method of limiting. I normally use Shorewall, and the default connection limit there is per service.

 

[XOR != OR]

I think we might be over engineering this problem a bit, keenan.

Still, depending on the sensitivity of the server, I wouldn't be above implementing all of this. However, lacking that I prefer to keep my layer 3 filtering at layer 3. I'm anal retentive like that. Nothing wrong with the wrappers option, certainly.

 

[tojoski]

Thanks for the help guys, the above suggestions worked perfectly.


On a side note, one of the clients is making a connection from India.. and it seems for some reason it denies them access like their is an authentication problem, although we're sure the user name and password are correct.

Would just being in a different country cause an issue like this? They are the only ones having the problem.. All the clients in the US work perfectly..

 

[XOR != OR]

If they are getting prompted for a username, then neither keenan's nor my fix would be causing interference.

Speaking about ssh usernames and passwords; one thing I neglected to mention is that you can use cryptographic keys instead of passwords. You could then disable the password authentication method, which will eliminate brute force attempts. It does have a significantly higher administrative overhead though, keeping the keys in check.

Just another thing to consider.

 

[LightningCrash]

When I started mail greylisting I got DoSed by spambots who didn't understand RFC specs (imagine that). So I used the iptables rules below, the article has it written for SSH, but I modified it for SMTP.
http://www.debian-administration.org/articles/187
Worked great and it was per-IP, not per-port.


I get beat on by China all the time at work... DenyHosts loves to block them. I second that suggestion by keenan.

I also use AllowUsers in sshd_config, since I am the only user account to use ssh.

 

[keenan]

Yeah, public key authentication is great, I love it. Just make sure that if you disable passwords entirely you have several backups of your main keys, or at least know the passwords if you have physical access.

As for your Indian user, I wonder if it's a Unicode issue or something. I'm assuming they get an authentication failed message? What client are they using? What do you see in the logs on your end?