Re: Nmap vs DTK ?

[Nicodimus <AF64A () MPTP freeserve co uk>]

Fyodor wrote:

> On Fri, 5 May 2000, Mr. Man wrote:
>
> > On Fri, 5 May 2000, Cameron Palmer wrote:
> >
> > > You'll list off your security measures and say we're lying about the OS
> > > type, and how is it your OS masking hasn't introduced a new problem.
> >
> > What problems might it introduce?  So far I've read of none associated
> > with either the Linux patches, or with dropping packets with odd
> > combinations of TCP header flags set.  This is not like just turning off
> > all ICMP and watching path MTU discovery break.
>
> Attempting to defeat OS detection could cause all sorts of problems.  And
> in fact, the current attempts DO cause all sorts of problems.  So far, I
> have seen two main tools discussed for this purpose:
>
> iplog -z (or --fool-nmap=true) : The man page for iplog
>   (http://ojnk.sourceforge.net/iplog.8.html) states: "Warning: This
>   option is dangerous and can set off network traffic storms."
>
> KOSF ( http://www.hit2000.org/kosf/ ): This page says:
>    "As most of the systems that kosf can fake utilize the so called
>     64K rule, it gets easier to spoof the sequence number. But then again,
>     it is probably clear that faking an apple color laserwriter on a high
>     load computer is not a very good plan, as the printer was not designed
>     for that... "

 I am surprised that the third one, DTK ( Deception ToolKit ) by Dr. Cochen (
http://all.net ), did not drain anyone's attention.

 It seems to work just fine, especially if the code is tweaked to remove port
365 msg and "exploits" that aren't possible on the OS you are trying to
emulate. Although I mentioned 2 problems:

1. When scanning linux boxes with 2.0.x kernels running DTK, the toolkit does
not seem to work with -sX -sF -sN, while performing well with full connect and
-sS scans. This problem does not exist on 2.2.x boxes.

2. If filtering ( e.g. with ipchains ) is applied behind the DTK ( which
employs TCP wrappers ), -sA scan will still show which ports are filtered (!),
indicating that the services bound to them do, indeed, exist.

Apart from these two points, are there any ideas on defeating the "DTK
obscurity" using NMAP ?

And as scanning the DTK - running machine is very time / bandwith consuming,
does implementing the automatic exit with "target running DTK" msg into
NMAP make any sense before the "cure" for DTK is discovered ?

Thank you for attention.

Nicodimus.

*some dumb toxicologist with pathological interest in Linux*