One more lockdown on ssh I have not seen mentioned recently is /etc/hosts.allow and /etc/hosts.deny. The sshd uses these. If you have some idea of where people will be ssh'ing from, you can limit the IP ranges, or domain names which can get past in. If you don't match the list, you never even get to the login prompt. For example, my home ssh only allows the IP address of my machine at work to get a login prompt.
Note that sshd (and tcpwrappers) looks at hosts.allow first and if it gets a thumbs up you get a login prompt. It then looks at hosts.deny. If you are not covered by this list, YOU GET IN! You probably want a hosts.deny file that reads:
ALL: ALL
That blocks everything except what is in hosts.allow.
If you have a lot of people coming in from very diverse IP addresses, you could play the reverse game and use the hosts.deny to just block the IP ranges you see trolling. Lot of flexibility here. Breaking in to ssh is even harder when you can't get a login prompt.
Robert E. Styma Principal Engineer (DMTS) Lucent Technologies, Phoenix Email: stymar@lucent.com Phone: 623-582-7323 FAX: 623-581-4390 Company: http://www.lucent.com Personal: http://www.swlink.net/~styma
Blocking repeat SSH attacks with IPTables
http://www.dsrtech.com/sshblock/
On Thu, 2004-10-14 at 19:10, STYMA, ROBERT E (ROBERT) wrote:
One more lockdown on ssh I have not seen mentioned recently is /etc/hosts.allow and /etc/hosts.deny. The sshd uses these. If you have some idea of where people will be ssh'ing from, you can limit the IP ranges, or domain names which can get past in. If you don't match the list, you never even get to the login prompt. For example, my home ssh only allows the IP address of my machine at work to get a login prompt.
Note that sshd (and tcpwrappers) looks at hosts.allow first and if it gets a thumbs up you get a login prompt. It then looks at hosts.deny. If you are not covered by this list, YOU GET IN! You probably want a hosts.deny file that reads:
ALL: ALL
That blocks everything except what is in hosts.allow.
If you have a lot of people coming in from very diverse IP addresses, you could play the reverse game and use the hosts.deny to just block the IP ranges you see trolling. Lot of flexibility here. Breaking in to ssh is even harder when you can't get a login prompt.
Robert E. Styma Principal Engineer (DMTS) Lucent Technologies, Phoenix Email: stymar@lucent.com Phone: 623-582-7323 FAX: 623-581-4390 Company: http://www.lucent.com Personal: http://www.swlink.net/~styma
dave wrote:
Blocking repeat SSH attacks with IPTables
dave, On this URL it times out and when I did get through it was a 404 on 'sshblock'
david
WFM (now).
--- Vladimir
David,
Sorry depends on what IP your coming from. Some networks are blocked due to hack attempts.
Below is information located at that URL.
Thanks, Dave
Blocking repeat SSH attacks with IPTables
The following information will assist you in configuring your Linux host to block repeat SSH connections that are not authorized to access your host without having to identify the source IP address.
Requirements: a) Linux host to be protected with IPTables installed b) OpenSSH on the host to be accessed c) Swatch "simple watchdog" log analyzer v3.0.8 (http://swatch.sourceforge.net) d) The configuration example below
Most Linux flavors provide IPTables and OpenSSH in the form of a package. Check with your distribution and ensure IPTables is installed before continuing this tutorial.
How it Works: The Swatch application follows or "tails" your message syslog and acts on information that is defined in the configuration file below. This implementation will enter a "drop" line to your IPTables configuration when someone attempts to login to your host with the username "root" or any username that is not defined on the host.
An example would be of the recent SSH scans on the internet utilizing the usernames "root" and "test". Below are two examples of what will be displayed in your message log that will be acted upon.
linuxhost sshd[19657]: Failed password for root from 192.168.0.150 port 34753 ssh2 linuxhost sshd[20049]: Failed password for illegal user test from 192.168.0.151 port 34749 ssh2
In this example the host IP 192.168.0.150 would be blocked as it attempted to login as the user "root" and IP 192.168.0.151 would be blocked as it attempted to login ad the user "test" which does not exist on this host.
Preliminary Configuration: A basic security measure is to not permit login to any server with the username "root". After making the changes below you will not be able to login to your host with the user root. Ensure you have a user configured for remote access which you can then "su" (superuser) to the root user.
Modify your /etc/ssh/sshd_config file to reflect the following.
PermitRootLogin no
Make sure you restart your SSH server or reboot your host for this change to take effect.
After downloading Swatch 3.0.8 (the version that worked correctly for this implementation) unpack the file and follow the "INSTALL" directions. You may have to install four PERL modules which are identified in the directions. You can download these modules from www.cpan.org.
Swatch SSH DROP Configuration: Replace the "myaddress" field with the e-mail address you wish to be alerted on when a match occurs. Also make sure your ethernet interface is "eth0" with the command /sbin/ifconfig. If not change the eth0 to whatever is defined on your host. Save the configuration to your /root/ directory as a file named sshblock.conf. You will be referencing this file in your run command.
#start
watchfor /sshd.*: Failed password for root from/ mail=myaddress,subject=Root_Login_Attempt exec /sbin/iptables -I INPUT -i eth0 -s $11 -d 0/0 -p tcp --dport 22 -j DROP
watchfor /sshd.*: Illegal user/ mail=myaddress,subject=Illegal_user_attempt exec /sbin/iptables -I INPUT -i eth0 -s $10 -d 0/0 -p tcp --dport 22 -j DROP #end Starting the SSH Block: As root from the command line of the server run the following command.
/usr/bin/swatch --config-file=/root/sshblock.conf --tail-file=/var/log/messages --restart-time=01:00am &
This statement will tail the "/var/log/messages" syslog file while looking for matches in our sshblock.conf file. The restart time is implemented to enable the re-read of the messages file in the event the logs roled for archival purposes.
If you wish this application to run every time you restart your server add the above command line to your /etc/rc.local file without the trailing "&".
Viewing your IPTables: After you receive a message in your mailbox you can confirm your IPTables block by running the following command as root.
/sbin/iptables -L
A successfull implementation would be as indicated below.
[root@linuxhost username]# /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- 192.168.0.150 anywhere tcp dpt:ssh DROP tcp -- 192.168.0.151 anywhere tcp dpt:ssh
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@linuxhost username]#
UPDATE:
The "time" restart in the command line above did not function and every week when the logs rolled swatch stopped reading the messages log.
The fix was to use this rc script and run a cron job that restarted the swatch process on each log roll.
You can use a cron that restarts twice a day as below.
0 1,13 * * * /etc/rc.d/init.d/swatchrc restart > /dev/null 2>&1
**** RC SCRIPT ********
#!/bin/sh # # swatch swatch is monitaring for logs and specific action from external # will send mail for specific users. # # chkconfig: 2345 42 42 # description: monitaring logs tool. # processname: swatch # config: /etc/swatch/swatch_secure
# Source function library. . /etc/rc.d/init.d/functions
# Source networking configuration. . /etc/sysconfig/network
# Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/bin/swatch ] || exit 0
RETVAL=0
# See how we were called. case "$1" in start) # Start daemons. echo -n "Starting Swatch: " /usr/bin/swatch --config-file=/etc/swatch/sshblock.conf --tail-file=/var/log/messages & RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/swatch ;; stop) # Stop daemons. echo -n "Shutting down Swatch: " #killproc swatch #pid=`pidof tail`
# pid_secure=`ps ax | grep secure | awk '{print $1}'` pid_message=`ps ax | grep message | awk '{print $1}'`
#kill -9 $pid > /dev/null 2>&1 # kill -9 $pid_secure > /dev/null 2>&1 kill -9 $pid_message > /dev/null 2>&1
RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/swatch ;; status) status swatch RETVAL=$? ;; restart|reload) $0 stop $0 start RETVAL=$? ;; *) echo "Usage: swatch {start|stop|restart|reload|status}" exit 1 esac
exit $RETVAL
On Fri, 2004-10-15 at 01:47, david walcroft wrote:
dave wrote:
Blocking repeat SSH attacks with IPTables
dave, On this URL it times out and when I did get through it was a 404 on 'sshblock'
david
dave wrote:
the configuration file below. This implementation will enter a "drop" line to your IPTables configuration when someone attempts to login to your host with the username "root" or any username that is not defined on the host.
Can this be modified to trigger only after three failed attempts within five minutes or so, so that nobody gets locked out because of a simple typo?
Björn Persson
Am Fr, den 15.10.2004 schrieb dave um 12:24:
Sorry depends on what IP your coming from. Some networks are blocked due to hack attempts.
Below is information located at that URL.
david
Does this behaviour of your website already shows your "tool / solution" at work? If yes, I would really be interested in to know on which basis you block my browsing attempt as like that by others. I hardly doubt there were hack attempts coming from the German provider I use.
Alexander
"d" == dave drinker@dsrtech.com writes:
d> Blocking repeat SSH attacks with IPTables d> d> http://www.dsrtech.com/sshblock/
At what point (i.e. with how many blocked IP addresses) does networking begin to slow down? Or is this not really a problem because the checks are only done at connection setup time?
--- Vladimir
Vladimir,
Good question. I just tested this and the connection does stay connected to the host until it times out.
So although it will block repeated attempts from a single host, a DDOS would be possible from hundreds of unique hosts.
The question would be how many open connections can a linux server handle before it will accept no more connections to the SSH service.
Thanks, Dave
On Fri, 2004-10-15 at 02:09, Vladimir G. Ivanovic wrote:
"d" == dave drinker@dsrtech.com writes:
d> Blocking repeat SSH attacks with IPTables d> d> http://www.dsrtech.com/sshblock/At what point (i.e. with how many blocked IP addresses) does networking begin to slow down? Or is this not really a problem because the checks are only done at connection setup time?
--- Vladimir
-- Vladimir G. Ivanovic http://leonora.org/~vladimir Palo Alto, CA 94306 +1 650 678 8014
Vladimir G. Ivanovic wrote:
"d" == dave drinker@dsrtech.com writes:
d> Blocking repeat SSH attacks with IPTables d> d> http://www.dsrtech.com/sshblock/At what point (i.e. with how many blocked IP addresses) does networking begin to slow down? Or is this not really a problem because the checks are only done at connection setup time?
As written, every incoming packet would be compared to those rules. You couls however create a new chain, "blocked" say, and configure the log watcher to add the rules to that chain. In the main "INPUT" chain you would then have a rule to jump to the chain "blocked" only on connection attempts to port 22.
Björn Persson
"bp" == Björn Persson listor1.rombobeorn@comhem.se writes:
bp> As written, every incoming packet would be compared to those rules. You bp> couls however create a new chain, "blocked" say, and configure the log bp> watcher to add the rules to that chain. In the main "INPUT" chain you bp> would then have a rule to jump to the chain "blocked" only on connection bp> attempts to port 22.
I see. Could someone more iptables-knowledgeable than I post some rules that accomplish what Björn has suggested?
--- Vladimir
-
Alexander Dalloz -
Björn Persson -
dave -
david walcroft -
Styma, Robert E (Robert) -
Vladimir G. Ivanovic