Tag Info

Hot answers tagged

29

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 ...


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

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 ...


8

Here is why I think that is a terrible idea: Contrary to what you seem to believe, spam RBLs aren't a particular good or well-liked concept. They are in widespread use only because their contribution to the anti-spam fight outweighs their numerous drawbacks (often just slightly). I am sure you have heard about errors, outages and other problems related to ...


6

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 has been removed from OS X 10.8 (Mountain Lion). 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 use pfctl here: A Cheat Sheet For Using pf in OS X Lion and Up


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

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.


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. ...


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.


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

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

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

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


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.


2

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 ...


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

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


2

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 ...


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 ...


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.


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

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

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.


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


1

In my opinion, it doesn't make sense to have such a large `/etc/hosts.deny' file for several reasons: botnet activity can come from possible legitimate sources IP addresses, and it is usually useless to forever block an IP that can just be the temporary public IP of a compromised home computer with dynamic address. there are better tools for this job, like ...


1

Have you tried connecting from another IP? If not, I would try connecting from another IP, you can either ssh from another server or goto McDonalds and use their free WiFi. In the future, you can avoid getting locked out / banned again by adding your ip to the hosts.allow list.


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 ...



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