Configuration Security
travis+security@subspacefield.org
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:
- http://www.subspacefield.org/security/configuration_security/
-
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
http://www.windowsecurity.com/articles/DHCP-Security-Part1.html
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
Most of these configuration tips come from the DNS HOWTO (http://www.langfeldt.net/DNS-HOWTO/BIND-9/DNS-HOWTO.html).
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
http://www.semicomplete.com/articles/ssh-security/
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
http://www.mail-abuse.org/
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
http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
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
http://www.networkworld.com/newsletters/sec/1004sec1.html
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
http://net-snmp.sourceforge.net/
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
http://openvpn.net/index.php/documentation/howto.html
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
http://openvpn.net/index.php/documentation/howto.html#mitm
File translated from
TEX
by
TTH,
version 3.85.
On 28 Jul 2010, 14:23.