firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Performance question Drop or Reject (Jason Lewis)
2. Re: Performance question Drop or Reject (K K)
3. Re: Performance question Drop or Reject (Paul Melson)
4. Re: Performance question Drop or Reject (Paul D. Robertson)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jan 2010 13:24:43 -0500
From: Jason Lewis <jlewis@packetnexus.com>
Subject: Re: [fw-wiz] Performance question Drop or Reject
To: Paul Melson <pmelson@gmail.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<554140e81001151024x16d8d2e9mc74a9342058b7608@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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@gmail.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20100115/1137eaae/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 15 Jan 2010 10:56:11 -0600
From: K K <kkadow@gmail.com>
Subject: Re: [fw-wiz] Performance question Drop or Reject
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<dc718edc1001150856w4e900ac0r30beefd627856555@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Jan 13, 2010 at 9:10 PM, Jason Lewis <jlewis@packetnexus.com> 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?
Reject involves generating a new reply packet and transmitting it,
this does have a performance impact.
Drop is "faster", a drawback to drop is that the originating host is
likely to re-send the packet, so you'll just have to do the work
again. If your site is often the target of spoofed packets (e.g.
DDoS), then you would want to choose "drop".
IME, the #1 reason people chose "Drop" is that they like to see
"stealth" in their ShieldsUP! results :)
------------------------------
Message: 3
Date: Fri, 15 Jan 2010 07:19:35 -0500
From: "Paul Melson" <pmelson@gmail.com>
Subject: Re: [fw-wiz] Performance question Drop or Reject
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@listserv.icsalabs.com>, "'Jason Lewis'"
<jlewis@packetnexus.com>
Message-ID: <000a01ca95dd$0078d3b0$016a7b10$@com>
Content-Type: text/plain; charset="iso-8859-1"
> 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
------------------------------
Message: 4
Date: Sat, 16 Jan 2010 11:10:12 -0500 (EST)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] Performance question Drop or Reject
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.44.1001161059440.13495-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 15 Jan 2010, Paul Melson wrote:
> 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.
More properly, thaqt should be be an ICMP *destination* unreachable. For
TCP and UDP I'd expect to see code 3 (port unreachable) as the destination
unreachable code (unless the source address is a broadcast or multicast
address) although filters should give back code 9, 10 or 13. Code 1 is
host unreachable, and is generally only sent by routers.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
Moderator: Firewall-Wizards mailing list
Art: http://PaulDRobertson.imagekind.com/
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 45, Issue 7
***********************************************
No comments:
Post a Comment