Protecting against ssh brute-force attacks

[Warren Togami]

Jason L Tibbitts III wrote:
>>>>>>"NB" == Neal Becker <ndbecker2 at gmail.com> writes:
> 
> 
> NB> Unfortunately (IMO) the expiration is set to 1year by default.
> 
> I set it that high because I wanted to leave expiration enabled but
> felt that it was better to let things live there too long rather than
> violate someones security assumptions by expiring too soon.  Heck, I
> even explained that in the configuration file _and_ put this text into
> README.fedora:
> 
> By default, DenyHosts is set up to purge old block entries, but only
> after one year.  If you wish to adjust this, edit /etc/denyhosts.conf
> and look for "PURGE_DENY".

I personally think that 2 or 3 months would be a lot more reasonable a 
default than 1 year for our package.  1 year is extremely long in 
Internet time...

> 
> I sure wish the DenyHosts author would cook up a version that doesn't
> require the admin to edit the config file for every new feature that's
> added.  Currently if you update and don't put the new settings in your
> config file, the program won't start.  (So an automatic update would
> leave you without a running denyhosts daemon.)  This prevents me from
> pushing updated FC3 and FC4 packages.
> 

A simple solution to this is something like how spamassassin does it. 
The default config is shipped in one file containing large warnings "DO 
NOT EDIT".  Then a local.cf is where the user makes configuration 
changes to override the shipped config.  local.cf is %config(noreplace) 
while the shipped config is a regular file, replaced every time the 
package is updated.  This makes it safe and easy to add new config options.

And I personally think the risk of upgrading Extras to the latest 
version is small.  It isn't like SSH server will stop working after an 
update.  Only the paranoid protection might turn itself off.  Doing this 
once would be well worth gaining the above local.cf ability in a future 
update IMHO.

Warren Togami
wtogami at redhat.com