Some Easy DenyUsers Filters for OpenSSH

Update (2008-05-30): ARIN was issued the IPv4 address blocks 113/8 and 114 /8 by the IANA in May 2008, so those networks have been removed from the unallocated space listed below (and added to the APNIC space). I know I've missed some other updates; I need to check the new assignments when I get a chance.

Update (2008-04-17): ARIN was issued the IPv4 address blocks 173/8 and 174/8 by the IANA on 4 February 2008, so those networks have been removed from the unallocated space listed below (and added to the APNIC space).

Update (2010-02-07): 173/8 and 174/8 are apparently now Comcast space, so removed from the APNIC list.

The following discussion applies to OpenSSH specifically, but I believe the sample configuration statements below are written so that they'll work with other sshd implementations, too. YMMV.

Motivation

In an ideal world, your remotely-administered server would be locked down so it could only be accessed with a private key from the single IP of your single super-secure workstation. But what if your situation requires that your server accept logins via SSH from network hosts whose IP addresses and hostnames you don't know in advance?

Of course you're going to start by setting PermitRootLogin to "no" (or perhaps "forced-commands-only") and using AllowUsers and AllowGroups to restrict logins to the users who actually need access. But is there more you can do?

Because DenyUsers allows us to use some simple regular expressions to match IP address ranges, it's easy to filter out wide swaths of the Internet if you're pretty sure your users should never be connecting from a given address range. That's only going to slow down a determined attacker about 30 seconds, but it might turn away some of those pests who generate "Failed password for root from" messages in your logs every day.

Sample DenyUsers Rules

So which address ranges can we safely eliminate? That's entirely dependent on your situation, but below I've listed rules for blocking over half the possible IPv4 address space that many of us in North America can implement wholesale and from which others can choose. I've only included the "easy pickings" (mostly /8 or shorter) below, but if worthwhile you can easily extend this list with a little research. (This listing of IPv4 address space from IANA is a good place to start. I checked the rules below using the 19 January 2006 version of that list.)

Note that DenyUsers rules get processed first. So, even if you have an AllowUsers statement that would allow a login, if it's blocked by a DenyUser statement that login won't be allowed. This is exactly the behavior I want, but it might not be the behavior you want.

The address ranges to block break down into a few categories:

Addresses Probably Outside North America

If an IP address has been allocated by a registry other than ARIN, the organization using them should be located outside North America. However, this doesn't necessarily mean a host assigned such an address is located outside North America. A large European company, for example, might use address space allocated by RIPE to number hosts located outside Europe. This is more than a theoretical possibility, so before blocking based on this criterion, recognize that a legitimate user could easily be denied access by one of the rules in this category. If the consequences of having that happen and having to edit your sshd_config to remove the rule are minor, though, it may be useful for your situation.

I've also included a couple of /8s allocated to government networks in the UK.

# RIPE networks
DenyUsers *@62.*.*.*
DenyUsers *@80.*.*.*
DenyUsers *@81.*.*.*
DenyUsers *@82.*.*.*
DenyUsers *@83.*.*.*
DenyUsers *@84.*.*.*
DenyUsers *@85.*.*.*
DenyUsers *@86.*.*.*
DenyUsers *@87.*.*.*
DenyUsers *@88.*.*.*
DenyUsers *@89.*.*.*
DenyUsers *@90.*.*.*
DenyUsers *@91.*.*.*
DenyUsers *@193.*.*.*
DenyUsers *@194.*.*.*
DenyUsers *@195.*.*.*
DenyUsers *@212.*.*.*
DenyUsers *@213.*.*.*
DenyUsers *@217.*.*.*
# APNIC networks
DenyUsers *@58.*.*.*
DenyUsers *@59.*.*.*
DenyUsers *@60.*.*.*
DenyUsers *@61.*.*.*
DenyUsers *@112.*.*.*
DenyUsers *@113.*.*.*
DenyUsers *@121.*.*.*
DenyUsers *@122.*.*.*
DenyUsers *@123.*.*.*
DenyUsers *@124.*.*.*
DenyUsers *@125.*.*.*
DenyUsers *@126.*.*.*
DenyUsers *@202.*.*.*
DenyUsers *@203.*.*.*
DenyUsers *@210.*.*.*
DenyUsers *@211.*.*.*
DenyUsers *@218.*.*.*
DenyUsers *@219.*.*.*
DenyUsers *@220.*.*.*
DenyUsers *@221.*.*.*
DenyUsers *@222.*.*.*
# AFRINIC networks
DenyUsers *@41.*.*.*
# JAPANI networks
DenyUsers *@43.*.*.*
# LACNIC networks
DenyUsers *@189.*.*.*
DenyUsers *@190.*.*.*
DenyUsers *@200.*.*.*
DenyUsers *@201.*.*.*
# UK Government (DINSA/DSSU) networks
DenyUsers *@25.*.*.*
DenyUsers *@51.*.*.*

US Military & Intelligence Networks

