Don't make any hard-coded
assumptions about service
Use the library
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,
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.
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.
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
servers that may continue attempting delivery indefinitely.
Put reasonable time-outs on each network
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
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).
Consider doing a call to the
service on the remote site to identify
the putative source of the connection.
not to place too much trust in the response.
Do not require the user to send a reusable
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
protocol used in the
mail service has the server send the client a
unique character string, usually including the current date and
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
Consider adding some form of session
encryption to prevent eavesdropping and foil session hijacking.
But don't try writing your own cryptography
for algorithms that are known to be strong.
Build in support to use a proxy.
, described in
Wrappers and Proxies
) so that the code is firewall
Make sure that good logging is performed.
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
Usually, this process means trapping the
signal and cleaning up afterwards.
Consider programming a "heartbeat"
log function in servers that can be enabled dynamically.
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.