2

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-

some services (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 Ubuntu Repositories.

Thanks

Improve this question

3 Answers 3

Reset to default
1

I'm not aware of such a module. Your second question (why) is going to solicit answers that are primarily opinion based, as I cannot think of any definitive reasons for why such a PAM module couldn't exist.

Below are the design considerations I identified when assessing feasibility:

  • Speed: Must not stall logins to heck and back. ssh+PAM are already in in a bad place when it comes to DNS delays under default configs. I'd go as far as to say the DNS lookups to each server should be made in parallel, to avoid stacking timeouts on top of each other.
  • Retries Are Bad: Using the C library for DNS lookups is fine so long as retries are considered to be under the purview of /etc/resolv.conf. If DNS retries are implemented, the module must not use the C library for DNS lookups. The end result would be nested retry operations.
  • Skip Private IP Ranges: RFC1918 (and similar) space should always get a free pass, as it's useless to pass this information to a DNSBL.
  • Lockout Considerations: What happens when all DNS is unavailable? Does the module always fail the login, barring a private IP? This must be documented.
  • Generate log errors if you're called in the auth stack. The auth stack is used for authentication. This module is not used to authenticate. Decisions that bypass the auth stack (SSH key auth, GSSAPI auth, etc.) will defeat the module if the user places it there.
Improve this answer
5
  • These are all very important aspects to think about when developing such a module. thank you for your opinion, and taking the time to provide potentially very helpful considerations.
    – RapidWebs
    Jul 1, 2014 at 19:53
  • see my comment about a tcp-wrappers like implementation of a hosts.allow/deny file, per user. Users could turn on the module for only specific services, only specific hosts, or both. using /etc/skel It could drop in a default configuration of DNSBL:ALL:ALLOW and the user could modify this to white-list their local networks, hostname, etc. furthermore, it could be reasonable that it might used as a drop in replacement for the hosts.allow file, but per user. all-though.. with this functionality and scope, it would be more of a per user TCP-Wrappers replacement module, with DNSBL Support.
    – RapidWebs
    Jul 1, 2014 at 20:43
  • @RapidWebs The services the module should apply to is more a function of the PAM config. An admin who wants this config to apply to sshd wouldn't put this module in /etc/pam.d/common-auth, for example. Excluding specific networks is borderline: pam_access.so is usually used to skip over a module that you don't want applying to specific network sources.
    – Andrew B
    Jul 3, 2014 at 20:33
  • (also I'm a terrible person for saying common-auth instead of common-account)
    – Andrew B
    Jul 3, 2014 at 22:49
  • I am testing the script based implementation of this module at the moment. and I agree that it should be defined per service using PAM Config. but since the one obvious issue about DNSBL support that we can all agree on.. is that, say , on a shared server.. it needs a way to be be activated or subverted at the users discretion. per host. i realize my idea in the above comment is entirely out of the scope of DNSBL support in PAM, but some sort of user whitelist would need to be implemented.. considering a regular user cannot access /etc/security or /etc/pam.d/ (nor should they be able to..)
    – RapidWebs
    Jul 4, 2014 at 23:37
1

I am more of a redhat guy myself but I've long wondered about a similar module. Good question. I haven't seen a module to handle this.

As far as publishing software goes this may help.

I never had good luck with the main repositories but rpmforge (now repoforge ) has some pretty easy going ways to get involved. See here.

For debian / ubuntu I havent seen a single large third party repository. They all seem to be product specific. My stuff never seemed to quite fit , and I couldn't ever justifying running my own public facing repository.

I tended to just leave anything that needed to packaged for debian derivatives sitting source on github.

Improve this answer
0

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:

  1. 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?
  2. 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.

Improve this answer
4
  • 1
    #2 is very context specific. If the ssh users are customers, then that's a problem. If they're not, there should probably be a firewall involved. If for some reason you can't involve a firewall, that's the sweet spot.
    – Andrew B
    Jun 30, 2014 at 21:57
  • @AndrewB Even I occasionally need to log in to my own servers from arbitrary locations. Since they are all geographically scattered, I could do a VPN between them all, but it doesn't provide that much real benefit. Looks good on the resume though...
    – Michael Hampton
    Jun 30, 2014 at 21:59
  • I have one or two services which are being constantly bruteforced. the services are getting connections from a fairly large botnet. i've already had to increase the maximum size of the worker pool, to allow for more incoming connections, in order to process legitimate requests. if i ONLY use very specific DNSBL's, targetting only zombie networks, TOR exit relays, and open proxies. and i cache these requests against a local DNS server. I don't see where the downfall would be. I have also implemented a TCPWrappers like system, where you can SKIP the DNSBL check depending on the service or host
    – RapidWebs
    Jul 1, 2014 at 19:48
  • I only came to this opinion because A) as for latency, comparing to the Apache implementation, when caching locally.. it has not added very much additional overhead. the user could set an option for what to do in the event of a DNS timeout, or failed connection. moreover, like I said, B) they can white-list their local networks, or login using VPN. mail services might be a problem, and for this, they can disable the DNSBL check in their per user configuration. this would resemble a hosts.deny/allowed file, and can disable the check depending on the Service, or Host (or both)(DNSBL:ALL:ALLOW)
    – RapidWebs
    Jul 1, 2014 at 20:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .