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.

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

free trial zilore monitoring

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, Provider

    fail2ban for SSH

    Every web application should have its own system.

  • mikhomikho Member, Provider

    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
    I can now be found at https://talk.lowendspirit.com
    or on twitter
    Come say HI! :)
  • OSSec is quite popular for this, though its better handled at a network level if you can

  • Awmusic12635Awmusic12635 Member, Provider

    csf

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

  • 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!

    Have an Allwinner H3 device? Check out H3Droid! | Lichee Pi Zero - The 6$ SBC | #SYSarm - Get It! | Armbian | Atomic Pi Mirror
    22+ Years IT Experience in Linux/Windows Hosting, Administration and Development Services

  • 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.

    CEO of W3-Host | Check out our VPS plans here. LET Exclusive Deal.

  • 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!

    This signature wasted 121 bytes of your data allocation.

    https://nixstats.com/report/56b53d6465689e44598b4567

  • @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, Provider

    Yeah, CSF (more specifically LFD)

    [BudgetNode] DDoS Protected. 7 Locations (US/EU). Check out our latest offer!
  • MCHPhilMCHPhil Member, Provider

    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.

    Transparency is key - Webhosting with a spine! - Live US based support, not to be confused with aliens.
  • @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

    I ❤ Laravel

  • MCHPhilMCHPhil Member, Provider
    edited March 2014

    MCHPhil said: Security through obscurity is not security.

    The only defense is multi-layered and employs multiple techniques.

    Transparency is key - Webhosting with a spine! - Live US based support, not to be confused with aliens.
  • tchentchen Member

    @MCHPhil said:

    That, plus monitoring/alerting.

  • BAKABAKA Member
    edited March 2014

    Silvenga said: Can't we just port scan now with netcat and find the SSH port in minutes?

    Yes, you can do that.

    But if I am to scan ports, I would rather scan 1 port/machine * 65,535,000 machines than 65535 ports/machine * 1,000 machines.

    Most scanning behaviors are not targeted, and only try a few ports.

    Not quite agree.

    1: This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords.

    If sshd (root) has already occupied port 2222, non-priviledged software cannot kick sshd and listen to that port.

    2: is it a problem to have so many people banging at the front of your house?

    Yes, it is.

    For non-targeted scans, if port 22 is found to be open, further attack attempt is likely to happen; if not, seldom will they bother to attack.

    That means, a machine with port 22 may receive 100 attack attempts per month, while a machine with port 24739 receives only one.

    Given that other defending strength are the same, such probability does matter.

    I admit that if you are targeted, changing port does not help at all.

  • tchentchen Member

    hwdsl2 said: You can stop the port scanners cold in their tracks using an IPTables module ("psd") from the xtables-addons package.

    I installed it and locked myself out when I forgot which port I moved my ssh to and had to run nmap. /s

    Thanked by 1gattytto
  • tchentchen Member

    @hwdsl2 I kid ;)

  • nunimnunim Member

    Moving SSH to a different port has stopped all SSH brute force attacks I was seeing. I've noticed that some networks are scanned far more often than others, i.e. I see a lot more attacks against SingleHop IPs than other providers.

    I know that changing the SSH port is "security through obscurity" and will not protect me against a determined attacker, however it does stop all the drive by attacks from scanner bots. I've been working on deploying CSF on all of my machines, my only complaint is that the built-in WebUI is awful. I've more than capable of managing CSF via SSH, however sometimes the WebUI is just more convenient.

    The built-in WebUI just eats CPU while it's active, I need to see how CSF is interfaced with cPanel and Webmin to see if it's possible to use my own webserver instead of the built in LFD daemon.

    SonicBoxes.com - VPS Tips, Tricks & Tutorials
    6UA.net Various tools, screenshots, password gen, looking glass, etc..

  • im new to the low end box world and finding it very interesting.
    ive configured iptables to only allow ssh access from my home and office IPs
    ive also configured to not allow root to ssh directly.
    one has webmin installed and the other whm dnsonly and ive configured those with the same ip retrictions...
    one server is a backup dns so i definitely need DNS open on it and the other has no need to interact with anyone other than my own servers... are there other ports/applications i should be securing?

  • said: what brute force protection do you use on your server?

    csf - lfd in ALL servers, fail2ban in VoIP servers

  • DewlanceVPSDewlanceVPS Member, Provider
    1. Disable SSH root login
    2. Change ssh port
    3. Set maximum 1 failure in CSF(Ban for 2 days, etc)


    DemoTiger.com - custom cPanel branded Videos for your KB/YouTube,etc.
  • @DewlanceVPS said:
    1. Disable SSH root login

    2. Change ssh port

    3. Set maximum 1 failure in CSF(Ban for 2 days, etc)


    Also disable passwords altogether and use SSH keys for authentication :)

    Thanked by 1DewlanceVPS
Sign In or Register to comment.