Re: merits of Reject vs. Drop
From: Myke Place (mp@xmission.com)Date: 01/17/02
- Next message: Jose Nazario: "Re: crack v.5 problems"
- Previous message: Tim Haynes: "Re: merits of Reject vs. Drop"
- In reply to: J: "merits of Reject vs. Drop"
- Next in thread: sverre: "Re: merits of Reject vs. Drop"
- Reply: sverre: "Re: merits of Reject vs. Drop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Myke Place <mp@xmission.com> Date: Thu, 17 Jan 2002 14:44:19 -0700
A couple of brief thoughts here...
ICMP DOS:
The first thing that comes to mind is the possibility of a DOS attack on
your firewall if an attacker can produce a large number of ICMP responses
generated by the reject rules. It seems resonable that you could be used
to DOS someone else if the ICMP responses were in response to a forged
source address. Of course many variables can affect the viability of this
attack, it would most likely be beyond the capacity of your pipe out to
the world to overwealm the firewall itself and this really isn't the most
effective way to DOS somebody other host on the net.
Host OS detection:
A really good port scanner such as nmap can analyze ICMP messages to
assist in remote host detection. It seems reasonable that an astute
attacker might notice that the differences in ICMP responses between the
firewall and the protected machine. This would clue them in that a
firewall was in place and give them additional information should they
choose to launch an attack against the firewall itself. Of course if the
host can't send ICMP messages back in the first place then this point is
moot, I just thought it was interesting... :) See
http://www.insecure.org/nmap/nmap-fingerprinting-article.html for more
info here.
Knowing that a firewall exists anyway:
There are techniques that an attacker could use to determine if a firewall
was in place that have nothing to do with. For example if you are blocking
all ICMP traffic, notably ICMP echo responses, it would be seem
suspicious if you could connect to a port on a machine but not ping it (of
course this isn't a sure sign but it's a clue). I'm sure others who are
more creative than I can think up a host of ways that might be more
complex.
Just my two cents.
-mp
On Thu, 17 Jan 2002 13:42:24 -0700, J wrote:
> I'm interested in comments on the merits of Rejecting packets vs.
> Dropping packets.
>
> Common beliefs suggest that dropping packets is always preferred to
> rejecting packets. I'm not so sure.
>
> Case 1: If I had no services running, and I dropped all new incoming
> packets, my machine would basically be invisible to potential intruders.
> So in this case, Dropping packets makes sense.
>
> Case 2: If I have services that I need running - SMTP and SSHD in my
> case - the merits of Dropping packets are not so clear. A potential
> intruder knows that we're running a firewall if they can see some ports
> opened and the remaining ports are dropping (not rejecting) packets.
> Knowing that we are running a firewall is a good tip that we may be
> running some valuable services that they can't get to. Rejecting
> packets behaves more like your basic dial-up account.
>
> Thoughts?
>
>
>
>
>
- Next message: Jose Nazario: "Re: crack v.5 problems"
- Previous message: Tim Haynes: "Re: merits of Reject vs. Drop"
- In reply to: J: "merits of Reject vs. Drop"
- Next in thread: sverre: "Re: merits of Reject vs. Drop"
- Reply: sverre: "Re: merits of Reject vs. Drop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]