From: dtk@all.net
Reply-to: dtk@all.net
Organization: Deception ToolKit Mailing List
Subject: DTK Mailing List 980927
<pre>---------------------------------------------
Date: Sun, 27 Sep 1998 10:29:02 +0000
From: "Paul Drain" <secure@magic-badger.net.au>
Organization: Magic Badger Networking Australia
Subject: DTK a real success

Greetings,

	Job well done :) - I have 0.4 of DTK running on about 8 machines
at work, all of which were receiving odd amounts of portscanning activity. 

After putting 0.4 on the telnet ports and enabling the DTK port, we
managed to flush the intrusion out completely and take the required
action. 

Is there (or will there be a way) to implement the logfiles that DTK
generates into syslog, possibly so there's only one logfile to check?

Other than that, an excellent product which i'm looking forward to
seeing become even better in the future.

Regards

Paul

	[We always like suggestions.  There is a way to remotely fetch
	DTK log files from a network of computers, and using DTK's
	database format, this can be fed into an SQL database for
	analysis.  There is also the infocon measure.  These, to me,
	seem a lot better for a network than feeding syslog files for
	several reasons - to wit:

		DTK logs tend to have only information about bad things
		(i.e., attack detections) while syslog files have lots of
		information of which only a small portion is related to
		attacks. This means that all I do is 'tail /dtk/log'
		every once in a while and I am appraised of the situation.
		I also have a program to pull relevant information from
		syslog files and present it to me, but it's a lot less
		convenient, consumes cycles, and is far more time consuming
		over a network.

		DTK's 'infocon' - which can be remotely fetched as well -
		provides a nice network-based quick assessment of the
		time picture of attacks.  I have the ability to pull infocon
		levels from a network of 50 computers and present the data
		on one screen with colors used to tell me what's worthy of
		attention. Without significant performance impacts, I can
		do this several times per minute. When I see something worth
		investigating, I drill-down into the DTK logs, and if called
		for, into the syslogs on a system-by-system basis. This
		approach seems to work a lot better for large networks.
		

	All this being said - I will also try to rig a syslog capability
	for version 0.5. - FC]

---------------------------------------------
