RE: Ambiguities in TCP/IP - firewall bypassing

["John Fitzgerald" <john () match-fit com>]

An interesting point, T/TCP does indeed require multiple flags to be set
simultaneously, however, it's also not a proven protocol. In fact there
are potential security issues
Apart from the potential DoS (re-introducing SYN floods to some
environments) it's not clear how all IP stacks will respond to these
packets.
There's also a clear security issue with allowing one side of the
handshake to send commands before the handshake's been completed - with
standard TCP/IP it's relatively easy to spoof the source IP for the SYN
but this doesn't get the perpetrator very far - with T/TCP a spoofed SYN
could actually send a command which may be actioned if the target host
only uses the source IP as validation (such as rlogin/rsh). This last
matter isn't a show stopper, I don't allow rlogin etc - and if I did it
would only be for addresses that can only be internal (the firewall
would prevent external devices from spoofing such addresses). But this
is just one example of a new security hole being opened by T/TCP...Ever
cautious, I'm inclined to block this traffic and see what else turns up
as the protocol matures.

If anything, this reaffirms my belief in blocking any unexpected traffic
(allow it only when it becomes clear that it must be allowed through,
and only after making sure that new security holes aren't being
introduced)

While on the subject, have there been any moves to ramp up the
acceptance of T/TCP, I can see that there are distinct performance
advantages for HTTP?



-----Original Message-----
From: Alun Jones [mailto:alun () texis com] 
Sent: 18 October 2002 22:28
To: benjamin () seattleFenix net
Subject: Re: Ambiguities in TCP/IP - firewall bypassing

At 03:55 PM 10/18/2002, Benjamin Krueger wrote:
>   One could also make a case for continuing to abide by the cardinal
> rule "Be permissive in what you accept, and strict in what you send".
> Tough call, but its difficult to justify describing stacks that are
> permissive as "highly bogus" or "lazy" given that being permissive in
> what you accept is an established notion.

If a usage makes any kind of sense, then it has usually been allowed.

> Compliant by the letter, if questionably in spirit. I'm not aware of
any
> tcp client systems that would send SynFin in the real world, so a stack
> that responded with RST could arguably be "more" correct (for example).

Not necessarily.  Have you heard of T/TCP?  Before that was around, I 
remember hearing discussion of using a packet with SYN, FIN, and data
all 
in one, to cut down on round-trips in really short communications, while

still providing reliability.

One of the lessons you learn when writing / reading RFC material is that

"there are more things on heaven and earth, Horatio, than are dreamt of
in 
your philosophy" (or thereabouts).  Just because _you_ don't see a use
for 
a feature, that doesn't mean to say that someone else won't / can't, and

specifically, it isn't usually worth limiting a protocol for the rather 
arbitrary reason that you can't see how a feature would be used.

Alun.
~~~~

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us
at
1602 Harvest Moon Place   | http://www.wftpd.com or email alun () texis com
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure
to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.