These are the questions asked by Configure and some insight
into the answers.

The first message you can get from Configure is "Make clean first". 
This means that you did not complete the last run of Configure, either
because of a configuration error or a user interrupt to the process If
you get this message, type:

	make clean

Next, configure will ask for the install directory.  This is normally
/dtk and, unless there is a real good reason to place it elsewhere, that
is the right place for it.  Press <enter> to use the last setting.

	Install directory (/dtk):

Next, Configure asks where Perl is located.  It makes a good guess, but
if it is wrong, you might try `which perl` to find out the proper path
for Perl - or perhaps you need to install Perl.  DTK will not run
without Perl.

Next, Configure asks where perl lib is located.  As above, you will need
to get it right or DTK will not run.

Next, Configure asks for host information:

	Which fully-qualified domainname should I claim:

This is almost certainly supposed to be the same domain name you use for
your computers (I use all.net).

Next, configure asks for your REAL operating system name.

	Select your real OS from this list (by number) or enter the OS name (Linux):
		1) Linux	2) Solaris	3) SunOS	4) HPUX
		5) AIX		6) SGI		7) NT		8) Ultrix
		9) SCO"
	Selection:

This is the real operating system your computer is using.  It needs to
be right in order for the configuration files that specify protocol
elements of the TCP/IP stack to come out right.  This information is in
a file called socket.ph - if there is a special one for your system, you
might have to copy it into your directory so you can use it instead of
the ones provided with DTK, but normally, the OS name will tell DTK
allit needs to get it right. 

Next, DTK asks for the operating system name you want to claim you are
using to people you are lying to.  It's a good idea to make this
DIFFERENT from the real operating system so that the deception is even
more confusing and any data they get from your system will mislead them
into trying vulnerabilities that you don't have.

	Select your DECEPTION OS from this list (by number) or enter the OS name (SunOS):
		1) Linux	2) Solaris	3) SunOS	4) HPUX
		5) AIX		6) SGI		7) NT		8) Ultrix
		9) SCO"
	Selection:

Next, DTK asks how you want to log incoming information.  The choice I
currently use is 'D' for database format, but if you get a lot of
attacks that DTK picks up, you might want to use 'C' (compressed)
format.  I would avoid the other formats if I were you.

	Log files Standard, sYslog, Compressed, or Database format (Database):

Next, Configure asks what sort of authentication you want to use for
remote access to your system.  Remote access means that some of the
deceptions will have passwords or other authentication methods that an
outsider can use to gain access to or information from your system.  If
you don't want to configure remote access, select ':' and DTK will never
let anyone in.  I sometimes use 'O' - the one-time-pad - which allows me
to have all of my access points protected by DTK - EXCEPT - after
someone who can guess a 60-character string that is generated
pseudo-randomly by DTK - then guesses a password and knows the protocol
for subsequent entry.

	Password for remote retrieval of the DTK log (all-characters-no-spaces)
	 - OR - : for no password)
	 - OR - O for One Time Pad
	 - OR - A for Algorithmic Authentication
	 - OR - T for Time-Based Authentication: (:)

If you have chosen time-based or one-time passwords, DTK will then ask
if it should generate passwords - or some such thing.  Since you
probably won't be using this feature, we'll ignore it for now.

Now, Configure starts to ask technical questions.  It wants to know how
much information to retain from attempts to overflow input buffers.  DTK
doesn't have an input buffer overflow problem as far as I can tell,
because it uses fixed sized buffers for input, but this also means that
you need to tell it what that fixed size is.  If it is very big, then
when a big input buffer overflow comes along, DTK will store gobs of
useless information - followed by the code of the attack.  If it is very
small, you won't be able to deal with even the normal attack codes.  I
use something around 200, but it's a good idea to use different values
on different machines so the attacker can't use this to figure out what
you are doing.

	Maximum input length to log (200)?

The next question is how long we are willing to wait between inputs
before we shut down the connection with the attacker.  Now I like 20
seconds or so, but like buffer overflow sizes, it is better varied.  If
this time is long, it means that someone trying to flood you with syn
packets or open ports will have more time to do it.  It means that you
may have more resources consumed in deception than desired or have the
resources consumed over a longer period of time.  It also means that a
patient attacker will find out in that many seconds that they are
getting cut off by the system and suspect something is up.  You will
detect this because the audit will reflect the timeout condition, but
that may be a good intelligence indicator for the attacker as well.

	Time (in seconds) between inputs before we act like a core dump (20)?

The next question deals with the limits of your deceptive FSMs.  If you
build a really good FSM, it may be able to lie for a lot of different
inputs, and this would provide a rich environment for the attacker.  If
you use one of the free FSMs provided with DTK, the attacker is likely
to figure out that this system is screwy pretty soon.  Also, the
combination of maximum wait time times maximum number of inputs gives
the maximum time a single session can last..

	Maximum inputs before we act like a core dump (20)?:

Next, Configure wants to know who to send email to if an attack gets to
the point where someone should be notified.  The default is your root -
unless you claim to be from all.net - in which case I will get the mail. 
Please don't send me your private information on attacks!

	Who should I email (root@yourhost.com)?

The next thing Configure does is update installation files.  This causes
lots of things to be displayed and takes a few seconds to a few minutes
depending on how much it has to do for your situation.  Then, it asks if
you want it to generate a fake password file in case anybody wants to
try to steal one.  Now the whole fake password thing is rather complex,
so I will explain a lot more about it - somewhere else.  For now, the
question is, do you want a fake password file that uses your system's
user IDs and other information as a basis for the fake, or do you want
DTK to create one on its own that has nothing to do with your system?

	Generate a fake password file based on your password file (Y/n):N

I chose 'N' for NO in this case, but you might like to choose Y for yes
if you want to fool insiders who steal password files and would know a
pure fake if they saw one.

If you chose a one-time-password scheme for authentication, DTK will now
ask if you want it to create a new set of one-time-passwords, use the
one that you currently have, or not bother to create one at all.  IF you
have created one already and are using it, you normally want to retain
the old one so you don't have to redistribute the new
one-time-passwords.  If you want to change them - perhaps because they
are running out - or perhaps because someone stole the old ones, you
tell DTK to create a new one.

	Generate an OTP file of 100 mantras (y/n/O):Y

If you are (foolishly) working in the /dtk directory instead of doing
the installation the way I described earlier, DTK will try to finish up
now, but otherwise, you get the option to install or not install what
you have just configured.

	Move files in $WORKING_DIR (Y/n):Y

If you say yes - as I did in the example, DTK will now be installed or
updated in the /dtk directory.  The last thing it does is save your new
configuration and clean up any mess it may have left so it will run
properly bext time.
