From: dtk@all.net
Reply-to: dtk@all.net
Organization: Deception ToolKit Mailing List
Subject: DTK Mailing List 19981107
<pre>---------------------------------------------
Date: Sat, 07 Nov 1998 02:24:21 +0000
From: Lachlan Cranswick <l.m.d.cranswick@dl.ac.uk>
Subject: Nice things about Deception Toolkit


Hi Fred,

Just wanting to say nice things about Deception Toolkit
as per your web-page for feedback.

It is wonderful to come across something like this that
has the power to give early warning of an attack - compared
to the ancient software that seems to come up high on
the search engines.

I have installed this on a SGI O2 running IRIX 6.3 (soon to be 6.5)
and apache 1.3.3 web-server.  (My main job is not meant to be
sysadmin - but it is turning out that way).

-----

Some suggestions if you have the time:

I am more interested in a single machine mode because
that is what my project has.   Thus could there be installation
modes depending on what people want to achieve for their computer.
Thus have an option not to have the "fake" services too buggy as 
don't want to attract too many "script kiddies" given on a small
site - resources might be lacking to report hackers effectively
to people who might be able to do something about them

[FC - I encourage anyone who wishes to write strong defensive scripts to
provide me with copies so I can implement multiple modes of scripting]

(i.e.,  Web server - so other services (except ftp and telnet from
specified domains can be go?  - in my case I only want people from .dl.ac.uk 
an .ccp14.ac.uk to be able to telnet and ftp into my machine.)

[FC - I currently use tcp wrappers as follows (IP addresses changed for
obvious reasons)

	in.telnetd:	1.2.3.4:	allow
	in.telnetd:	2.3.4.5:	allow
	in.telnetd:	6.7.8.9:	allow
	in.telnetd:	all:	twist /u/linux/netkit-telnet-0.10/telnetd/telnetd -L /dtk/Telnet.pl -P %a
	...
	all:	all:	twist /dtk/coredump.pl %a 0 %u %d

Another alternative is to rig 0.response as the response for undesired services.
This produces a message along the lines of:

	remote server access port authenticode:

and if they type root or some such thing, it responds with:

	Second part of authenticode:

and then refuses entry.
]

Thus can Deception Toolkit recommend what superflous services be turned
off - and maybe provide a more elaborate inetd.conf example.

[FC - The way it works now, dtk.rc.local runs on services not otherwise
turned on.  Thus, anything not in use gets deception is there is a
decption available for it.  I am considering a daemon that listens to
all unused ports below 1024 so that it detects anything and provides a
generic response. It's a dead give away, but it sure increases detection
probabilities.]

----

And a query - what are the risks of running this as root - and what
is the safest thing to be doing in terms of ownerships?

[FC - You have to run as root to use ports 0..1024 unless you have a
modified kernel.  Higher ports you can run however you like.  DTK is
still in version 0.? and as such, I haven't done all the work I would do
for a commercial product - however, unless perl has a serious problem in
memory allocation, it should be pretty safe.

If you look at the input routines, input is normally handled as follows:

	$what=~y/A-Za-z0-9//cd;                 # safe grep capability
	$what=~tr/A-Z/a-z/;                     # case independent

Thus the only information that gets to the response subroutine (except
for *.response files using special pragmas) are sequences of lower case
letters and the digits 0-9.

The RESPOND subroutine starts by reading the response file - which you
provide (I provide defaults).  These can cause arbitrary bad things to
happen if provided with inputs that you associate with bad things, but
as I provide them they should be relatively safe. It looks for various
sorts of matching criteria as follows:

# formats for response files:
#       # anything is ignored as a comment
#       STATE   !       NEXTSTATE CONTINUE CRLF STIMULUS RESPONSE       Match STIMULUS -> response
#       STATE   !O      NEXTSTATE CONTINUE CRLF RESPONSE                Match One Time Password -> response
#       STATE   !A      NEXTSTATE CONTINUE CRLF RESPONSE                Match Algorithmic Authentication -> response
#       STATE   !T      NEXTSTATE CONTINUE CRLF RESPONSE                Match Time-based Authentication -> response
#       STATE   M!patternmatch! NEXTSTATE CONTINUE CRLF RESPONSE        Match patternmatch -> response
#       STATE   /patternmatch/  NEXTSTATE CONTINUE CRLF RESPONSE        Match patternmatch -> response
#       STATE   word    NEXTSTATE CONTINUE CRLF RESPONSE                Match first word -> response

The pattern matching is a bit tricky, but I believe I have implemented
is so that no input is ever interpreted (i.e., the string from the
response file is matched against the input and not the other way
around).  Then, if no match has yet been found, the first 'word' in the
input (all lower case letters and digits) is compared to the remaining
response file entries.  If no match is found, the default response
occurs.  I believe all of these are 'safe' in the sense that I have not
used input as program, and I have both checked this and tested it fairly
extensively over a substantial period of time.

To date, no holes have been reported, but there may still be some.

The 'final solution' is to rewrite it all in C and have it proven to
meet flow control properties by an anxious graduate student (that's what
we did with the secure Web server). Perhaps I will get to that some day.
Any graduate students out there?

FC
]

Regards (this definitely looks a winner).
---------------------------------------------