# RIP Denyhosts [WONTFIX]

## jesnow

Openssh removed support fot tcp wrappers THREE YEARS AGO, so if anybody was wondering why denyhosts seemed to be letting through a lot of brute force logins, it's because sshd no longer pays any attention to the hosts.* files. 

There are still packages that do make use of tcp-wrappers:

```

Merckx jesnow # equery hasuse tcpd

 * Searching for USE flag tcpd ... 

[IP-] [  ] app-admin/syslog-ng-3.7.3:0

[IP-] [  ] net-analyzer/net-snmp-5.7.3-r5:0

[IP-] [  ] net-analyzer/rrdtool-1.6.0-r1:0/8.0.0

[IP-] [  ] net-fs/nfs-utils-1.3.4-r1:0

[IP-] [  ] net-misc/socat-1.7.3.1:0

[IP-] [  ] net-nds/openldap-2.4.44:0

[IP-] [  ] net-nds/rpcbind-0.2.4-r1:0

Merckx jesnow # 

```

But the big one ssh does not. This happened very quietly and I'll bet I'm not the only one who was wondering why my primary security strategy was failing silently. 

Jon.

----------

## krinn

https://bugs.gentoo.org/show_bug.cgi?id=531156

equery hasuse only show keyword use by packages you have install, not all packages that could use it.

ie: xinetd use tcpd and could spawn sshd

----------

## NeddySeagoon

jesnow,

You probably want depends, which shows hard dependencies too rather than hasuse, which only shows packages that have the given USE flag, thus optional support for the feature.

```
$ equery d tcp-wrappers

 * These packages depend on tcp-wrappers:

net-fs/nfs-utils-2.1.1-r1 (tcpd ? sys-apps/tcp-wrappers)

net-nds/openldap-2.4.44-r1 (tcpd ? sys-apps/tcp-wrappers)

net-nds/rpcbind-0.2.4-r1 (tcpd ? sys-apps/tcp-wrappers)
```

tcp-wrappers is a bad example are there are no hard dependencies.

----------

## krinn

LOL let's force JRG to add a "coulduse" feature to equery  :Smile: 

----------

## jesnow

Sure: 

```

Merckx linux # equery depends tcp-wrappers

 * These packages depend on tcp-wrappers:

app-admin/syslog-ng-3.7.3 (tcpd ? >=sys-apps/tcp-wrappers-7.6)

net-analyzer/net-snmp-5.7.3-r5 (tcpd ? >=sys-apps/tcp-wrappers-7.6)

net-analyzer/rrdtool-1.6.0-r1 (tcpd ? sys-apps/tcp-wrappers)

net-fs/nfs-utils-1.3.4-r1 (tcpd ? sys-apps/tcp-wrappers)

net-misc/socat-1.7.3.1 (tcpd ? sys-apps/tcp-wrappers)

net-nds/openldap-2.4.44 (tcpd ? sys-apps/tcp-wrappers)

net-nds/rpcbind-0.2.4-r1 (tcpd ? sys-apps/tcp-wrappers)

Merckx linux # 

```

That's not the point. The point is:

WARNING: OPENSSH NO LONGER USES hosts.deny ACCESS CONTROL.

WARNING: DENYHOSTS NO LONGER WORKS WITH SSHD.

WARNING: EVEN THOUGH DENYHOSTS RUNS, OPENSSH DISREGARDS IT.

WARNING: ANY SYSTEM USING DENYHOSTS IS NOW OPEN TO DICTIONARY ATTACK. 

This was a silent change to openssh with big security implications that nobody adequately warned us 

about, and there is a huge amount of incorrect documentation out there suggesting that hosts.* 

hardens ssh connections, which they do not. 

I haven't audited gentoo documentation to check this point but somebody should. 

Cheers, 

Jon

----------

## Ant P.

 *Quote:*   

> ANY SYSTEM USING DENYHOSTS IS NOW OPEN TO DICTIONARY ATTACK.

 

Why are you using password authentication in the first place‽

 *Quote:*   

> This was a silent change to openssh

 

As was pointed out to you in the other thread you necro-bumped to complain about this, warning messages have been present in the OpenSSH ebuilds about this for much longer than a sensible deprecation period.

It was in the release notes in October 2014 too. Didn't you bother to read those?

This thread reads like a laundry list of security worst practices. If it took you three years just to notice this was misconfigured on your end...

----------

## krinn

cop: you know why i stop you?

you: no sir

cop: you didn't stop at sign

you: but the sign wasn't big enough!

cop: the sign is there yes or no?

you: yes

cop: here's your ticket.

Hu is the cop there, didn't he shown you the sign already?

Just take your ticket, and pay attention to signs.

----------

## jesnow

Thanks guys, you are super helpful.

----------

## UberLord

So this is one reason why a NetBSD Dev invented blacklistd. It's a much cleaner solution.

I have no idea of its availability on Linux or its integration with iptables.

Here's a link to the FreeBSD man page.

https://www.freebsd.org/cgi/man.cgi?query=blacklistd&apropos=0&sektion=8&manpath=FreeBSD+12-current&arch=default&format=html

----------

## jesnow

What we need is an addon to denyhosts (which still works btw) that sets and delted drop rules in iptables. Fail2ban does this, but is super complicated. Denyhosts was super clean and easy for normal mortals to comprehend.

----------

## szatox

And what makes denyhost better than `iptables -I CUSTOMRECENTLYFAILED -j REJECT -s <intruders IP>` ?

Denyhost must be explicitly supported by an application, right? It basically does the same job, but it does it on a different layer, and it must be explicitly handled. And when you do that yourself, you run into risk of making your implementation inconsistent with a bunch of other programs using the same tools.

Why duplicate functionality of kernel's firewall inside your application? It makes room for mistakes, it's non-standard (requires specific training), and it even consumes more system resources, because iptables would have dropped it much earlier (e.g. before passing it to userspace)

----------

## krinn

i think with a little bash script (trigger with xinetd on port 22) that just run the iptables command given by szatox you will ban like 99% of script kiddies, sure they will then switch from port 22, but they are now ban  :Wink: 

----------

## NeddySeagoon

szatox,

Why REJECT and not DROP?

----------

## szatox

Either works as in prevents that data from being delivered to your application. Since that machine already knows you exist, there is no harm in telling it to leave you alone.

This said, DROP might actually be better, as it consumes more attacker's resources and prevents your machine from being used in reply attacks (smurf, anyone?).

Not that such a reflective attack using RST-flagged messages would be particularily effective, or that resource usage would be of any significance.

----------

## NeddySeagoon

My policies are to DROP anything I might not want from the outside world and REJECT anything from the inside trying to get out.

Then ACCEPT things that I want.   Not that I'm paranoid.

DROP does not appear in my logs

REJECT does. It makes debug easier.

----------

