More suggestions :)
>>The best way to differ between a port which the firewall is configured
>>to "drop" a packet(s) and a port the firewall is configured to
"reject"
>>a packet(s) is to look for the ICMP Error Message (Destination
>>Unreachable - Communication with Destination Network is
Administratively
>>Prohibited) as you stated.
>This is to expand on what Ofir wrote.
>If a TCP packet is =not= filtered, and there is no listening
>socket, the response should be a RST. This should also be taken
>into account. If a UDP packet is =not= filtered, and there is
>a listening socket, a response is application layer specific
>and typically a misunderstood datagram will be dropped. So a
>firewall dropping a UDP packet and a listening UDP socket can
>be difficult to differentiate. If there is no listening
>UDP socket, a Destination Port Unreachable message should be
>returned. But if we are talking about a firewall between
>source and destination, we don't know anything if the
>firewall happens to drop those Unreachables. Such is life
>made more difficult.
Imagine there is no spoon.
What you can do is to test for firewall presence. This is a very simple
test that will give you the ability to understand what you facing.
With UDP you can use this remedy:
Choose some UDP ports that should be 99.9% close. How can you choose, or
where to choose from? You can try for example the IANA list of
registered ports.
Now, a closed UDP port will elicit an ICMP Destination Unreachable Port
Unreachable error message back to the sender.
This means that when trying to communicate with a limited number of
presumably closed UDP ports we have chosen we need to receive ICMP
Destination Unreachable error messages for all UDP packets hitting these
close UDP ports. If we are not receiving any reply back than it is 99.9%
that there is a Firewall which is between the source IP and the
Destination IP.
With this way we limited are choices of who are we communicating with,
and who is sending us the ICMP error messages.
>>As a thumb rule configuring a firewall to "reject" rather than "drop"
is
>>a mistake. The firewall needs to be transparent as possible for
traffic
>>going through.
>It depends if the firewall returns a RST on reject. One
>example where this is useful is to RST ident. I think the
>actual reject response (ICMP or TCP RST) is implementation
>specific and depends on semantics.
One nice added value for the auditor will be the ability to identify the
operating system the FW software will be installed on, given the fact
the firewall TCP/IP stack generates these lovely RSTs. Another thing
that the auditor might gain is the understanding that he is dealing with
several systems and not only with the one he is querying - looking at
the traces will result in identifying at least two systems which
communicate with his machine although he is targeting one.
Just my 2c.
Ofir Arkin [ofir@sys-security.com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Wed Oct 10 2001 - 08:00:37 PDT