Defeating NMAP Null scans (and Nessus scans).

Defeating NMAP Null scans (and Nessus scans).

[Jason Ziemba]

I am attempting to secure a new machine and thought I did until I ran NMAP's
Null scan (which sends no TCP flags).  NMAP was able to determine just about
every port running on the machine, and Nessus found more (even though a
standard TCP Connect and SYN scan found exactly what I wanted). 

I tried a number of TCP Flag combination rules in IPTables attempting to
filter out these scans and was unsuccessful.  Does anybody know how to
successful conceal your machine from these scans (while still allowing the
ports that 'should' be open to function correctly)?

Re: Defeating NMAP Null scans (and Nessus scans).

[Jan Engelhardt]

>I am attempting to secure a new machine and thought I did until I ran NMAP's
>Null scan (which sends no TCP flags).  NMAP was able to determine just about
>every port running on the machine, and Nessus found more (even though a
>standard TCP Connect and SYN scan found exactly what I wanted). 
>
>I tried a number of TCP Flag combination rules in IPTables attempting to
>filter out these scans and was unsuccessful.  Does anybody know how to
>successful conceal your machine from these scans (while still allowing the
>ports that 'should' be open to function correctly)?

Here's some code from my Very Own Firewall(tm), AS_IPFW.

# Rejects NULL and XMAS scan
#
function HANDLE_NMAP_SCAN() {
    # Remainder: soon to be replaced with function HANDLE_PORTSCAN 
    iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable \
     -p tcp --tcp-flags FIN FIN -m state --state INVALID;
    iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable \
     -p tcp --tcp-flags ALL NONE -m state --state INVALID;
}

# Reject about anything unnormal, given that you have conntracking.
#
iptables -A INPUT -j REJECT --reject-with host-unreach -p tcp ! --syn -m state 
--state INVALID;

^^ If someone thinks some packets might get lost in this last iptables 
command, please tell me.



Jan Engelhardt                                                               
--                                                                            

Re: Defeating NMAP Null scans (and Nessus scans).

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Actually, a null scan should be generating INVALID packets, and if one 
turns on those detections and rejections within the kernel, as well as 
perhaps adding a rule or two to DROP INVALID packets they should be 
covered, should they not?  And thus with far less resource over head as 
extensive rules in their ruleset?

Thanks,

Ron DuFresne

On Wed, 22 Jun 2005, Jan Engelhardt wrote:

>
>> I am attempting to secure a new machine and thought I did until I ran NMAP's
>> Null scan (which sends no TCP flags).  NMAP was able to determine just about
>> every port running on the machine, and Nessus found more (even though a
>> standard TCP Connect and SYN scan found exactly what I wanted).
>>
>> I tried a number of TCP Flag combination rules in IPTables attempting to
>> filter out these scans and was unsuccessful.  Does anybody know how to
>> successful conceal your machine from these scans (while still allowing the
>> ports that 'should' be open to function correctly)?
>
> Here's some code from my Very Own Firewall(tm), AS_IPFW.
>
> # Rejects NULL and XMAS scan
> #
> function HANDLE_NMAP_SCAN() {
>    # Remainder: soon to be replaced with function HANDLE_PORTSCAN
>    iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable \
>     -p tcp --tcp-flags FIN FIN -m state --state INVALID;
>    iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable \
>     -p tcp --tcp-flags ALL NONE -m state --state INVALID;
> }
>
> # Reject about anything unnormal, given that you have conntracking.
> #
> iptables -A INPUT -j REJECT --reject-with host-unreach -p tcp ! --syn -m state
> --state INVALID;
>
> ^^ If someone thinks some packets might get lost in this last iptables
> command, please tell me.
>
>
>
> Jan Engelhardt
> --
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCuZZBst+vzJSwZikRAmhLAJ4kPUFGR625yiZq1qMtc0wro+ZhVgCdG3Bn
ldsJm1Y1u3sMZNjUlxq+RuQ=
=wZtP
-----END PGP SIGNATURE-----

Re: Defeating NMAP Null scans (and Nessus scans).

[Jan Engelhardt]

> Actually, a null scan should be generating INVALID packets, and if one

Does it really? What if there happens to be a null-flags/xmas-flags tcp packet 
in an otherwise well-behaved tcp connection? I'd guess it would match 
ESTABLISHED, even if it has got null flags.

> turns on those detections and rejections within the kernel, as well as
> perhaps adding a rule or two to DROP INVALID packets they should be
> covered, should they not? And thus with far less resource over head as
> extensive rules in their ruleset?

