Sometimes a network needs to be isolated from another one. The most common case is a LAN that needs to be protected from
unsolicited access via the Internet.
Any LAN security (NetBIOS scope IDs, port access permissions etc.), application layer filtering (proxy servers) and IDS/IPS are outside scope of this article.
Basic protection can easily be achieved by a NAT router. Although there are several different NAT types and
implementations they all have the same principle - they forward only those incoming packets that should be response to some of outgoing.
Such simple NAT can protect against most simple connection attempts. The hardware required for this can be as low as a simple cheap
router with NAT capability.
To achieve more sophisticated protection additional filtering should be used. This should include filtering out all unknown and unexpected.
- Tight stateful inspection is required. Although every NAT implementation has to use some kind of stateful inspection/translation, a detailed one
(inspecting TCP flags etc.) should be used.
- Router should reassemble packets before checking and forwarding rather than forward each fragment separately. This can protect from fragmentation
exploitation attacks. Actually this is a part of tight stateful inspection.
- Filtering should be done as much on interface basis as possible. Filtering on source IP addresses should be used as less as possible, because
IP addresses can be faked.
- Unsolicited ARP packets should be filtered (or ignored) or static ARP entries (especially for routers on untrusted multiple access networks) should be
used. This can avoid malicious traffic redirection.
- ICMP messages with type 5 (Redirect) should be filtered out (or ignored). As the name says they can be used for traffic redirection.
- Also filtering of any routing protocols on untrusted networks is highly suggested.
Additionally these measures should be taken to workaround common misconfigurations, various software drawbacks and hide network topology.
This will create additional layer of protection so even if generic filtering will be bypassed the most common entry points will remain closed.
- More tight address filtering should be used. Router should drop all packets from untrusted network (Internet) where destination IP address isn't
address of router (or in appropriate address pool). If required, exceptions for DHCP and other broadcast traffic should be defined. This can prevent some
routing related attacks.
- All packets with source IP addresses that doesn't belong to network from which the packet arrives should be dropped. This filtering
protects against some address spoofing. Exceptions for DHCP and similar protocols may be needed.
- Unused IP protocols should be filtered out. In most cases only TCP, UDP and ICMP should be allowed. Often there is very less support for tracking such
unpopular protocols and sometimes they can be supported by hosts on protectable network.
- Packets with IP options should be dropped. IP options are often used to explore network topology and alter normal routing. Although they are almost
never used in regular network communication.
- For packets from untrusted networks with low TTL (low enough to expire before reaching destination host on trusted network) TTL should be increased to
be high enough (to reach destination). This will block certain attempts of discovering network topology.
If NAT is used for packets coming from trusted networks to untrusted, normal TTL for such packets may be increased to TTL of router. This would
cloak one of most common signs of IP level forwarding. Both these techniques require extra caution to prevent routing loops.
- Router should respond with TCP reset to all invalid TCP packets (except packets with RST flag set) or at least to such packets from trusted networks.
This can prevent creation of TCP connection even if somehow initial packet is injected in network.
For this kind of protection a PC running Linux with properly configured
Netfilter can be used.
Additionally such Linux can be run from a read-only media. PC hardware requirements depend mainly on network complexity (count of simultaneous
connections) and throughput required. For small networks an old P120 with 32MB RAM will do.
I would suggest
FloppyFW distribution, because it is relatively well maintained and provides direct
configuration of Netfilter (via shell script). FloppyFW also has a development kit allowing easy compilation of custom builds (
TTL target and
ipv4options match Netfilter patches are additionally required to implement abovementioned methods with FloppyFW).
