Re: Performance question Drop or Reject

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 <[email protected]> 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
> performance
> hit between the two
> > rules, is there anything else that might steer me towards picking one
> over
> the other?
>
> 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
> performance
> 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
> a
> 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.
>
> PaulM
>
>
>

_______________________________________________
firewall-wizards mailing list
[email protected]
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards