HOWTO Setup Deny Hosts: Difference between revisions

From Research
Jump to navigation Jump to search
No edit summary
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -pv net-misc/openssh'''
== Purpose ==
[ebuild  <font color=green>R</font> ] <font color=green>net-misc/openssh-x.x</font>  USE="<font color=red>'''tcpd'''</font><font color=blue></font>"


* There will be more USE flags listed in addition to '''tcpd''' but it is the only necessary flag for this setup.
Fail2ban, working in combination with iptables, is our favoured method of controlling crack-attempts.  Fail2ban is reactionary though (responding as/after attacks occur), and is best-used only on a real server.  Denyhosts makes use of a collaborative, on-line list of attackers, and can therefore be very pro-active in blocking crack-attempts.  So, we're testing defence-in-depth by applying '''both''' fail2ban and denyhosts on some machines.  In addition, our virtual servers (Gentoo Linux Vserver guests) cannot directly address hardware, do not run iptables, and cannot use fail2ban - Denyhosts is a great security addition to a Vserver-guest.


emerge -vp openssh
== Setup ==
[ebuild  R  ] net-misc/openssh-4.7_p1-r1  USE="pam tcpd


emerge -vp denyhosts
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -v denyhosts'''
[ebuild  <font color=green>N</font> ] <font color=green>app-admin/denyhosts-x.x</font>


rc-update add denyhosts default
Manually create a missing file:
<font color=red>hostname</font> <font color=blue>~ #</font> '''touch /var/lib/denyhosts/sync-timestamp'''
Note:  this will produce an error on the first-sync, due to the empty-file (which, being empty, contains a non-compliant date):
2012-11-21 09:09:11,501 - sync        : ERROR    invalid literal for long() with base 10: ''
After a second sync (nominally 2hrs after the first time denyhosts is run) this error will disappear.


vi /etc/denyhosts.conf
* Denyhosts can be run as a cron job, but we run it as as service:


PURGE_DENY =2h
<font color=red>hostname</font> <font color=blue>~ #</font> '''rc-update add denyhosts default'''


PURGE_THRESHOLD = 3
== Configure ==


BLOCK_SERVICE  = ALL
* There are several values to change in denyhosts.conf. Refer to the comments in this file for more information.


REM out BLOCK_SERVICE = sshd
  <font color=red>hostname</font> <font color=blue>~ #</font> '''emacs -nw /etc/denyhosts.conf'''
 
DENY_THRESHOLD_ROOT = 4
SECURE_LOG = /var/log/auth.log ''or for some servers and all workstations: SECURE_LOG = /var/log/messages''
 
SYSLOG_REPORT=YES
BLOCK_SERVICE  = ALL
 
