5. Network Address Translation

NAT (strictly NAT/PAT) setups with multiple systems sharing a single public IP address, make tracing problems far harder, owing to the loss of the usual one-to-one mapping between host and public IP address. It is still essential that network traffic be traceable to a single host on the internal network.

Many NAT setups provide a certain amount of logging, for instance a log of all HTTP connections. While useful, these data are not sufficient, and will fail to log anything for certain types of malware.

In order to reliably trace the source of an outgoing network connection from a system behind NAT, it must be possible to map from the public data (timestamp, protocol, source and destination IP addresses, source and destination ports where appropriate) to the IP addresses and port numbers used on the internal network.

A tool such as Argus running on a mirror port may be useful for recording details of every network flow on the inside of a NAT gateway. For almost all purposes the data gathered will be sufficient. However, argus will not log the NAT gateway's port number mappings as packets traverse the gateway. This may cause problems under certain circumstances. Ideally the gateway itself should log the mappings as used within its own state table. Please bear in mind that every outbound connection attempt which reaches the backbone network needs to be logged. It is not sufficient merely to log successful connections, as such logs will be missing information that is often vital to OxCERT.

OxCERT have given presentations covering NAT, from which slides are available here, in particular our Introduction to NAT Logging will be of use. Addditionally, please see the network team's documentation on Network Address Translation for more general details on NAT.

Up: Contents Previous: 4. Multi-user systems Next: 6. DNS server logs