14.12. Miscellaneous Recommendations

In the course of the book, I have considered numerous aspects of the task of creating a secure system; however, some of the recommendations I would like to offer could not be placed into any of the topics considered . Therefore, I decided to place all of them at the end of the book.

14.12.1. Packet Defragmentation

Packet fragmentation is often used to carry out attacks on servers. Linux can be configured to defragment incoming packets. If your kernel is monolithic (i.e., lacks module support), this can be achieved by writing 1 to the /proc/sys/net/ipv4/ip_always_defrag file. This can be done by executing the following command:

 echo 1 > /proc/sys/net/ipv4/ip_always_defrag

For newer kernel modules, which support modules, the ip_conntrack module has to be loaded using the following command:

 modprobe ip_conntrack

14.12.2. Source Routing

As you should remember from Section 14.5.3 , inside a network packets are moved using MAC addresses, and between networks they are moved using IP addresses. In the latter case, a router is necessary to move packets to the proper address. Routers determine the route for sending packets from the source to the destination. However, these devices are programmable, and there are several methods of sending packets over specific routes. One of these methods is source routing.

Source routing involves specifying the route, over which a packet is moved from the source to the destination. Sometimes, this is a handy option, but, as you already know, what is convenient usually is not secure. The source-routing feature is better disabled, and it would be the best if it had never been invented.

So how does source routing affect security? Suppose that you detected an attack attempt from address 192.168.1.1 and took countermeasures by configuring the firewall to prohibit connections from this address. Because routers send all packets from the hackers through this address, the hackers can no longer connect to your system. But they can use the source-routing feature to specify the route, by which their packets are to be moved to your system and to exclude the router, or a server playing the role of a router, with the disallowed address from this route.

Unfortunately, you cannot disable the source-routing feature on a hacker's computer; but you should disable it on your own computer, and even more so on the computer used as the Internet gateway (the proxy server or firewall). This can be done by writing 1 to the /proc/sys/net/ipv4/conf/all/accept_source_route file as follows :

 echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

14.12.3. SNMP

The Simple Network Management Protocol (SNMP) is used to control network devices, such as routers, programmable switches, and even home appliances connected to a network.

There are three versions of this protocol. The first version was developed a long time ago and does not employ encryption. The encryption option was added to SNMP in the second version. Therefore, you are recommended not to use the first version of the protocol; in the best case, it should be disabled altogether.

Another drawback of SNMP is that it uses UDP as the transport. This means that SNMP packets are transmitted as payload inside of UDP packets. Because UDP does not support virtual connection and just send packets without any authorization, any fields of its packets can be faked.

I recommend not using SNMP, because most tasks do not require it. The encryption feature added in the second version has raised the protocol's security significantly, and it can be used for especially important tasks. You have to make sure, however, that the second or a higher version of the protocol is on hand before using it for tasks requiring data protection.

14.12.4. Absolute Path

When running some utility, most users and even administrators simply enter the command's name , which may lead to a break-in. Thus, you should specify the complete path when launching any program.

The following is an example of how using short names can be used to compromise the system:

A file with the same name as the target program, let it be ls, is created in a public directory, for example, /tmp.

A script to carry out specific actions is saved in this file. For example, the following:

 #!/bin/sh # Changing access rights to the /etc/passwd and /etc/shadow files chmod 777 /etc/passwd > /dev/null chmod 777 /etc/shadow > /dev/null # Executing the ls program exec /bin/ls "$@"

The script contains only three commands or, rather, only two because the first two commands are the same, just applied to different files. These first two chmod commands change access rights to the /etc/passwd and /etc/shadow files. Moreover, any system messages that may be produced when these commands are executed are redirected to the /dev/null device and are not displayed on the screen. The second command in the script file executes the legitimate ls system command from the /bin directory.

Now, set the file's execute permission so that it can be executed by any user :

 chmod 777 /tmp/ls

The fake ls file is ready. But now it has to be made to execute instead of the system's legitimate ls file. This is an easy enough task: Simply add the /tmp directory at the beginning of the PATH system environment variable. Now, if the ls command is executed without its full path specified, executed instead of it will be the script file, which will try to change access rights to the password files. If the user who executes the command has enough privileges for this, the attempt will be successful and you can consider the system as good as cracked.

The conclusion that should be drawn from this example is that you should regularly check the contents of the PATH environment variable for potential modifications. If you find that the variable has been changed, you can consider your system compromised and should initiate the post-break-in procedure.

14.12.5. Trusted Hosts

The .rhosts file contains names of trusted hosts. Users of these computers can connect to your computer remotely using such programs as Telnet or FTP without having to go through the authentication process.

The security aspects of remote connections are described numerous times throughout this book, so by now you should easily see that the source address can be easily faked. Once this is done, your computer becomes a public thoroughfare.

14.12.6. Password Protection

The main thing for protecting a Linux password is to safeguard the /etc/shadow file. In addition, you should also make sure that users have strong passwords. To this end, you should regularly run password-cracking programs using popular dictionaries that can be found on the Internet, which are what hackers usually exercise. If the passwords are strong, then even if hackers manage to get their hands on the /etc/shadow file, it will take them too long to decrypt the passwords in it for the passwords to be of any use, that is, if they can decrypt them at all.

But not everything is as easy as it seems to be. Where system login passwords are protected by the operating system and have mandatory encryption, passwords used in other programs may not be afforded this protection. For example, user programs to access certain services, such as FTP or POP3, may not use encryption. In this case, their passwords may be stored in a configuration file in plaintext.

Before installing any program, determine where it stores its passwords and whether they are encrypted and how. Set such file permissions that only the specific user and the administrator can have access to them. It is desirable that groups are assigned zero rights, especially if there is more than one user in a group .

If a separate group is created for each user, the group may be given some rights. Nevertheless, I would recommend against this, because you never know what may become of a group in the future. A hacker may add himself or herself to a group, or you may join several users into one group.

I recommend to all my users not to save passwords in programs. This means, for example, that the password has to be supplied every time a user checks his or her mail. This is inconvenient, especially if you have more than one mailbox, which nowadays is a norm. But even with only one mailbox, users are difficult to convince to memorize passwords and not save them in the system.

But passwords have to be entered directly into the program; ideally , they should not be displayed on the screen. This means that passwords should not be specified in the command line, which displays all data entered into it.

There are many methods to oversee a password being entered, for example, the ps utility. A good example of a proper way to enter a password is the login utility. When you are logging into Linux, the password entered is not displayed on the screen.

Passwords may be stored in plaintext in databases, which is where the most important data of any company are stored. Databases are a separate subject that requires a book in itself and is beyond the scope of this book. Databases, however, always should be kept in mind.

14.12.7. Redirecting Services

Services used by a limited number of users should work on nonstandard ports. This will protect the system from many potential problems.

One of the most common security threats presented by using standard ports is that they can be scanned. For example, a hacker discovers that there is a bug in a particular database. Suppose that this database uses port 1457. All the hacker needs to do to find vulnerable databases is to scan the network for computers with port 1457 open . Having detected such machines, the hacker can write a program that exploits the vulnerability on all of these machines.

The problem is easily solved by reconfiguring the service to use another port and removing any banners that may be displayed when a connection to this port is being established. This will prevent the hacker from learning what port the program uses and how to work with it.

If services are used by a limited number of people, the ports of the most vulnerable services (e.g., those that allow users to upload files to or execute commands on the server) can have their places switched. For example, make the FTP service work on port 80 and the Web service on port 21. Unfortunately, public services cannot be made to work on different ports. For example, making a Web server work on port 81 instead of the standard port 80 would require that every potential user of this service be informed of this change. This defeats the purpose of port switching, because a hacker is also a potential user.