Hot answers tagged

36

IIRC, DenyHosts will only watch your SSH service. If you need it to protect other services as well, Fail2ban is definitely a better choice. It is configurable to watch nearly any service if you are willing to tweak its configuration, but that shouldn't be necessary as the newer versions of Fail2ban include rulesets which are suitable for many popular ...


12

best way to prevent brute force logons? Don't let them get to your machine in the first place! There are plenty of ways to stop brute force attempts before they get to your host, or even at the SSH level. Having said that, protecting your Operating System with something like fail2ban is a great idea. Fail2ban is slightly different to DenyHosts, though they ...


9

You actually need to stop denyhosts, then remove the offending entry from 6 other files and restart it. The affected files are: /var/lib/denyhosts/hosts /var/lib/denyhosts/hosts-restricted /var/lib/denyhosts/hosts-root /var/lib/denyhosts/hosts-valid /var/lib/denyhosts/users-hosts /etc/hosts.deny here is a Python script I created to do the same thing -- ...


8

Copy this code into a new file /etc/fail2ban/filter.d/sshd-root.conf: [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = sshd failregex = ^%(__prefix_line)sFailed (?:password|publickey) for root from <HOST>(?: port \d*)?(?: ssh\d*)?$ ignoreregex = ...


5

Tcpwrappers (which uses the entries in hosts.deny) has been removed from OS X 10.8 (Mountain Lion), so sshd is no longer paying attention to what is in that file. You can use Packet Filter instead, or install libwrap via MacPorts and recompile sshd. Run "man pfctl" to get details on how to control and configure the rules. There's a nice run-down on how to ...


5

I use iptables rules to rate-limit new connections from the same IP address (SSH mainly, but it'd work fine for FTP, too). The advantage, as I see it, over "fail2ban" and other such tools is that the iptables route occurs totally in kernel mode and doesn't rely on any user mode tools to tail / parse log files. ...


4

It's safe to remove them. Depending on your version of denyhosts, there may be a provision to purge old entries. You can either zero the files or remove them and restart the daemon. If you remove the file, it will most-likely be repopulated with the entries from your online /var/log/secure.* - say, the last week or 5 weeks, depending on your daemon config. ...


4

By my read of it, there are two reasons to continue using DenyHosts: Failed-login processing still takes resources, so using it keeps that lower. Your log-files with DenyHosts will be a lot smaller than your log-files without it. If either of those don't really matter to you, then DenyHosts isn't doing anything for you.


3

The files hosts.allow and hosts.deny are, so to say, deprecated. They are mainly used for tcp-wrapper and maybe used by other services or applications. But if they are used depends on the implementation of the program. Using a firewall is the preferred method because their rules are based on IPs, ports and other criteria. The firewall is independent of the ...


3

Probably you tested one of the conditions where denyhosts should block users, e.g. logging in as root. Here is what you can do to reset the hosts.deny file so that you will be able to login again (from the DenyHosts FAQ): Stop DenyHosts Remove the IP address from /etc/hosts.deny Edit WORK_DIR/hosts and remove the lines containing the IP address. Save the ...


3

You need to comment out the HOSTS_DENY = /etc/hosts.allow line, since you are on Ubuntu and not on a BSD box. Then, you need to understand how the hosts.(allow|deny) files are processed. Services which use these files always check hosts.allow before hosts.deny and stop at the first match. So, if you grant an IP address access in your hosts.allow file, ...


3

denyhosts is for ssh. fail2ban is more comprehensive (HTTP, FTP, etc.). Both use iptables behind the scenes.


3

ANOTHER GREAT WAY TO PROTECT SSH (I have used this for a decade or better) is to use the recent libraries in iptables natively(depending on your distro). Basically it can be used as port knocking thats built into iptables. This will save you plenty of headaches. As long as you can tcp connect(telnet is one way. I have also used ssh clients and pointed them ...


3

please review the following links: http://denyhosts.sourceforge.net/faq.html#3_9 http://denyhosts.sourceforge.net/faq.html#3_19 http://denyhosts.sourceforge.net/faq.html#allowed if you wanted to scrap the whole fail2ban, and denyhosts idea, do as Nathan Powell below says, change from port 22 to something more obscure also a few more ideas: iptables: ...


3

One thing to note about Fail2Ban is that it seems to use about 10MB more memory than DenyHosts. So if you are on a 128MB VPS you might want to look into that. Also, out-of-the-box fail2ban is only setup on SSH which means that with no changes to the config - DenyHosts does the same thing in less memory.


3

hosts.allow can override hosts.deny. Remove those entries from hosts.allow. See the hosts_access(5) man page for details.


3

Looking at this previous serverfault question, I suspect that you could use fail2ban to do this. I don't see an obvious way to count emails from senders, though. You might indeed be on your own for scripting this. Also, are you doing greylisting with milter-greylist? That could help reduce the spam volume as well.


2

Put yourself in /etc/hosts.allow. The order of processing goes as follows, stopping after there is a match: Grant access based on rules in /etc/hosts.allow Deny access based on rules in /etc/hosts.deny Grant access.


2

/usr/local/bin/denyhosts_unban #!/bin/bash if [ -z "$1" ]; then echo -e "Error:\n\tProvide IP as the first param" echo -e "Usage:\n\t$0 <IP>" exit 1 fi /etc/init.d/denyhosts stop echo ' /var/lib/denyhosts/hosts /var/lib/denyhosts/hosts-restricted /var/lib/denyhosts/hosts-root /var/lib/denyhosts/hosts-valid /var/lib/denyhosts/users-hosts ...


2

I believe I've seen someone say that some of those apps will count failed key logins as a brute force attempt. Do you have an ssh-agent running with keys in it? Connecting with that set will offer every key in turn before falling back to password, so that might be why. Try setting sshd's log level higher, and check fail2ban/denyhost logs. Edit: here is the ...


2

Any recommendations on other alternative ways to prevent brute force of ssh? Change the port SSH runs on. Brute force attempts are largely done against port 22. $ sudo grep ^Port /etc/ssh/sshd_config Port 10022 Limit the users that are allowed to connect, for example: $ sudo grep ^AllowUsers /etc/ssh/sshd_config AllowUsers dannix AllowUsers ...


2

WORK_DIR is a variable that is defined in your denyhosts.cfg. Default values I have seen are: /usr/share/denyhosts/data. /var/lib/denyhosts. Check your denyhosts.cfg to be certain but it's probably one of those two. [edit] On Ubuntu 14.04 you should look in the file /etc/denyhosts.conf


2

You have both of those uncommented, so it's leading me to believe that denyhosts is using /etc/hosts.allow. Comment out the second HOSTS_DENY line and restart denyhosts. If you still get the emails, you need to add SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS = NO to your denyhosts.conf file. This requires DenyHosts 0.6 or higher. See this for details. You'll ...


2

Use ipset to create set of IP ranges (with a script probably) and then use --match-set in iptables rule. This way matching will be pretty efficient because ipsets are hashed.


2

Depending on your distribution, edit /etc/fail2ban/jail.conf Update the [ssh] section to show something like this [ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log bantime = 3600 maxretry = 3 Change the parameters as required. It won't specifically block root, but every attempt that fails. Be careful with maxretry and the ...


1

Create a file named WORK_DIR/allowed-hosts and input your IP. Restart Denyhosts.


1

Since the default /etc/fail2ban/filter.d/sshd.conf already has a regex for AllowUsers and DenyUsers... ... ^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$ ^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$ ... The following will: Allow connections from exampleusername from ...


1

If you have completely disabled password-based login (PasswordAuthentication = no in sshd_config) then brute-force attacks become a lot harder if not impossible - the client would have to supply a large number of keys, none of which are related to an account or to each other. Nevertheless, you may still want to block IPs that originate large amounts of ...


1

Do you really need ssh access from anywhere on the Internet? If you can narrow it down to a couple of fixed IP ranges like work or home and limit SSH access only to them, you'll be better off. I realise that isn't great if you're out and about and need access from a random wireless network on a random IP range. That's what a vpn is for, say openvpn with two ...


1

You can also use Fail2ban instead Denyhosts. Here's a good explanation of how to do it for SMTP: http://theether.net/kb/100141



Only top voted, non community-wiki answers of a minimum length are eligible