Packet filtering firewalls follow a methodology whereby they analyse the source, destination and port numbers of traffic as it arrives at the firewall. When a packet arrives it passes through a set of rules and follows the course of action determined by the first rule it matches. This course of action will turn out to be one of the following three:
- ACCEPT
Traffic is allowed to pass just as if there is no firewall in place. If the port is closed at the destination, then a response will be returned from the destination exactly as if a REJECT rule is in place. Whether or not the above responses are forwarded on beyond the firewall depends on whether any filtering is employed by the firewall to drop the responses or not.
- REJECT
When a packet is arrives at the firewall and matches a REJECT rule, the following responses occur depending on whether TCP or UDP;
When a TCP connection attempts a 3-way handshake with a closed port then a RST packet should be sent back as a response. See RFC793.
When UDP attempts a connection to a closed port there is no action required by the UDP protocol according to RFC768. However according to ICMP RFC792 a message Type 3 Code 3, Destination Unreachable: Destination port unreachable that may be sent.
This makes basic port scanning a lot faster since the source is notified that the port is closed straight away and does not attempt to retry connecting. Using REJECT is also a give-away that a packet filtering firewall is in place.
- DROP
When a DROP rule is matched the firewall discards the packet and sends no response back to the source host that sent the packet. The host originating the connection will continue to wait for a response until a timeout occurs. It may then attempt to retry the connection after the timeout occurs. Timeouts can be anything over a minute long.
Internet Connected Zones
Everything internet facing will be attacked. As a rule of thumb; for anything internet connected it is best to use DROP instead of REJECT. This will slow down basic port scans and cause lengthy timeouts where elementary script may have been developed to attack a specific port. However a sophisticated port scanner like nmap will not be effected by using DROP.
DROP may also protect against DoS attacks on DSL links. This is because the download speed receiving traffic is much greater than the upload speed. If using REJECT, the traffic attempting to get through on a much larger download bandwidth may cause the firewall to overload the upload with ICMP responses resulting in a DoS.
The downside of using DROP on internet facing zones is that it may make it difficult troubleshooting inbound connectivity from the internet due to lack of ICMP response which may cause inbound connections to timeout.
Trusted Zones
Where a firewall is configured to disallow traffic sourced from a trusted zone such as your internal LAN for example; it is recommended to use REJECT for this purpose. Since a REJECT rule sends a response back to the source host in a single round-trip-time, this means that your client devices will receive an instant response from the firewall without having to wait for a lengthy timeout to occur.
In contrast, a DROP rule would notnotify the source host, and may result in unpredictable behaviour which may give the impression that the client or source host has crashed or hung.
Conclusion
There is debate about when to use DROP versus REJECT, and there is no perfect implementation. This post describes what is probably best suitable in most basic firewall setups where the internet is on one side and the internal LAN is on the other. It comes down to whether you either want to gracefully notify hosts using REJECT, or send them no response and let them timeout using DROP.
In summary; use REJECT to disallow trusted hosts by gracefully informing them that the traffic is not allowed to pass, and use DROP in an attempt to cause delays and disruption to a no so persistent attacker by sending their packets into a black hole without any response for them to analyse.
Other articles you might like:
Processing of PCAP files with Snort