That depends on what you want.

The full fun (shortened here) currently present in AS_IPFW is:

    (base is iptables -P INPUT DROP)
    iptables -A scanchk -j REJECT --reject-with host-unreach -m random \
      --average 20;
    iptables -A INPUT -g scanchk -p tcp ! --syn -m state --state INVALID;
    iptables -A INPUT -j TARPIT -p tcp;
    iptables -A INPUT -j REJECT --reject-with net-unreach -m random \
      --average 10;

Of course you can all DROP that, but I like to actively hinder unwanted
senders, and so, the implementation of this hindering requires REJECT.



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: Defeating NMAP Null scans (and Nessus scans).

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Jun 2005, Jan Engelhardt wrote:

>
>> Actually, a null scan should be generating INVALID packets, and if one
>
> Does it really? What if there happens to be a null-flags/xmas-flags tcp packet
> in an otherwise well-behaved tcp connection? I'd guess it would match
> ESTABLISHED, even if it has got null flags.

Perhaps my understanding of these kinds of scans is innacurate, but, a 
null scan has no flags set, and xmas scan has all the flags set, thus 
would these not cancel one another or still be two sets of invalid scans 
hitting you at once?  no flags all flags still invalid in my book.


>
>> turns on those detections and rejections within the kernel, as well as
>> perhaps adding a rule or two to DROP INVALID packets they should be
>> covered, should they not? And thus with far less resource over head as
>> extensive rules in their ruleset?
>
> That depends on what you want.


what we want is for the firewall to be imune to invalid packets generated 
by these kinds  of scans, yes?  to not give out port information when hits 
with these bogus packets that no decent application should be spewin in 
the first place?

>
> The full fun (shortened here) currently present in AS_IPFW is:
>
>    (base is iptables -P INPUT DROP)
>    iptables -A scanchk -j REJECT --reject-with host-unreach -m random \
>      --average 20;
>    iptables -A INPUT -g scanchk -p tcp ! --syn -m state --state INVALID;
>    iptables -A INPUT -j TARPIT -p tcp;
>    iptables -A INPUT -j REJECT --reject-with net-unreach -m random \
>      --average 10;
>
> Of course you can all DROP that, but I like to actively hinder unwanted
> senders, and so, the implementation of this hindering requires REJECT.
>
>
REJECT is the ind way to end a connection and does not slow an automated 
scanner one bit, while a DROP lets that attack tool keep the socket open 
on it;s end and tries to wait for feedback from the other end, and thus 
slows or stops the scanner in t's tracks, if not totally for each attepted 
connection to each port for its timeout period.  That to me is the way I 
want my firewall to respond to bogus script kiddies hitting me with their 
messing little scanners as they play and try to learn the processes that 
should put their lame little butts in jail and cost mom and dad tons of 
cash for rasing little deamons in the first place <smile>.

Of course, perhaps I'm incorrect in my analysis, and open to pointers to 
my misunderstanding of the processes.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCubtOst+vzJSwZikRAgvzAJ4qlQ+8xlz38DhQHAQFHq96UxvOcwCfbKJX
5aJ5eG0RmV4hO6X40B5hK8A=
=sjxD
-----END PGP SIGNATURE-----

Re: Defeating NMAP Null scans (and Nessus scans).

[Jan Engelhardt]

>> > turns on those detections and rejections within the kernel, as well as
>> > perhaps adding a rule or two to DROP INVALID packets they should be
>> > covered, should they not? And thus with far less resource over head as
>> > extensive rules in their ruleset?
>> 
>> That depends on what you want.
>
> what we want is for the firewall to be imune to invalid packets generated by
> these kinds  of scans, yes?  to not give out port information when hits with

I do not give out port information. At least, I do not give correct port 
information, which is just as much gain.

> REJECT is the ind way to end a connection and does not slow an automated
> scanner one bit, while a DROP lets that attack tool keep the socket open on

Read closely. It uses -m random to switch between REJECT/DROP.
Try that rulesets and then nmap yourself with "nmap -r localhost -p 1-2500". 
Count the time, and compare to a pure DROP based approach.
  (iptables -F; iptables -P INPUT DROP; nothing more)

> it;s end and tries to wait for feedback from the other end, and thus slows or

Surprisingly no. The REJECT/DROP mix confuses nmap more than a plain DROP. See 
above.

