[fw-wiz] Inappropriate TCP Resets Considered Harmful

Crispin Harris Harris_C@DeMorgan.com.au
Sat, 2 Jun 2001 15:40:51 +1000


--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

(Reposted because the anti-virus software DID do silly things with
attachments. - We have since upgraded from that software.)

(Hoping that the organisations Anti-Virus software won't do silly things
with attachments this time :-)

> -----Original Message-----
> From: Ben Nagy [mailto:ben.nagy@marconi.com.au]
> Sent: Tuesday, 15 May 2001 4:02 PM
> Subject: RE: [fw-wiz] Inappropriate TCP Resets Considered Harmful
> 
> [Crispin]
> > One family of opinion states that the firewall should provide 
> > an absolute
> > minimum of information regarding its configuration and state.

I should say here that I am of the school who believe in "Defense In Depth".
(I was recently asked to build a 'secure' data centre, and my response was
"Against who am I defending, and how quickly must they be repelled in a
physical attack? Security Agencies, Professionals, Corporate Espionage,
Talented Amateurs, or Media?" My response was "up to 50kUSD attacks, and 10
minutes unapposed access".)

While a determined/skilled/cash-ready attacker can gain access to (almost)
all of the information necessary to perform the attack, I would prefer that
they have to spend the time/effort/cash to gain it, as that gives me that
much longer to identify that an attack is in planning/progress, and
stop/interrupt it.

This is good, solid, dependable, and time-tested information/physical
security technique. (I think that a lot of "Computer Security Professionals"
disregard (or are unable to obtain) the lessons of the physical/military
security environment. This is a real pity, as the concepts are still valid
in the new realm.

> [Ben] 
> Being able to have your firewall fingerprinted is probably 
> not optimal, but
> not an overriding concern, IMO. Going too far down that path leads to
> "Security by Obscurity" sophistry.

I don't believe that obscurity is a valid security concept, however
"information hiding" (obscuring) CAN be used to increase security.
(Otherwise pre-shared secrets wouldn't work...)

> [Crispin]
> > 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.
> 
> [Ben]
> I agree. This seems to be a common opinion among firewall 
> people. 

And not just firewall people. Talk to any trained Security Officer, and they
will tell you that the Primary Tenet of Operational Security (in a security
sensitive situation) is "Prevent that which is not explicitly allowed".
[Deem the standard disclaimer about the inverse situation included]

> That would tend to lead me to assume that the only reason that 
> ECN works for such a large percentage of hosts is because many 
> firewalls so not adequately enforce RFC compliance in the TCP 
> stream, not because the administrators have taken a lenient 
> security stance.

Some-Some. My experience would tend to say that for "Highly-Competant
Security Professionals", that is the case, however I have found that the
vast majority of Firewall Administrators are NOT Security Professionals....

> [Crispin votes for TCP RST as a response to ECN-TCP packets]
> > (Mind you, the argument changes when talking non-TCP :-)
> 
> OK - what's your pick for non-TCP? 

The RST mechanism is only appropriate when dealing with TCP streams. My
basic argument doesn't change: "I believe that session/connection/packet
rejections should be handled in the same way regardless of whether it was a
'Deny by rule', 'Inappropriate Options', or 'Host/Service not available'.

(Here is where I wish I could find my copy of Internetworking... [Comer].)

UDP doesn't have a RST mechanism. 
	I would propose ICMP Port Unreachable for all cases. 
ICMP doesn't really require a RST mechanism. 
	I guess would suggest either no response, or one of the
unreachables.
	
IP other protocols
	<?help? Don't have an answer for this, although I am looking...>

> That's going to be relevant, as well, and variation in the 
> handling of ECN for other IP protocols is almost certainly
> going to lead to fingerprinting heaven.

What a wonderful thought. <wry grimace>
 
Regards,
	Crispin Harris
	DeMorgan Information Security Specialists

--=_IS_MIME_Boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

 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.

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

--=_IS_MIME_Boundary--