IptablesRocks.org -> blocking IP(s)

[sornman]

I set up a firewall on my server following the instructions at iptablesrocks.org, but am having problems blocking IPs. I have blocked a few specific IP addresses, just under the 'OUTPUT' rules in their install, but am still getting SSH and other login attempts from the addresses I added adn the addresses listed are not showing up in my 'blocked' logs.

Example entry:
-A INPUT -s 170.140.188.59 -j DROP

I also have several entries where I only want to allow HTTPD (port 80) access, so I added the following:
-A INPUT -s 202.0.0.0/7 -j DROP
-A INPUT -s 202.0.0.0/7 -p tcp -m tcp --dport 80 -j ACCEPT

Do I need to add 'OUTPUT' rules for the same blocks?

I know this forum is for QmailRocks.org, but as there is no forums set up at IPTablesRocks.org, I figured this would be an OK place to ask. Any help would be appreciated.

[Donboy]

>> am still getting SSH and other login attempts

You should consider reinforcing this in other ways. Try using tcp wrappers. /etc/hosts.allow and /etc/hosts.deny can do wonders for you. You can deny all connections except from your IP address.

You should also consdier looking at public key auth for your server. This will stop everybody cold and make it impossible for anyone to login to your server unless they have the correct public key installed on their computer. This is a very powerful way to block people from trying to login via SSH.

Here's a little howto you can use for setting this up...

http://www.linuxquestions.org/questions/answers.php?action=viewarticle&artid=79

[sornman]

Hmm, I already have several IP blocks in hosts.deny, including the address from yesterdays most recent attempts. And setting up public keys for this server is not a good idea due to the user base. I guess I just get tired of seeing my logwatch reports come in with something like this:

--------------------- SSHD Begin ------------------------

Failed logins from these:
alias/password from 220.228.104.132: 2 Time(s)
invalid user Ionutz (password) from 220.228.104.132: 2 Time(s)
invalid user Melk (password) from 220.228.104.132: 2 Time(s)
invalid user abc (password) from 220.228.104.132: 2 Time(s)
invalid user ace (password) from 220.228.104.132: 4 Time(s)
invalid user adela (password) from 220.228.104.132: 2 Time(s)
invalid user adi (password) from 220.228.104.132: 1 Time(s)

Add to that excerpt another couple hundred lines, all from the same IP address. I just want to block that traffic from hitting my server. I thought that blocking it via iptables (kernel) would prevent it from making it to ssh attempts, I guess I was wrong? Hmm, I guess to totally block off them, I would need an external firewall instead of just the one of the server itself.

[Donboy]

My advice: Don't allow users to login via SSH to your mail server. If you installed according to this website, you shouldn't need any system accounts other than your own. You can create all the mailboxes and accessories needed to administer them using web interface tools like qmailadmin.

Sorry, I know that's probably not what you wanted to hear, but honestly, if you want to be serious about securing your system, don't allow SSH except for yourself. Otherwise, use hosts.deny to deny everyone from SSH, and then explicitly allow certain IPs to connect to SSH from certain IPs.

[sornman]

Thanks for the advice, and yea, not really what I wanted to hear. It's not my mail server, but a client's server that they need to access from around the country.

[Donboy]

Well, if its just a single admin who needs to run the server, then great... he can use public key auth, and you can too. As long as it's just a few users who need access, it's not too much trouble. But if you have like 20 system accounts and they are a bunch of unpriv users, then you may have trouble. The problem is security from within. I've read countless articles that say the majority of security compromize happens from within by people who were supposed to be "trusted" users. There are a whole lot of security flaws being found and patched all the time, and they always seem to originate from within the LAN or from local users logging in. Security has gotten pretty good from the standpoint of users outside the system who try to break in, but when it comes to users who are allowed to login, there are just too many programs on the system that could be exploited.

[sornman]

Yep, I understand. And yes, there are many users that need access. I was just trying to block all IPs from Amsterdam and Asia as that is where most of the 'hacking' login attempts take place from, and I have no users that need access from those locations. So I guess without a separate firewall machine, blocking via iptables and hosts.deny as I am doing now is the best I can do. I just wasn't sure why the attempts were still making it in as SSH attempts if iptables and hosts.deny were blocking them.

