I have been enumerating the remaining security concerns on one of my back-end production servers, when I came to the realization that something which could be incredibly useful was missing from my operating systems upstream repository.
I have been looking for a PAM Module, which checks the Remote Host IP address against a DNS Block List (DNSBL).
My use case is that… While IDS Software can respond after detecting an probe, vulnerability scan, or brute force attack–
(i.e. Apache2, proFTPd, Sendmail, SpamAssassin) include a DNSBL module or feature, which help vastly decrease the number of machines that can participate in an attack. it does this by blocking known infected or zombie machines, public proxies, and TOR exit relay nodes (for example).
Others, to my knowledge, do not.
Dovecot/Saslauthd do not include such functionality. These are frequently targeted in brute force attacks on my network. these service are still covered by the IDS system, but suffer a large majority of the attacks.
With a PAM Module that checks the remote host IP, during authentication, against a DNSBL… effectively ALL services could have this extra layer of resilience against a distributed brute force attack, or probe (limiting the possible machines that can be used in said attack)
I am wondering if there is an existing PAM Module to serve this purpose? and if not, why has this been overlooked by developers?
It would be an incredibly simple module, which (in my opinion) could serve a great purpose..
For now, I have wrote a script which interfaces with PAM (via the
“pam_exec.so” module). For some reason, this is not working (simply
causes BASH to crash). When I get the chance, I plan to try the
“pam_script.so” module instead..
I would be willing to write a PAM Module to do this, but am not
sure how hard it is to get a piece of software into the Debian or
You could implement this without much trouble, but it’s a bad idea to do so.
First, let’s remember what PAM is: it’s a system for handling user logins. Authentication, authorization, accounting, etc.
So, where this proposal falls down is:
- It will slow down legitimate logins. Typically the slowdown will be imperceptible, as DNS lookups don’t take that much time, but they can take several seconds or just time out completely. What do you do when that happens? Do you refuse a legitimate user?
- More importantly, it will completely block legitimate logins, even when everything is working perfectly. Many users have the misfortune to be on dynamic IP addresses, and they may themselves be on a malware-riddled computer which is participating in a botnet, causing the IP address to be listed in a DNSBL, or have recently been assigned an IP address which is DNSBL listed even though they themselves are clean.
There are plenty of ways to deal with brute-force attacks on various services, the most commonly used of which is fail2ban, but this proposal seems like a Very Bad Idea.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.