<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>edeca.net &#187; security</title>
	<atom:link href="http://edeca.net/wp/tag/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://edeca.net/wp</link>
	<description>Musings of a geek</description>
	<lastBuildDate>Sat, 10 Jul 2010 11:10:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Blocking SSH brute forcing using denyhosts</title>
		<link>http://edeca.net/wp/2010/01/blocking-ssh-brute-forcing-using-denyhosts/</link>
		<comments>http://edeca.net/wp/2010/01/blocking-ssh-brute-forcing-using-denyhosts/#comments</comments>
		<pubDate>Thu, 07 Jan 2010 23:04:44 +0000</pubDate>
		<dc:creator>David</dc:creator>
				<category><![CDATA[Computing]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://edeca.net/wp/?p=254</guid>
		<description><![CDATA[Tired of seeing repeated attempts to login to a Linux server you run?  There are a number of options, all with their own benefits and disadvantages.  The easiest way is to move the port that the SSH server runs on, perhaps to 2222 instead of 22.  However. this can be annoying behind some firewalls and [...]]]></description>
			<content:encoded><![CDATA[<p>Tired of seeing repeated attempts to login to a Linux server you run?  There are a number of options, all with their own benefits and disadvantages.  The easiest way is to move the port that the SSH server runs on, perhaps to <tt>2222</tt> instead of <tt>22</tt>.  However. this can be annoying behind some firewalls and means that you need to specify the port each time you SSH to a host.  This post looks at denyhosts, a viable alternative.<br />
<span id="more-254"></span><br />
denyhosts will monitor your authorisation log (typically <tt>/var/log/auth.log</tt>) and ban IPs that repeatedly fail to authorise as a genuine user.  It will deny future logins by adding the IP address to <tt>/etc/hosts.deny</tt>.</p>
<p>On a sensible Debian or Ubuntu install, getting denyhosts is as simple as running:</p>
<div class="codecolorer-container text twitlight" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><table cellspacing="0" cellpadding="0"><tbody><tr><td style="padding:5px;text-align:center;color:#888888;background-color:#EEEEEE;border-right: 1px solid #9F9F9F;font: normal 12px/1.4em Monaco, Lucida Console, monospace;"><div>1<br /></div></td><td><div class="text codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">$ aptitude install denyhosts</div></td></tr></tbody></table></div>
<p>denyhosts should work as soon as it is installed.  However, a few options can be tweaked to make it work nicely.  The configuration file is at <tt>/etc/denyhosts.conf</tt>.</p>
<p>Firstly, set a proper administration email by changing <tt>ADMIN_EMAIL</tt>.  The option <tt>RESET_ON_SUCCESS</tt> might also be important to you, by setting it to <tt>yes</tt> the failure count for an IP address will be reset if there is a successful login.  If you want the blocks to expire (which is more important if you use synchronisation) then you should tweak <tt>PURGE_DENY</tt> to a sensible value, for example 1 week.</p>
<p>Synchronisation is one nice feature of denyhosts that means that information on IPs that attempt SSH bruteforcing can be shared between servers.  Information about synchronisation can be read <a title="denyhosts FAQ" href="http://denyhosts.sourceforge.net/faq.html#sync">in the FAQ</a> but enabling it is as simple as uncommenting the <tt>SYNC_SERVER</tt> line.  By default, your server will share information on bruteforcers and receive it from other administrators who run denyhosts.</p>
<p>You can check how denyhosts is working by watching the logfile at <tt>/var/log/denyhosts</tt>.  You can see newly added blocks logged as a line like the below:</p>
<p><tt>new denied hosts: ['202.107.228.xxx']</tt></p>
<p>Of course, you don&#8217;t need this as you&#8217;ve already disabled SSH password logins and your firewall disables access to port 22 from anywhere except a specially crafted list of IPs.  But for 5 minutes work, it provides some peace of mind.</p>
]]></content:encoded>
			<wfw:commentRss>http://edeca.net/wp/2010/01/blocking-ssh-brute-forcing-using-denyhosts/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
