You are not logged in.
What measures do you guys take to secure your ssh servers? I've installed this little script "denyhosts" from the repos. It works well, but I don't like that my deny.hosts-file increases with 5-10 lines every day. Any suggestions to other things I should try to lower the amount of attacks?
My /var/log/auth.log is FULL of break-in attempts from numerous ip-addresses. They seem to be trying every port, every username and every password possible.
I've disabled root login in sshd_config. In addition to denyhosts, that's about it.
Please use this thread to give me some suggestions.
Thanks
Offline
I put ssh on a high port (e.g. not 22), disable root-access and passwords. I use passphrased public-keys instead. This adds A LOT to security.
Last edited by mucknert (2007-11-19 10:34:49)
Todays mistakes are tomorrows catastrophes.
Offline
instead of denyhosts, you could use ip tables to block brute force attacks
http://searchenterpriselinux.techtarget … 48,00.html
Offline
port-knocking through iptables. and then allow only 1-3 attempts per hour. or more if you need more.
$TABLES --new-chain limitations
$TABLES --new-chain recent_allowed_input
$TABLES -A limitations -m limit --limit 3/hour --limit-burst 3 -j ACCEPT
$TABLES -A limitations -m recent --name RECENT_FILTER --set
$TABLES -A limitations -m recent --name RECENT_FILTER --rcheck --hitcount 6 -j recent_allowed_input
$TABLES -A limitations -m recent --name RECENT_ALLOW --set
$TABLES -A limitations -j DROP
$TABLES -A recent_allowed_input -m recent --name RECENT_ALLOW --update --seconds 300 -j ACCEPT
$TABLES -A recent_allowed_input -m recent --name RECENT_FILTER --remove -j DROPthis is only for port-knocking. you can set allowed logins per hour through -m limit (smth like: -m state --syn --state NEW --dport 22 -m limit --limit 1/hour --limit-burst 1 -j ACCEPT).
vlad
Last edited by DonVla (2007-11-19 11:38:45)
Offline
Wow, that iptables syntax really is hard to understand if you dont know how it works ![]()
Its a pity a blocking function ain't included with sshd. I mean, everyone suffers from this, and there are loads of different solutions, some working on some OS's and some on others, and maybe some of them are not so recommended while others work very well.
Why not just solve it once for all, have it in sshd from the start? Why dont they (the OpenBSD devs, right?) do like that?
So many people dont have the knowledge to mess around with all these strange solutions, learning to program PF, or trust some anonomous developer who has made some small script that is supposed to do magic.
Would be more safe and much easiser to have a "official" solution for it, that is available to everyone running Linux/BSD/UNIX.
Would probably limit the number of hacked hosts too, which are used for all kinds of bad things.
Oh well, will probably never happen anyway, just a thought from my side.
Offline
It won't happen if you just talk about it here - submit a feature request if you feel strongly about it.
That said, the use of separate tools for distinct functions is generally regarded as the right way to do things in *nix circles.
Offline
Yeah but if the tools are so spread around and rely on anonymous individuals here and there that have the coding skills, instead of having one officially universal solution.....oh well, it wont happen. But would have been really nice and we wouldn't have these threads appearing on all unix/linux forums ![]()
Last edited by Seb74 (2007-11-19 13:20:09)
Offline
well the strategy is to have the 'Guys Who Know This Stuff Really Good' do 'This', and the 'Guys Who Know That Stuff Really Good' do 'That', so that This+That is really good instead of having the 'This' guys do 'That' half-good (and as it is integrated, it would be used by everyone, only slowing the potential coming of 'That' better stuff, especialli if 'That' comes out to be half-bad). plus this way, if either A or B does not satisfy or disappears, one can take it over and replace it.
That said, fail2ban is fairly easy to setup (at least on my debian box) and layers you away from those frightening (well, until you get things into your head) iptables rules
Last edited by lloeki (2007-11-19 15:58:10)
To know recursion, you must first know recursion.
Offline
Before running denyhosts take a look at http://www.ossec.net/en/attacking-logan … #denyhosts. The current version is vulnerable to a dos attack, anybody can make it add ALL: ALL in your /etc/hosts.deny...
I can confirm from own experience what mucknert says, changing the default port will drastically reduce the attack attempts. It's almost common sense to disable root-access.
If you want paranoia, you can use openssh-chroot, too bad it is not up2date, osshChroot-4.5p1.diff applies to current openssh sources and works. I did some set-ups with a restricted shell in chroot. The only accessible binary in the chroot environment is a renamed copy of ssh... Even more you can add "StrictHostKeyChecking yes" to the chrooted /etc/ssh/ssh_config so the only thing you can do from there is renamed_ssh user@localhost. Isn't it cool? Of course some more digging/reading/testing is required.
Last edited by VikM (2007-11-19 16:48:12)
Offline
Before running denyhosts take a look at http://www.ossec.net/en/attacking-logan … #denyhosts. The current version is vulnerable to a dos attack, anybody can make it add ALL: ALL in your /etc/hosts.deny...
Zoiks! Thanks for the link, that is VERY GOOD TO KNOW... I need to rethink my security, it would seem ![]()
-nogoma
---
Code Happy, Code Ruby!
http://www.last.fm/user/nogoma/
Offline
Offline
Turn off root login, passwords and protocol version 1, done. Then learn to ignore the logs or even filter that stuff completely.
I hate sigs. This one only exists to remind myself to get an avatar.
Offline
thanks a lot vikm, that's really good to know, esp. patches available down the page.
Last edited by lloeki (2007-11-21 16:52:33)
To know recursion, you must first know recursion.
Offline