Defeating NMAP Null scans (and Nessus scans).
Jason Ziemba netfilter at ziemba.net
Wed Jun 22 14:28:03 CEST 2005
Previous message: Script verification
Next message: Defeating NMAP Null scans (and Nessus scans).
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
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)?
--------------------------------------------------------------------------------
>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
--
----------------------------------------------------
-----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:
----------------------------------------------------------------------------
--------------------------------------------------------------------------------
> 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,
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-----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 .
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCubtOst+vzJSwZikRAgvzAJ4qlQ+8xlz38DhQHAQFHq96UxvOcwCfbKJX
5aJ5eG0RmV4hO6X40B5hK8A=
=sjxD
-----END PGP SIGNATURE-----
--------------------------------------------------------------------------------
>> > 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 .
>
> 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,
--------------------------------------------------------------------------------
-----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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCvCP6st+vzJSwZikRAm5lAKC0NUYKngyDpRzPcdbli2+F17xmIgCgvm5J
6Ck0P7LOcsqflFJllb5e1vU=
=Gzgq
-----END PGP SIGNATURE-----
--------------------------------------------------------------------------------
>>>>
>>>> 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
--------------------------------------------------------------------------------
>>>>
>>>> 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
--------------------------------------------------------------------------------
> 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.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
-----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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCuc5est+vzJSwZikRAnQVAJ9nurjYu+VWpnz3QJshOAcFdumGtQCeNwAP
qo0xSiG4TW0WanW41fEonHI=
=B1GT
-----END PGP SIGNATURE-----
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
> 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,
