Results 1 to 38 of 38
  1. #1
    Join Date
    May 2004
    Posts
    394

    Lightbulb Methods to block SSH attacks

    Alot of people are talking about SSH attacks, ways to prevent them.. Well I just thought that posting this would be somehow helpful.

    Methods:
    1. Allow the IPs you would like to have access to SSH through your firewall.
    Code:
    Example: 
    iptables -A INPUT -i eth0 -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT
    2. Change SSH port.
    Code:
    Example:
    Edit your ssh configuration file under /etc/ssh/sshd_config and add/replace this line:
    Port 6445
    3. Use a utility like BFD, BlockHosts and DenyHosts
    4. Use ip tables to limit the rate of incomming connections to SSH.
    Code:
    iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent   --set
    
    iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent   --update --seconds 60 --hitcount 4 -j DROP
    
    This will limit incoming connections to port 22 to no more than 3 attemps in a minute. Any more will be dropped.
    
    You can adjust the numbers yourself to limit connections further.
    5. Use Port knocking to open a the port for the firewall.
    Example using iptables:

    # Netfilter/IPtables - example of multiple-port knocking
    # Note: Knock ports 100,200,300,400 to open SSH port for 5 seconds.
    # Nice thing to knock TCP with is `telnet' program:
    # $> alias k='telnet ip_address_or_hostname'
    # $> k 100 ; k 200 ; k 300 ; k 400 ; ssh ip_address_or_hostname
    # Then press Ctrl-C 4 times. That's all. Enjoy.

    HOST_IP="12.34.56.78"

    /sbin/iptables -N INTO-PHASE2
    /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE1 --remove
    /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE2 --set
    /sbin/iptables -A INTO-PHASE2 -j LOG --log-prefix "INTO PHASE2: "

    /sbin/iptables -N INTO-PHASE3
    /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE2 --remove
    /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE3 --set
    /sbin/iptables -A INTO-PHASE3 -j LOG --log-prefix "INTO PHASE3: "

    /sbin/iptables -N INTO-PHASE4
    /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE3 --remove
    /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE4 --set
    /sbin/iptables -A INTO-PHASE4 -j LOG --log-prefix "INTO PHASE4: "

    /sbin/iptables -A INPUT -m recent --update --name PHASE1

    /sbin/iptables -A INPUT -p tcp --dport 100 -m recent --set --name PHASE1
    /sbin/iptables -A INPUT -p tcp --dport 200 -m recent --rcheck --name PHASE1 -j INTO-PHASE2
    /sbin/iptables -A INPUT -p tcp --dport 300 -m recent --rcheck --name PHASE2 -j INTO-PHASE3
    /sbin/iptables -A INPUT -p tcp --dport 400 -m recent --rcheck --name PHASE3 -j INTO-PHASE4

    /sbin/iptables -A INPUT -p tcp -s $HOST_IP --dport 22 -m recent --rcheck --seconds 5 --name PHASE4 -j ACCEPT


    This script can be found @ http://pub.ligatura.org/fs/netfilter...ortknock_multi

  2. #2
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,574
    Great post, I'm sure it'll help people out!
    MediaLayer, LLC - www.medialayer.com Learn how we can make your website load faster, translating to better conversion rates for your business!
    The pioneers of optimized web hosting, featuring LiteSpeed Web Server & SSD Storage - Celebrating 10 Years in Business

  3. #3
    nice thx , im sure this will help me

  4. #4
    Thanks thats really good post

  5. #5

    hi

    What about DOS attacks? many hosts are still vulnerable to them, how do you know if you are safe?

  6. #6
    Join Date
    Jan 2005
    Location
    Jakarta, Indonesia
    Posts
    86

    Lightbulb

    There are a number of ways you can protect your network from DOS attack (not 100%).

    1. Filter ICMP and UDP to your network or your server. You can ask your uplink provider to filter this packet in their border routers. This will prevent almost smurf and fragmented attacks.

    2. Put a hardware firewall, acting like proxy which only passing on completed packets. This will protect you from malicious TCP Traffic like SYN|ACK flooding.

    3. Filter out bad ip sources and put some policy to rate connections from specific hosts.

    I wish this could help you.

  7. #7
    Join Date
    Oct 2005
    Location
    Canada
    Posts
    33
    Helpful Article, thanks kalpin.

  8. #8
    Join Date
    May 2004
    Posts
    394
    Quote Originally Posted by kalpin
    There are a number of ways you can protect your network from DOS attack (not 100%).

    1. Filter ICMP and UDP to your network or your server. You can ask your uplink provider to filter this packet in their border routers. This will prevent almost smurf and fragmented attacks.

    2. Put a hardware firewall, acting like proxy which only passing on completed packets. This will protect you from malicious TCP Traffic like SYN|ACK flooding.

    3. Filter out bad ip sources and put some policy to rate connections from specific hosts.

    I wish this could help you.
    I agree with you. Also traffic shaping is one of the solutions for DOS attacks.

  9. #9
    If I used iptables to drop ssh attempts, is there a log of those drops? I want to check that it's working. Also, if attempts are dropped, are they still logged and therefore checkable with lastb?

    Thanks!

    Joe R.

  10. #10
    The ssh logs normally get logged in /var/log/messages or in /var/log/secure. I think you better check these files for logs.

  11. #11
    Ok, yeah I'm seeing a lot of authentication failure logs which is good. Thanks for the tip, I hadn't thought of it. It'd be nice to see messages about drops done by iptables. Perhaps iptables doesn't log these by default? Or maybe just need to find some third party software to do this for me.

  12. #12
    Great post!

  13. #13
    Join Date
    May 2004
    Posts
    394
    You can use logwatch and see that maximum failed logins from each IP is the number you have set. I suggest using higher time than 60 seconds.. something like 20 minutes (1200 seconds).

  14. #14
    Join Date
    Jun 2003
    Posts
    364
    Quote Originally Posted by kalpin View Post
    There are a number of ways you can protect your network from DOS attack (not 100%).

    1. Filter ICMP and UDP to your network or your server. You can ask your uplink provider to filter this packet in their border routers. This will prevent almost smurf and fragmented attacks.

    2. Put a hardware firewall, acting like proxy which only passing on completed packets. This will protect you from malicious TCP Traffic like SYN|ACK flooding.

    3. Filter out bad ip sources and put some policy to rate connections from specific hosts.

    I wish this could help you.
    While I agree it's a good idea to blog some types of ICMP packets it is also very useful to allow certain types of ICMP requests such as ICMP echo request/reply and all of the Destination unreachable replies.

    While setting up a dedicated firewall will prevent your server being heavily loaded by D/DoS your server will still appear unresponsive to the outside world if the D/DoS exceeds the amount of traffic the device is rated for. It will also be useless if the D/DoS exceeds the bandwidth of your up-link.

  15. #15
    Join Date
    Apr 2006
    Posts
    66
    Changing post is easiest and the best. That's what i do first.

  16. #16
    Join Date
    Jun 2008
    Location
    UK
    Posts
    265
    surely the best way is to set up ssh keys and disable password login completely ?

  17. #17
    Join Date
    May 2007
    Posts
    438
    Question about this:
    Edit your ssh configuration file under /etc/ssh/sshd_config and add/replace this line:
    Port 6445
    Don't you have to be logged into ssh to do this? Can't you lock yourself out?

  18. #18
    Join Date
    Dec 2002
    Location
    USA
    Posts
    337
    Quote Originally Posted by webcertain View Post
    surely the best way is to set up ssh keys and disable password login completely ?
    Yep.

    Disable password login.

    Change SSH port.

    Use SSH public/private key with password.

    Limit SSH login attempts via sshd.config

  19. #19
    Join Date
    Apr 2008
    Location
    USA & Germany
    Posts
    193
    Fail2Ban is a nice tool to automatically block IPs after a number a wrong login attempts. www.fail2ban.org

  20. #20
    Hi,

    At times, even public key may be hacked. google it and you will find more info

    You might have to use high encryption as a security measure. I agree that most people would prefer to use pulic key. Even with public key, you can ofcourse restrict IPs which can ssh.

    Another way to use ssh securely with password authentication is allowing only specific IPs to allow ssh to the server.

    Ofcourse, it is good to use a non standard port as well as wheel (su user ) and with very strong passwords for both root and su passwords

  21. #21
    Agreed. Changing port is an easy and quick way to stop SSH attacks and perhaps reduce resource usage. I was getting random brute force attacks on a server around 10 times per second, changing SSH port stopped this completely.

  22. #22
    Join Date
    May 2007
    Posts
    438
    Does anyone know how to set a limit?

    A while back I had some guy do a zillion tries.. I'd like to limit it to something more reasonable, like 2... anything beyond that zaps them from the server. (If possible)

  23. #23
    Join Date
    Aug 2004
    Posts
    136
    Good tutorial

  24. #24
    Join Date
    Apr 2006
    Posts
    52
    I use WHM to block that attack. Visit security area, and config some option. its Good if you use cPanel / WHM

  25. #25
    Join Date
    Apr 2010
    Posts
    24
    Remember these tips, too:

    - Deny root via SSH.
    - Deny Empty Passwords via SSH.
    - You have 65535 ports to choose from.

  26. #26
    Join Date
    Dec 2007
    Location
    Indiana, USA
    Posts
    16,057
    Changing the port, disable password authentication, use use a Login Failure Daemon to detect and block those trying to brute force the server.
    Michael Denney - MDDHosting LLC
    New shared plans for 2016! Check them out!
    Highly Available Shared, Premium, Reseller, and VPS
    http://www.mddhosting.com/

  27. #27
    Join Date
    Apr 2010
    Posts
    24
    Quote Originally Posted by MikeDVB View Post
    Changing the port, disable password authentication, use use a Login Failure Daemon to detect and block those trying to brute force the server.

    The important thing to remember is once an attacker is in via SSH, there is really no going back. If you have a user connect as a superuser, root, etc, most of the time they do something very harmful to the system such as backdoor the ssh daemon, launch attacks. It's very important to protect your ssh to the fullest extent as its one of your barricades.

  28. #28
    Join Date
    Dec 2007
    Location
    Indiana, USA
    Posts
    16,057
    Quote Originally Posted by xor_ View Post
    The important thing to remember is once an attacker is in via SSH, there is really no going back. If you have a user connect as a superuser, root, etc, most of the time they do something very harmful to the system such as backdoor the ssh daemon, launch attacks. It's very important to protect your ssh to the fullest extent as its one of your barricades.
    That's a given - but aside from unplugging all networking or disabling SSH all together (say, via KVM) there's only so much you can do.

    Only allowing SSH from specific IPs is another aspect that will help if you don't have a dynamic IP Some firewalls do support dynamic DNS where you can enter in your DynDNS and always be allowed through the firewall as well.
    Michael Denney - MDDHosting LLC
    New shared plans for 2016! Check them out!
    Highly Available Shared, Premium, Reseller, and VPS
    http://www.mddhosting.com/

  29. #29
    Join Date
    Mar 2010
    Posts
    993
    Even i am facing such attacks these days. I mean i never opened an account with email address in paypal and some days later paypal sent me an email that my account with email - "____" has been suspended.

    Once i was stunned but second thought came into my mind where i thought that i never opened an account with this email so how come its suspended.

    They also said that i was due to the fact that you have tried too many times with wrong password and this is why it is suspended...

    I then tried IPTlabes method to prevent it..

  30. #30
    Join Date
    Mar 2009
    Posts
    649
    I've found that changing the port SSH listens on gets rid of 100% of attacks CSF blocks any port scanning, so somebody will have to make a lucky guess to even start attempting to hack SSH, and even then CSF will ban their IP when they fail to use a correct username/password within 5 attempts.
    [GB ≠ GiB] [MB ≠ MiB] [kB ≠ kiB] [1000 ≠ 1024] [Giga ≠ gram] [Mega ≠ milli] [Kelvin ≠ kilo] [Byte ≠ bit]
    There is no millibit. There is no gram-bit. There is no Kelvin-Byte.

  31. #31
    Join Date
    Dec 2007
    Location
    Indiana, USA
    Posts
    16,057
    Quote Originally Posted by petteyg359 View Post
    I've found that changing the port SSH listens on gets rid of 100% of attacks CSF blocks any port scanning, so somebody will have to make a lucky guess to even start attempting to hack SSH, and even then CSF will ban their IP when they fail to use a correct username/password within 5 attempts.
    Unfortunately this won't stop them if they get your user/pass/port by other means. This is where only allowing certain IPs and disabling password authentication would really help.
    Michael Denney - MDDHosting LLC
    New shared plans for 2016! Check them out!
    Highly Available Shared, Premium, Reseller, and VPS
    http://www.mddhosting.com/

  32. #32
    Join Date
    Mar 2009
    Posts
    649
    Quote Originally Posted by MikeDVB View Post
    Unfortunately this won't stop them if they get your user/pass/port by other means. This is where only allowing certain IPs and disabling password authentication would really help.
    If they've managed to get my password (stored only in my brain) and port (stored only in my brain and ~/.ssh/config), then they've already got a keylogger or worse on my local system, and they can just tunnel straight through to the server from my own IP. Excessive paranoia (and useless) to only allow certain IPs.
    Last edited by petteyg359; 04-24-2010 at 04:55 AM.
    [GB ≠ GiB] [MB ≠ MiB] [kB ≠ kiB] [1000 ≠ 1024] [Giga ≠ gram] [Mega ≠ milli] [Kelvin ≠ kilo] [Byte ≠ bit]
    There is no millibit. There is no gram-bit. There is no Kelvin-Byte.

  33. #33
    Join Date
    Dec 2007
    Location
    Indiana, USA
    Posts
    16,057
    Quote Originally Posted by petteyg359 View Post
    If they've managed to get my password (stored only in my brain) and port (stored only in my brain and ~/.ssh/config), then they've already got a keylogger or worse on my local system, and they can just tunnel straight through to the server from my own IP. Excessive paranoia (and useless) to only allow certain IPs.
    Any security measures could be seen as pointless depending on your level of paranoia.

    You may keep that mindset until the day it does actually happen to you and a server gets wiped. I'm pretty sure just about everybody who has had a server wiped or compromised believed that their password, server, and methods were secure up until it was demonstrated that they weren't.

    To each their own, I'm not saying you're right or wrong but just that we may have a difference in opinions
    Michael Denney - MDDHosting LLC
    New shared plans for 2016! Check them out!
    Highly Available Shared, Premium, Reseller, and VPS
    http://www.mddhosting.com/

  34. #34
    Quote Originally Posted by MikeDVB View Post
    Any security measures could be seen as pointless depending on your level of paranoia.

    You may keep that mindset until the day it does actually happen to you and a server gets wiped. I'm pretty sure just about everybody who has had a server wiped or compromised believed that their password, server, and methods were secure up until it was demonstrated that they weren't.

    To each their own, I'm not saying you're right or wrong but just that we may have a difference in opinions
    I can not agree more with you mike for me so far so good touch wood

  35. #35
    Join Date
    Mar 2005
    Location
    Minneapolis, MN
    Posts
    877
    Thanks for the information .. I know this will come in handy..
    Mrgeekchris.com ~ It's not just a job It's a passion
    "Mistakes are proof that you are trying"

  36. #36
    I dont think allowing specific ips to access ssh is a good idea,lot of webmasters are there who uses dynamic to connect to internet,how would they be able to use ssh ?

    Instead its better to change there listenaddress to some other ip then your main share ip,and changing the port is very effective way

  37. #37
    Nice helpful post. Surely it would found helpful for others.
    Support Facility | 24/7 web hosting technical support services
    Technical support | Server management | Data migration

    Technical Articles

  38. #38
    Join Date
    Aug 2008
    Location
    Around the Servers!
    Posts
    33
    Great one... Really useful

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •