Advertisement
Guest User

Stopping SSH Brute Force attacks with PF on FreeBSD

a guest
Jan 30th, 2015
250
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
Bash 7.13 KB | None | 0 0
  1. http://128bitstudios.com/2010/06/13/stopping-ssh-brute-force-attacks-with-pf-on-freebsd/
  2. 128bit.io
  3. 2^7 bits of goodness!
  4. Stopping SSH Brute Force attacks with PF on FreeBSD
  5. By Anthony Scotti  on 13 Jun 2010
  6.  
  7. Most people know that port 22 is used for SSH communication and due to this common knowledge, you get people using scripts to test for weak passwords. If you look into your /var/log/auth.log and you see tons of fails/errors from users not on your system or from invalid passwords for root, it means you have people trying to break into your system. Truthfully, anyone that puts a system online with port 22 open will see this happen to them.  It’s quite common and not direct attack against you, just scripts looking for IPs with port 22 open.
  8.  
  9. Now it goes without saying that you should make sure you have a strong password that take use of numbers, upper and low case letters and symbols. Doing this will go along way in preventing someone from breaking into your system. You should also ensure that people can’t remotely log in as root by making sure that you have ‘PermitRootLogin’ set to ‘no’ in your /etc/ssh/sshd_config file. This will ensure that no mater how many passwords they try for root they will never be able to log in.
  10.  
  11. Now you could just set your SSH server to run on a different port or have your firewall redirect a different port from the outside to the system, but what’s the fun in that when you can use a great tool like PF.
  12.  
  13. PF or Packet Filter comes from the OpenBSD group and was ported over to FreeBSD. It’s a great firewall tool with many advanced features to it. PF comes pre-installed and just needs a quick edit to your /etc/rc.conf. Just add the lines below.
  14. pf_enable="YES"
  15. pf_rules="/etc/pf.conf"
  16. pflog_enable="YES"
  17.  
  18. Now we need to add some rules to the /etc/pf.conf file that will deal with the SSH brute force attacks.
  19. table <bruteforce> persist
  20. block quick from <bruteforce>
  21. pass inet proto tcp from any to any port ssh \
  22. flags S/SA keep state \
  23. (max-src-conn 5, max-src-conn-rate 5/30, \
  24. overload <bruteforce> flush global)
  25.  
  26. What is happening here is that you are making a table that will keep track of the IPs of SSH brute forcers and make sure they are unable to connect to the system after being added to the table. The next part in the rule is how they are added to the table. If they connect with more then 5 clients to the SSH server and try reconnect 5 times within 30 secs they get added to the table. Feel free to edit the rules for whatever works best for your situation. For myself, this works fine and deals with anyone quickly.
  27.  
  28. If you want to see the IPs on the table you can run pfctl -t bruteforce -T show as root and get a list.  If somehow an IP gets put in the table that you don’t wanted blocked you can removed it by running pfctl -t bruteforce -T delete <IP> and that will remove it from the table.
  29.  
  30. For people using Linux, I believe there are ways to do the same thing with something called iptable. If I ever set this up I will make a posting on it.
  31.  
  32. EDIT: I made a new posting going over ways to stop SSH brute force attacks on Linux. The posting can be found here, Stopping SSH Brute Force attacks on Linux
  33.  
  34. Open for questions, comments, or any way to improve this!
  35.     
  36. 128bit.io
  37. 2^7 bits of goodness!
  38. Stopping SSH Brute Force attacks on Linux
  39. By Anthony Scotti  on 30 Aug 2010
  40.  
  41. From my other posting “Stopping SSH Brute Force attacks with PF on FreeBSD” I’ve been getting a good number of hits from people searching on how to stop SSH Brute Force attacks but on Linux and not FreeBSD, so I kind of feel the need to make a posting on this for the linux people. I also just setup a Fedora 13 server on Rackspace’s Cloud and I wanted to ensure I could stop SSH Brute Force attacks.
  42.  
  43. Quick over view from my other posting
  44.  
  45. You should make sure that no one can log in as root from SSH. A lot of servers let you do this so you can get things setup.  So make a new user, install sudo and add them do the sudoers list. After that edit your /etc/ssh/sshd_config file to have ‘PermitRootLogin’ set to ‘no’. Don’t forget to restart sshd for the new setting to take place “service sshd restart” on Fedora. This set is key as root is the only known user on all Linux/Unix base system.
  46.  
  47. A lot of SSH Brute Forcers are only looking at port 22 for SSH, you can change the port that SSH is running and stop a lot of SSH Brute Force attacks. This can be done within /etc/ssh/sshd_config or by using your firewall. I’m really not a big fan of this step but it helps out a lot.
  48.  
  49. iptables - Linux Firewall
  50.  
  51. iptables is the linux firewall that comes pre-installed on a lot of distros. Within Fedora it comes pre-installed and is able to run  from first boot. Looking around on the web I couldn’t find anything on the same level as what I had for PF but I did find something that would help slow down SSH Brute Force attacks.
  52.  
  53. The file that keeps all the rules for iptables can be found in /etc/sysconfig/iptables on Fedora, add the lines below to the file.
  54. -I INPUT  -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH--rsource
  55. -I INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name SSH--rsource -j DROP
  56.  
  57. The first rule will start a table that will log IPs which starts a connection to ssh port. The next rule will count the number of tries from the same IP, if that count passes 4 with in 180  seconds then the server will not accept any more connections from that IP for 180 seconds.
  58.  
  59. You are going to need to restart iptables, this can be done on Fedora by running “service iptables restart”.
  60.  
  61. The idea with this rule is that the SSH Brute Forcer is just a script that is running until it see that it’s being blocked and move on to the next IP.
  62.  
  63. DenyHosts
  64.  
  65. After looking around for software that would give me something more permanent for blocking SSH Brute Force attackers I found DenyHosts.
  66.  
  67. From denyhosts.sourceforge.net “DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).”
  68.  
  69. DenyHost will read you log file looking for fails from SSH connections, it will then add that IP to your /ect/hosts.deny and block them from being able to log in at all. You can also set it to deny the IP from all services on the server.
  70.  
  71. I found DenyHosts to be easy to install and setup. On Fedora to install it is just using “yum install denyhosts”, to run is “service denyhosts start” start and to have it run on boot “chkconfig denyhosts on”
  72.  
  73. One of the things DenyHosts does that takes it a step beyond the rest, is it lets you sync up with their network of other people submitting IPs of SSH brute forcers. So you will be blocking attacks before they even start, which is really nice!
  74.  
  75. I highly recommend using DenyHosts, it’s great software that really give you sound of mind about SSH Brute Force attacks. DenyHosts will run on other OS beside Linux like FreeBSD, Max OS X and Solaris.
  76.  
  77. Would love to hear other ideas or software people are using to help block SSH Brute Force attacks.
  78.     
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement