Tips on Writing Network Programs
If you are coding a new network service, there are also a number of pitfalls to consider. This is a partial list of concerns and advice for writing more secure network code:
- Don't make any hard-coded assumptions about service port numbers.
Use the library getservbyname() and related calls, plus system include files, to get important values. Remember that sometimes constants aren't constant.
- Don't place undue reliance on the fact that any incoming packets are from (or claim to be from) a low-numbered, privileged port.
Any PC can send from those ports, and forged packets can claim to be from any port.
- Don't place undue reliance on the source IP address in the packets of connections you received. Such items may be forged or altered.
- Do a reverse lookup on connections when you need a hostname for any reason.
After you have obtained a hostname to go with the IP address you have, do another lookup on that hostname to ensure that its IP address matches what you have.
- Include some form of load shedding or load limiting in your server to handle cases of excessive load.
Consider what should happen if someone makes a concerted effort to direct a denial of service attack against your server. For example, you may wish to have a server stop processing incoming requests if the load goes over some predefined value.
- Put reasonable time-outs on each network-oriented read request.
A remote server that does not respond quickly may be common, but one that does not respond for days may hang up your code awaiting a reply. This rule is especially important in TCP-based servers that may continue attempting delivery indefinitely.
- Put reasonable time-outs on each network write request.
If some remote server accepts the first few bytes and then blocks indefinitely, you do not want it to lock up your code awaiting completion.
- Make no assumptions about the content of input data, no matter what the source is.
For instance, do not assume that input is null-terminated, contains linefeeds, or is even in standard ASCII format. Your program should behave in a defined manner if it receives random binary data as well as expected input.
- Make no assumptions about the amount of input sent by the remote machine.
Put in bounds checking on individual items read, and on the total amount of data read (see the sidebar for one reason why).
Getting More Than You Expected
You must ensure that your programs, whether they run locally or over a network, properly handle extended and ill-defined input. We illustrate this point with an edited retelling of an anecdote related to one of us by Tsutomu Shimomura.
One day, Shimomura noticed that a certain Department of Energy FTP server machine was set to finger any machine from which it received an anonymous FTP request. This bothered Shimomura a little, as anonymous FTP is more or less as the name implies. Why should the administrators of that site care? If who was on the machines connecting to theirs mattered, they shouldn't have put up anonymous FTP.
This also piqued Shimomura's scientific curiosity, however. Were they using standard finger? He modified his local inetd configuration to point incoming finger requests to his character generator (chargen). He then connected to the remote FTP server and logged out again.
Over the next few hours, Shimomura's machine shipped tens of megabytes of characters to the remote site. Eventually, late at night, the connection was broken. The remote machine no longer answered any network requests and appeared to have disappeared from the network. When it reappeared the next morning, the automatic finger-of-machines connection for FTP was no longer present.
The moral of this little story is that if you are going to ask for something, be sure that you are able to handle anything that you might get.
- Consider doing a call to the authd service on the remote site to identify the putative source of the connection.
However, remember not to place too much trust in the response.
- Do not require the user to send a reusable password in cleartext over the network connection to authenticate himself.
Either use one-time passwords, or some shared, secret method of authentication that does not require sending compromisable information across the network.
For instance, the APOP protocol used in the POP mail service has the server send the client a unique character string, usually including the current date and time.[10] The client then hashes the timestamp together with the user's password. The result is sent back to the server. The server also has the password and performs the same operation to determine if there is a match. The password is never transmitted across the network. This approach is described further in the discussion of POP in TCP/IP Services.
- Consider adding some form of session encryption to prevent eavesdropping and foil session hijacking.
But don't try writing your own cryptography functions; see Cryptography, for algorithms that are known to be strong.
- Build in support to use a proxy.
Consider using SOCKS, described in Wrappers and Proxies) so that the code is firewall friendly.
- Make sure that good logging is performed.
This includes logging connections, disconnects, rejected connections, detected errors, and format problems.
- Build in a graceful shutdown so that the system operator can signal the program to shut down and clean up sensitive materials.
Usually, this process means trapping the TERM signal and cleaning up afterwards.
- Consider developing a "heartbeat" log function in servers that can be enabled dynamically.
This function will periodically log a message indicating that the server was still active and working correctly, and possibly record some cumulative activity statistics.
- Build in some self recognition or locking to prevent more than one copy of a server from running at a time.
Sometimes, services are accidentally restarted, which may lead to race conditions and the destruction of logs if it's not recognized and stopped early.