SYNC_SERVER = http://xmlrpc.denyhosts.net:9911
SYSLOG_REPORT=YES
SYNC_SERVER = http://xmlrpc.denyhosts.net:9911
SYNC_INTERVAL = 1h
SYNC_UPLOAD = yes
SYNC_DOWNLOAD = yes
<br>
Problems arise when friendly folks attempt to access services and fail.  This is especially harsh when an automated tool attempts to re-access a service repeatedly with the failing credentials, and before the user can even react, they are blocked :-(  We add entries to /etc/hosts.allow to try to prevent this:
<font color=red>hostname</font> <font color=blue>~ #</font> '''emacs -nw /var/lib/denyhosts/allowed-hosts'''
# the following line prevents DenyHosts from blocking SFU
sfu.ca
iat.sfu.ca
142.58.0.1/16
209.87.60.1/24
# the following line prevents DenyHosts from blocking admin from common offsite:
shaw.ca
telus.com
deltacable.com
teksavvy.com
bell.ca
rogers.ca


SYNC_INTERVAL = 1h
== Turn It On ==


SYNC_UPLOAD = yes
<font color=red>hostname</font> <font color=blue>~ #</font> '''/etc/init.d/denyhosts start'''
Be patient - during startup, your specified log-file is read... this can take several ''minutes'', during which it may appear that DenyHosts isn't starting... it is, though.  Just wait.


SYNC_DOWNLOAD = yes
== Problems? ==
 
Try:
SYNC_DOWNLOAD_THRESHOLD = 3
  <font color=red>hostname</font> <font color=blue>~ #</font> '''tail -f /var/log/denyhosts'''
 
Also - given the above settings, it takes one hour (1h) after starting the denyhost daemon before a sync to the denyhost-server is attempted.
/etc/init.d/denyhosts start
<br>
 
And - if you're trying crazy-strict '''outgoing''' firewall rules, you may need to open to xmlrpc.denyhosts.net:9911.
 
 
 
== Purpose ==
 
TCPWrappers can effectively control access to services which have tcpwrapper support compiled in.  The controlling daemon is '''tcpd''', which is automatically pulled in whenever the '''tcpd''' USE flag in enabled (Gentoo Linux).
 
== Setup ==
In this example, we'll use the SSH (Secure Shell) daemon, because it's one of the first services we want to have secured.<br>
 
First, verify that SSH has tcpwrapper support (tcpd flag indicates it does, in this example):
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -pv net-misc/openssh'''
  [ebuild  <font color=yellow>R</font>    ] <font color=green>net-misc/openssh-4.3_p2-r5</font>  USE="<font color=red>ipv6 ldap pam '''tcpd'''</font><font color=blue> -X -X509 -chroot -hpn -kerberos -libedit (-selinux) -sftplogging -skey -smartcard -static</font>"
 
== Configure ==
 
The goal with SSH and tcpwrappers is to allow anyone within the SFU IP-address range to have access to SSH, and deny everyone else.  We'll do this by editing the '''/etc/hosts.deny''' file (which won't initially exist, but once created - it will be in effect.  There is no need to re-start the sshd daemon, because hosts.deny is consulted on each connect-attempt, and is therefore immediately in-effect after saving). Here's an example:
 
# /etc/hosts.deny    This file describes the names of the hosts which are
#                    *not* allowed to use the specified services, as decided
#                    by the '/usr/sbin/tcpd' server.
# Authour:  Gordon Pritchard <gordonp@sfu.c

Latest revision as of 22:11, 27 February 2017

Purpose

Fail2ban, working in combination with iptables, is our favoured method of controlling crack-attempts. Fail2ban is reactionary though (responding as/after attacks occur), and is best-used only on a real server. Denyhosts makes use of a collaborative, on-line list of attackers, and can therefore be very pro-active in blocking crack-attempts. So, we're testing defence-in-depth by applying both fail2ban and denyhosts on some machines. In addition, our virtual servers (Gentoo Linux Vserver guests) cannot directly address hardware, do not run iptables, and cannot use fail2ban - Denyhosts is a great security addition to a Vserver-guest.

Setup

hostname ~ # emerge -v denyhosts
[ebuild   N ] app-admin/denyhosts-x.x

Manually create a missing file: 

hostname ~ # touch /var/lib/denyhosts/sync-timestamp

Note: this will produce an error on the first-sync, due to the empty-file (which, being empty, contains a non-compliant date): 

2012-11-21 09:09:11,501 - sync        : ERROR    invalid literal for long() with base 10:

After a second sync (nominally 2hrs after the first time denyhosts is run) this error will disappear.

  • Denyhosts can be run as a cron job, but we run it as as service:
hostname ~ # rc-update add denyhosts default

Configure

  • There are several values to change in denyhosts.conf. Refer to the comments in this file for more information.
hostname ~ # emacs -nw /etc/denyhosts.conf

SECURE_LOG = /var/log/auth.log or for some servers and all workstations: SECURE_LOG = /var/log/messages

BLOCK_SERVICE  = ALL

SYSLOG_REPORT=YES

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

SYNC_INTERVAL = 1h

SYNC_UPLOAD = yes

SYNC_DOWNLOAD = yes


Problems arise when friendly folks attempt to access services and fail. This is especially harsh when an automated tool attempts to re-access a service repeatedly with the failing credentials, and before the user can even react, they are blocked :-( We add entries to /etc/hosts.allow to try to prevent this: 

hostname ~ # emacs -nw /var/lib/denyhosts/allowed-hosts

# the following line prevents DenyHosts from blocking SFU
sfu.ca
iat.sfu.ca
142.58.0.1/16
209.87.60.1/24

# the following line prevents DenyHosts from blocking admin from common offsite:
shaw.ca
telus.com
deltacable.com
teksavvy.com
bell.ca
rogers.ca

Turn It On

hostname ~ # /etc/init.d/denyhosts start

Be patient - during startup, your specified log-file is read... this can take several minutes, during which it may appear that DenyHosts isn't starting... it is, though. Just wait.

Problems?

Try: 

 hostname ~ # tail -f  /var/log/denyhosts

Also - given the above settings, it takes one hour (1h) after starting the denyhost daemon before a sync to the denyhost-server is attempted.
And - if you're trying crazy-strict outgoing firewall rules, you may need to open to xmlrpc.denyhosts.net:9911.

Retrieved from "https://research.wiki.iat.sfu.ca/research/index.php?title=HOWTO_Setup_Deny_Hosts&oldid=5837"