Securing SSH with tcp wrappers - Revision history

Jeff: /* /etc/hosts.allow */

Jeff — Wed, 11 Nov 2009 07:48:27 GMT

/etc/hosts.allow

←Older revision		Revision as of 07:48, 11 November 2009
Line 17:		Line 17:
	<pre>		<pre>
	ALL: localhost 127.0.0.1 ::1		ALL: localhost 127.0.0.1 ::1
-	ALL: 192.168.1.0/255.255.255.0 [fe80::]/4	+	ALL: 192.168.1.0/255.255.255.0 [fe80::]/10 [fec0::]/10

	sshd: /etc/hosts.deny.sshd : DENY		sshd: /etc/hosts.deny.sshd : DENY

Jeff at 08:09, 6 September 2009

Jeff — Sun, 06 Sep 2009 08:09:13 GMT

←Older revision		Revision as of 08:09, 6 September 2009
Line 83:		Line 83:

	Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.		Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.
		+
		+	One final note about iptales. You may be wondering why I do all this with tcp_wrappers and not with iptables. Simple, really. If I configure denyhosts to execute iptables, then first of all, the accept and drop rules lists would be really huge, and iptables stores all of its rules in memory. Also, I want my protection to be preserved across reboots. If denyhosts executes iptables directly, it doesn't store dropped IPs to disk anywhere, which means I have to rely on iptables-save, which wouldn't necessarily run in the event of a power failure. So, it's a trade off: increased disk access for reduced overall memory consumption and reliability.

	----		----
	[[User:Jeff\|Jeff]]		[[User:Jeff\|Jeff]]

Jeff at 03:13, 6 September 2009

Jeff — Sun, 06 Sep 2009 03:13:09 GMT

←Older revision		Revision as of 03:13, 6 September 2009
Line 84:		Line 84:
	Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.		Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.

		+	----
	[[User:Jeff\|Jeff]]		[[User:Jeff\|Jeff]]

Jeff at 03:10, 6 September 2009

Jeff — Sun, 06 Sep 2009 03:10:36 GMT

←Older revision		Revision as of 03:10, 6 September 2009
Line 83:		Line 83:

	Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.		Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.
		+
		+	[[User:Jeff\|Jeff]]

Jeff at 19:04, 5 September 2009

Jeff — Sat, 05 Sep 2009 19:04:46 GMT

