RE: Inappropriate TCP Resets Considered Harmful

[Crispin Harris <Harris_C () DeMorgan com au>]

*********************************************************

 ---------------------------------------------------------------------
 This correspondence is for the named person's use only.  It may
 contain confidential or legally privileged information or both.
 No confidentiality or privilege is waived or lost by any
 mistransmission.  If you receive this correspondence in error, please
 immediately delete it from your system and notify the sender.  You
 must not disclose, copy or rely on any part of this correspondence
 if you are not the intended recipient.

 Any views expressed in this message are those of the individual sender,
 except where the sender expressly, and with authority, states them to
 be the views of DeMorgan Pty Ltd.

 This e-mail has been checked for known Viruses. It is the responsibility
 of the receiver to check their system for infected files and any such
 file is deemed not to be the responsibility of DeMorgan.

 ---------------------------------------------------------------------

*********************************************************

<an asside>
I have been following this thread with great interest, as this cuts to the
core of a common scheme of firewall configurations.

One family of opinion states that the firewall should provide an absolute
minimum of information regarding its configuration and state.

In this case, the firewall would provide exactly the same response to _ANY_
security related connection:
 - Packet Denied
 - Service unavailable
 - Service busy

This significantly reduces the usefulness of products such as firewalk, as
there is (almost) nothing to differentiate between:
 - a packet that got through and was rejected by the destination host
 - a packet that was rejected by rule
 - a packet that was not part of an open session (for stateful inspection)
 - a packet denied by attribute (Fragmented, invalid flags, etc)

As I am not able to enforce "ICMP port unreachable" under all these
circumstances, I prefer to configure "TCP RST" for all (as many as possible)
of these.

When nmap, CyberCop, ISS or a number of other tools try any scan a firewall
setup like this, you get the anoying, consistant and useless almost
identical responses from almost all ports on all IP addresses. When faced
with such a load of responses, it is difficult to determine which ones are
are being rejected by the firewall, and which ones are being rejected by the
destination server.

(I am aware that 2/3's decent hacker will then look at the TTL's of the
RST's to differentiate, but this would then require running the scan again,
as I am not aware of a scan tool the looks at these fields in the
responses.)

With regards to sending RST's to "Malformed TCP Flags" (0x03 (SYN+FIN),
> =0x3A (URG,ACK,PSH,-,SYN-)), my position is that I want to REJECT all
traffic with such flags.

As the use of bits 6 & 7 of the TCP flags is not _CURRENTLY_ supported, I
include them in this category.

> From a security point of view, I believe that it is perfectly valid for a
firewall to deny or reject any traffic that is not _PRE-APPROVED_. i.e. if
the firewall receives ECN traffic, and the organisation has not said "We
want to allow ECN", then the firewall administrator would be negligent if
this traffic was not dropped.


> -----Original Message-----
> From: Ben Nagy [mailto:ben.nagy () marconi com au]
> Sent: Monday, 14 May 2001 9:43 AM
> To: 'Darren Reed'
>
> Why is a retry bad? If I were writing firewall (heaven 
> forbid!) I'd treat
> ECN packets either by silently discarding them or by sending 
> an ICMP error.

This is one area in which I disagree. One network scanning option is to send
a packet with the high-bit tcp flags set. How can I tell if this packet is
ECN or scanning?

> I can see the argument for not using a RST, but don't 
> consider it a "broken"
> choice, just "uninformative".

Which is my point entirely, I don't WANT to be informative.

[BTW: in case you were wondering, my position on NAT is that while it is not
a security feature, the information hiding that it provides, can (and
arguably should) be used to provide a further icremental increase to
information hiding.]

> If I chose the "stealth" option, the packets would get 
> dropped and there
> would be several SYN retries anyway. Even if I chose an ICMP Parameter
> problem, that's not exactly a common error, and would get 
> filtered in many
> cases (plus it would make fingerprinting my firewall 
> trivial), so there
> would also be resends there.

This is one of the reasons that I prefer REJECT to DROP.

> If the ECN stack knows that there's a fair chance that the 
> RST just means
> "ECN not spoken here" then why is it bad to have a go in non-ECN mode?

Certainly if I was implementing a protocol that preferred ECN, I would try
and fall-back if I received an error.

> > Personally, I see little difference between dropping packets 
> > with undefined
> > bits set and sending an error back.  I wouldn't call 
> > responding to those
> > packets in an unfriendly way "broken".
>
> That's pretty much how I feel. Which error, though? Parameter 
> Problem (12), Unreachable for type of service (3/11 or 12) or 
> administratively prohibited (3/13)? 
> Almost all of those will make pretty obvious fingerprints, too.

And thus, my preference for TCP RST.

(Mind you, the argument changes when talking non-TCP :-)

Regards,
        Crispin Harris
        DeMorgan Information Security Specialists