[parsec]

>>I also have several entries where I only want to allow HTTPD (port 80) >>access, so I added the following:
>>-A INPUT -s 202.0.0.0/7 -j DROP
>>-A INPUT -s 202.0.0.0/7 -p tcp -m tcp --dport 80 -j ACCEPT


-A INPUT -s 202.0.0.0/7 -p tcp --dport 80 -j ACCEPT
-A INPUT -s 202.0.0.0/7 -p tcp -j DROP

else /etc/hosts.deny
ALL EXCEPT httpd: 202.0.0.

Note: You will have to check these, I am not sure if they entirely work as planned. It's just a quick guess at what you are trying to achieve.

[sornman]

Well, after spending a lot of time searching google for more info on this, I currently am looking at using:

-A INPUT -s 202.0.0.0/7 -p tcp -m tcp --syn --dport ! 80 -j DROP

Any input on how this should work? Should I try blocking the syn packets for the IP(s)? Also, using the "--dport ! 80" should block all ports but 80, so I would only need the 1 line for each IP(s), rather than the 2 I was using.

Another thing I found that may be useful is:

iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT

This limits the amount of syn connection attempts as per:
http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm#_Toc92808868

I emailed the contact at iptablesrocks.org, hopefully someone with a bit more knowledge than me on iptables can help tell whether the above examples are good or bad, and why. It would be cool to see a forum set up on that site, or one set up on http://www.rocksproject.org/ for help on all the various 'Rocks' sites.

[sornman]

Oh, another thing, if I am blocking all packets from the IPs except for those on port 80, shouldn't I also be blocking emails from them? I am still getting spam emails from the IP address blocks I am supposedly blocking.

Edit:
While I am posting, here is why I want to make sure I am properly blocking certain IP ranges:

Failed Logins: root/password from 61.220.80.198: 753 Time(s)

I have SSH to not allow root logins, but still 753 tries from that IP address yesterday, when it is supposed to be blocked by my firewall. Ouch.

[metalized]

I am no security or whatever expert by any means, but I think that a standard way to begin securing a system is to disallow everything and then only allow what u specifically need.

It might sound stupid, but as far as ssh is concerned I would block everything from the outside and open port only per request.

I use shorewall as firewall which is a great and easy to understand and configure iptables based firewall.

AllowSSH loc:xxx.xxx.xxx.xzz fw
AllowSSH net:xxx.xxx.xxx.xxx,xxx.xxx.xxx.xx1 fw

this would allow ssh logins to ur firewall (fw) from the local lan only from the host xxx.xxx.xxx.xzz and from the net oply from the hosts xxx.xxx.xxx.xxx and xxx.xxx.xxx.xx1

and there u can have ip ranges or even MAC adrresses.

if there are only few known hosts from where ur clients need access to their servers, u get the job done in a blink of an eye.

[jms1]

Well, after spending a lot of time searching google for more info on this, I currently am looking at using:

-A INPUT -s 202.0.0.0/7 -p tcp -m tcp --syn --dport ! 80 -j DROP

Any input on how this should work? Should I try blocking the syn packets for the IP(s)? Also, using the "--dport ! 80" should block all ports but 80, so I would only need the 1 line for each IP(s), rather than the 2 I was using.

this rule will drop TCP packets with the SYN bit set, with a destination port other than 80.

it will not drop UDP, ICMP, GRE, or anything without the SYN bit set.

i suspect what you're looking for is something like this:

-N WEBONLY
-A WEBONLY -s 202.0.0.0/7 -j DROP
-A WEBONLY -s 208.0.0.0/7 -j DROP

-A INPUT -p tcp -m tcp --syn --dport 80 -j WEBONLY

this way if a packet comes in and is not web traffic, the kernel only has to evaluate the one rule... and if it is web traffic, the rules in the WEBONLY chain will only have to look at the source IP, rather than checking protocols and ports and TCP header flags every time.