HOWTO Setup Deny Hosts: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(→Setup) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Purpose == | == Purpose == | ||
Fail2ban, working in combination with | 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 == | == Setup == | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -v denyhosts''' | <font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -v denyhosts''' | ||
| Line 18: | Line 10: | ||
Manually create a missing file: | Manually create a missing file: | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''touch /var/lib/denyhosts/sync-timestamp''' | <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. | |||
* Denyhosts can be run as a cron job, but | * Denyhosts can be run as a cron job, but we run it as as service: | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''rc-update add denyhosts default''' | <font color=red>hostname</font> <font color=blue>~ #</font> '''rc-update add denyhosts default''' | ||
| Line 29: | Line 24: | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''emacs -nw /etc/denyhosts.conf''' | <font color=red>hostname</font> <font color=blue>~ #</font> '''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 | BLOCK_SERVICE = ALL | ||
SYSLOG_REPORT=YES | SYSLOG_REPORT=YES | ||
| Line 48: | Line 37: | ||
SYNC_DOWNLOAD = yes | SYNC_DOWNLOAD = yes | ||
<br> | <br> | ||
Problems | 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 / | <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 | |||
== Turn It On == | == Turn It On == | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''/etc/init.d/denyhosts start''' | <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. | |||
== Problems? == | == Problems? == | ||
Try: | Try: | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''tail -f /var/log/denyhosts''' | <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. | |||
<br> | |||
And - if you're trying crazy-strict '''outgoing''' firewall rules, you may need to open to xmlrpc.denyhosts.net:9911. | |||
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.