From: Paul Melson (pmelson@gmail.com)
Date: Wed Apr 04 2007 - 20:01:29 EDT
On 4/3/07, Mohamed Abdel Kader <mak.pen@gmail.com> wrote:
> I wanted to gather your opinions on whether firewall rules should be Dropped
>
> Or Rejected. To me I believe that both give away the firewall rules.
>
>
> What does everyone out there think?
A 'reject' action on a firewall really means that you send an ICMP
3:3* (destination/port unreachable) message back to the source. Best
practice for this is to use drop unless there's a specific need for
the source to receive an ICMP reject message. Using reject
incorrectly can make your firewall a pawn on DoS attacks by spoofing
ICMP or DNS traffic to it. One of the few reasons to use reject is
for inside-facing rules where drop timeouts negatively impact
performance (i.e. If you block outbound SMTP from a set of UNIX
servers, using reject causes Sendmail to detect a 'fatal' condition
quickly and bounces the message back instead of filling up the queue
for days.)
As far as giving away information, your firewall will probably be
detected but also assumed by attackers. Your firewall policy should
be to deny all traffic except for the [small number of] services that
you need to allow through. This shouldn't be any big deal. No worse
than ICMP timestamps being allowed on your routers, for example.
Also, the fact that you're asking about drop vs. reject tells me that
there's a good probability that your firewall is either Check Point or
iptables. Recon is easy. Get over it. The best thing to do is to
harden your network against attack assuming that those details are
publicly available.
PaulM
* http://www.networksorcery.com/enp/protocol/icmp/msg3.htm
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:41 EDT