Hatch - Hacking exposed Linux: Linux security secrets & solutions

.

Special thanks to Jonathan Bokovza, arnas Grigalinas, and Harald Welte for their timely assistance when a little help was required. Also special thanks to Jane Brownlow, Jennifer Housh, and LeeAnn Pickrell.

.

Being responsible for a computer environment is a task that requires thorough procedures and helpful tools. This appendix gives insight into the decisions a system administrator needs to make when setting up nodes, designing a network, and implementing tools that help in everyday system administration tasks. The first half of this appendix could be used as a sort of checklist, whereas the other half includes references to interesting projects and applications.

A best practices setup begins at its lowest level: the nodes. A node could be a server, a blackbox device, a workstation, or anything else that is connected to a network. The next few sections detail necessary decisions that influence the way you set up a node. The hints are intended to be operating-system independent, but the mentioned tools and commands have been tested on Linux.

Cryptography has been used in computers only for a short time. Therefore, many solutions and applications still transmit data unencrypted and unauthenticated. This increases the possibility of two common attacks:

Sniffing passwords and other sensitive information off the wire

Man-in-the-middle attacks

Using a network sniffer, such as Wireshark or tcpdump , you can reveal the contents of a clear-text network transmission. shows an example of Wireshark, which displays a clear-text HTTP connection with the help of the Follow TCP Stream function. Looking at that example, it is quite clear that the network communication was unencrypted and thus vulnerable.

Today's best practices solution against these threats is to use cryptographically secured services wherever possible. These services have three common characteristics:

Data is transmitted encrypted, thus making it quite complex, if not impossible, for an attacker to discover the transmitted contents in clear text.

Figure A-1 Wireshark displays the contents of an unencrypted network connection.

Each server and client involved in the communication can be identified. This makes spoofing an identity quite complex, if not impossible, for an attacker.

Transmitted data is integrity checked, thus preventing unnoticed modifications on sent data.

A commonly used protocol that implements the cryptographic measures outlined here is HTTPS. All data is transmitted encrypted through SSL, and servers and clients can be identified through x.509 certificates. Although having a certificate isn't mandatory for clients, servers need to have one. Web browsers complain if a server certificate is considered invalid.

More resources are needed when using such cryptographically secured protocols as compared to their clear-text counterparts because they involve mathematical calculations. Fortunately, today's hardware renders the performance drawback practically unnoticeable, so there is no good reason not to deploy encrypted services.

Most of the protocols allow clear text and an encrypted variant (HTTP vs. HTTPS). Therefore, you need to take specific countermeasures to avoid users accidentally employing the clear-text variant (with the HTTP example, it would be possible to configure the server to accept only HTTPS connections).

A common attack to obtain access to a system is to brute-force usernames and passwords. The most promising prevention for this kind of attack is to avoid passwords altogether and switch the authentication method to one of the other available authentication techniques that are more resistant to such attacks (e.g., public key or smartcard authentication). The features and setup instructions vary depending upon the particular techniques. One popular service, where public key authentication is used, is SSH (the ssh-keygen man page includes setup instructions).

An appropriate policy while configuring the services on a node is to generally deny everything and only allow what's specifically needed. For example, OpenSSH has configuration options for users that are allowed to log in. shows some of the configuration options that can be applied to sshd_config . The settings cover the following decisions:

Is the root user allowed to log in?

Is anyone allowed to log in with an empty password?

Is anyone allowed to log in with passwords at all?

Are only certain users or groups allowed to log in?

If only public key authentication is used, why not disable password authentication completely in the services configuration? If only certain users need SSH access to a node, why not specifically only allow them in the service configuration? In a best practices setup, such considerations should be made and applied to the services configuration.