Home page logo

Nmap Announce mailing list archives

Re: Nmap vs DTK ?
From: Nicodimus <AF64A () MPTP freeserve co uk>
Date: Thu, 11 May 2000 23:27:27 +0100

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.


*some dumb toxicologist with pathological interest in Linux*

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]