When working with iptables firewall rules in Linux, the fundamental difference between REJECT
and DROP
lies in how they handle unwanted network traffic:
# REJECT sends an explicit rejection response
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable
# DROP silently discards packets without response
iptables -A INPUT -p tcp --dport 22 -j DROP
The REJECT
action immediately notifies the sender that their connection attempt was refused, while DROP
makes the packet disappear without any acknowledgment. This creates different user experiences:
- REJECT: Web browsers show "Connection refused" immediately
- DROP: Browsers keep retrying until timeout occurs
While DROP
might seem more secure by making your system appear nonexistent, it can actually cause more problems:
# Example of REJECT being more network-friendly
iptables -A INPUT -p tcp --dport 80 -j REJECT --reject-with tcp-reset
# Example of stealth mode with DROP
iptables -A INPUT -p tcp --dport 23 -j DROP # Telnet port
There's minimal performance difference between the two actions, but REJECT
generates slightly more network traffic due to rejection packets. The choice should be based on operational requirements rather than performance.
Use REJECT
when:
- Managing internal networks where quick feedback is valuable
- Handling services that might retry aggressively
- Debugging firewall rules
Use DROP
when:
- Implementing stealth against port scanners
- Dealing with known malicious IPs
- On internet-facing ports where you want to appear non-responsive
# Combined example showing both actions
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j REJECT
iptables -A INPUT -p tcp --dport 22 -j DROP
When working with iptables firewall rules, both REJECT and DROP terminate unwanted connections, but their interaction with clients differs significantly:
# Silent packet discard
iptables -A INPUT -p tcp --dport 22 -j DROP
# Explicit rejection with ICMP response
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable
REJECT sends termination responses according to protocol specifications:
- TCP: Sends RST packet
- UDP/ICMP: Returns port-unreachable message
DROP simply discards packets without any notification, appearing as network latency to the client.
When to Use DROP
# Stealth mode for security through obscurity
iptables -A INPUT -p tcp --dport 23 -j DROP # Telnet protection
# Preventing port scanning feedback
iptables -N ANTISCAN
iptables -A ANTISCAN -m recent --name ATTACKER --set -j DROP
When to Use REJECT
# For internal services where quick failure is preferred
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 3306 -j REJECT
# User-facing services needing clear feedback
iptables -A INPUT -p tcp --dport 25 -j REJECT --reject-with tcp-reset
While REJECT generates additional network traffic, modern hardware impacts are negligible. Security implications:
- DROP may cause TCP retries (potentially 3 minutes of waiting)
- REJECT immediately terminates connections but reveals firewall existence
# Rate-limited REJECT for SSH brute force protection
iptables -A INPUT -p tcp --dport 22 -m recent --name SSH --update --seconds 60 --hitcount 3 -j REJECT
# Combination approach for different networks
iptables -A INPUT -s 10.0.0.0/8 -j REJECT
iptables -A INPUT -s 0.0.0.0/0 -j DROP
Network diagnostics differ between the two actions:
# DROP shows as filtered in nmap
# REJECT shows as closed (with appropriate nmap flags)
nmap -Pn -p 22 target_host