Configuration Security
Abstract
This is an attempt by me to come up with a configuration checklist for each software subsystem (DNS, SMTP, etc.). I intend to explain the general security principles for that service, explain how they may be abused, then demonstrate how to configure various subsystems securely, and, importantly, how to test that they have been secured (or not). I will not make an attempt to be comprehensive; this will be biased towards the services with which I am most familiar.
This is a work in progress.
1 Metadata
1.1 Copyright and Distribution Control
Kindly link a person to it instead of redistributing it, so that people may always receive the latest version. However, even an outdated copy is better than none. The latest version is always here:
This is a copyrighted work, with some rights reserved. This work is licensed under the
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License (
http://creativecommons.org/licenses/by-nc-nd/3.0/us/). This means you may redistribute it for non-commercial purposes, and that you must attribute me properly (without suggesting I endorse your work). For attribution, please include a prominent link back to this original work and some text describing the changes. I am comfortable with certain derivative works, such as translation into other languages, but not sure about others, so have yet not explicitly granted permission for all derivative uses. If you have any questions, please email me and I’ll be happy to discuss it with you.
My goal in creating this document is to have a checklist for every subsystem that I need to configure for my own system administration purposes. By publishing it, I encourage peer review by people who may know more about a particular protocol or program than I do. I also get an opportunity to share this knowledge with those who need it.
I do not intend to address security vulnerabilities that can only be fixed by re-writing code; there are plenty of secure coding guidelines out there.
1.3 Audience
The expected audience for this document will be system administrators who wish to configure their subsystems properly, penetration testers who wish to help clients configure their subsystems securely, and security experts who may want to expand their core of knowledge about security.
1.4 Related Work
1.5 Conventions Used in This Document
When I describe an IP address or domain name that will be different for your setup, I use bold. When I use a machine name that will be different for you, I use emphasis.
I will assume that the server you intend to configure has an IP address of 192.168.1.1 and a hostname of server. I assume that any authorized client machines in your administrative domain will be in 192.168.1.0/24 and have a hostname such as trusted. When it is required to test from a client outside your network, the machine will have an IP address of 10.1.1.1 and a hostname of untrusted.
2 DHCP
2.1 General Issues
2.2 Dynamically Assigned Hosts
If clients on a subnet are to be assigned addresses dynamically, a range declaration must appear within the subnet declaration. It is suggested that you keep this range seperate from the statically assigned hosts range.
-
subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.128 192.168.1.254; }
2.3 Statically Assigned Hosts
For clients with statically assigned addresses, or for installations where only known clients will be served, each such client must have a host declaration. It is suggested that you keep this range seperated from the dynamically assigned hosts range.
-
group { host trusted { hardware ethernet 00:11:22:33:44:55; fixed-address trusted.mine.com; } }
3 DNS
3.1 General Issues
3.1.1 Recursive Resolution
The most common configuration mistake for DNS is to allow recursive resolution (i.e. lookups) for machines that you do not own. Some well-known servers, such as 4.2.2.2, are configured to allow public lookups and have been that way for some time. This can be abused in multiple ways.
-
The adversary simply uses your DNS server to look up DNS names. Since DNS lookups are fast and relatively inexpensive, this is a minor annoyance. One could argue it is theft of resources, but the cost of such theft is trivial.
-
The adversary looks up DNS records with long time-to-live (TTL) values, causing your DNS server to cache them in memory for long periods of time. Dan Kaminsky showed how to use such servers to cache portions of files, allowing for massively parallel downloading of such files from thousands of servers simultaneously, creating an extremely high-bandwidth download channel. This uses up virtual memory, and having lots of people downloading large (TXT) records could consume some bandwidth.
-
The adversary poisons the DNS server by forcing the server to cache a record which has forged results. This means that any other users of this DNS server would get incorrect information from that DNS query.
-
The adversary uses DNS to launder his enumeration; rather than showing his IP address as making the lookups, your IP address is the one making the request, since you are acting as a proxy for him.
To test for recursive resolution, simply query the server from an IP address that is outside your administrative domain using the host or nslookup commands:
-
untrusted$ host www.google.com 192.168.1.1
If you get back IP addresses for google, the server is configured to allow recursive queries for the untrusted client, and thus, usually everyone.
3.1.2 Zone Transfers
In this misconfiguration, untrusted clients are allowed to transfer entire zone files, rather than looking up individual names. Since the names of your machines may indicate their function, and they will be associated with an IP address, this allows an adversary to enumerate the machines in their networks, their roles, and their IP addresses.
-
untrusted$ host -l mine.com 192.168.1.1
If it does not say “transfer failed”, you are vulnerable.
In this misconfiguration, the name server is supposed to serve a given domain to certain trusted clients, but allows anyone to query for the same information. By doing so, it enables the adversary to make guesses about your domain names and retrieve IP addresses associated with them. If names map into functionality, this gives the adversary a knowledge of what purpose a machine with a given IP has. There are hostname guessing scripts designed for this purpose; when they work well, the results are similar to a zone transfer.
3.2 BIND 9
3.2.1 Defining Access Control Lists
BIND 9 supports access control lists (ACLs), which can make configuring the server much simpler and reduce repetition of things like IP addresses and netblocks. By having all this information in one place, it reduces the chance of you changing one and forgetting to change the list in another location, and that increases security. You should use them.
First, define an ACL for clients which are allowed to do anything with the server. This example includes localhost (127.0.0.1) in IPv4 notation as well as IPv6.
-
acl clients { localhost; ::1; };
Next define one for the nameserver slave machines which will need to do zone transfers:
-
acl slaves { 192.168.1.2; };
Next define an ACL for all the clients that should be authorized to use this server for recursve lookups:
-
acl recursive { clients; 192.168.1.0/24; };
3.2.2 Disabling Recursive Lookups
-
options { allow-recursion { recursive; }; };
3.2.3 Disabling Zone Transfers
-
zone "mine.com" { allow-transfer { slaves; }; };
3.2.4 Controlling Who May Query What Domains
-
options { allow-query { clients; }; };
-
zone "mine.com" { allow-query { any; }; };
4 SSH
4.1 General Issues
4.1.1 Root Logins
Some people wish to enhance their security by not allowing direct logins as root. As I see it, they may do this for multiple reasons:
-
It’s easy to guess the root username, whereas other usernames might be more difficult. I say that the security of the system rests entirely in the password; it should be effectively unguessable to have any security at all, since usernames are leaked via email and a number of other methods.
-
If you allow direct root logins, it can be difficult to figure out who logged in as root and did something at a particular time. System administrators can log in under their personal accounts and use su or sudo to execute commands as root, with more accountability.
However, disabling root logins prevents running rsync over SSH as root, which may be necessary for performing backups or what-have-you.
4.1.2 Using /bin/false As A Login Shell
4.1.3 TCP Forwarding
This feature allows clients which have authenticated to create TCP connections on the server side to any system that suits their fancy, including 127.0.0.1. These connections appear to come from the server, which may bother you. For example, he could abuse this by creating a network scanning program which launders its connections through your server. The sshd_config manpage properly points out that a user with a valid shell can do this by installing his own forwarder, but that would be more difficult and easier to detect, since by default sshd does not log valid connections at all, much less TCP forwarding.
4.1.4 Supporting Protocol Version 1
There were a number of security problems found in protocol version 1, and it may be possible as a man-in-the-middle to force an SSH handshake to be version 1 rather than version 2. For this reason it is recommended that you force your server to support only version 2 of the protocol.
4.2 OpenSSH
All server configuration is done in /etc/ssh/sshd_config.
4.2.1 Disallow Root Logins
4.2.2 Disallow Password-Based Logins
-
PasswordAuthentication no
4.2.3 Disallow TCP Forwarding
5 SMTP
5.1 General Issues
5.1.1 Open Relays
Perhaps the most serious mail configuration error involves relaying email for anyone. In this case the adversary forges some email and provides it to your system for delivery. Your system then happily delivers his spam, and since the From fields are forged, the bounces go to some innocent third party who has been “joe-jobbed” (
http://en.wikipedia.org/wiki/Joe_job). Mail servers like this are sure to be found and abused, then your IP address will be blacklisted as delivering spam.
5.2 Postfix
5.2.1 smtpd_recipient_restrictions
By default, Postfix has a moderately restrictive approach to mail relaying. Postfix forwards mail only from clients in trusted networks, or to domains that are configured as authorized relay destinations.
-- http://www.postfix.org/SMTPD_ACCESS_README.html
6 HTTP
6.1 General Issues
6.1.1 Directory Indexing
In this misconfiguration, you have enabled “indexes” of directories where you did not intend to. This results in an adversary being able to look at the contents of the directory, and possibly find files that he or she may not have been able to find otherwise. Thus, confidentiality is lost. However, one should be aware that merely turning off directory indexing is insufficient security; you should protect files you don’t want disclosed with password protection (at least); otherwise, the adversary need only guess the name of the file or directory, without the assistance of having and index. Furthermore, the URL for these files is going to appear in Referer logs of other web servers when somone follows a link from that page to another.
6.2 Apache 2
7 SNMP
7.1 General Issues
7.1.1 Community Strings
The community string is the most basic form of access control in SNMP; it should be treated as a shared secret, or password. Some devices come with the default community string either empty or the string “public”; these should be changed to something difficult to guess.
7.1.2 Authentication Trapping
If an adversary can modify snmpEnableAuthenTraps, he could prevent the system from sending traps for failed authentication. Once this is disabled, an adversary could start a brute-force attack on the admin password without causing any logs to be formed.
Needless to say, you should set up SNMP traps to log this kind of behavior, and verify that the OID is not writable by adversaries.
7.1.3 Write Access
You should have a secret community string for the read-write community, and guard it carefully.
Version 1 has no encryption whatsoever. The only protection it has is the community string, which can be sniffed. So upgrade to SNMP v2 or better.
You should use ACLs to restrict access to authorized nodes or subnets.
7.2 Net-SNMP
7.2.1 Community Strings
Check for lines such as the following and verify that their community string is not “public” or otherwise guessable:
-
com2sec SECURITYNAME default COMMUNITYSTRING
Test by running the following command:
-
snmpwalk -Os -c public -v1 server system
There should be no response from the system.
8 NTP
8.1 General Issues
8.2 OpenNTPD
9 NFS
There are a few exportfs options that you may enable on your exported partitions to enhance security. This assumes that you are exporting data partitions and not system partitions which may include device files and so on. It also assumes that you export full filesystems and not portions.
9.1 secure
This option requires that requests originate on an Internet port less than IPPORT_RESERVED (1024). This option is on by default.
9.2 mountpoint=path
This option makes it possible to only export a directory if it has successfully been mounted. If no path is given (e.g. mountpoint or mp) then the export point must also be a mount point. If it isn’t then the export point is not exported. This allows you to be sure that the directory underneath a mountpoint will never be exported by accident if, for example, the filesystem failed to mount due to a disc error.
If a path is given (e.g. mountpoint=/path or mp=/path) then the nominated path must be a mountpoint for the exportpoint to be exported.
9.3 root_squash
Enable this if you don’t want root accounts on client systems to have full access to the file system. Note that if they have root, they can su to any account they want, so this is of little use.
10 OpenVPN
10.1 DoS Attacks
Since the TLS/SSL handshake used by OpenVPN performs a public-key operation, it can be computationally intensive. An adversary could connect to you multiple times, forcing a resource utilization attack against the CPU. The way to prevent this is called tls-auth, and it basically is a symmetric key used to authenticate via an HMAC algorithm (
http://openvpn.net/howto.html#security).
-
openvpn --genkey --secret ta.key
-
tls-auth ta.key 0 (server)
-
tls-auth ta.key 1 (client)
10.2 MITM Attacks By Clients Impersonating Server