If you need to be able to reach your server from a military installation, then this category isn't for you. But, for the rest of us, blocking these networks is a Good Idea. Not because the US government is spying on you. (They are, but they don't need access from DoD networks to do that.) Because servers located within this address space are already owned by attackers and large parts of the US government are too clueless even to accept abuse reports properly.

# DNIC (DoD) networks
DenyUsers *@6.*.*.*
DenyUsers *@11.*.*.*
DenyUsers *@21.*.*.*
DenyUsers *@22.*.*.*
DenyUsers *@26.*.*.*
DenyUsers *@28.*.*.*
DenyUsers *@29.*.*.*
DenyUsers *@30.*.*.*
DenyUsers *@33.*.*.*
DenyUsers *@214.*.*.*
DenyUsers *@215.*.*.*

(I'm sure your local government is just as bad.)

Reserved & Unallocated Addresses ("Bogons")

This is a diverse category that includes RFC 1918 ("private") addresses, other special-use addresses, and address space that hasn't yet been allocated. If your server is sitting behind a good firewall and/or connected via a good ISP, it should never even see connections from many (or even any, depending) of these addresses. But bogons happen, so why take chances?

Of course, unallocated space eventually becomes allocated space. So you may need to check up on these rules once in a while, even if they're suitable at at first.

# RFC 1918           
DenyUsers *@10.*.*.* 
DenyUsers *@172.16.*.*
DenyUsers *@172.17.*.*
DenyUsers *@172.18.*.*
DenyUsers *@172.19.*.*
DenyUsers *@172.2?.*.*                 
DenyUsers *@172.30.*.*
DenyUsers *@172.31.*.*          
DenyUsers *@192.168.*.*       
# RFC 3330                       
DenyUsers *@0.*.*.*               
DenyUsers *@14.*.*.* 
DenyUsers *@169.254.*.*
DenyUsers *@192.0.2.*      
DenyUsers *@192.88.99.*
DenyUsers *@198.18.*.*
DenyUsers *@198.19.*.*
# Other IANA reserved/unallocated
DenyUsers *@1.*.*.*
DenyUsers *@2.*.*.*
DenyUsers *@5.*.*.*
DenyUsers *@7.*.*.*
DenyUsers *@23.*.*.*
DenyUsers *@27.*.*.*
DenyUsers *@31.*.*.*
DenyUsers *@36.*.*.*
DenyUsers *@37.*.*.*
DenyUsers *@39.*.*.*
DenyUsers *@42.*.*.*
DenyUsers *@77.*.*.*
DenyUsers *@78.*.*.*
DenyUsers *@79.*.*.*
DenyUsers *@92.*.*.*
DenyUsers *@93.*.*.*
DenyUsers *@94.*.*.*
DenyUsers *@95.*.*.*
DenyUsers *@96.*.*.*
DenyUsers *@97.*.*.*
DenyUsers *@98.*.*.*
DenyUsers *@99.*.*.*
DenyUsers *@10?.*.*.*
DenyUsers *@110.*.*.*
DenyUsers *@111.*.*.*
DenyUsers *@114.*.*.*
DenyUsers *@115.*.*.*
DenyUsers *@116.*.*.*
DenyUsers *@117.*.*.*
DenyUsers *@118.*.*.*
DenyUsers *@119.*.*.*
DenyUsers *@120.*.*.*
DenyUsers *@175.*.*.*
DenyUsers *@176.*.*.*
DenyUsers *@177.*.*.*
DenyUsers *@178.*.*.*
DenyUsers *@179.*.*.*
DenyUsers *@180.*.*.*
DenyUsers *@181.*.*.*
DenyUsers *@182.*.*.*
DenyUsers *@183.*.*.*
DenyUsers *@184.*.*.*
DenyUsers *@185.*.*.*
DenyUsers *@186.*.*.*
DenyUsers *@187.*.*.*
DenyUsers *@197.*.*.*
DenyUsers *@223.*.*.*
DenyUsers *@24?.*.*.*
DenyUsers *@250.*.*.*
DenyUsers *@251.*.*.*
DenyUsers *@252.*.*.*
DenyUsers *@253.*.*.*
DenyUsers *@254.*.*.*
DenyUsers *@255.*.*.*

Multicast Addresses

If you're doing something that involves SSH and multicast addresses, I'm gonna assume you already know not to use the rules below. For the rest of us, we probably shouldn't even be receiving connections on these addresses, but it can't hurt to be sure, right?

# multicast         
DenyUsers *@224.*.*.*
DenyUsers *@225.*.*.*
DenyUsers *@226.*.*.*
DenyUsers *@227.*.*.*
DenyUsers *@228.*.*.*
DenyUsers *@229.*.*.*
DenyUsers *@23?.*.*.*

For Further Research

As I said, those are the easy pickings. But, for my particular scenario, the rules above actually catch many of the casual, merely-annoying attempts that show up in my daily log. So, while they don't make my servers "more secure" in and of themselves, they do allow me to prioritize my efforts.

I suspect we could cut the remaining space in half again with a little research (using whois, RBLs, etc.), but IMHO this is where the point of diminishing returns sets in. If you find more "easy pickings", though, feel free to nominate more networks for inclusion on my list!