Re: [fw-wiz] Performance question Drop or Reject
- From: Jason Lewis <jlewis@xxxxxxxxxxxxxxx>
- Date: Fri, 15 Jan 2010 13:24:43 -0500
Very helpful. I was in the process of blocking outbound SMB and wondered if
there was any cost benefit to using one over the other. Sounds like
REJECTing internal clients and DROPing external requests is the way to go.
On Fri, Jan 15, 2010 at 7:19 AM, Paul Melson <pmelson@xxxxxxxxx> wrote:
_______________________________________________Is there any performance difference between a Drop/Deny or Reject rules?IDK if it's > relevant, but I'm using iptables. If there isn't
hit between the two
rules, is there anything else that might steer me towards picking oneover
The difference between DROP and REJECT in iptables is that DROP simply
discards the packet while REJECT discards the packet and sends an ICMP
host-unreachable response to the source IP. You can also configure TCP
REJECT rules to respond with a TCP RST packet. There are several
and security considerations that should be weighed when setting up your
rules and deciding whether to DROP or REJECT.
From a CPU and memory standpoint on the firewall, the difference is
negligible since we're not inserting into the state table with either DROP
or REJECT. Deciding whether or not to log a rule has a much bigger impact
on the firewall's performance.
From a network performance standpoint, DROP is always cheaper because it
doesn't put new packets on the wire. It's also typically more secure. An
attacker can use spoofing against REJECT rules to attempt a DoS attack or a
reflection scan of another system using your firewall to generate the
packets. For this reason, you want to use DROP for your external-facing
rules wherever possible.
From a client performance standpoint, REJECT is often preferred. In the
case of a DROP rule, the client gets no response so it must wait for the
connection to time out before closing the connection attempt. If a REJECT
is used, then it fails much more quickly. For this reason, you may choose
to use REJECT rules for some internal-facing rules to avoid network timeout
conditions. It also makes troubleshooting network connectivity issues
easier since the client actually gets a response, it's easy to distinguish
firewall REJECT from an internal routing problem. Be careful, though, that
you don't unintentionally create internal network performance issues with a
REJECT rule because it's being triggered constantly.
Hope that helps.
firewall-wizards mailing list