> stops the scanner in t's tracks, if not totally for each attepted connection to
> each port for its timeout period.  That to me is the way I want my firewall to
> respond to bogus script kiddies hitting me with their messing little scanners
> as they play and try to learn the processes that should put their lame little
> butts in jail and cost mom and dad tons of cash for rasing little deamons in
> the first place <smile>.
>
> Of course, perhaps I'm incorrect in my analysis, and open to pointers to my
> misunderstanding of the processes.



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: Defeating NMAP Null scans (and Nessus scans).

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 23 Jun 2005, Jan Engelhardt wrote:

>
>>>> turns on those detections and rejections within the kernel, as well as
>>>> perhaps adding a rule or two to DROP INVALID packets they should be
>>>> covered, should they not? And thus with far less resource over head as
>>>> extensive rules in their ruleset?
>>>
>>> That depends on what you want.
>>
>> what we want is for the firewall to be imune to invalid packets generated by
>> these kinds  of scans, yes?  to not give out port information when hits with
>
> I do not give out port information. At least, I do not give correct port
> information, which is just as much gain.
>
>> REJECT is the ind way to end a connection and does not slow an automated
>> scanner one bit, while a DROP lets that attack tool keep the socket open on
>
> Read closely. It uses -m random to switch between REJECT/DROP.
> Try that rulesets and then nmap yourself with "nmap -r localhost -p 1-2500".
> Count the time, and compare to a pure DROP based approach.
>  (iptables -F; iptables -P INPUT DROP; nothing more)
>
>> it;s end and tries to wait for feedback from the other end, and thus slows or
>
> Surprisingly no. The REJECT/DROP mix confuses nmap more than a plain DROP. See
> above.
>

Interesting this use of random.  I'll have to play with it when I get that 
rare bit of spare time for testing and fooling about with things not in 
prod or requirening immediate attention to fix!  Which tend to be even 
more rare these days in our understaffed env.  But, your reports of this 
random further confusing the scanner and slowing it down are extremely 
interesting...


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCvCP6st+vzJSwZikRAm5lAKC0NUYKngyDpRzPcdbli2+F17xmIgCgvm5J
6Ck0P7LOcsqflFJllb5e1vU=
=Gzgq
-----END PGP SIGNATURE-----

Re: Defeating NMAP Null scans (and Nessus scans).

[Kirk]

>>>>
>>>> what we want is for the firewall to be imune to invalid packets
>>>> generated by
>>>> these kinds  of scans, yes?  to not give out port information when
>>>> hits with
>>>

hi

i'm using an alternate method to be a bit immune to these scans, i've found it about a year ago googling ;)
it isn't matches on syn/other flags, it requires that the packet must hava the 2 tcp option ;)
and it's working fine, all operating systems are sending they mtu in the syn packet only

$ipt -p tcp --tcp-option ! 2                    -j DROP #REJECT --reject-with tcp-reset

kirk

Re: Defeating NMAP Null scans (and Nessus scans).

[Kirk]

>>>>
>>>> what we want is for the firewall to be imune to invalid packets
>>>> generated by
>>>> these kinds  of scans, yes?  to not give out port information when
>>>> hits with
>>>

hi

i'm using an alternate method to be a bit immune to these scans, i've found it about a year ago googling ;)
it isn't matches on syn/other flags, it requires that the packet must hava the 2 tcp option ;)
and it's working fine, all operating systems are sending they mtu in the syn packet only

$ipt -p tcp --tcp-option ! 2                    -j DROP #REJECT --reject-with tcp-reset

kirk

Re: Defeating NMAP Null scans (and Nessus scans).

[curby .]

On 6/23/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> Read closely. It uses -m random to switch between REJECT/DROP.
> Try that rulesets and then nmap yourself with "nmap -r localhost -p 1-2500".
> Count the time, and compare to a pure DROP based approach.
>   (iptables -F; iptables -P INPUT DROP; nothing more)

There's a good chance that TARPIT and not REJECT is the thing slowing
down scans.  You might want to check replacing TARPIT with
DROP/REJECT; I think you'll see nonTARPIT scans take the same amount
of time regardless of whether the firewall uses DROP or REJECT.  I
didn't test this though.

Here are some rules I've used when testing out ways to catch nmap
scans.  If anyone knows what the SYN,RST SYN,RST match is for, please
let me know.

# Xmas scan, caught nmap v3.00
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j
DROP || die 05 81

# Generic Xmas scan, haven't checked if nmap triggers this
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL ALL         -j
DROP || die 05 83

# Null scan, nmap v3.00 Null scan is caught by INVALID match above, so
this is commented out
#$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ALL NONE        -j
DROP || die 05 85

# Misc scan - everyone tests for this, but what scan does it match?
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j
DROP || die 05 87

# FIN scan, nmap v3.0 sends ACK,FIN FIN
# SYN,FIN SYN,FIN does not match nmap
# FIN FIN gets false positives when using SSH TARPIT
$IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -m state
--state NEW -j DROP || die 05 89

Re: Defeating NMAP Null scans (and Nessus scans).

[Jörg Harmuth]

curby . schrieb:

[SNIP]

> Here are some rules I've used when testing out ways to catch nmap
> scans.  If anyone knows what the SYN,RST SYN,RST match is for, please
> let me know.
> 

[SNIP]

> # Misc scan - everyone tests for this, but what scan does it match?
> $IPTABLES -t nat -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j
> DROP || die 05 87
> 

"--tcp-flags SYN,RST SYN,RST" means "watch TCP flags SYN and RST and
match if out of the watched flags SYN and RST are set". Ok you knew that
already :)

According to RFC793 sending a SYN means "hey guy, I wanna talk to to
you, let's SYNchronize our sequence numbers". The only flag that is
allowed to be sent along with a SYN is ACK, and this only in the 2nd
packet of the 3-way-handshake.

Sending RST means "oohps, there's something wrong, ReSeT the connection".

So, sending SYN in conjunction with RST means, that a connection shall
be opened and aborted at the same time. This is

1.) A violation of RFC793
2.) Absolutely senseless in terms of a real connection

Thus, chances are good that someone is scanning you. Hum, cold coffee too.

