mailing list archives
RE: Inappropriate TCP Resets Considered Harmful
From: Crispin Harris <Harris_C () DeMorgan com au>
Date: Tue, 15 May 2001 11:21:59 +1000
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.
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)
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
(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
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.
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
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
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 :-)
DeMorgan Information Security Specialists
- RE: Inappropriate TCP Resets Considered Harmful, (continued)