Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Brute Force Protection
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Brute Force Protection

reading about passwords being hacked on another thread reminded me to ask about this.

what brute force protection do you use on your server?

cPanel uses cPHulk, which is good but not free

Fail2Ban ? not tried it myself

Anyone got a tutorial on securing your server?

  • disable login as root
  • disable login with password just use ssh with keys
  • setup 2-factor authentication on as much as possible
«1

Comments

  • iSkyiSky Member

    my friend suggest me to use Fail2Ban after i got problem with crissic, thats more secure. however that other thread you mention, is very strictly that i even dont wanna try get speedtest and benchmark of the vps because it will make their alarm suspend me because abusive

  • perennateperennate Member, Host Rep

    fail2ban for SSH

    Every web application should have its own system.

  • mikhomikho Member, Host Rep

    Fail2ban and keys will get you far when it comes to securing sshd.

    Other applications that answers on a tcp/udp port needs special attention on a case by case basis.

    Thanked by 1netomx
  • OSSec is quite popular for this, though its better handled at a network level if you can

  • Awmusic12635Awmusic12635 Member, Host Rep

    csf

  • tchentchen Member

    BFD for edges. But ya, like @MarkTurner says, OSSIM stuck on a promisc port watches everything better.

  • ATHKATHK Member

    @Fliphost said:
    csf

    +1

  • You can also use CSF or DenyHosts for this also. CSF includes LFD which handles brute force attacks.

    If you wish to use DenyHosts and would like an easy way to setup and install, I wrote a script to help with that, if can be found here.

    Cheers!

  • CSF is fine on VPS or a dedicated server but if you are hosting VPS then you don't want to be running it on the host node/DOM0

  • Currently I'm using Denyhosts and logwatch. Each 1 failed attempts will be blacklisted.

    I'm also using iptables for counting the attempts and add the bruteforcer to blacklist

  • smansman Member
    edited March 2014

    People rely far too much on hammers that see everything as nails. Fail2ban would be one of those. The vast majority of attacks we are seeing these days get around fail2ban like water flows around rocks in a stream.

    If you are trying to solve bruteforce hacks by using hammers you are doing it wrong imho. Simply using moderately strong passwords is a far far far better approach.

    However, like every other security discussion I have ever seen on the innertubez...feel free to completely ignore this advice and continue to play whack-a-mole.

  • tchentchen Member

    ssh defense in depth isn't to protect you stupid password. It's to protect against your own stupidity.

  • smansman Member
    edited March 2014

    If we are strictly talking SSH brute force. You will hear all sorts of advice from all sorts of supposed experts. You will read all sorts of things about all kinds of solutions that may or may not be a PiTA to set up/learn and/or yet another thing to deal with. As any admin would know, we are ALL looking for more things to deal with aren't we?! None of us have more than enough and are always looking for more stuff we gotta deal with right?! Even if it's just another supposedly minor thing that adds to the hundreds, maybe thousands of other 'minor' simple things we gotta deal with spread across dozens, hundreds, maybe thousands of servers.

    The reality is that in the real world the absolute best solution we have ever found is also the simplest. Change the port #. Anything but 22. I would guess that eliminated upwards of 95% of all bruteforce attacks on SSH for us.

    Of course you will also read advice from supposed experts who say that relying on port # change alone is a bad idea. They often throw out one of their favorite phrases which is "security through obscurity" and how it's a bad idea to rely on that because blah blah yada yada.

    I'm here to tell you that in this case it works and it's simple and did I mention that it works? YMMV.

  • tchentchen Member

    That's fair enough for you typical drive-by bot scanners. Anyone remotely focused on you will be doing port scans though. But I concede your point that the OP should do a risk assessment and balance exposure vs complexity/intrusiveness.

  • NomadNomad Member

    In my case, minutes after installing Fail2Ban, I already had 2 blocked IP's. Turned out to be ssh scanners.

    Also you can set it up to monitor nginx/apache2/varnish or whatever.

  • LorneLorne Member

    CSF usually for me.

  • Duo Security for me - https://www.duosecurity.com/

    I login and it'll auto push a request to my phone. If it doesn't receive a request in the allotted time, the connection is terminated. Note, you must disable tunneling so that at login they cannot attempt to tunnel to any exposed port applications. Beyond that, extremely secure and used by many companies for two way authentication both on Windows and Linux.

  • I asked something similar not so long ago.
    http://lowendtalk.com/discussion/23132/box-security#latest

    I go with the IP whitelisting approach in /etc/hosts.allow

  • BAKABAKA Member

    Just don't use port 22. Don't even answer any knocking.
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j DROP

  • CSF

  • @BAKA said:
    Just don't use port 22. Don't even answer any knocking.
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j DROP

    That stops script kiddie attacks. Offers no real protection.

  • I use CSF.

  • SilvengaSilvenga Member
    edited March 2014

    BAKA said: Just don't use port 22

    I know its a good idea not to use default ports, but frankly I'm lazy. I wonder if using non default ports is helpful any more. Can't we just port scan now with netcat and find the SSH port in minutes?

  • @Silvenga said:
    I know its a good idea not to use default ports, but frankly I'm lazy. I wonder if using non default ports is helpful any more. Can't we just port scan now with netcat and find the SSH port in minutes?

    This is why we have port knocking!

  • @MarkTurner said:
    OSSec is quite popular for this, though its better handled at a network level if you can

    I agree, fail2ban asks for like a few more packages and, in debian 7 it conflicts with a pre-installed package (can't remember the name) which if you agree to uninstall "may lead to system damage" according to aptitude softie. So it sounds like a little too much for me in a production environment.

    iptables "burst-rate" would be a nice topic to digg into. Most of the scripts for securing ip(6)tables I've seen on the net will DROP everything and then allow only a few ports in (like http, https, custom ssh[this one for your home/vpn ip only], ICMP[same]) and maybe dns if you use bind.

    then it's also a good advice (even if it's obvious for some) to keep your distro updated with security fixes, since n00b scripters will try brute-force/port-scanning and such, but a bit more experience range of geeks will look for bugs to [exploit] so it's a nice thing to keep up to date with available exploits and have a "testing" environment (maybe at home, in a virtualized small-ram box) for intrussion testing to see if you can root yourself.

    I used to scan universities in taiwan for "readonly" access to passwd files, from which I could make a list in seconds and try get same user=password user access to the shell and then from there you can get more info 'bout the box itself and search the net for exploits (or try make your own if you're good with c! which I'm not at all).

    so nice topic for a thread, I know there must be some gnus here who can teach us a lot 'bout all this! besides just saying "go for fail2ban".

  • IshaqIshaq Member

    Yeah, CSF (more specifically LFD)

  • Good read available here -> https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

    Really puts this all into perspective. SSH on a port other than 22 is bad. Don't do it. Security through obscurity is not security.

  • @0xdragon - port knocking is fine, but if you are having issues with your server and low on RAM, this often fails badly.

  • @MCHPhil said:
    Good read available here -> https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

    Really puts this all into perspective. SSH on a port other than 22 is bad. Don't do it. Security through obscurity is not security.

    Just don't put it on a non privileged port. (Keep it below 1024)

  • CSF does the job

Sign In or Register to comment.