--- denyhosts-2.6.orig/debian/control +++ denyhosts-2.6/debian/control @@ -0,0 +1,26 @@ +Source: denyhosts +Section: net +Priority: optional +Maintainer: Marco Bertorello +Uploaders: Marco Nenciarini +Build-Depends: cdbs (>= 0.4.43), debhelper (>= 5.0.37.1), dpatch, python, python-central (>= 0.5) +Standards-Version: 3.7.2.0 +XS-Python-Version: current + +Package: denyhosts +Architecture: all +Depends: lsb-base (>= 3.1-10), ${python:Depends} +Conflicts: denyhosts-common, denyhosts-python2.3, denyhosts-python2.4 +Replaces: denyhosts-common, denyhosts-python2.3, denyhosts-python2.4 +XB-Python-Version: ${python:Versions} +Description: an utility to help sys admins thwart ssh hackers + DenyHosts is a python program that automatically blocks ssh + brute-force attacks by adding entries to /etc/hosts.deny. + It will also inform Linux administrators about offending + hosts, attacked users and suspicious logins. + . + Syncronization with a central server is possible too. + . + Differently from other software that do same work, denyhosts + doesn't need support for packet filtering or any other kind + of firewall in your kernel --- denyhosts-2.6.orig/debian/denyhosts.postrm +++ denyhosts-2.6/debian/denyhosts.postrm @@ -0,0 +1,22 @@ +#!/bin/sh +# postrm script for denyhosts + +set -e + +case "$1" in + purge) + rm -f /var/log/denyhosts /var/log/denyhosts.0 /var/log/denyhosts.[0-9].gz + rm -fr /var/lib/denyhosts + ;; + remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) + ;; + + *) + echo "postrm called with unknown argument \`$1'" >&2 + exit 1 + +esac + +#DEBHELPER# + +exit 0 --- denyhosts-2.6.orig/debian/rules +++ denyhosts-2.6/debian/rules @@ -0,0 +1,31 @@ +#!/usr/bin/make -f +# -*- makefile -*- +# This file was originally written by Joey Hess and Craig Small. +# +# Customized for denyhosts by Marco Bertorello and Marco Nenciarini +# + +DEB_PYTHON_SYSTEM = pycentral + +include /usr/share/cdbs/1/rules/debhelper.mk +include /usr/share/cdbs/1/class/python-distutils.mk +include /usr/share/cdbs/1/rules/dpatch.mk + +DEB_PYTHON_PRIVATE_MODULES_DIRS = /usr/share/denyhosts/DenyHosts +DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --force \ + --install-scripts=/usr/sbin \ + --install-purelib=/usr/share/denyhosts + +DEB_DH_INSTALL_SOURCEDIR := $(DEB_DESTDIR) + +DEB_INSTALL_DIRS_denyhosts := var/lib/denyhosts +DEB_INSTALL_MANPAGES_denyhosts := debian/denyhosts.8 +DEB_INSTALL_DOCS_denyhosts := debian/FAQ.html +DEB_INSTALL_EXAMPLES_denyhosts := scripts plugins + +DEB_COMPRESS_EXCLUDE := .py + +install/denyhosts:: + mv $(DEB_DESTDIR)/usr/sbin/denyhosts.py $(DEB_DESTDIR)/usr/sbin/denyhosts + mv $(DEB_DESTDIR)/usr/sbin/daemon-control-dist $(DEB_DESTDIR)/usr/share/denyhosts/denyhosts_ctl.py + install -D -m 0644 denyhosts.cfg-dist $(DEB_DESTDIR)/etc/denyhosts.conf --- denyhosts-2.6.orig/debian/watch +++ denyhosts-2.6/debian/watch @@ -0,0 +1,21 @@ +# Example watch control file for uscan +# Rename this file to "watch" and then you can run the "uscan" command +# to check for upstream updates and more. +# See uscan(1) for format + +# Compulsory line, this is a version 3 file +version=3 + +# Uncomment to examine a Webpage +# +#http://www.example.com/downloads.php denyhosts-(.*)\.tar\.gz + +# Uncomment to examine a Webserver directory +#http://www.example.com/pub/denyhosts-(.*)\.tar\.gz + +# Uncommment to examine a FTP server +#ftp://ftp.example.com/pub/denyhosts-(.*)\.tar\.gz debian uupdate + +# Uncomment to find new files on sourceforge, for debscripts >= 2.9 +#http://sf.net/denyhosts/denyhosts-(.*)\.tar\.gz +http://sf.net/denyhosts/DenyHosts-(.*)\.tar\.gz debian uupdate --- denyhosts-2.6.orig/debian/changelog +++ denyhosts-2.6/debian/changelog @@ -0,0 +1,168 @@ +denyhosts (2.6-1) unstable; urgency=high + + * New upstram release (Closes: #401795) + This release cover a security issue (CVE-2006-6301) + + -- Marco Bertorello Mon, 11 Dec 2006 14:40:35 +0100 + +denyhosts (2.5-4) unstable; urgency=low + + [ Marco Nenciarini ] + * debian/denyhosts.postrm: removed bashism + * Get rid of transitional packages denyhosts-python2.3, + denyhosts-python2.4 and denyhosts-common + + [ Marco Bertorello ] + * debian/denyhosts.prerm: added workarround to "Install fails if + previous version daemon not running" bug found in pre 2.5-3 versions + (Closes: #393461) + * debian/denyhosts.logrotate: removed minimal size of logfile for rotation + (Closes: #397452) + + -- Marco Bertorello Tue, 7 Nov 2006 16:46:24 +0100 + +denyhosts (2.5-3) unstable; urgency=low + + [ Marco Nenciarini ] + * debian/rules: add /var/lib/denyhosts directory to denyhosts + * debian/denyhosts.postrm: remove log and /var/lib/denyhosts duning purge + * debian/denyhosts.init: + + use pidfile and kill -0 to detect if daemon is runnig to avoid false + negative if python version is changed after last start. + + factorized start code + + [ Marco Bertorello ] + * Some initscript cleaning: + + does not use --exec switch with start-stop-daemon during stop + invocation because it can cause --purge doesn't work. (Closes: #387682) + + exits silently if invoked with stop and pidfile does not exists. + + exits with success errorcode if stop is required, pidfile exists + but daemon is not running. + + -- Marco Nenciarini Wed, 4 Oct 2006 11:51:39 +0200 + +denyhosts (2.5-2) unstable; urgency=low + + * Patched for a warning when --migrate is used (Closes: #384511) + * Updated README.Debian whit information for preserve hosts from purging + * Updated manpage for a reference to FAQ.html in /usr/share/doc/denyhosts + and some fix in comments on /etc/denyhosts.conf (Closes: #384452) + + -- Marco Bertorello Sat, 2 Sep 2006 13:56:39 +0200 + +denyhosts (2.5-1) unstable; urgency=low + + [ Marco Bertorello ] + * New upstream release (Closes: #377469) + * Switch to cdbs build system + * From now patches are handled with dpatch + * Build-Depend on dpatch + * New python policy (Closes: #361085, #380770) + * Modified init script to call the upstream one + * Moved private python modules under /usr/share/denyhosts to not + pollute the python sys.path namespace. + * Included FAQ.html as documentation + * Added logrotate script (thanks to Jesse Norell) + * Included README.Debian that explains how to make denyhosts working + with bastilla (thanks to Jesse Norell). + * Depends on lsb-base 3.1-10, prevoius versions are buggy + (Closes: #372090) + * Moved python from Build-Depends-Indep to Build-Depends line. Thaks + to Marc Dequènes (Duck) + + [ Marco Nenciarini ] + * Removed all files from denyhosts-python* and denyhosts-common + packages. All functionality are now in denyhosts package. + * denyhosts-python2.3, denyhosts-python2.4 and denyhosts-common are now + empty transitional packages. + * Switch debhelper compat level to 5 + * Added myself to Uploaders field + + -- Marco Nenciarini Mon, 7 Aug 2006 14:50:09 +0200 + +denyhosts (2.3-3) unstable; urgency=low + + * Temporary fixes to make this package upgradable. I hope to upload a + really fixed version ASAP. + * debian/control: Added conflicts/replaces from denyhosts-python2.3 and + denyhosts-python2.4 to denyhosts-common (<< 2.3-2) + * /etc/init.d/denyhosts: Modified to stop the daemon even if + executable is missing, this fix denyhosts-common's postrm script. + + -- Marco Bertorello Mon, 24 Apr 2006 20:02:57 +0200 + +denyhosts (2.3-2) unstable; urgency=low + + * Commented Mac OS X logfile from default configuration (Closes: #361738) + * Removed denyhosts-common dependancy from python + * Moved denyhosts executable to the python-versioned packages (Closes: #361085) + * Added override for "no manpage" warning to linda and lintian + * Updated information in copyright file + + -- Marco Bertorello Wed, 19 Apr 2006 12:54:59 +0200 + +denyhosts (2.3-1) unstable; urgency=low + + * New upstream release + - Security Fix: denied hosts weren't being re-added after purge unless + daemon was restarted after the purge. + * Fixed wrong executable name in man page (Closes: #359631) + + -- Marco Bertorello Wed, 5 Apr 2006 12:14:19 +0200 + +denyhosts (2.2-1) unstable; urgency=low + + * New upstream release + * Changed description of denyhosts package from "dummy package" to + "dependency package" (Closes: #356731) + * Added default mail destination to root@localhost + + -- Marco Bertorello Mon, 20 Mar 2006 13:30:34 +0100 + +denyhosts (2.1-2) unstable; urgency=low + + * Fixed lockfile in configuration file (Closes: #353951) + + -- Marco Bertorello Wed, 22 Feb 2006 09:56:02 +0100 + +denyhosts (2.1-1) unstable; urgency=low + + * New upstream release + * Updated denyhosts.conf to match upstream (Closes: #353821) + * Fixed python Depends for denyhosts-python2.3 and denyhosts-python2.4 + * Added some Replaces/Conflicts for smoother upgrade (Closes: #353840) + * Added watch file + + -- Marco Bertorello Tue, 21 Feb 2006 16:22:10 +0100 + +denyhosts (2.0-1) unstable; urgency=low + + * Upgraded to last upstream version + * Build-Depend on python (Closes: #351630) + + -- Marco Bertorello Mon, 6 Feb 2006 14:27:46 +0100 + +denyhosts (1.1.4-3) unstable; urgency=low + + * Added useful patch for init script from Martin T. Ranang + Now, an alternative configuration file can be specified + * From now, four packages are geneated for python version compatibility. (Closes: #350948) + denyhosts is now a dumy package for 1.1.4-2 compatibilty + denyhosts-common contains commons things for all denyhosts packages + denyhosts-python2.3 that work with Python 2.3 + denyhosts-python2.4 that work with Python 2.4 + + -- Marco Bertorello Fri, 03 Feb 2006 14:03:18 +0100 + +denyhosts (1.1.4-2) unstable; urgency=low + + * Added dependency from lsb-base (>= 3.0) + + -- Marco Bertorello Mon, 23 Jan 2006 13:07:26 +0100 + +denyhosts (1.1.4-1) unstable; urgency=low + + * Initial Release. (Closes: #338694) + + -- Marco Bertorello Thu, 12 Jan 2006 14:07:43 +0100 + --- denyhosts-2.6.orig/debian/denyhosts.prerm +++ denyhosts-2.6/debian/denyhosts.prerm @@ -0,0 +1,28 @@ +#!/bin/sh +# prerm script for denyhosts + +set -e + +case "$1" in + remove|upgrade|deconfigure) + ;; + failed-upgrade) + # workarround to bug #393461 in denyhosts version < 2.5-3 + if dpkg --compare-versions "$2" lt "2.5-3"; then + if [ ! -e /var/run/denyhosts.pid ]; then + # denyhosts isn't running then the broken + # initscript ends with an error. + # Skipping all DEBHELPER tasks + exit 0 + fi + fi + ;; + *) + echo "prerm called with unknown argument \`$1'" >&2 + exit 1 + ;; +esac + +#DEBHELPER# + +exit 0 --- denyhosts-2.6.orig/debian/denyhosts.8 +++ denyhosts-2.6/debian/denyhosts.8 @@ -0,0 +1,47 @@ +.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.36. +.TH DENYHOSTS "8" "July 2006" "DenyHosts version: 2.5" "User Commands" +.SH NAME +DenyHosts \- version: 2.5 +.SH DESCRIPTION +.B DenyHosts +is a python program that automatically blocks ssh attacks by +adding entries to /etc/hosts.deny. +.B DenyHosts +will also inform Linux administrators about offending hosts, +attacked users and suspicious logins. + +Usage: +/usr/sbin/denyhosts [\-f logfile | \fB\-\-file\fR=\fIlogfile]\fR [ \fB\-c\fR configfile | \fB\-\-config\fR=\fIconfigfile]\fR [\-i | \fB\-\-ignore]\fR [\-n | \fB\-\-noemail]\fR [\-\-purge] [\-\-migrate] [\-\-daemon] [\-\-sync] [\-\-version] +.TP +\fB\-\-file\fR: +The name of log file to parse +.HP +\fB\-\-ignore\fR: Ignore last processed offset (start processing from beginning) +.HP +\fB\-\-noemail\fR: Do not send an email report +.HP +\fB\-\-unlock\fR: if lockfile exists, remove it and run as normal +.HP +\fB\-\-migrate\fR: migrate your HOSTS_DENY file so that it is suitable for \fB\-\-purge\fR +.HP +\fB\-\-purge\fR: expire entries older than your PURGE_DENY setting +.HP +\fB\-\-daemon\fR: run DenyHosts in daemon mode +.HP +\fB\-\-sync\fR: run DenyHosts synchronization mode +.HP +\fB\-\-version\fR: Prints the version of DenyHosts and exits +.PP +Note: multiple \fB\-\-file\fR args can be processed. If multiple files are provided, \fB\-\-ignore\fR is implied +.SS "When run in --daemon mode the following flags are ignored:" +.HP +\fB\-\-file\fR, \fB\-\-purge\fR, \fB\-\-migrate\fR, \fB\-\-sync\fR, \fB\-\-verbose\fR +.SH "SEE ALSO" +Please refer to http://denyhosts.sourceforge.net/faq.html for full documentation +This file can be also found in /usr/share/doc/denyhosts/FAQ.html +.SH AUTHOR +.B DenyHosts +was written by Phil Schwartz +.PP +This manual page was written by Marco Bertorello +for the Debian project (but may be used by others). --- denyhosts-2.6.orig/debian/compat +++ denyhosts-2.6/debian/compat @@ -0,0 +1 @@ +5 --- denyhosts-2.6.orig/debian/README.Debian +++ denyhosts-2.6/debian/README.Debian @@ -0,0 +1,41 @@ + +Bastille compatibility (thanks to Jesse Norell) +=============================================== + +The default mode of operation for denyhosts (ie. adding lines to +/etc/hosts.deny) is incompatible with the tcpwrappers configuration that +bastille sets up for you. Bastille puts a default deny at the end of +hosts.allow, so hosts.deny is never consulted. + +A simple solution for me was to set: + + HOSTS_DENY = /etc/denyhosts.blocked + BLOCK_SERVICE = + +Then in my hosts.allow where I previously had: + + sshd : /24 : allow + + # Bastille: default deny + # no safe_finger for in.fingerd (prevent loops) + in.fingerd : ALL : DENY + # but everything else is denied & reported with safe_finger + ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port Denial noted %d-%h" root) & : DENY + +I changed to: + + sshd : /etc/denyhosts.blocked : deny + sshd : 192.168.10.0/24 : allow + ...etc... + +Migrate function warning +======================== + +When --migrate is used for migrate a previus denyhostized hosts.deny +file for work whit purging system, it migrate ALL your entries and this +maybe a possible security hole in your system. + +The right way to preserve some entries from purging, is to edit your +HOSTS_DENY file and comment these entries. Now you can execute --migrate +switch on your file. Re-edit the HOSTS_DENY file and de-comment the entries. + --- denyhosts-2.6.orig/debian/denyhosts.logrotate +++ denyhosts-2.6/debian/denyhosts.logrotate @@ -0,0 +1,10 @@ +/var/log/denyhosts { + create 0640 root root + missingok + weekly + rotate 7 + compress + postrotate + /etc/init.d/denyhosts restart > /dev/null + endscript +} --- denyhosts-2.6.orig/debian/pycompat +++ denyhosts-2.6/debian/pycompat @@ -0,0 +1 @@ +2 --- denyhosts-2.6.orig/debian/denyhosts.init +++ denyhosts-2.6/debian/denyhosts.init @@ -0,0 +1,88 @@ +#! /bin/sh +# +# Init script for denyhosts +# +# Author: Marco Bertorello . +# +### BEGIN INIT INFO +# Provides: denyhosts +# Required-Start: $syslog $local_fs $time +# Required-Stop: $syslog $local_fs +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# Short-Description: Start denyhosts and watch . +### END INIT INFO + + +# Using LSB funtions: +. /lib/lsb/init-functions + +set -e + +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin +DESC="DenyHosts" +NAME=denyhosts +DAEMON=/usr/bin/python +DAEMONCTL=/usr/share/denyhosts/denyhosts_ctl.py +PIDFILE=/var/run/$NAME.pid +SCRIPTNAME=/etc/init.d/$NAME +CONFIG=/etc/denyhosts.conf +FLAGS="--config=$CONFIG" + +# Function that starts the daemon/service. +d_start() { + # Gracefully exit if the package has been removed. + test -x $DAEMON || exit 5 + + if [ -e $PIDFILE ]; then + pid=$(cat $PIDFILE) + if kill -0 "$pid" > /dev/null; then + log_success_msg "$DESC already running" + return + else + log_success_msg "Removing stale PID file $PIDFILE." + rm -f $PIDFILE + fi + fi + log_daemon_msg "Starting $DESC" "$NAME" + start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --startas $DAEMONCTL -- start $FLAGS >/dev/null + log_end_msg $? +} + +# Function that stops the daemon/service. +d_stop() { + if [ -e $PIDFILE ]; then + pid=$(cat $PIDFILE) + if kill -0 "$pid" > /dev/null; then + log_daemon_msg "Stopping $DESC" "$NAME" + start-stop-daemon --stop --quiet --pidfile $PIDFILE + log_end_msg $? + else + log_failure_msg "I can't stop $DESC" "Maybe it's NOT runnig?" + rm -f $PIDFILE + fi + fi +} + +# Function that sends a SIGHUP to the daemon/service. +case "$1" in + start) + d_start + ;; + stop) + d_stop + ;; + restart|force-reload) + log_warning_msg "Restarting $DESC" + d_stop || /bin/true + sleep 1 + d_start + log_warning_msg "Done" + ;; + *) + log_warning_msg "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2 + exit 3 + ;; +esac + +exit 0 --- denyhosts-2.6.orig/debian/patches/02_FHS.dpatch +++ denyhosts-2.6/debian/patches/02_FHS.dpatch @@ -0,0 +1,35 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 01_debian_etc_patch.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: A patch for Debian System + +@DPATCH@ +diff -urNad denyhosts-2.4b~/DenyHosts/constants.py denyhosts-2.4b/DenyHosts/constants.py +--- denyhosts-2.4b~/DenyHosts/constants.py 2006-04-08 00:03:39.000000000 +0200 ++++ denyhosts-2.4b/DenyHosts/constants.py 2006-05-19 19:10:03.000000000 +0200 +@@ -36,7 +36,7 @@ + # Miscellaneous constants # + ################################################################################# + +-CONFIG_FILE = "denyhosts.cfg" # default can be overridden on cmd line ++CONFIG_FILE = "/etc/denyhosts.conf" # default can be overridden on cmd line + + DENY_DELIMITER = "# DenyHosts:" + ENTRY_DELIMITER = " | " +diff -urNad denyhosts-2.4b~/daemon-control-dist denyhosts-2.4b/daemon-control-dist +--- denyhosts-2.4b~/daemon-control-dist 2006-03-21 21:48:38.000000000 +0100 ++++ denyhosts-2.4b/daemon-control-dist 2006-05-19 19:10:03.000000000 +0200 +@@ -11,9 +11,9 @@ + #### Edit these to suit your configuration #### + ############################################### + +-DENYHOSTS_BIN = "/usr/bin/denyhosts.py" +-DENYHOSTS_LOCK = "/var/lock/subsys/denyhosts" +-DENYHOSTS_CFG = "/usr/share/denyhosts/denyhosts.cfg" ++DENYHOSTS_BIN = "/usr/sbin/denyhosts" ++DENYHOSTS_LOCK = "/var/run/denyhosts.pid" ++DENYHOSTS_CFG = "/etc/denyhosts.conf" + + + ############################################### --- denyhosts-2.6.orig/debian/patches/05_does-not-install-useless.dpatch +++ denyhosts-2.6/debian/patches/05_does-not-install-useless.dpatch @@ -0,0 +1,37 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 05_does-not-install-useless.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: No description. + +@DPATCH@ +diff -urNad denyhosts-2.5~/setup.py denyhosts-2.5/setup.py +--- denyhosts-2.5~/setup.py 2006-04-05 01:53:02.000000000 +0200 ++++ denyhosts-2.5/setup.py 2006-10-09 17:30:13.000000000 +0200 +@@ -20,17 +20,17 @@ + author="Phil Schwartz", + author_email="phil_schwartz@users.sourceforge.net", + url="http://denyhosts.sourceforge.net", +- scripts=['denyhosts.py'], ++ scripts=['denyhosts.py', 'daemon-control-dist'], + package_dir={'DenyHosts': 'DenyHosts'}, + packages=["DenyHosts"], +- data_files=[(libpath, glob("denyhosts.cfg-dist")), +- (libpath, glob("setup.py")), +- (libpath, glob("daemon-control-dist")), +- (libpath, glob("CHANGELOG.txt")), +- (libpath, glob("README.txt")), +- (scriptspath, glob("scripts/*")), +- (pluginspath, glob("plugins/*")), +- (libpath, glob("LICENSE.txt"))], ++# data_files=[(libpath, glob("denyhosts.cfg-dist")), ++# (libpath, glob("setup.py")), ++# (libpath, glob("daemon-control-dist")), ++# (libpath, glob("CHANGELOG.txt")), ++# (libpath, glob("README.txt")), ++# (scriptspath, glob("scripts/*")), ++# (pluginspath, glob("plugins/*")), ++# (libpath, glob("LICENSE.txt"))], + license="GPL v2", + ##extra_path='denyhosts', + long_description=""" --- denyhosts-2.6.orig/debian/patches/01_load-private-modules.dpatch +++ denyhosts-2.6/debian/patches/01_load-private-modules.dpatch @@ -0,0 +1,18 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 01_debian_etc_patch.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: A patch for Debian System + +@DPATCH@ +diff -urNad denyhosts-2.4b~/denyhosts.py denyhosts-2.4b/denyhosts.py +--- denyhosts-2.4b~/denyhosts.py 2006-03-11 15:45:51.000000000 +0100 ++++ denyhosts-2.4b/denyhosts.py 2006-05-19 19:09:19.000000000 +0200 +@@ -1,6 +1,7 @@ + #!/usr/bin/env python + import os + import sys ++sys.path.insert(0, '/usr/share/denyhosts') + + import DenyHosts.python_version + --- denyhosts-2.6.orig/debian/patches/04_migrate_warning.dpatch +++ denyhosts-2.6/debian/patches/04_migrate_warning.dpatch @@ -0,0 +1,39 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 04_migrate_warning.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: No description. + +@DPATCH@ +diff -urNad denyhosts-2.5~/DenyHosts/denyfileutil.py denyhosts-2.5/DenyHosts/denyfileutil.py +--- denyhosts-2.5~/DenyHosts/denyfileutil.py 2006-04-20 05:44:58.000000000 +0200 ++++ denyhosts-2.5/DenyHosts/denyfileutil.py 2006-09-06 15:11:22.000000000 +0200 +@@ -56,10 +56,24 @@ + + class Migrate(DenyFileUtilBase): + def __init__(self, deny_file): +- DenyFileUtilBase.__init__(self, deny_file, "migrate") +- self.backup() +- self.create_temp(self.get_data()) +- self.replace() ++ print "" ++ print "**** WARNING ****" ++ print "migrate switch will migrate ALL your entries in your HOSTS_DENY file" ++ print "and this can be potentially dangerous, if you have some entry that " ++ print "you won't purge" ++ print "" ++ print "If you don't understand, please type 'No' and" ++ print "read /usr/share/doc/denyhosts/README.Debian" ++ print "for more info" ++ print "" ++ response = raw_input("Are you sure that you want do this? (Yes/No)") ++ if response == "Yes": ++ DenyFileUtilBase.__init__(self, deny_file, "migrate") ++ self.backup() ++ self.create_temp(self.get_data()) ++ self.replace() ++ else: ++ print "nothing done" + + def create_temp(self, data): + try: --- denyhosts-2.6.orig/debian/patches/00list +++ denyhosts-2.6/debian/patches/00list @@ -0,0 +1,5 @@ +01_load-private-modules.dpatch +02_FHS.dpatch +03_default-config.dpatch +04_migrate_warning.dpatch +05_does-not-install-useless.dpatch --- denyhosts-2.6.orig/debian/patches/03_default-config.dpatch +++ denyhosts-2.6/debian/patches/03_default-config.dpatch @@ -0,0 +1,94 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 03_config.dpatch by +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: New patch generated from denyhosts 2.4b-1 diff.gz + +@DPATCH@ +--- DenyHosts-2.6/denyhosts.cfg-dist 2006-08-20 16:09:57.000000000 +0200 ++++ /tmp/denyhosts.cfg-dist 2006-12-11 15:28:19.000000000 +0100 +@@ -9,7 +9,7 @@ + # argument + # + # Redhat or Fedora Core: +-SECURE_LOG = /var/log/secure ++#SECURE_LOG = /var/log/secure + # + # Mandrake, FreeBSD or OpenBSD: + #SECURE_LOG = /var/log/auth.log +@@ -24,6 +24,8 @@ + # Mac OS X (v10.3 or earlier): + #SECURE_LOG=/private/var/log/system.log + # ++# Debian: ++SECURE_LOG = /var/log/auth.log + ######################################################################## + + ######################################################################## +@@ -150,7 +152,7 @@ + # Note: it is recommended that you use an absolute pathname + # for this value (eg. /home/foo/denyhosts/data) + # +-WORK_DIR = /usr/share/denyhosts/data ++WORK_DIR = /var/lib/denyhosts + # + ####################################################################### + +@@ -192,10 +194,10 @@ + # running at a time. + # + # Redhat/Fedora: +-LOCK_FILE = /var/lock/subsys/denyhosts ++#LOCK_FILE = /var/lock/subsys/denyhosts + # + # Debian +-#LOCK_FILE = /var/run/denyhosts.pid ++LOCK_FILE = /var/run/denyhosts.pid + # + # Misc + #LOCK_FILE = /tmp/denyhosts.lock +@@ -216,7 +218,7 @@ + # Multiple email addresses can be delimited by a comma, eg: + # ADMIN_EMAIL = foo@bar.com, bar@foo.com, etc@foobar.com + # +-ADMIN_EMAIL = ++ADMIN_EMAIL = root@localhost + # + ####################################################################### + +@@ -386,7 +388,7 @@ + # PLUGIN_DENY: If set, this value should point to an executable + # program that will be invoked when a host is added to the + # HOSTS_DENY file. This executable will be passed the host +-# that will be added as it's only argument. ++# that will be added as its only argument. + # + #PLUGIN_DENY=/usr/bin/true + # +@@ -398,7 +400,7 @@ + # PLUGIN_PURGE: If set, this value should point to an executable + # program that will be invoked when a host is removed from the + # HOSTS_DENY file. This executable will be passed the host +-# that is to be purged as it's only argument. ++# that is to be purged as its only argument. + # + #PLUGIN_PURGE=/usr/bin/true + # +@@ -429,7 +431,7 @@ + ####################################################################### + # + # DAEMON_LOG: when DenyHosts is run in daemon mode (--daemon flag) +-# this is the logfile that DenyHosts uses to report it's status. ++# this is the logfile that DenyHosts uses to report its status. + # To disable logging, leave blank. (default is: /var/log/denyhosts) + # + DAEMON_LOG = /var/log/denyhosts +@@ -595,7 +597,7 @@ + # to this resiliency period or greater. + # + # Resiliency is defined as the timespan between a hackers first known +-# attack and it's most recent attack. Example: ++# attack and its most recent attack. Example: + # + # If the centralized denyhosts.net server records an attack at 2 PM + # and then again at 5 PM, specifying a SYNC_DOWNLOAD_RESILIENCY = 4h --- denyhosts-2.6.orig/debian/copyright +++ denyhosts-2.6/debian/copyright @@ -0,0 +1,13 @@ +This package was debianized by Marco Bertorello on +Thu, 12 Jan 2006 14:07:43 +0100. + +It was downloaded from http://denyhosts.sourceforge.net + +Copyright Holder: 2005-2006 (C) Phil Schwartz + +License: GPL V2 + +You are free to distribute this software under the terms of +the GNU General Public License. +On Debian systems, the complete text of the GNU General Public +License can be found in /usr/share/common-licenses/GPL-2 file. --- denyhosts-2.6.orig/debian/FAQ.html +++ denyhosts-2.6/debian/FAQ.html @@ -0,0 +1,1895 @@ + + + + + + + +DenyHosts Frequently Asked Questions + + + +
+   DenyHosts +
+ + + + + + +
+

  + + +

+

+ +Home | +FAQ | +Statistics | +Links | +Features | +Download | +SourceForge + +
+ +

  + +

 + + + +

DenyHosts - Frequently Asked Questions

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 
General
Q. 1.0 What is DenyHosts?
Q. 1.1 Who should use DenyHosts?
Q. 1.2 Who wrote DenyHosts?
Q. 1.3 What steps can I take to make sshd more secure?
Q. 1.4 What was the motivation behind DenyHosts?
Q. 1.5 How does DenyHosts work?
Q. 1.6 What else does DenyHosts do?
Q. 1.7 What are the requirements for running DenyHosts?
Q. 1.8 I just installed DenyHosts and receive a SyntaxError: invalid syntax. What happened?
Q. 1.9 My server has an earlier version of Python installed, can I still run DenyHosts?
Q. 1.10 Will DenyHosts work with my sshd configuration?
Q. 1.11 This FAQ is cool... I want one! How did you create it?
Q. 1.12 The DenyHosts logo is cool, who designed it?
Q. 1.13 Where can I download DenyHosts from?
Q. 1.14 Is DenyHosts available as a Redhat or Fedora Core package?
Q. 1.15 Is DenyHosts available as a Debian package?
Q. 1.16 Is DenyHosts available for Mac OS/X?
Q. 1.17 Is DenyHosts available for Gentoo?
Q. 1.18 DenyHosts is cool, can I make a generous donation?
Q. 1.19 Are there other tools similar to DenyHosts?
 
Configuring DenyHosts
Q. 2.0 How do I configure DenyHosts?
Q. 2.1 How do I configure cron for DenyHosts use?
Q. 2.2 How can I disable hostname lookups?
Q. 2.3 Will DenyHosts work with metalog?
Q. 2.4 Will DenyHosts work with FreeBSD?
Q. 2.5 Will DenyHosts works with Solaris?
Q. 2.6 Can I use a non-standard hosts.deny file?
Q. 2.7 Can I use DenyHosts on FreeBSD using a non-standard hosts.deny file?
Q. 2.8 Can DenyHosts purge old entries added to the HOSTS_DENY file?
Q. 2.9 What time values are appropriate for PURGE_DENY, DAEMON_SLEEP, DAEMON_PURGE?
Q. 2.10 I just upgraded to 1.0.0, what do I need to do?
Q. 2.11 I just upgraded to 0.9.9 (or later) what do I need to do?
Q. 2.12 DenyHosts is unable to parse my syslog (or other) log file
Q. 2.13 Can I supply additional regular expressions to DenyHosts?
Q. 2.14 What is the difference between FAILED_ENTRY_REGEX and +USERDEF_FAILED_ENTRY_REGEX? +
Q. 2.15 Can I use DenyHosts with djb multilog?
Q. 2.16 Why isn't DenyHosts recognizing successful ssh logins?
Q. 2.17 What is the difference between DENY_THRESHOLD_INVALID, DENY_THRESHOLD_ROOT +and DENY_THRESHOLD_VALID and DENY_THRESHOLD_RESTRICTED?
Q. 2.18 Can I specify a set of users that should never be able to login?
Q. 2.19 Can I specify an alternate timestamp format for the DAEMON_LOG file?
Q. 2.20 Can failed login attempts be reset over a period of time?
Q. 2.21 Can failed login attempts be reset automatically?
Q. 2.22 Does DenyHosts support plugins?
Q. 2.23 Can TCPWRAPPERS automatically invoke DenyHosts per login attempt?
Q. 2.24 Can I dynamically specify configuration values?
 
Using DenyHosts
Q. 3.0 I've configured DenyHosts, now what?
Q. 3.1 Do I need to run DenyHosts as root?
Q. 3.2 How should DenyHosts be run?
Q. 3.3 When my logs are rotated will DenyHosts work properly?
Q. 3.4 I want to process the entire log file regardless of the last offset, how can I do this?
Q. 3.5 DenyHosts exits without producing any output, what happened?
Q. 3.6 I don't want to receive an email report of hosts added to /etc/hosts.deny.
Q. 3.7 How can I prevent a legitimate IP address from being blocked by DenyHosts?
Q. 3.8 What if SSH sometimes logs hostnames rather than IP addresses
+How can I prevent these from being blocked?
Q. 3.9 DenyHosts reports suspicious login activity for allowed hosts, how can I stop this? +
Q. 3.10 Can DenyHosts process gzipped logfiles
Q. 3.11 Can DenyHosts process bzipped (bz2) logfiles
Q. 3.12 I've just upgraded to 0.8.0 (or greater) and want to update +my HOSTS_DENY for use with PURGE_DENY +
Q. 3.13 How can I prevent more than one instance of DenyHosts from running?
Q. 3.14 Why does DenyHosts report "Error sending email"?
Q. 3.15 Can DenyHosts email reports to SMTP servers that require +authentication?
Q. 3.16 Can DenyHosts be run as a daemon (background) process?
Q. 3.17 I have additional questions, where can I get help?
Q. 3.18 I've found a bug, will you fix it?
Q. 3.19 What are all of the files in my DenyHosts WORK_DIR?
 
DenyHosts Synchronization Mode
Q. 4.0 What is synchronization mode?
Q. 4.1 What is denyhosts.net?
Q. 4.2 How does synchronization mode work?
Q. 4.3 What are the requirements for synchronization mode?
Q. 4.4 Is synchronization mode enabled by default?
Q. 4.5 How do I enable synchronization mode?
Q. 4.6 How do I configure synchronization mode?
Q. 4.7 Can I just send denied data?
Q. 4.8 Can I just receive data?
Q. 4.9 When receiving denied data will I get all denied hosts?
Q. 4.10 How do I know that DenyHosts synchronization mode is working?
Q. 4.11 I decided that I don't want to use synchronization mode, how do I disable it?
Q. 4.12 How long will retrieved ip addresses remain in my HOSTS_DENY file?
Q. 4.13 What is the cost of the synchronization service?
Q. 4.14 What information is collected from me?
Q. 4.15 How will information collected from me be used?
Q. 4.16 What is the acceptable use policy of the data that denyhosts.net provides?
Q. 4.17 I administer many commercial servers, can I run my own denyhosts.net server?
+
+

General

+ +

A. 1.0

What is DenyHosts?


DenyHosts is a Python script that analyzes the sshd server log messages to determine what hosts +are attempting to hack into your system. It also determines what user accounts are being targeted. +It keeps track of the frequency of attempts from each host.

+ +Additionally, upon discovering a repeated attack host, the /etc/hosts.deny file is updated +to prevent future break-in attempts from that host. +

+ +An email report can be sent to a system admin. + + +

Return to top

+
+ +

A. 1.1

Who should use DenyHosts?


Although DenyHosts is designed for the use by Linux system administrators, the script can be +useful to anybody running an sshd server. + +

Return to top

 +
+ +

A. 1.2

Who wrote DenyHosts?


Phil Schwartz. You can see some of the other cool projects that I have written on the +links page. + +

Return to top

 +
+ + +

A. 1.3

What steps can I take to make sshd more secure?


OpenSSH has many settings that can be adjusted in order to increase security. You may wish to refer to +OpenSSH security websites or to the many books on the subject. However, here are some things that you may +wish to consider based on my experience:

+ +

    +
  1. Disable logins to root. This can be accomplished by setting the PermitRootLogin setting +in the sshd_config file (typically, /etc/ssh/sshd_config).
    +PermitRootLogin no +

    + +

  2. Disable password logins entirely by editing the PasswordAuthentication setting. By doing so, +each user with access to the server will need to create ssh keys (which is beyond the scope of this +document).
    +PasswordAuthentication no +

    + + +

  3. Run sshd on a different port. By default, sshd runs on port 22. Most sshd hackers will only attack +port 22 so if you run sshd on a different port, the chances of being compromised are reduced dramatically. +However, by running sshd on an alternate port requires each user to be aware of this (so if your server is +accessed by many user accounts then this solution might not be feasible). To run sshd on an alternate port +simply edit the sshd_config and set the Port setting appropriately:
    +Port 9922

    + +To access yourserver running on port 9922 you would connect using the -p command line +option:
    +$ ssh -p 9922 yourserver +

    +Alternatively, you can edit your $HOME/.ssh/config file or your site-wide +/etc/ssh/ssh_config file and add an entry similar to:

    + + + + + + + + +
    Host yourserver
    Port 9922
    + +

    + +

  4. Install DenyHosts! + +
+ +Note: After saving changes to the sshd_config file you will need to restart +the sshd server for these settings to take effect + + +

Return to top

 +
+ +

A. 1.4

What was the motivation behind DenyHosts?


I run a number of Linux servers and I noticed that one of them was hacked +into. Upon browsing my sshd log I noticed that the system was targeted for some time and +eventually, somebody hacked out a password. Had I been using DenyHosts, that never would've happened +(if only I had the foresight to write this script before my system was compromised!). I then +looked at the logs of my other servers, and noticed hundreds of break-in attempts. I wanted to +thwart these hosts and future attackers from attempting to hack into my system. + + +

Return to top

 +
+ +

A. 1.5

How does DenyHosts work?


When run for the first time, DenyHosts will create a work directory. The work directory will ultimately +store the data collected and the files are in a human readable format, for each editing, if necessary. +

+ +DenyHosts then processes the sshd server log (typically, this is /var/log/secure, /var/log/auth.log, etc) +and determines which hosts have unsuccessfully attempted to gain access to the ssh server. Additionally, +it notes the user and whether or not that user is root, otherwise valid (eg. has a system +account) or invalid (eg. does not have a system account).

+ +When DenyHosts determines that a given host has attempted to login using a non-existent user account a +configurable number of attempts (this is known as the DENY_THRESHOLD_INVALID), DenyHosts will add that host +to the /etc/hosts.deny file. This will prevent that host from contacting your sshd server again.

+ +The DENY_THRESHOLD_ROOT configuration value specifies the maximum acceptable times that the +root user account can fail to login before being blocked. Typically this value is set lower than +DENY_THRESHOLD_INVALID such that root level attackers are blocked earlier than other accounts. It is also a +good practice to disable root logins within the sshd.conf file in conjunction with +this setting. By doing so, no user can login to root@your-server and their host will be blocked from attacking other user accounts +when the DENY_THRESHOLD_ROOT is reached. + +

+ + +The DENY_THRESHOLD_VALID configuration value specifies the maximum acceptable times a valid user +(ie. a user that exists in /etc/passwd) can fail to login before being blocked. This parameter +can be helpful for those with "fat fingers". Typically this value is set higher than +DENY_THRESHOLD_INVALID.

+ +Also, DenyHosts will note any successful logins that occurred by a host that has exceeded the deny_threshold. +These are known as suspicious logins and should be investigated further by the system admin. + + +

Return to top

+
+ +

A. 1.6

What else does DenyHosts do?


Please see the features page for more information. + +

Return to top

 +
+ +

A. 1.7

What are the requirements for running DenyHosts?


Please see the requirements page. + +

Return to top

 +
+ + +

A. 1.8

I just installed DenyHosts and receive a SyntaxError: invalid syntax. What happened?


If you see an error similar to this:

+ +

+File "/etc/init.d/denyhosts", line 72  
+   if args: cmd+= ' '.join(args)
+                ^
+ SyntaxError: invalid syntax
+
+

+ +Then you are using an earlier version of Python. +DenyHosts requires Python v2.3 or later. + + + +

Return to top

+
+ + +

A. 1.9

My server has an earlier version of Python installed, can I still run DenyHosts?


DenyHosts requires Python v2.3 or later. If you are using an earlier version of Python then you should +install a newer version of Python on your system. Multiple versions of Python can safely co-exist on your server +so you do not need to worry about breaking any dependencies. You should +obtain the latest version of Python and install it on your system. +Depending on the method of download, your latest Python executable is typically installed in +/usr/local/bin or /usr/bin.

+ +If you downloaded version Python v2.3, then the executable is python2.3. If you downloaded +Python v2.4 then the executable is python2.4. +

+If you will be using DenyHosts in daemon mode, then you will need to edit the +daemon-control-dist script. You will want to copy this file to "daemon-control" +such that future DenyHosts upgrades will preserve your edits.

+ +$ cp daemon-control-dist daemon-control +

+ +Assuming you installed Python v2.4 and the +executable is in /usr/bin then you will need to make the following changes to your daemon-control script:

+ + + + + + + + + + + + + + + + + +
Line #FromTo
1#!/usr/bin/env python#!/usr/bin/python2.4
18PYTHON_BIN = "/usr/bin/env python"PYTHON_BIN = "/usr/bin/python2.4"
+

+ +You may need to modify the above paths to reflect the actual installation location and version of Python that +you installed. +

+ +If you are not using DenyHosts in daemon mode then to execute DenyHosts you would do the following: +

+ +$ python2.4 denyhosts ... args... +

-or-

+$ python2.3 denyhosts ... args... + + + +

Return to top

 +
+ +

A. 1.10

Will DenyHosts work with my sshd configuration?


Most likely it will work with your configuration. +However, please see the ssh +configuration page for more details. + +

Return to top

 +
+ +

A. 1.11

This FAQ is cool... I want one! How did you create it?


Funny you should ask. I have also written +FAQtor, which +is a FAQ generaTOR. +You can see my other projects on the links page. + +

Return to top

 +
+ + +

A. 1.12

The DenyHosts logo is cool, who designed it?


The DenyHosts logo was designed by Curtis +Taylor. Many thanks to Curtis for the logo. Incidentally, Curtis also designed the +ReleaseForge logo. + +

Return to top

 +
+ +

A. 1.13

Where can I download DenyHosts from?


DenyHosts is available for +download from +SourceForge.

+ +DenyHosts is currently released in several formats by the author: + +

    +
  • Source tar.gz +
  • An RPM for Python 2.3 +
  • An RPM for Python 2.4 +
  • Source RPM +
+

+ +Additionally, DenyHosts has been re-packaged and/or is available for the following distributions: +

+

+ + +

Return to top

 +
+ + +

A. 1.14

Is DenyHosts available as a Redhat or Fedora Core package?


Various RPM packages of DenyHosts are available from +DAG Wieers repository +

+ +Additionally, DenyHosts is included in the Fedora Extras repository +repository and should be accessible via yum and/or up2date. You can view the +appropriate repository:

+ +Fedora Core 4 +
+ +Fedora Core 3 + + +

Return to top

+
+ + +

A. 1.15

Is DenyHosts available as a Debian package?


Thanks to Marco Bertorello, DenyHosts is now available as a +Debian package. +

+Falko Timme has written a "How To" document on +How to +setup DenyHosts on Debian + + +

Return to top

+
+ + +

A. 1.16

Is DenyHosts available for Mac OS/X?


DenyHosts should work under Mac OS/X. You will have to edit your denyhosts configuration file +(typically denyhosts.cfg) according to the Mac OS X version that you are running:

+ +If you are using Mac OS v10.4 or greater +

+ +If you are using Mac OS v10.3 or earlier +

+ + +

Return to top

+
+ + +

A. 1.17

Is DenyHosts available for Gentoo?


I'm not a Gentoo user so I can't provide a package for Gentoo. However, +Mike Kelly has released a +Gentoo package +for DenyHosts. + + +

Return to top

 +
+ + +

A. 1.18

DenyHosts is cool, can I make a generous donation?


Unfortunately, your +donation +can not exceed $250 US, but I'll accept it anyway :)

+ +Portions of your donation help support SourceForge and the Python Software Foundation +(and PayPal takes a piece too). Whatever money remains will no doubt be spent on +delicious beer and other less important necessities of life. + +

Return to top

+
+ + +

A. 1.19

Are there other tools similar to DenyHosts?


Yes. There are plenty of other tools that have the same goal as DenyHosts but have different +implementations. Here is a short list of those that I am aware of: + + + + +

Return to top

 +
+

Configuring DenyHosts

+ +

A. 2.0

How do I configure DenyHosts?


DenyHosts uses a simple configuration file. An example, denyhosts.cfg-dist is +supplied in the distribution. This file should be copied to denyhosts.cfg and edited +to match your system configuration. + + +

Return to top

 +
+ + +

A. 2.1

How do I configure cron for DenyHosts use?


Presumably, you will need to run DenyHosts as root (in order for DenyHosts to update /etc/hosts.deny and read +entries from /var/log), so you first must become root. Once you have either logged in as root (or +used su - root, for instance) you can then run the following command:

+ +# crontab -e +

+ +The above command will launch the crontab editor. To launch DenyHosts every 20 minutes you would then add the +following line to the crontab:

+ +0,20,40 * * * * python PATH_TO_DENYHOSTS/denyhosts.py -c +PATH_TO_DENYHOSTS_CONFIG/denyhosts.cfg

+ +You will need to substitute your site-specific paths above. As an example, if you installed DenyHosts in +/usr/local/etc and maintain your configuration file there as well, then the following crontab entry would be +appropriate: +

+ +0,20,40 * * * * python /usr/local/etc/denyhosts/denyhosts.py -c /usr/local/etc/denyhosts/denyhosts.cfg +

+ +Once you have edited the crontab you should then save it. Assuming you didn't make any errors, +the crontab will automatically install itself. +

+For more information regarding the crontab format please see the crontab man page (man 5 crontab). + + +

Return to top

+
+ +

A. 2.2

How can I disable hostname lookups?


Denyhosts v0.6.0 added a feature to lookup corresponding hostnames for ip addresses that it +reports. The default enables these lookups. If you wish to disable this behavior you can +edit your DenyHosts configuration file and set the HOSTNAME_LOOKUP parameter to +NO. The default is YES. + + +

Return to top

 +
+ + +

A. 2.3

Will DenyHosts work with metalog?


Yes. Metalog is an alternative to syslog and is the standard logging agent on (some) Gentoo +systems.

+ +Based on a patch contributed by Mike Kelly, DenyHosts 0.7 and greater will successfully parse +syslog and metalog log formats. This feature is implemented in a seemless manner so there is +no further configuration necessary in order to use DenyHosts with metalog. + + +

Return to top

+
+ + +

A. 2.4

Will DenyHosts work with FreeBSD?


Yes. According to Frencesca Smith, DenyHosts 0.7 and greater will work under FreeBSD. +DenyHosts automatically detects if you are running it under FreeBSD and if so, will append +your deny entries with " : deny". You should also update your HOSTS_DENY +configuration value to "/etc/hosts.allow" since FreeBSD does not recognize the default +"/etc/hosts.deny" file that many other vendors use.

+ +You may also wish to view these items: + +

+ +

Return to top

 +
+ + +

A. 2.5

Will DenyHosts works with Solaris?


Yes. DenyHosts has been reported to work with Solaris. However, since Solaris uses a +pam_afs format for logging messages, you will need to add this line to +your configuration file (typically, denyhosts.cfg ). + + +

Return to top

 +
+ + +

A. 2.6

Can I use a non-standard hosts.deny file?


Yes. To do so follow this procedure:

+

    +
  1. edit your HOSTS_DENY configuration value to point it to another file +such as "/etc/hosts.evil". + +
  2. edit your BLOCK_SERVICE configuration value and leave it blank + +
  3. edit your /etc/hosts.allow file and add:

    +sshd: ALL EXCEPT /etc/hosts.evil + +

  4. issue the following command:
    +touch /etc/hosts.evil +
+ +This will result in tcp_wrappers allowing all hosts to login except for those hosts +explicitly listed in + +/etc/hosts.evil.

+ +This procedure will only work on DenyHosts 0.7 and greater and was implemented based on a +patch contributed by John Meinel Jr. + + +

Return to top

+
+ + +

A. 2.7

Can I use DenyHosts on FreeBSD using a non-standard hosts.deny file?


Yes. Beginning with DenyHosts version 0.7.2 this can be accomplished by following these +steps: + +
    +
  1. edit your HOSTS_DENY configuration value to point it to another file +such as "/etc/hosts.evil". + +
  2. edit your BLOCK_SERVICE configuration value and leave it blank + +
  3. edit your /etc/hosts.allow file and add:

    +sshd : /etc/hosts.evil : deny
    +sshd : ALL : allow     + +

  4. issue the following command:
    +touch /etc/hosts.evil +
+ + +

Return to top

 +
+ + +

A. 2.8

Can DenyHosts purge old entries added to the HOSTS_DENY file?


DenyHosts v0.8.0 (and greater) offers the ability to remove old entries from the HOSTS_DENY +file (eg. /etc/hosts.deny). You must set the PURGE_DENY parameter in your +configuration file and invoke DenyHosts with the --purge command line flag:

+ +$ denyhosts.py --purge

+ +When DenyHosts is run with the --purge flag it locates entries in the HOSTS_DENY file +that have been previously timestamped by DenyHosts that have exceeed the PURGE_DENY value +using the following algorithm: + +

    +
  1. HOSTS_DENY is backed up to a file named HOSTS_DENY.purge.bak + +
  2. a temp file is created, HOSTS_DENY.purge.tmp + +
  3. the HOSTS_DENY is parsed and each non-expired entry and each non-timestamped entry + +will be written to HOSTS_DENY.purge.tmp + +
  4. each HOSTS_DENY that has expired (based on PURGE_DENY) will not be written to + +HOSTS_DENY.purge.tmp + +
  5. after all lines are parsed, if atleast one entry was not written to +HOSTS_DENY.purge.tmp (that is, no entries were expired) then +HOSTS_DENY.purge.tmp will be deleted and no further processing will be performed. + +
  6. otherwise, HOSTS_DENY.purge.tmp is moved to HOSTS_DENY (atomically-- such that +even in the case of failure, the HOSTS_DENY should always be present). In the event of a +catastrophic emergency you can manually move the HOSTS_DENY.purge.bak back to +HOSTS_DENY. + +
+

+ +The PURGE_DENY value is given as a time specification. + +

    +
  • PURGE_DENY = # an empty value disables the purge facility +
  • PURGE_DENY = 1h # purge entries older than one hour +
  • PURGE_DENY = 20m # purge entries older than twenty minutes +
  • PURGE_DENY = 31d # purge entries older than 31 days +
  • PURGE_DENY = 2w # purge entries older than two weeks +
  • PURGE_DENY = 1y # purge entries older than one year +
+

+ +Entries in HOSTS_DENY that were added before the PURGE_DENY value was defined +(for example, if you upgraded from a previous version of DenyHosts or you have just decided +to enable the purge functionality) will not be impacted by the --purge flag. +However, if you wish for these "legacy" HOSTS_DENY entries to be subject to expiration +then you will need to migrate your HOSTS_DENY data.

+ +Once PURGE_DENY has been configured to a non-empty value, DenyHosts will automatically +timestamp each record that is added to HOSTS_DENY. If PURGE_DENY is empty then +DenyHosts will not timestamp the records added to HOSTS_DENY. + + +

Return to top

+
+ + +

A. 2.9

What time values are appropriate for PURGE_DENY, DAEMON_SLEEP, DAEMON_PURGE?


Denyhosts configuration parameters that expect a unit of time as a value are specified as such:

+ +number[period] + +Where number is any integer greater than zero and period can contain one of the values in: +s, m, h, d, w, y. Where: + +

    +
  • s: seconds +
  • m: minutes +
  • h: hours +
  • d: days +
  • w: weeks +
  • y: years +
+ +

+ +If the period is blank, then seconds is assumed.

+ +Examples: +

    +
  • 1d is one day +
  • 10 is 10 seconds +
  • 10s is 10 seconds +
  • 3w is 3 weeks +
  • 30m is 30 minutes +
  • 120d is 120 days +
+ + +

Return to top

 +
+ + +

A. 2.10

I just upgraded to 1.0.0, what do I need to do?


Users upgrading from versions prior to 0.9.9 should also see this FAQ answer. +

+ +DenyHosts 1.0.0 adds two additional required configuration parameters that must be defined. You can +refer to the denyhosts.cfg-dist file for sample usage of the new DENY_THRESHOLD_ROOT and +DENY_THRESHOLD_VALID parameters. These parameters are also documented. + + + +

Return to top

+
+ + +

A. 2.11

I just upgraded to 0.9.9 (or later) what do I need to do?


If you are upgrading to v0.9.9 (or later) from DenyHosts 0.8.0 through 0.9.8 and you have +previously set PURGE_DENY in your configuration file then you must do the +following:

+ +To upgrade your HOSTS_DENY file to the new timestamped format you must first invoke +denyhosts with the --upgrade099 flag.

+ +$ denyhosts.py --upgrade099

+ +Versions between 0.8.0 and 0.9.8 added a comment-timestamp (when PURGE_DENY was set) that +caused tcp_wrappers to report an error. DenyHosts 0.9.9 fixes this problem by upgrading the +entries of HOSTS_DENY to an alternative format which should prevent errors from being +reported.

+ +If you are upgrading from a version prior to 0.8.0 or have not yet set PURGE_DENY +then there is no need to upgrade. If you wish to now set PURGE_DENY for the first time then +you should run DenyHosts with the --migrate flag rather than the +--upgrade099 flag. + + +

Return to top

+
+ + +

A. 2.12

DenyHosts is unable to parse my syslog (or other) log file


New to version 0.9.9 (and greater), DenyHosts allows the end user to supply custom regular +expressions that may be necessary to parse unusual SECURE_LOG files. This feature +requires regular expression knowledge. If you are unsure how to parse your particular log +file please feel free to email me +directly for regex support.

+ +The following regex entries can be overridden in your denyhosts.cfg file:

+ +

    +
  • SSHD_FORMAT_REGEX +
  • FAILED_ENTRY_REGEX +
  • FAILED_ENTRY_REGEX2 +
  • FAILED_ENTRY_REGEX3 +
  • FAILED_ENTRY_REGEX4 +
  • FAILED_ENTRY_REGEX5 +
  • FAILED_ENTRY_REGEX6 +
  • SUCCESSFUL_ENTRY_REGEX +
+ +

Note that each of these configuration parameters are completely optional. +If a value is not configured within this file then the default value will be used. +The defaults can be seen by viewing the DenyHosts/regex.py file within the +source distribution.

+ +When providing a custom regular expression make sure that you only include the +portions between the opening and closing triple-quotes (ie. '''this value'''). +That is, if you are modifying the SSHD_FORMAT_REGEX which appears in DenyHosts/regex.py as:

+ +SSHD_FORMAT_REGEX = re.compile(r""".* (sshd.*:|\[sshd\]) (?P<message>.*)""")

+ +You would enter the following in your denyhosts.cfg file:

+ +SSHD_FORMAT_REGEX = .* (sshd.*:|\[sshd\]) (?P<message>.*)

+ +You could then customize the above regex as you see fit based on your log file's particular +format. You can use a tool such as Kodos (also +developed by Phil Schwartz) to test your custom +regex patterns against your log contents.

+ +If I do provide you with a custom regex that helps DenyHosts perform for your particular +configuration, please consider making a +donation. + + +

Return to top

+
+ + +

A. 2.13

Can I supply additional regular expressions to DenyHosts?


Yes. New in v1.1.5, DenyHosts adds the ability for the user to specify additional +regular expressions that can be used to locate possible break-in attempts. The +USERDEF_FAILED_ENTRY_REGEX can be specified repeatedly. Each value must +contain a single regular expression that includes a host regular expression group and +optionally a user group. It is assumed that the end user is familiar with regular +expressions in order to take advantage of this feature.

+ +Examples:

+ +USERDEF_FAILED_ENTRY_REGEX=break in attempt for (?P.*) from (?P.*)
+USERDEF_FAILED_ENTRY_REGEX=break in attempt from (?P.*)

+ +If multiple USERDEF_FAILED_ENTRY_REGEX are supplied they are evaluated in the order +that they appear in the configuration file. Additionally, this parameter is evaluated +after the built-in regular expressions (ie. FAILED_ENTRY_REGEX, FAILED_ENTRY_REGEX2, ...). + + +

Return to top

+
+ +

A. 2.14

What is the difference between FAILED_ENTRY_REGEX and +USERDEF_FAILED_ENTRY_REGEX? +


FAILED_ENTRY_REGEX, FAILED_ENTRY_REGEX2, FAILED_ENTRY_REGEX3 ... refer to the +regular expressions that DenyHosts uses in order to recognize hackers. Under most +circumstances these are adequate. However, if DenyHosts is unable to parse your logfile +then these regular expressions should be overridden in your +configuration file.

+ +The optional USERDEF_FAILED_ENTRY_REGEX +configuration parameter can be specified in order to add additional +regular expressions to DenyHosts which may allow it to identify more hacker attempts +based on your particular configuration. Therefore, these regular expressions do not +replace the non-USERDEF versions and are intended to extend DenyHosts hacker +recognition. + + +

Return to top

+
+ + +

A. 2.15

Can I use DenyHosts with djb multilog?


DenyHosts v0.9.9 (and greater) supports DJB's multilog output format. +The output format appears as:

+ + +@4000000042f4e1d3057febbc Failed password for invalid user network ...
+@4000000042f4e1d305800ee4 Connection closed by ... +

+ +In order for DenyHosts to easily parse this log format, simply edit your denyhosts.cfg file +and add the following line:

+ +SSHD_FORMAT_REGEX = @.*? (?P<message>.*)

+ + +

Return to top

+
+ +

A. 2.16

Why isn't DenyHosts recognizing successful ssh logins?


Unfortunately, all log files are not created equally. Depending on the format of your log file, +DenyHosts may not be able to process all of the entries. You can supply a suitable +custom regular expression in your configuration file.

+ +For instance, if your log file has the following entry: +

+

+error: PAM: authentication error for SOME_VALID_USERNAME from 192.168.1.1
+
+ +Then adding this to your configuration file should resolve the +issue. + + +

Return to top

 +
+ + +

A. 2.17

What is the difference between DENY_THRESHOLD_INVALID, DENY_THRESHOLD_ROOT +and DENY_THRESHOLD_VALID and DENY_THRESHOLD_RESTRICTED?


DENY_THRESHOLD_INVALID - applies to non-existent (aka invalid accounts that do not appear in +/etc/passwd) user accounts

+ +DENY_THRESHOLD_ROOT - applies to login attempts to the root user account

+ +DENY_THRESHOLD_VALID - applies to existent user accounts (those that exist +within /etc/passwd)

+ +DENY_THRESHOLD_RESTRICTED - (New in v2.1) Applies to the optionally defined usernames in +WORK_DIR/restricted-usernames. See restricted users for more +details.

+ +Typically, the value for DENY_THRESHOLD_VALID should be larger than the +DENY_THRESHOLD_INVALID value and the value for DENY_THRESHOLD_ROOT should be less +than DENY_THRESHOLD_INVALID. That is:
+ +DENY_THRESHOLD_ROOT < DENY_THRESHOLD_INVALID < DENY_THRESHOLD_VALID +

+DENY_THRESHOLD_RESTRICTED should typically be the same as DENY_THRESHOLD_ROOT. +

+ +As an example, consider a system "myhost" that has a valid user "foo" and an invalid user +"bar" (that is, "foo" exists in the /etc/passwd file on "myhost", whereas "bar" does not). +If a user at host 1.1.1.1 attempts to login to "foo@myhost" more than +DENY_THRESHOLD_VALID then 1.1.1.1 will be blocked (added to the HOSTS_DENY +file). However, if a user at 2.2.2.2 had attempted to login to "bar@myhost" then that IP +address would be blocked after DENY_THRESHOLD_INVALID attempts. If a user at 3.3.3.3 +attempted to login to multiple accounts ("foo" and "bar") then the IP address would be +blocked as soon as either threshold was exceeded.

+ +Therefore, at most, a malicious user can attempt to gain access to your system +DENY_THRESHOLD_INVALID + DENY_THRESHOLD_VALID times before being +added to HOSTS_DENY. + + +

Return to top

+
+ + +

A. 2.18

Can I specify a set of users that should never be able to login?


New in v2.1. DenyHosts now allows you to create a file, restricted-usernames in the +DenyHosts WORK_DIR. The contents of this optional file should contain one username +per line. Each username listed is considered to be a restricted account or simply, any +username that satisfies these scenarios:

+ +

    +
  • An account that does not allow logins (such as lpd) +
  • An account that should never login via ssh (such as mysql) +
  • A ficticious username that often is associated with hackers (such as toor) +
+

+ +Any username listed in the restricted-usernames file will be subject to the +DENY_THRESHOLD_RESTRICTED configuration setting (by default this will be set +to DENY_THRESHOLD_ROOT).

+ +To aid in creating a suitable restricted-usernames file there are currently 2 scripts in +the scripts subdirectory: + +

    +
  • restricted_from_passwd.py will parse the /etc/passwd +file, find each of the usernames that have /sbin/nologin, /sbin/halt +or /sbin/shutdown shells and output them to the console. You can either cut-and-paste +these into restricted-usernames or redirect the output to this file. + +
  • restricted_from_invalid.py will parse DenyHosts invalid login attempts file and +find the most frequently attacked user accounts on your system. You must provide your +WORK_DIR setting on the command line so that this script can locate the necessary file to +parse, namely users-invalid. You can also specify the number of usernames to display, +the default is 10. + +
+ +

+Note: This restricted-usernames file is loaded at start-up time so any +changes you make while the DenyHosts daemon is still running will not take effect until +you restart the daemon. + + +

Return to top

+
+ + +

A. 2.19

Can I specify an alternate timestamp format for the DAEMON_LOG file?


As of DenyHosts v1.0.1, yes!

+ +By default, DenyHosts (when run in daemon mode) will timestamp log entries with an ISO8061 timestamp +format. This may be undesirable for some users and may not blend easily with 3rd party packages such as +log_check, log_watch, etc). To specify an alternate timestamp format, simply set the +DAEMON_LOG_TIME_FORMAT parameter in the denyhosts.cfg file. It is recommended that you refer to the +man page for strftime for possible values.

+ +A typical alternative timestamp may be Jan 1 22:05:59. To set the DAEMON_LOG_TIME_FORMAT to +this format, insert the following line in your denyhosts.cfg file:

+ +DAEMON_LOG_TIME_FORMAT = %b %d %H:%M:%S + + +

Return to top

+
+ + +

A. 2.20

Can failed login attempts be reset over a period of time?


DenyHosts will automatically block hosts that fail to successfully login after a user configured +threshold is exceeded. Starting with version 1.1, DenyHosts will automatically +reset the failed login attempts to 0 when a host fails to login and the previous failed attempt from +this same host exceeds the respective AGE_RESET_* value.

+ +The AGE_RESET_* parameters are optional. If not provided, failed login attempts per host will +not be reset automatically (this is the behavior in previous versions of DenyHosts). The following +parameters can be specified in the DenyHosts configuration file:

+ +

    +
  • AGE_RESET_VALID - applies to login attempts to existant users (those that appear in /etc/passwd) with the exception of the root user +
  • AGE_RESET_ROOT - applies to the root user account +
  • AGE_RESET_INVALID - applies to non-existant users (those that do not appear in /etc/passwd) +
  • AGE_RESET_RESTRICTED - (new in 2.1) applies to usernames that are optionally defined +in WORK_DIR/restricted-usernames (typically, usernames that appear in /etc/passwd that should not +be able to login, such as "lpd" or "apache") +
+ +If desired, these parameters and their values can be specified in the +DenyHosts configuration file.

+ + +

Return to top

+
+ + +

A. 2.21

Can failed login attempts be reset automatically?


Although the AGE_RESET_* factility may be ideal for most situations, +DenyHosts v2.1 introduces the optional parameter RESET_ON_SUCCESS. + +DenyHosts will automatically block hosts that fail to successfully login after a user configured +threshold is exceeded. If RESET_ON_SUCCESS = yes then the +failed login attempts will be reset to 0 for the respective ip address if a user successfully logs +in from this ip address. The default is RESET_ON_SUCCESS = no + + +

Return to top

 +
+ + +

A. 2.22

Does DenyHosts support plugins?


In v1.1.0 and greater, DenyHosts introduces support for plugin applications to be run when DenyHosts adds +a new entry to the HOSTS_DENY file and when an entry is purged from HOSTS_DENY.

+ +Two optional configuration parameters exist to support plugins. They are:

+ +

    +
  • PLUGIN_DENY - specifies the program to be run when a host is blocked by DenyHosts +
  • PLUGIN_PURGE - specifies the program to be run when a host is no longer blocked by DenyHosts +
+ +Note: program can be any executable (script, application, etc...).

+ +Each of the executed programs will receive the host (typically the IP address) that was denied/purged as +it's sole argument. + +

Return to top

+
+ + +

A. 2.23

Can TCPWRAPPERS automatically invoke DenyHosts per login attempt?


Apparently, yes! Thanks to Tilo Winkler for providing an example of +spawning DenyHosts +from TCPWRAPPERS. + + +

Return to top

 +
+ + +

A. 2.24

Can I dynamically specify configuration values?


Starting with DenyHosts version 2.2, you can now specify all or part of a configuration +value to use an environment variable setting.

+ +To specify a dynamically substituted value you specify the portion of the value you +would like to replace using the syntax $[ ... ] where the ... maps to an +environment variable name. + +

+Notes: the environment variable must be specified in UPPERCASE and will be retrieved from the +local environment when DenyHosts is started. Therefor, if you make a change to the underlying +environment variable that you would like DenyHosts to use then you must restart DenyHosts. +

+ +You may wish to do this, for instance, if you run DenyHosts on several servers and would like +to use the same configuration file on each. In this case, you may want to dynamically +specify the server name for the SMTP_SUBJECT option.

+ +SMTP_SUBJECT = DenyHosts report - $[HOSTNAME] +

+If the systems HOSTNAME environment variable is defined as foo.bar.com then +the SMTP_SUBJECT will be interpreted as: +

+SMTP_SUBJECT = DenyHosts report - foo.bar.com +

+ +All DenyHosts configuration values can be specified to include environment variables in this way. + + +

Return to top

+
+

Using DenyHosts

+ + +

A. 3.0

I've configured DenyHosts, now what?


If you have several log files (eg. in your /var/log directory you have ssh server logs with .1, +.2, ... .n) due to log rotation then it is best to process the old files first.

+ +This can be done by invoking DenyHosts with the --file= flag:
+$ python denyhosts.py --file=/var/log/secure.log.1

+ +Additionally, you can process several files at once:
+$ python denyhosts.py --file=/var/log/secure.log.1 --file=/var/log/secure.log.2 .... --file=/var/log/secure.n

+ +Note: You must run DenyHosts as root so that it can read /var/log/ files and update the +/etc/hosts.deny file + + +

Return to top

+
+ +

A. 3.1

Do I need to run DenyHosts as root?


If you are running DenyHosts in daemon mode then yes you must run DenyHosts as root. +

+ +In all other cases, such as running DenyHosts from cron then technically speaking, no. +However, in order to run DenyHosts as non-root you must ensure that you have read-permissions +on the /var/log/ sshd server logs. Alternatively, you can copy them to a directory where you do have read-permissions. +

+ +Also, in order for DenyHosts to block hosts, it needs write permissions for the /etc/hosts.deny file. DenyHosts will +gladly run without being able to update this file. In this mode, the hosts that should be blocked are written to stdout +(in a form suitable for pasting into /etc/hosts.deny). Also, you can use an alternate HOSTS_DENY +file (other than /etc/hosts.deny) which may not require root priviledges. + + +

Return to top

+
+ +

A. 3.2

How should DenyHosts be run?


Version 0.9.0 introduces daemon mode support. If you run DenyHosts with the --daemon +flag, then DenyHosts will run constantly in the background. See the previous link for more details. +

+ +In addition to the deamon mode, DenyHosts can also be run periodically from the command line. If you do not wish to +use the daemon mode, then I recommend that DenyHosts be run from cron on a routine basis. +DenyHosts is fairly lightweight and does not put an excessive drain on system resources. DenyHosts initially checks +to see if the sshd log has changed in size and if it determines that it hasn't, then it exits without further +processing. If the log has changed, DenyHosts only examines the portion that has changed.

+ +The interval between DenyHosts runs is left up to the user. Personally, I run DenyHosts every 10 minutes. + + +

Return to top

+
+ + +

A. 3.3

When my logs are rotated will DenyHosts work properly?


Yes. DenyHosts checks the first line of your sshd server log file and the file size. It then compares these +values to the previous invocation of DenyHosts.

+ +

    +
  • If the first line is different, then DenyHosts will process the entire +log file (since it is assumed that the log has been rotated). + +
  • If the first line is the same it then compares the file size to the last runs offset. +
      +
    • If they are the same, then DenyHosts assumes that there are no changes and exits. +
    • If the current file size is greater then the last offset, then the +log file is processed from the last offset. +
    + +
  • When DenyHosts exits it stores the first line of the processed log file and the file offset into the offset +file (which is located in the WORK_DIR that is defined in your denyhosts.cfg file). +
+ +

Return to top

 +
+ +

A. 3.4

I want to process the entire log file regardless of the last offset, how can I do this?


Although I'm not sure why you'd want to do this, DenyHosts provides the --ignore command line argument for +this purpose. + +

Return to top

 +
+ +

A. 3.5

DenyHosts exits without producing any output, what happened?


Since DenyHosts is intended to run from cron, by default it therefor tries to minimize output. +In general, only error conditions are output.

+However, if you'd like to see more details of what it's doing, you can supply the --verbose flag on the command +line.

+ +Alternatively, if you'd like to see all of the gory details of what DenyHosts is doing, you can invoke DenyHosts +with the --debug flag. It is recommened, when reporting a bug that you supply the output from +running DenyHosts with the --debug flag. + +

Return to top

+
+ +

A. 3.6

I don't want to receive an email report of hosts added to /etc/hosts.deny.


That's not a question.

+Seriously, though, if you would like to disable the email reports you can either edit the denyhosts.cfg +file (and set the admin_email value to nothing) or run the script with the --noemail flag supplied.

+ +# in your denyhosts.cfg file:
+ADMIN_EMAIL=

+ +# command line:
+$ python denyhosts.py --noemail + + +

Return to top

+
+ + +

A. 3.7

How can I prevent a legitimate IP address from being blocked by DenyHosts?


Since it is quite possible for a user to mistype their password repeatedly it may be desirable to +have DenyHosts prevent specific IP addresses from being added to /etc/hosts.deny. To address +this issue, create a file named allowed-hosts in the WORK_DIR. Simply add an IP +address, one per line. Any IP address that appears in this file will not be blocked. +

+Additionally, as of v1.0.3, a valid hostname can also be placed in the allowed-hosts file. +For each hostname appearing in this file, the IP address will be resolved and any ssh connections +that match either this hostname or this resolved IP address will not be blocked. + + +# this is a comment line
+# the following line prevents DenyHosts from blocking IP address 1.1.1.1
+1.1.1.1
+# The following lines prevent IP addresses 1.1.1.2 and 1.1.1.3 from being blocked
+1.1.1.2
+1.1.1.3
+#
+# The first 3 parts of the IP address must be provided (eg. 1.2.3.)
+# The last part of the IP address can be a wildcard.
+# The wildcard can be given with an asterisk -or- as a range.
+#
+# This line prevents all IP address in the 1.1.1 network from being blocked
+# 1.1.1.*
+#
+# This line prevents IP addresses in the range 1.1.1.6 to 1.1.1.23 from being blocked
+# 1.1.1.[6-23]
+# the following line prevents DenyHosts from blocking the host foo
+foo
+ + +

Return to top

+
+ + +

A. 3.8

What if SSH sometimes logs hostnames rather than IP addresses
+How can I prevent these from being blocked?


If your versions and configuration of sshd and tcp_wrappers sometimes/always log hostnames +rather than IP addresses then you can have DenyHosts attempt to resolve each IP address in the +allowed-hosts file in order to determine the corresponding hostname. In doing so, any host +that matches either this resolved IP address or the hostname will not be blocked. +

+To enable this feature, you must specify the following option in your configuration file:

+ +ALLOWED_HOSTS_HOSTNAME_LOOKUP=yes +

+Note: Depending on the number of entries in your allowed-hosts file, this +operation can be network intensive but only at DenyHosts startup. Therefor, It is recommended +that this option only be used when running DenyHosts in daemon mode since +this initialization only occurs once. Additionally, if hostnames never appear in your +SECURE_LOG then you shouldn't set this parameter at all (or set it to no):

+ +ALLOWED_HOSTS_HOSTNAME_LOOKUP=no + + +

Return to top

+
+ +

A. 3.9

DenyHosts reports suspicious login activity for allowed hosts, how can I stop this? +


In DenyHosts v0.6.0, a new configuration parameter SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS was +added to address this issue. You can refer to the included denyhosts.cfg-dist file +for more information. +

+This parameter can be set to YES or NO. The default value is YES. If you wish to +change +the default behavior and only report suspicious login activity from unknown ip addresses, set this +value to +NO.

+ +Regardless of whether this value is YES or NO, if the suspicious login did not originate from +a known allowed-hosts the activity will always be reported. That is, this +parameter only applies to ip addresses in your allowed-hosts file. + +

Return to top

+
+ + +

A. 3.10

Can DenyHosts process gzipped logfiles


Yes. DenyHosts v0.7.0+ will automatically detect whether a log supplied with the -f +parameter is gzipped (based on the .gz file suffix). Some system configurations compress rotated logs using +gzip (eg. /var/log/messages when rotated can be named /var/log/messages.1.gz). To process a gzipped +logfile simply provide the fullpath on the command line using the -f flag (just as if it were a non-gzipped +file):

+ +$ denyhosts.py -f /var/log/secure.log.1.gz

+ +When DenyHosts encounters a gzipped logfile it will automatically open it (without uncompressing it on disk) and +process it. + + +

Return to top

+
+ + +

A. 3.11

Can DenyHosts process bzipped (bz2) logfiles


Yes. DenyHosts v0.8.0+ will automatically detect whether a log supplied with the -f +parameter is bzipped (based on the .bz2 file suffix). Some system configurations compress rotated logs using +bzip2 (eg. /var/log/messages when rotated can be named /var/log/messages.1.bz2). To process a bzipped +logfile simply provide the fullpath on the command line using the -f flag (just as if it were a non-bzipped +file):

+ +$ denyhosts.py -f /var/log/secure.log.1.bz2

+ +When DenyHosts encounters a bzipped logfile it will automatically open it (without +uncompressing it on disk) and process it. + + +

Return to top

+
+ + +

A. 3.12

I've just upgraded to 0.8.0 (or greater) and want to update +my HOSTS_DENY for use with PURGE_DENY +


Note:
+You may wish to refer to setting the PURGE_DENY configuration parameter for information +related to this entry. +

+To instruct DenyHosts to migrate your HOSTS_DENY for use with PURGE_DENY invoke DenyHosts with the +--migrate flag:

+ +$ denyhosts.py --migrate

+ +Note:
+ +Using the --migrate flag without previously defining a value for the PURGE_DENY +parameter will result in an error condition such that DenyHosts will exit immediately.

+ +When DenyHosts is run with the --migrate flag it locates entries in the +HOSTS_DENY file that have not been been previously timestamped by DenyHosts and +timestamps them (using the current time). The following algorithm is used to update the +HOSTS_DENY file:

+ +

    +
  1. HOSTS_DENY is backed up to a file named HOSTS_DENY.migrate.bak +
  2. a temp file is created, HOSTS_DENY.migrate.tmp +
  3. the HOSTS_DENY is parsed and each entry that is commented or is a blank link will be written to +HOSTS_DENY.migrate.tmp as-is. +
  4. otherwise, each HOSTS_DENY entry will have a comment added in the form of # DenyHosts: +timestamp and then written to HOSTS_DENY.migrate.tmp +
  5. after all lines are parsed, HOSTS_DENY.migrate.tmp is moved to HOSTS_DENY (atomically-- such that +even in the case of failure, the HOSTS_DENY should always be present). In the event of a catastrophic +emergency you can manually move the HOSTS_DENY.migrate.bak back to HOSTS_DENY. +
+

+ +Note:
+ +If you have a manually added specific hosts to HOSTS_DENY (without the use of +DenyHosts, for instance) then you may wish to edit HOSTS_DENY and remove the timestamp +data that was appended to the line by the --migrate function. You may also wish to do +this for any entry that you never want DenyHosts to remove. Any timestamped entry +will automatically be removed by DenyHosts when it is invoked with the --purge flag +subject to the PURGE_DENY value. Refer to the purge section for +more details. + + +

Return to top

+
+ +

A. 3.13

How can I prevent more than one instance of DenyHosts from running?


DenyHosts v0.8.0 (and greater) uses the configuration parameter LOCK_FILE which should +point to some unique path. When DenyHosts is run initially it will attempt to create this +file and record it's process id (pid). If it already exists, DenyHosts will exit indicating +that DenyHosts is still running and the pid of the previous process. Upon exit, DenyHosts +will delete the LOCK_FILE so that it will not interfere with other instances (such as +another instance run from cron).

+ +In the event that something goes awry (or if you savagely killed the current DenyHosts +process before it had a chance to delete the LOCK_FILE itself) there is a chance that +the LOCK_FILE will not get deleted. If this occurs, you can manually clear the +LOCK_FILE by invoking DenyHosts with the --unlock flag:

+ +$ denyhosts.py --unlock

+ + +

Return to top

+
+ + +

A. 3.14

Why does DenyHosts report "Error sending email"?


Depending on your particular email server you may see an error message such as:

+ + +Error sending email
+{'foo@localhost': (504, '<DenyHosts>: Sender address rejected: need +fully-qualified address')}

+ +If you do receive this error message simply edit your configuration file and enter a fully +qualified email address for the SMTP_FROM parameter. For instance:

+ +SMTP_FROM = DenyHosts <nobody@yourdomain.com> + + +

Return to top

+
+ + +

A. 3.15

Can DenyHosts email reports to SMTP servers that require +authentication?


Beginning with version 1.1.1, DenyHosts can email reports to SMTP servers that require +username/password authentication. If your SMTP server requires authentication you will +need to set the following parameters in your denyhosts.cfg file:

+ +

    +
  • SMTP_USERNAME - your SMTP username. +
  • SMTP_PASSWORD - your SMTP password. +
+ + +

Return to top

 +
+ + +

A. 3.16

Can DenyHosts be run as a daemon (background) process?


DenyHosts v0.9.0 (and greater) introduces daemon support. When launched with the --daemon flag, DenyHosts +will run in the background and constantly monitor your SECURE_LOG for new activity:

+ +$ denyhosts.py --daemon + +Note:
+The following command line flags are ignored when --daemon is used: --file, --verbose, --migrate, +--purge

+ +Note:
+The daemon mode must be invoked as superuser (root)

+ +There are 3 optional configuration settings specific to daemon mode. You can refer to the included +denhosts.cfg-dist file for sample usage. These new values are:

+ +

    + +
  1. DAEMON_LOG: specifices the path to which DenyHosts should record activity. The default is +/var/log/denyhosts + +
  2. DAEMON_SLEEP: the amount of time that DenyHosts will pause between checking +for new activity in your SECURE_LOG. The default is 30s + +
  3. DAEMON_PURGE: the amount of time that DenyHosts should attempt to +purge historical entries from your HOSTS_DENY file. If left blank, purging will be +disabled. The default is 1h + +
+ +

+ +For your convenience there is a python script daemon-control-dist that is located in the DenyHosts +distribution. You should copy this file to daemon-control and edit the 3 variables at the top to match your +environment. If you wish you can place this in your /etc/init.d directory.

+ +You can then invoke this script to control the DenyHosts daemon: + +

    +
  • daemon-control start - stats DenyHosts in daemon mode + +
  • daemon-control stop - cleanly stops the DenyHosts daemon + +
  • daemon-control restart - stop and start the daemon + +
  • daemon-control debug - Instructs the daemon to toggle between the debug and normal log output + +
  • daemon-control status - display the state of the daemon + +
+ +The start and restart commands (as of v0.9.6) can also accept command line options. For instance to +load an alternate configuration file, you can do the following:

+ +$ daemon-control start --config=test.cfg

+ +To restart the above example in debug mode:

+ +$ daemon-control restart --config=test.cfg --debug

+ + +

Return to top

+
+ +

A. 3.17

I have additional questions, where can I get help?


You can subscribe to the DenyHosts Mailing List + +

+or +

+ +You can contact me directly. + +

Return to top

+
+ + +

A. 3.18

I've found a bug, will you fix it?


Bug? That's "unpossible".

+ +In the rare and highly unlikely event that you do find what you think might be considered a bug (even though it's +really a feature) you can report it +at Sourceforge.

+ + +When reporting a bug, please try to include the output from DenyHosts when invoking it with the --debug flag:
+$ denyhosts.py --debug

+ +Alternatively, You can send the bug report to my Sourceforge +email address. + +

Return to top

+
+ + +

A. 3.19

What are all of the files in my DenyHosts WORK_DIR?


The WORK_DIR contains files that DenyHosts uses for keeping track of the hackers. In addition +to these files that DenyHosts creates and updates there are also some files that are intended +as user editable files (those that which the DenyHosts user creates and edits as appropriate). +

+User maintained files (they are optional)

+ +allowed-hosts - contains a list of ip addresses that are exempt from being denied by DenyHosts. +For further details refer to the allowed hosts FAQ entry. +

+ +restricted-usernames - contains a list of real or ficticious usernames that should never log into your sshd server. +Refer to restricted usernames for more information. + +

+DenyHosts maintained files

+ +offset - DenyHosts stores the offset of the last position read from your SECURE_LOG file. DenyHosts uses +this to quickly determine if new data is available in your logfile. This file also stores the first line of your log file +such that DenyHosts can determine if the file has been rotated between scans. +

+ +purge-history - (new in 2.4) contains a list of the denied hosts that have been purged from your +HOSTS_DENY file. Additionally, this file records the number of times this host has +been purged and the timestamp of the most recent purge. This file is only created if +DenyHosts is operating in purge mode. +

+ +sync-received - a list of the hosts that have been received from the DenyHosts Synchronization server. Refer to sync mode for more details. +

+ +sync-timestamp - the last time that synchronization has occurred. Refer to +sync mode for more details. +

+ +hosts - a list of all hosts that have attempted to access your sshd server. In addition the file contains the number +of failed attempts and most recent attempt timestamp. +

+ +hosts-restricted - +a list of hosts that have attempted to access restricted username accounts on your server. The +file has the same format as hosts. +

+ +hosts-root - a list of hosts that have attempted to access the root account on your server. The +file has the same format as hosts. +

+ +hosts-valid - a list of hosts that have attempted to access valid username accounts on your server. The +file has the same format as hosts. +

+ +suspicious-logins - a list of suspicious login activity (that is, logins that were successful after the deny threshold +should have been reached). +

+ +users-hosts - a list of usernames along with the ip address that attempted to login to your sshd server. This file +also contains the number of attempts for the username/ip address along with the most recent timestamp. +

+ +users-invalid - a summary of non-existent usernames that were used in order to login to your server. +The file also +contains the number of attempts per usernames and the most recent timestamp. +

+ +users-valid - a summary of all existing usernames (including 'root') that attempts to login to your sshd server. +The file also contains the number of attempts per usernames and the most recent timestamp. +

+ + +

Return to top

+
+

DenyHosts Synchronization Mode

+ + +

A. 4.0

What is synchronization mode?


DenyHosts v2.0 and later introduces synchronization mode which allows DenyHosts daemons the +ability to transmit denied host data to a central remote server (hosted by denyhosts.net). +Additionally, DenyHosts daemons can also receive data that other DenyHosts daemons have sent to +the central server. +

+This feature is intended to provide the ability to proactively deny ip addresses that have attacked +other users of DenyHosts. That is, each DenyHosts 2.0 (or later) user can benefit from other +users of Denyhosts. Similarly each DenyHosts user can benefit other DenyHosts users. + + +

Return to top

+
+ +

A. 4.1

What is denyhosts.net?


www.denyhosts.net is the new home of DenyHosts operated +by the creator of DenyHosts. + + +

Return to top

 +
+ +

A. 4.2

How does synchronization mode work?


DenyHosts daemons periodically connect (based on the configuration file parameter +SYNC_INTERVAL) to the denyhosts.net remote server. +If hosts have been denied by this daemon then they will +automatically be transmitted to denyhosts.net. If new hosts have been denied by others (that is, +other users running DenyHosts in synchronization mode), then they will be added to your +HOSTS_DENY
file automatically (based on your +SYNC_DOWNLOAD_THRESHOLD setting). +This allows your DenyHosts daemon to proactively deny hosts that have not +yet attacked you. +

+ +Each time that your DenyHosts daemon connects to the denyhosts.net server, only the data that +has changed since the last data synchronization is transmited. + + +

Return to top

+
+ +

A. 4.3

What are the requirements for synchronization mode?


To use DenyHosts in synchronization mode, you must be using DenyHosts 2.0 or later. +Additionally, DenyHosts must be running in daemon mode +(such that it will periodically synchronize with the denyhosts.net server). + + +

Return to top

 +
+ + +

A. 4.4

Is synchronization mode enabled by default?


No. To enable DenyHosts in synchronization mode you must explicitly enable it. + +

Return to top

 +
+ + +

A. 4.5

How do I enable synchronization mode?


You must add or modify several parameters in your DenyHosts configuration file +(typically, denyhosts.cfg). +

+ +Note: If you are upgrading DenyHosts to 2.0 (or later) from v1.x +then you will need to add several parameters to the configuration file. The +denyhosts.cfg-dist file contains several new parameters for synchronization mode. +These parameters should be manually copied to your DenyHosts configuration file. +

+ +The parameters pertaining to synchronization mode support are prefixed with SYNC_. +They are:

+ + +

    +
  • SYNC_SERVER - required +
  • SYNC_INTERVAL +
  • SYNC_UPLOAD +
  • SYNC_DOWNLOAD +
  • SYNC_DOWNLOAD_THRESHOLD +
  • SYNC_DOWNLOAD_RESILIENCY - (version 2.1 or later) +
+ + +To enable synchronization mode SYNC_SERVER must be defined. Currently, the corresponding +value must be set to http://xmlrpc.denyhosts.net:9911 +

+ +If the SYNC_SERVER parameter is not defined then synchronization mode will be disabled.

+ +Note: by default synchronization mode is disabled. To enable it (recommended) you +must add the following to your configuration file:

+ +SYNC_SERVER = http://xmlrpc.denyhosts.net:9911 +

+ +The other synchronization mode parameters are optional. + + +

Return to top

+
+ +

A. 4.6

How do I configure synchronization mode?


Assuming you have edited your configuration file to +enable synchronization mode you can tweak the behavior of DenyHosts +synchronization mode by specifying appropriate values for the optional configuration parameters. +These parameters have no effect if synchronization mode is disabled (which is the default). +

+ +SYNC_INTERVAL - Specifies the length of time between synchronization attempts. +By default, this value is 1 hour. The minimum allowed value is 5 minutes. If your DenyHosts +daemon has not recorded any additional rogue hosts since the previous synchronization then +no data will be uploaded to denyhosts.net. If no new DenyHosts (that meet your +SYNC_DOWNLOAD_THRESHOLD and >SYNC_DOWNLOAD_RESILIENCY settings) are available +from the denyhosts.net server, then no hosts will be downloaded by your daemon. +

+ +SYNC_UPLOAD - Allow your DenyHosts daemon the ability to upload data. The default is "yes". +

+ +SYNC_DOWNLOAD - Allow your DenyHosts daemon the ability to transmit data. The default is "yes". +

+ +SYNC_DOWNLOAD_THRESHOLD - Only download recently +denied hosts that have been blocked by this number of other DenyHosts daemons. +

+ +SYNC_DOWNLOAD_RESILIENCY - Only download ip addresses +that have been attacking other servers for atleast this length of time. + + +

Return to top

+
+ +

A. 4.7

Can I just send denied data?


If you wish to only provide data (of the hosts that your DenyHosts daemon has blocked) +to the denyhosts.net server but not receive hosts that have been denied by others you can set +your SYNC_DOWNLOAD to no. The default is yes but only applies if +synchronization mode has been enabled. +

+ +SYNC_DOWNLOAD = no + + +

Return to top

+
+ +

A. 4.8

Can I just receive data?


If you wish to only receive data (that other DenyHosts daemons have thwarted) but +not provide any data (that your DenyHosts daemon has blocked) to denyhosts.net then +you can do so by setting your SYNC_UPLOAD to no. +The default is yes but only applies if synchronization mode has been enabled. +

+ +SYNC_UPLOAD = no + + +

Return to top

+
+ +

A. 4.9

When receiving denied data will I get all denied hosts?


When your DenyHosts daemon initially connects with the denyhosts.net server it will +download the most recent attacks that have been reported by other DenyHosts daemons. + +

+ +Subsequently, subject to your SYNC_INTERVAL setting, when your DenyHosts daemon +connects with the denyhosts.net server only the data that has changed since it's last +connection will be transmitted. That is, if there are a total of 1000 denied hosts in the +system but only 5 have been added (or re-added) since the last synchronization, then only +the 5 will be transmitted to your DenyHosts daemon. +

+ + + +Additionally, you can set your SYNC_DOWNLOAD_THRESHOLD to qualify the data being +transmitted such that you have more confidence in it. That is, each time a host is added +to the denyhosts.net server a counter is incremented for that ip address. If +your SYNC_DOWNLOAD_THRESHOLD = 1 and the counter for an ip address is 1 (that is, a single +DenyHosts daemon transmitted this address) then your DenyHosts daemon would download it. However, +if your SYNC_DOWNLOAD_THRESHOLD = 4 then your DenyHosts daemon would not download this +ip address until 3 other DenyHosts clients transmitted the data.

+ + + +DenyHosts 2.1 adds the SYNC_DOWNLOAD_RESILIENCY setting. Resiliency is defined as the +timespan between a hackers first known attack and it's most recent attack. This value is used in +conjunction with the SYNC_DOWNLOAD_THRESHOLD value and only hosts that satisfy both +values will be downloaded. This value has no effect if SYNC_DOWNLOAD_THRESHOLD = 1. + +

+Example: +

+ +If the centralized denyhosts.net server records an attack from an ip address at 12 PM +and then again at 2 PM, the resiliency of the offending ip address is 2 hours. +Specifying a SYNC_DOWNLOAD_RESILIENCY = 4h (4 hours) will not download this ip address. +However, if the attacker is recorded again at 5 PM then the ip address will be downloaded +by your DenyHosts instance since the ip address has been resilient for 5 hours (12 PM until 5 PM). + + +

Return to top

+
+ +

A. 4.10

How do I know that DenyHosts synchronization mode is working?


Check your DAEMON_LOG file (typically /var/log/denyhosts). You will see entries +similar to the following: + +
+
+Feb 04 07:42:51 - sync        : INFO     received 0 new hosts
+Feb 04 07:52:52 - sync        : INFO     sent 1 new host
+Feb 04 07:52:52 - sync        : INFO     received 0 new hosts
+Feb 04 08:02:52 - sync        : INFO     received 1 new host
+
+
+ +If you see errors, such as "connection refused" that would indicate that the centralize denyhosts.net +server is down (perhaps for maintenance). Once the server is restarted, any ip addresses that +your DenyHosts daemon has recorded since the last successful synchronization will be sent (if +your SYNC_UPLOAD is not set to "no"). + + +

Return to top

 +
+ + +

A. 4.11

I decided that I don't want to use synchronization mode, how do I disable it?


In the unlikely event that you don't find synchronization mode useful you can easily disable it +by commenting out the SYNC_SERVER line in your configuration file. You will then need to +restart the DenyHosts daemon for the setting to take effect. + + +

Return to top

 +
+ +

A. 4.12

How long will retrieved ip addresses remain in my HOSTS_DENY file?


Addresses obtained by your DenyHosts daemon via synchronization download will be +subject to purging based on your PURGE_DENY +configuration setting. It is therefor suggested that you set a reasonable +PURGE_DENY value to keep your HOSTS_DENY file from growing +excessively large. +

+ +If the optional PURGE_THRESHOLD (new in v2.4) value is defined and not 0 (zero) then +a host will be purged atmost this many times. That is, if this value is set to 3, then DenyHosts +will purge a host atmost 3 times. After the host has been purged 3 times the host will remain in +your HOSTS_DENY forever, effectively blocking it forever (unless you change this setting). +If this value is set to 0 (the default) then DenyHosts will purge each host indefinitely +(that is, each host can be added and purged repeatedly without being blocked permanently). +

+ + +

Return to top

+
+ + +

A. 4.13

What is the cost of the synchronization service?


Currently there are no plans to charge for this service and I encourage anybody that +finds this feature (and DenyHosts in general) useful to donate. +I am using my personal resources (servers, bandwith, etc) to provide this service to +the growing DenyHosts community. By using my own resources, there may come a time +when I am forced to charge for this service, however, it would almost certainly remain +free to individual users. + + +

Return to top

 +
+ + +

A. 4.14

What information is collected from me?


When your DenyHosts daemon connects with the denyhosts.net server +your ip address is transmitted (the same is true when you use your web browser to access +any internet site). Your ip address will never be shared and may be used +internally to track suspicious activity. Your ip address is also used to q +ualify the uniqueness of the denied hosts that are maintained by the +denyhosts.net server

+ +If you enable synchronization uploads, then, in addition to your ip address +being sent, all recently denied ip addresses that your DenyHosts daemon has +thwarted will be transmitted. This is of course the desired behavior and provides +all DenyHosts daemons (that have synchronization download enabled) the ability +to proactively block rogue hosts. + + +

Return to top

+
+ + +

A. 4.15

How will information collected from me be used?


Although denyhosts.net may use your ip address for monitoring suspicious +behavior this information will never be transmitted to other DenyHosts daemon +clients or provided to any 3rd parties. That is, your ip address will not +be shared.

+ +The hosts that your DenyHosts daemon denies will of course be shared with +other DenyHosts daemons. Additionally, this data may be shared with +3rd parties at the discretion of the creator of DenyHosts. + + +

Return to top

+
+ + +

A. 4.16

What is the acceptable use policy of the data that denyhosts.net provides?


The ip addresses that are downloaded from the denyhosts.net server (for instance, by DenyHosts +daemons that have synchronization download enabled) may not be used for any commercial +purpose nor can this data be shared with the intent of profiting from it. That is, if anybody is going +to make money from the data collected it should be me! + + +

Return to top

 +
+ + +

A. 4.17

I administer many commercial servers, can I run my own denyhosts.net server?


You may wish to run your own (aka local) denyhosts.net server to synchronize all +DenyHosts daemons within your organization-- that is, if one server is attacked then +the other servers on your network will automatically be protected from the attacker +(based on their individual SYNC_INTERVAL settings). The information collected +by the local denyhosts.net server can be used by your organization for any legal purposes +and would not be shared with other DenyHosts daemons (those that are not part of your network). +

+ +Currently, the server that denyhosts.net uses to interact with DenyHosts daemons is not +publicly available. You may contact me +if you would like to license the server component.

+ + +

Return to top

+
+
+ +

+

+ +
+Home | +FAQ | +Links | +Features | +Download | +SourceForge + +
+
+
+ + +