Shorewall users - Dec 2002 - Should we all start using ''tcpflags''?

Hi.  I searched the archives, and I''m surprised there hasn''t
been any
discussion of the interfaces file''s new ''tcpflags''
option.

The terse info in the Shorewall documentation and on the website
doesn''t
give any real feeling as to whether this option should be enabled for all
(or all external?) interfaces.

What sorts of malicious uses of illegal TCP flags combinations is it
protecting against?  What will happen if I receive such packets without
having tcpflags (and TCP_FLAGS_DISPOSITION=DROP) enabled?

What is the likelihood of the flag will causing legitimate packets generated
by buggy but non-malicious software to be dropped?

--
Dan Harkless
http://harkless.org/dan/

"Dan Harkless" <shorewall-users@harkless.org>
writes:
> What is the likelihood of the flag will causing legitimate packets
generated
> by buggy but non-malicious software to be dropped?
Oops.  Sorry for the editing error.  That should have been:
> What is the likelihood of the flag causing legitimate packets generated
> by buggy but non-malicious software to be dropped?
--
Dan Harkless
http://harkless.org/dan/

--On Tuesday, December 10, 2002 03:55:46 PM -0800 Dan Harkless 
<shorewall-users@harkless.org> wrote:
>
> Hi.  I searched the archives, and I''m surprised there
hasn''t been any
> discussion of the interfaces file''s new
''tcpflags'' option.
>
> The terse info in the Shorewall documentation and on the website
doesn''t
> give any real feeling as to whether this option should be enabled for all
> (or all external?) interfaces.
I recommend enabling it on all external interfaces.
>
> What sorts of malicious uses of illegal TCP flags combinations is it
> protecting against the following malicious flag combinations?
a) NULL (no TCP flags set -- so called NULL scan).
b) SYN+FIN
c) SYN+RST
d) FIN+URG+PSH (so called XMAS scan).
> What will happen if I receive such packets without
> having tcpflags (and TCP_FLAGS_DISPOSITION=DROP) enabled?
>
If it''s addressed to the Firewall box, probably nothing; if
it''s addressed
to a box behind the firewall, then it depends on what that box does with 
them.
> What is the likelihood of the flag will causing legitimate packets
> generated by buggy but non-malicious software to be dropped?
>
Very low.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

Tom Eastep <teastep@shorewall.net> writes:
> > Hi.  I searched the archives, and I''m surprised there
hasn''t been any
> > discussion of the interfaces file''s new
''tcpflags'' option.
> >
> > The terse info in the Shorewall documentation and on the website
doesn''t
> > give any real feeling as to whether this option should be enabled for
all
> > (or all external?) interfaces.
> 
> I recommend enabling it on all external interfaces.
Okay.  Probably worth adding a sentence to that effect to the documentation
somewhere, then.

I did not write the text after "protecting against":
> > What sorts of malicious uses of illegal TCP flags combinations is it
> > protecting against the following malicious flag combinations?
> 
> a) NULL (no TCP flags set -- so called NULL scan).
> b) SYN+FIN
> c) SYN+RST
> d) FIN+URG+PSH (so called XMAS scan).
> 
> > What will happen if I receive such packets without
> > having tcpflags (and TCP_FLAGS_DISPOSITION=DROP) enabled?
> 
> If it''s addressed to the Firewall box, probably nothing; if
it''s addressed
> to a box behind the firewall, then it depends on what that box does with 
> them.
I was actually thinking of a box with an Internet-routable address, using
Shorewall to protect against traffic to non-server ports.
> > What is the likelihood of the flag will causing legitimate packets
> > generated by buggy but non-malicious software to be dropped?
> 
> Very low.
Okay, thanks.  This info, as well, is probably worth documenting.

--
Dan Harkless
http://harkless.org/dan/

Tom Eastep <teastep@shorewall.net> writes:
> a) NULL (no TCP flags set -- so called NULL scan).
> b) SYN+FIN
> c) SYN+RST
> d) FIN+URG+PSH (so called XMAS scan).
Upon reflection, it occurred to me that basically tcpflags is protecting
against "invisible" port scans, eh?

A, B, and D can be tested by using nmap''s -sN, -sF, and -sN options,
respectively (not sure about C).  I figured I would check to see what the
log messages looked like by running these on the server, against itself, but
the probes all succeeded, and no log messages were generated.

Is this because I have the following in my policy file:
 
    [...]
    #SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
    fw              net             ACCEPT
    net             all             DROP            info
    all             all             REJECT          info
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Does allowing anything from the box to the network override the
''tcpflags''
option on the ''net'' interface?

Any way to test out tcpflags logging without having root access (required by
those nmap options) on some other Internet-connected UNIX box?  (I tried the
Windows build of nmap on my home box, but couldn''t get it working --
possibly Shorewall on my LEAF box is thwarting it, though it''s a
pre-tcpflags version...)

--
Dan Harkless
http://harkless.org/dan/

--On Tuesday, December 10, 2002 06:30:33 PM -0800 Dan Harkless 
<shorewall-users@harkless.org> wrote:
>
> Tom Eastep <teastep@shorewall.net> writes:
>> a) NULL (no TCP flags set -- so called NULL scan).
>> b) SYN+FIN
>> c) SYN+RST
>> d) FIN+URG+PSH (so called XMAS scan).
>
> Upon reflection, it occurred to me that basically tcpflags is protecting
> against "invisible" port scans, eh?
Exactly.
>
> A, B, and D can be tested by using nmap''s -sN, -sF, and -sN
options,
> respectively (not sure about C).  I figured I would check to see what the
> log messages looked like by running these on the server, against itself,
> but the probes all succeeded, and no log messages were generated.
Won''t work. All traffic from the system to itself go through the
''lo''
interface which Shorewall enables unconditionally.
>
> Is this because I have the following in my policy file:
>
>     [...]
>     #SOURCE         DEST            POLICY          LOG LEVEL
> LIMIT:BURST     fw              net             ACCEPT
>     net             all             DROP            info
>     all             all             REJECT          info
>     #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
>
> Does allowing anything from the box to the network override the
''tcpflags''
> option on the ''net'' interface?
>
> Any way to test out tcpflags logging without having root access (required
> by those nmap options) on some other Internet-connected UNIX box?
You have to have root access on a system that connects to the Shorewall box 
through the interface that has ''tcpflags'' set.

 (I
> tried the Windows build of nmap on my home box, but couldn''t get
it
> working -- possibly Shorewall on my LEAF box is thwarting it, though
it''s
> a
> pre-tcpflags version...)

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net