nmap doesn't generate this scan, and in fact I don't know which scanner
does. But it is possible to generate these packet with packet injection
tools like nemesis. So it is possible that these packets come to your
firewall (although they shouldn't) and you don't want them to pass.

That's why I probe for this.

Have a nice time,

Joerg

Re: Defeating NMAP Null scans (and Nessus scans).

[Jan Engelhardt]

>There's a good chance that TARPIT and not REJECT is the thing slowing
>down scans.  You might want to check replacing TARPIT with
>DROP/REJECT; I think you'll see nonTARPIT scans take the same amount

Not at all:

shanghai:~ # iptables -I INPUT -p tcp -j TARPIT
shanghai:~ # nmap lo -p 1-512 -sF -v -v -r -T Insane

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-09 12:24 CEST
Initiating FIN Scan against localhost (127.0.0.1) [512 ports] at 12:24
The FIN Scan took 7.30s to scan 512 total ports.
Host localhost (127.0.0.1) appears to be up ... good.
All 512 scanned ports on localhost (127.0.0.1) are: open|filtered

Nmap finished: 1 IP address (1 host up) scanned in 7.441 seconds
               Raw packets sent: 1026 (41KB) | Rcvd: 1026 (41KB)

shanghai:~ # iptables -D INPUT 1         # remove tarpit
shanghai:~ # !nmap
[...]
Nmap finished: 1 IP address (1 host up) scanned in 116.691 seconds
               Raw packets sent: 2411 (96.4KB) | Rcvd: 2900 (130KB)

>of time regardless of whether the firewall uses DROP or REJECT.  I
>didn't test this though.
>
>Here are some rules I've used when testing out ways to catch nmap
>scans.  If anyone knows what the SYN,RST SYN,RST match is for, please
>let me know.[...]

Mine, and it's basically just one (or two, depending on how you look at it) 
rules for all non-RFC-compliant scans/connections:

...
allow -m state --state ESTABLISHED,RELATED
...
HANDLE_PORTSCAN;
...
function HANDLE_PORTSCAN() {
    iptables -N scan_chk;
    # ACK,RST: rfc 793 page 65
==> iptables -A scan_chk -j RETURN -p tcp --tcp-flags ALL ACK,RST;
    iptables -A scan_chk -j REJECT --reject-with host-unreach -m random \
      --average 10;
    iptables -A scan_chk -j DROP;
==> iptables -A INPUT -j scan_chk -p tcp ! --syn -m state --state INVALID;
}



Jan Engelhardt                                                               
--                                                                            
| Alphagate Systems, http://alphagate.hopto.org/

Re: Defeating NMAP Null scans (and Nessus scans).

[Taylor, Grant]

> Does it really? What if there happens to be a null-flags/xmas-flags tcp packet 
> in an otherwise well-behaved tcp connection? I'd guess it would match 
> ESTABLISHED, even if it has got null flags.

As I understand it it is not possible to have the same packet be part of a null AND xmas scan as they are the exact opposite of each other acting on the SAME flags.

As far as not having the ESTABLISHED or RELATED state allowing the scan packets through you would want to have something like this first, before our stateful rule:

# Drop any XMas scan packets.
iptables -t filter -A FORWARD -i $INet -o $LAN -p tcp --tcp-flags ALL ALL -j DROP

# Drop any Null scan packets.
iptables -t filter -A FORWARD -i $INet -o $LAN -p tcp --tcp-flags ALL NONE -j DROP

# We could put any matches for any other type of scan that we wanted to here too.


# Allow any stateful traffic back in.
iptables -t filter -A FORWARD -i $INet -o $LAN -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow any normal LAN traffic out.
# Note:  We should probably do some validity checking here but we will not for simplicity.
iptables -t filter -A FORWARD -i $LAN -o $INet -j ACCEPT

You would probably want to do a corresponding drop in the INPUT chain too.

Re: Defeating NMAP Null scans (and Nessus scans).

[Alexey Toptygin]

On Wed, 22 Jun 2005, Taylor, Grant wrote:

> # Drop any Null scan packets.
> iptables -t filter -A FORWARD -i $INet -o $LAN -p tcp --tcp-flags ALL NONE -j DROP
>
> # We could put any matches for any other type of scan that we wanted to here too.
>
>
> # Allow any stateful traffic back in.
> iptables -t filter -A FORWARD -i $INet -o $LAN -m state --state ESTABLISHED,RELATED -j ACCEPT

TCP packets without flags are possible during a normal TCP connection, you 
don't want to drop them. --state ESTABLISHED,RELATED would never let in 
NULL scans anyway, because a NULL scan won't establish a valid TCP 
connection before it sends flagless packets.

 			Alexey

Re: Defeating NMAP Null scans (and Nessus scans).

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Jun 2005, Alexey Toptygin wrote:

> On Wed, 22 Jun 2005, Taylor, Grant wrote:
>
>> # Drop any Null scan packets.
>> iptables -t filter -A FORWARD -i $INet -o $LAN -p tcp --tcp-flags ALL NONE 
>> -j DROP
>> 
>> # We could put any matches for any other type of scan that we wanted to 
>> here too.
>> 
>> 
>> # Allow any stateful traffic back in.
>> iptables -t filter -A FORWARD -i $INet -o $LAN -m state --state 
>> ESTABLISHED,RELATED -j ACCEPT
>
> TCP packets without flags are possible during a normal TCP connection, you 
> don't want to drop them. --state ESTABLISHED,RELATED would never let in NULL 
> scans anyway, because a NULL scan won't establish a valid TCP connection 
> before it sends flagless packets.
>

I was under the impression and perhaps again I'm wrong in my 
understanding, tht once  a connection was established all packets had at 
least the ack flags set<?>.



Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCuc5est+vzJSwZikRAnQVAJ9nurjYu+VWpnz3QJshOAcFdumGtQCeNwAP
qo0xSiG4TW0WanW41fEonHI=
=B1GT
-----END PGP SIGNATURE-----

Re: Defeating NMAP Null scans (and Nessus scans).

[Alexey Toptygin]

On Wed, 22 Jun 2005, R. DuFresne wrote:

>> TCP packets without flags are possible during a normal TCP connection, you 
>> don't want to drop them. --state ESTABLISHED,RELATED would never let in 
>> NULL scans anyway, because a NULL scan won't establish a valid TCP 
>> connection before it sends flagless packets.
>
> I was under the impression and perhaps again I'm wrong in my understanding, 
> tht once  a connection was established all packets had at least the ack flags 
> set<?>.

I think all modern implementations will always send ACK on an established 
connection, but I don't think RFC793 requires it. Therefore, it may be 
safe to drop unflagged packets, but it seems like a bad idea to me.

As far as stopping NULL or XMAS scans, explicitly dropping packets is 
unnecessary if you have a DROP policy and explicitly ACCEPT --state 
ESTABLISHED,RELATED.

 			Alexey

Re: Defeating NMAP Null scans (and Nessus scans).

[Jan Engelhardt]

> I think all modern implementations will always send ACK on an established
> connection, but I don't think RFC793 requires it. Therefore, it may be safe to
> drop unflagged packets, but it seems like a bad idea to me.

ACK on everything? That does not sound right.

When I call send(fd, ..., "some message"), I'd expect

  - a non-ack packet from me->remote
  - an ack packet from remote



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de