Hello everyone,

I recently set up a debian wheezy home media server sort of deal. I configured SSH as I usually do: Only a single (non-root) user allowed, key-pair auth only, with separate key pairs for each device that I use the ssh client on.

Generally I also have sshd listen on a different port than 22 as well, but I decided to see what would happen if I left it default this time.

Within a few days, $sudo grep Invalid /var/log/auth.log | less shows this:
Which I see from the sticky is to be expected

I decided to learn how to use iptables rules instead of just installing fail2ban, so I used the ruleset from here: http://olivier.sessink.nl/publicatio...ing/index.html

My question is: how will I know if it is working? I understand that the ruleset should add ip's to a the blacklist chain and then drop packets from them, but where exactly is that blacklist stored? Will $iptables -L show new rules for each blacklisted IP? Or are they added to a different table of some kind? In either case, is the blacklist table persistent, or would rebooting the system set the blacklist back to empty? (assuming that I kept the iptables rules in place)

I also see that one of the rules should do some logging. Does this go to /var/log/syslog, or to /var/log/auth.log? Because then I should be able to grep for the prefix to see if anyone has been blacklisted.


p.s. Interestingly the login attempts stopped completely when I started working on this, even though I didn't have any rules in place for most of the time. I don't see any attempts for the last couple hours, and the frequency dropped off to about 1/hour, and from a different IP each time.

It seems to be a kind of brute force attack.
You can block ssh access by 2 ways.Either Iptable's INPUT chain or by using tcp wrappers.
To use tcp wrappers edit /etc/hosts.allow :
vim /etc/hosts.allow
sshd : "ip or domain u will log from"
Note: for ip range use dot like this "192.168.1." and domain ".example.com" or "*.example.com"
edit /etc/hosts.deny
vim /etc/hosts.deny
"ALL : ALL"
Note: The last line in the files hosts.allow and hosts.deny must be a new line character. Or else the rule will fail.
Linux first reads hosts.allow - if it doesnt find our ip , it checks hosts.deny.In the example above ALL : ALL means all services /supporting tcp wrappers/ to block all source - so if ip is not in hosts.allow - it will get blocked.
Editing these files doesn't require any service to be reloaded or restarted.Don't forget to use "at" command to restore hosts.allow and deny files if you log in remotely. /It won't be nice to get yourself locked out/.

As the iptables use the recent modules which in turn writes some files under the /proc directory. Guess the man page has some info else check out the /proc/net directory somewhere there it should be

find /proc -name "recent"

iptables -L will not show any sings of it. And yes you will loose the info on reboot. But you can save the entries and readd them. This way you can also add hosts on your own. Check the man page again for know how to do it.

Where iptables logs goes depends on the setings of your syslog daemon. Guess /var/log/syslog or /var/log/kernel are good places. But depends on distro and such.

Probably, you should read this (including the little note at the bottom).

That's probably the important point; expect bad stuff, because bad stuff happens, and more or less determined attempts occur on ssh all the time.

I know that using hosts.deny and blocking all, then explicitly allowing the IP I'm logging in from is the safest way. The issue is that I'm often using a mobile device to log in, so my IP will change depending on where I am at.

I will eventually move to a port other than 22 to cut down on these attacks, but I wanted to find a good solution to automatically ban brute force attackers before I did that. It's also interesting to me to watch how the attacks progress: First they brute force to find an allowable user name, then after that they start trying to brute force a password, which I see in the logs as "received disconnect from ##.##.##.##", since I only allow pubkey auth. My understanding is that sshd drops their connection as soon as they attempt password auth, so I see the disconnect message in the logs. This doesn't look very sophisticated, but I assume that a dragnet brute force compromises enough systems that they don't need to expend the effort to make a sophisticated attack.

Anyways, it sounds like fail2ban effectively does what was attempting to do manually with iptables, so I will probably start using that.

Is it correct that requiring pubkey auth is an effective defense? My thinking is that these brute force attacks are basically an annoyance as long as I keep my keys safe.

I think my next steps are to lock up every port, and then only open the ones I use (ssh, http for web browsing, etc), Although, the only port I'm forwarding through the router is 22 for ssh. I also need to double check to make sure I'm not running any outward facing services I'm unaware of (I may have an http server from the original install etc). Are there any other basic steps I can take after that to improve my security?

I found these resources:

https://www.debian.org/doc/manuals/s....html#contents
http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/

Plenty of material here to get me started! I could still use input on exactly how effective I can expect pubkey auth to be though. Can I assume that my ssh service is basically locked down as long as pubkey is the only allowed auth method and I keep my keys safe? If so, I'll move on to securing other things, but if not, I still have work to do on sshd.

There are many ways to skin this particular cat; see this, for example.

If you can do ssh key distribution securely, then pubkey ought to be safe, today. My feeling is that at some time, someone will find a way to make pubkey less safe, so it is probably best if pubkey is only one layer in your security picture, but maybe I'm being conservative, here.

That's probably reasonable; changing the port number probably cuts down on the dumbest of the dumb 'script kiddie' type attacks, but may not do much about the more competent attackers. But, it does enable you to see the serious attacks more clearly.

Here is another resource on iptables, if you are in that kind of mood.

To see which process are up and running on your machine use netstat -tulpn this lists all listening sockets.
And definitely have a default DROP at your firewall chains. Then only allow those ports that you want to.

You can do some fancy stuff with the recent module of iptables. I have a three tier blocking attempt.
First only ban for like 5 seconds. If the ip returns move it into a 1 minute ban recent list. If it still keeps coming back put it in half an hour ban recent list. While the other lists gets cleared once in a while through cron the ban list does not. So ever returning bad guys have to face the beholder each and everytime they pass by.
Using -m state --state NEW -m limit 3/s -j BLOCK to put offending ips into the BLOCK chain where it gets banned for like 5 seconds.
Just make sure that you have your sshd config so it only allows one login attempt per new connection (MaxAuthTries). Else a attacker might have 18 (6 default value * 3) guesses. If MaxAuthTries is set to 1 I had some trouble getting through to the key login. But dont remember correctly. Just follow sshd logs. Start it directly with sshd -ddd (might need to use absolute path on sshd binary).

Regarding to your non static ip. Create some port knocking with the recent module. (Though it does not help with tcpwrappers)
I like that better than any knocking daemon. Just use ssh -p 5000 -o ConnectionTimeout 1; ssh -p 5010 -o ConnectionTimeout 1; ssh -p SSH. Or telnet or some other thing. Might want to put in some -j REJECT rules here and there.

Coming to think of fail2ban have in mind that it searches your log files and bans ips due to that. Its no fast accting tool.

I think that's the primary criticism of fail2ban. It's not really "realtime". It's certainly better than nothing, and is as close to zero configuration as you can get.

Thanks for the tip on port knocking. I've heard the term a few times, but didn't really understand the application. That's extremely cool, and I'll set it up tonight.

Do you have any thoughts on my router? It's the router that actually is exposed to the internet, and my thoughts is that if I only have port 22 forwarded, then it's effectively limiting inbound connections to that port. Is this correct? Would it be a good idea to build a dedicated firewall between the router and the internet?

With a dedicated firewall between router an the inet you definitely have more control and might do some fancy stuff but i doubt that its needed. Make sure your route does not provide any "services" himself to the outward world. Like "external serviceing" or the like. Depending on what router you have you could even use it as a firewall itself.
With some sane settings you not need to worry.