←Older revision		Revision as of 19:04, 5 September 2009
Line 41:		Line 41:

	==/etc/hosts.deny.sshd==		==/etc/hosts.deny.sshd==
		+
		+	By default, [http://denyhosts.sf.net/ DenyHosts] appends IPs which attempt to violate your security to the end of <tt>/etc/hosts.deny</tt>. Since this file already contains a rule that denies every IP, this strategy is flawed.
		+
		+	What we will do is configure <tt>denyhosts</tt> to drop offending IPs into a different file. One more concern is that <tt>denyhosts</tt> prepends "<tt>sshd:</tt>" to each line, and this won't work for a file included in <tt>hosts.allow</tt>.
		+
		+	After installing <tt>denyhosts</tt>, edit <tt>denyhosts.conf</tt> and modify the following lines. Change
		+
		+	<pre>
		+	HOSTS_DENY = /etc/hosts.deny
		+	</pre>
		+
		+	to
		+
		+	<pre>
		+	HOSTS_DENY = /etc/hosts.deny.sshd
		+	</pre>
		+
		+	And
		+
		+	<pre>
		+	BLOCK_SERVICE = sshd
		+	</pre>
		+
		+	to
		+
		+	<pre>
		+	BLOCK_SERVICE =
		+	</pre>
		+
		+	Additionally, <tt>denyhosts</tt> can expire entries after a period, and there is a synchronization service offered, so IPs that attack other hosts on the Internet can be blocked by your computer. But do think about this as a potential denial of service before enabling this feature.

	==iptables==		==iptables==

Jeff: /* iptables */

Jeff — Thu, 03 Sep 2009 01:56:03 GMT

iptables

←Older revision		Revision as of 01:56, 3 September 2009
Line 44:		Line 44:
	==iptables==		==iptables==

-	In spite of the fact <tt>denyhosts</tt> will eventually drop offending IPs into <tt>/etc/hosts.deny.sshd</tt>, it only runs every ~~minutes~~ by default. I have seen brute force attempts on the order of dozens of attempts per minute. So, even if <tt>denyhosts</tt> will block an IP with only a few failed login attempts, the attackers might get 20 or more attempts in that first minute. Here is some iptables magic I found to limit those attempts to one every five seconds.	+	In spite of the fact <tt>denyhosts</tt> will eventually drop offending IPs into <tt>/etc/hosts.deny.sshd</tt>, it only runs every minute by default. I have seen brute force attempts on the order of dozens of attempts per minute. So, even if <tt>denyhosts</tt> will block an IP with only a few failed login attempts, the attackers might get 20 or more attempts in that first minute. Here is some iptables magic I found to limit those attempts to one every five seconds.

	<pre>		<pre>
Line 51:		Line 51:
	iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT		iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT
	</pre>		</pre>
		+
		+	Actually, this is better than only allowing one connection every five seconds. What this actually does is block the second and subsequent new connection to port 22, until no more connections come in for five seconds. So a legitimate user can retry after five seconds. An automated attack is not likely to understand this timing, and just keep trying to get back in, or give up.

Jeff at 08:15, 2 September 2009

Jeff — Wed, 02 Sep 2009 08:15:54 GMT

←Older revision		Revision as of 08:15, 2 September 2009
Line 29:		Line 29:
	I live in the United States. I work in the United States. I have never left the United States without knowing it was going to happen at least days in advance. So the likelihood of finding myself outside my country's borders and suddenly needing to SSH into my server at home is as close to nil as I can imagine. But, I do travel several times a year within my country's borders, and I don't know what IP I might be coming from. So within this file, I have listed all the IPs which are assigned inside the US.		I live in the United States. I work in the United States. I have never left the United States without knowing it was going to happen at least days in advance. So the likelihood of finding myself outside my country's borders and suddenly needing to SSH into my server at home is as close to nil as I can imagine. But, I do travel several times a year within my country's borders, and I don't know what IP I might be coming from. So within this file, I have listed all the IPs which are assigned inside the US.

-	How do you get this kind of information? I don't know how the people I got it from compiled their list, but there are a few sources on the Internet. I used to get this from a site which seems not to be in service any longer, blackholes.us. A few more sites have stepped up to fill the niche. Currently, I'm using [[http://countries.nerd.dk]]. There are other sites that offer this information as well, like [[http://software77.net/geo-ip/]]. If you search for "country by IP address," you will find more.	+	How do you get this kind of information? I don't know how the people I got it from compiled their list, but there are a few sources on the Internet. I used to get this from a site which seems not to be in service any longer, blackholes.us. A few more sites have stepped up to fill the niche. Currently, I'm using http://countries.nerd.dk. There are other sites that offer this information as well, like http://software77.net/geo-ip/. If you search for "country by IP address," you will find more.

	The files downloaded from countries.nerd.dk are in a format for a particular DNS server. I had to convert them to address/netmask format, one per line. Note that the version of ipcalc I have returns values for use in shell scripts; if I give the command <tt>ipcalc -m 10.0.0.0/8</tt> its output is <tt>NETMASK=255.0.0.0</tt>.		The files downloaded from countries.nerd.dk are in a format for a particular DNS server. I had to convert them to address/netmask format, one per line. Note that the version of ipcalc I have returns values for use in shell scripts; if I give the command <tt>ipcalc -m 10.0.0.0/8</tt> its output is <tt>NETMASK=255.0.0.0</tt>.
Line 35:		Line 35:
	<pre>		<pre>
	awk 'NR > 1 {print $1}' us.countries.nerd.dk.rbldnsd \| while read LINE ; do		awk 'NR > 1 {print $1}' us.countries.nerd.dk.rbldnsd \| while read LINE ; do
-	eval `ipcalc -m $LINE`	+	eval `ipcalc -m $LINE`
-	echo ${LINE%%/*}/$NETMASK	+	echo ${LINE%%/*}/$NETMASK
	done > /etc/hosts.allow.sshd		done > /etc/hosts.allow.sshd
		+	</pre>
		+
		+	==/etc/hosts.deny.sshd==
		+
		+	==iptables==
		+
		+	In spite of the fact <tt>denyhosts</tt> will eventually drop offending IPs into <tt>/etc/hosts.deny.sshd</tt>, it only runs every minutes by default. I have seen brute force attempts on the order of dozens of attempts per minute. So, even if <tt>denyhosts</tt> will block an IP with only a few failed login attempts, the attackers might get 20 or more attempts in that first minute. Here is some iptables magic I found to limit those attempts to one every five seconds.
		+
		+	<pre>
		+	iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set
		+	iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 5 --hitcount 2 -j DROP
		+	iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT
	</pre>		</pre>

Jeff at 08:03, 2 September 2009

Jeff — Wed, 02 Sep 2009 08:03:48 GMT

←Older revision		Revision as of 08:03, 2 September 2009
Line 5:		Line 5:
	To configure <tt>tcp_wrappers</tt>, start with a policy that denies everything by default.		To configure <tt>tcp_wrappers</tt>, start with a policy that denies everything by default.

-	~~<tt>~~/etc/hosts.deny~~</tt>~~	+	==/etc/hosts.deny==

	<pre>		<pre>
Line 13:		Line 13:
	By setting up a default deny policy in this way, you move all important processing instructions to the <tt>/etc/hosts.allow</tt> file. It is possible to add deny rules to <tt>hosts.allow</tt> by ending a line with an additional colon and the <tt>DENY</tt> command. I start by allowing access to localhost and my LAN. Notice, IPv4 networks must be specified with the full netmask, but IPv6 networks must be designated with CIDR notation.		By setting up a default deny policy in this way, you move all important processing instructions to the <tt>/etc/hosts.allow</tt> file. It is possible to add deny rules to <tt>hosts.allow</tt> by ending a line with an additional colon and the <tt>DENY</tt> command. I start by allowing access to localhost and my LAN. Notice, IPv4 networks must be specified with the full netmask, but IPv6 networks must be designated with CIDR notation.

-	~~<tt>~~/etc/hosts.allow~~</tt>~~	+	==/etc/hosts.allow==

	<pre>		<pre>
Line 25:		Line 25:
	I have included two rules to govern sshd specifically. The first denies any address listed in <tt>/etc/hosts.deny.sshd</tt>. The second only allows addresses listed in <tt>/etc/hosts.allow.sshd</tt>. The unspoken final rule is in <tt>hosts.deny</tt>, anything that hasn't matched so far will be denied. The allow line also shows an example of launching a command when the rule is triggered.		I have included two rules to govern sshd specifically. The first denies any address listed in <tt>/etc/hosts.deny.sshd</tt>. The second only allows addresses listed in <tt>/etc/hosts.allow.sshd</tt>. The unspoken final rule is in <tt>hosts.deny</tt>, anything that hasn't matched so far will be denied. The allow line also shows an example of launching a command when the rule is triggered.

-	~~<tt>~~/etc/hosts.allow.sshd~~</tt>~~	+	==/etc/hosts.allow.sshd==

	I live in the United States. I work in the United States. I have never left the United States without knowing it was going to happen at least days in advance. So the likelihood of finding myself outside my country's borders and suddenly needing to SSH into my server at home is as close to nil as I can imagine. But, I do travel several times a year within my country's borders, and I don't know what IP I might be coming from. So within this file, I have listed all the IPs which are assigned inside the US.		I live in the United States. I work in the United States. I have never left the United States without knowing it was going to happen at least days in advance. So the likelihood of finding myself outside my country's borders and suddenly needing to SSH into my server at home is as close to nil as I can imagine. But, I do travel several times a year within my country's borders, and I don't know what IP I might be coming from. So within this file, I have listed all the IPs which are assigned inside the US.

Jeff at 08:01, 2 September 2009

Jeff — Wed, 02 Sep 2009 08:01:36 GMT

←Older revision		Revision as of 08:01, 2 September 2009
Line 1:		Line 1:
-	/etc/hosts.deny	+	Just about everything on a modern Linux distro these days has <tt>tcp_wrappers</tt> support compiled in. I'll start with some basics on <tt>tcp_wrappers</tt> configuration. You should definitely also read the <tt>hosts_access(5)</tt> and <tt>hosts_options(5)</tt> man pages.
		+
		+	The basic flow of tcp_wrappers is, anything listed in <tt>/etc/hosts.allow</tt> is allowed. If it isn't found there, processing moves on to <tt>/etc/hosts.deny</tt> and anything found there is denied. Finally, anything not in either is simply allowed.
		+
		+	To configure <tt>tcp_wrappers</tt>, start with a policy that denies everything by default.
		+
		+	<tt>/etc/hosts.deny</tt>

	<pre>		<pre>
Line 5:		Line 11:
	</pre>		</pre>

-	/etc/hosts.allow	+	By setting up a default deny policy in this way, you move all important processing instructions to the <tt>/etc/hosts.allow</tt> file. It is possible to add deny rules to <tt>hosts.allow</tt> by ending a line with an additional colon and the <tt>DENY</tt> command. I start by allowing access to localhost and my LAN. Notice, IPv4 networks must be specified with the full netmask, but IPv6 networks must be designated with CIDR notation.
		+
		+	<tt>/etc/hosts.allow</tt>

	<pre>		<pre>
Line 13:		Line 21:
	sshd: /etc/hosts.deny.sshd : DENY		sshd: /etc/hosts.deny.sshd : DENY
	sshd: /etc/hosts.allow.sshd : spawn ( denyhosts )		sshd: /etc/hosts.allow.sshd : spawn ( denyhosts )
		+	</pre>
		+
		+	I have included two rules to govern sshd specifically. The first denies any address listed in <tt>/etc/hosts.deny.sshd</tt>. The second only allows addresses listed in <tt>/etc/hosts.allow.sshd</tt>. The unspoken final rule is in <tt>hosts.deny</tt>, anything that hasn't matched so far will be denied. The allow line also shows an example of launching a command when the rule is triggered.
		+
		+	<tt>/etc/hosts.allow.sshd</tt>
		+
		+	I live in the United States. I work in the United States. I have never left the United States without knowing it was going to happen at least days in advance. So the likelihood of finding myself outside my country's borders and suddenly needing to SSH into my server at home is as close to nil as I can imagine. But, I do travel several times a year within my country's borders, and I don't know what IP I might be coming from. So within this file, I have listed all the IPs which are assigned inside the US.
		+
		+	How do you get this kind of information? I don't know how the people I got it from compiled their list, but there are a few sources on the Internet. I used to get this from a site which seems not to be in service any longer, blackholes.us. A few more sites have stepped up to fill the niche. Currently, I'm using [[http://countries.nerd.dk]]. There are other sites that offer this information as well, like [[http://software77.net/geo-ip/]]. If you search for "country by IP address," you will find more.
		+
		+	The files downloaded from countries.nerd.dk are in a format for a particular DNS server. I had to convert them to address/netmask format, one per line. Note that the version of ipcalc I have returns values for use in shell scripts; if I give the command <tt>ipcalc -m 10.0.0.0/8</tt> its output is <tt>NETMASK=255.0.0.0</tt>.
		+
		+	<pre>
		+	awk 'NR > 1 {print $1}' us.countries.nerd.dk.rbldnsd \| while read LINE ; do
		+	eval `ipcalc -m $LINE`
		+	echo ${LINE%%/*}/$NETMASK
		+	done > /etc/hosts.allow.sshd
	</pre>		</pre>

Jeff at 10:15, 30 August 2009

Jeff — Sun, 30 Aug 2009 10:15:08 GMT

←Older revision		Revision as of 10:15, 30 August 2009
Line 8:		Line 8:

	<pre>		<pre>
-	ALL: localhost, 127.0.0.1, ::1	+	ALL: localhost 127.0.0.1 ::1
-	ALL: 192.168.1.0/255.255.255.0, [fe80::]/4	+	ALL: 192.168.1.0/255.255.255.0 [fe80::]/4

	sshd: /etc/hosts.deny.sshd : DENY		sshd: /etc/hosts.deny.sshd : DENY
	sshd: /etc/hosts.allow.sshd : spawn ( denyhosts )		sshd: /etc/hosts.allow.sshd : spawn ( denyhosts )
	</pre>		</pre>