From: dtk@all.net Reply-to: dtk@all.net Organization: Deception ToolKit Mailing List Subject: DTK Mailing List 980313 
---------------------------------------------
From POPmail Thu Mar 12 23:15:04 1998
 with Netcom Interactive Netcom POP3 (version 2.01  Mon Oct 20 16:14:44 CDT 1997) Fri Mar 13 01:12:47 1998
X-From_: jericho@dimensional.com  Fri Mar 13 01:08:34 1998
Received: from blackhole.dimensional.com (0@blackhole.dimensional.com [208.206.176.10]) by multi33.netcomi.com (8.8.5/8.7.3) with ESMTP id BAA09918 for ; Fri, 13 Mar 1998 01:08:34 -0600
From: jericho@dimensional.com
Received: from flatland.dimensional.com (jericho@flatland.dimensional.com [208.206.176.24])
	by blackhole.dimensional.com (8.8.8/8.8.nospam) with SMTP id AAA27483;
	Fri, 13 Mar 1998 00:08:34 -0700 (MST)
Date: Fri, 13 Mar 1998 00:08:33 -0700 (MST)
Reply-To: jericho@dimensional.com
To: Fred Cohen 
Subject: Re: deception tool kit? (fwd)
In-Reply-To: <199803121332.FAA16609@all.net>
Message-ID: 
X-NoSpam: Pursuant to US Code; Title 47; Chapter 5; Subchapter II; 227any and all nonsolicited commercial E-mail sent to this addressis subject to a download and archival fee in the amount of $500 US.E-mailing to this address denotes acceptance of these terms.
X-Copyright: The content of this message may not be reproduced in any form(including Commercial use) unless specifically permitted bythe author of the message. Requests must be in writing.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> All of what you are saying is probably true - but if you look at it, it
> drives up the workload for the attacker - thus they can hit fewer systems
> per unit time. For the attacker not willing or able to do this level of
> sophistocation, we win.

I maintain that any halfway decent hacker will probe from one site, attack
from another anyway. A common trend is to see a hacker use a "throwaway"
account" to probe hundreds of hosts one night, only to attack from other
sites over the next month.

If you are talking about the script kiddies that think 'finger' is a
halfway good chance of getting in a system, then the DTK isn't needed.
Their own lack of system knowledge does it for you.

I guess I am seeing this as a defense against a very small percentage of
hackers.

> It's a lot of work to keep updating software for every change on every
> system, most systems admins can't keep up, and perhaps more importantly, the

So you are adding to their workload, when that time can be spent securing.
Why spend time giving the image of security rather than actual security?

> With deception you are detecting attempts and consuming attacker resources
> during this window of opportunity. In addition, many attacks are just not
> discovered for a long period of time after they are in active use by their
> creators. Deception offers the potential for finding these earlier.

You mean new exploits that haven't been public announced? If so, how would
DTK find those potentially?

> In other words, you agree that it works, but it's not as easy as I make it

Yes and no. I ran them for fun because I have an open challenge for anyone
to hack my machine. So I wanted to monitor those attempts a little more.
If I hadn't made that challenge, I wouldn't have run the Deception style
services.

> sound. Fair enough. Perhaps you would like to provide me with copies of some
> of the better deceptions you have running so I can send them out with DTK?

Aside from fake banners on known services.. a fake copy of a passwd file
in the ftp area (that was crackable and would give a funny message if they
cracked all the words), a port open to catch portscanners, a fake daemon
that offered the user a chance to input, so people were hip to trying
buffer overflows, etc.

> > Really? If an admin has one hour to install a package, why install this
> > over Tripwire? (being devil's advocate)
> 
> In my opinion, tripwire is a poor substitute for a real defense, but I think

So you think DTK > Tripwire as far as "real defense"?

> it's fine to run it anyway. I have an internal audit tool that I run on
> every system I set up (if I want to keep it relatively secure).
> Unfortunately, the 10 hours that follow running tripwire where you try to
> figure out which of the things it claims are problems are really problems
> and which you need in place makes the 1-hour scenario a bit unrealistic.

True. I think Tripwire suffers the same problem Tiger does. Tiger gave me
a 180k ascii log of problems it found on a machine that I had secured
adequately. 179k of it was worthless.

> There's also TAMU which I think does a better job but produces more confusion
> because it tells you about so many more of the potential flaws in your
> system. But then none of these tools tells you about even a small percentage
> of the actual flaws in your system, and none of them increases the workload
> for the attacker. They are all aimed at making more work for the defender in
> an effort to get closer to perfect defense - which we all know is just not
> feasible today for the vast majority of systems.

True. Those tools SHOULD be aimed at looking for current problems.
Something that Ballista and ISS do.

> I think that admins should keep up with security concerns, and that
> deception is another way to do it. The question is, what gives more bang for
> the buck? We have proven over a period of more than 50 years that preventing
> every attack just doesn't work, and we have intrusion detection tools that
> are poor after 10 years and hundreds of millions of dollars of investment.
> Maybe it's time for cheap, fast, and easy to be considered as an alternative.

Making the DTK cheap and fast will be a task though..

> Not true. I have tested a variety of scans against DTK and it detects them
> quite well. It prints out a log entry that says "PortScan". At least some of
> these scans are reflected in the activation of a port where the initial read
> fails, and when DTK sees this, it lets you know.

It catches FIN scans, half scans, etc? Have you tried to run nmap against
it to see if it recognizes the portscan?

> As far as DTK goes, it will not protect you from overflows in a flawed
> sendmail. But it will allow you to detect people trying to exploit this flaw
> against the machines you have running deception, perhaps before it is
> exploited on the machine running the flawed sendmail.

Does it modify sendmail to log all non standard commands and traffic? Or
does it wrap sendmail and monitor "signature" attacks?

> > I maintain that if you put up this big bad fence with barbwire and bright
> > lights, people will go away long before an advanced trap will come into
> > use. Follow?
> 
> I do, and what I think you are saying is that deception (i.e., perception)
> is the right way to go.  As we both know, the big bad fence is not really

I dunno :)  I could be saying that closing down non-essential ports and
keeping up with recent software presents the image of more security. :)

How many people do you think you scared off with the fc.net telnet banner
a while back? And then how many people did you get to telnet to you just
to see it and challenge you? In the long run, was it worth it?

In that case you weren't presenting the big fence really, but you can see
how it may backfire.

> that much more secure than the defense you cannot tell is there. Neither
> really works at all unless you have the active response capability behind
> it, and a good response capability makes the big bad fence much less
> critical. The sign at the door (on port 507) that tells them there are
> attack dogs within and plays pre-recorded barks when they approach deters
> the casual attacker, while someone who is really serious about it will try
> no matter what kind of fence you have.

In which case a single port and five line script will do the DTK job :)

> > Like I said, I will check it out. And I will continue to play devil's
> > advocate to make sure you explore all possibilities. :)
> 
> I welcome your interest and active participation. If you have tools you
> would like to provide to enhance DTK, I would be happy to include them and
> give credit - if desired. When you try it out, you will probably find it
> fairly lame, but version 0.0 is only a beginning.

Right.. but what program was "good" during its first version? :)

-b
---------------------------------------------
From fc Fri Mar 13 06:06:48 1998
Subject: Re: deception tool kit? (fwd)
To: jericho@dimensional.com
Date: Fri, 13 Mar 1998 06:06:48 -0800 (PST)
In-Reply-To:  from "jericho@dimensional.com" at Mar 13, 98 00:08:33 am
From: Fred Cohen 
Reply-To: fred at all.net
Organization: Fred Cohen & Associates
X-Mailer: don't even ask
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 13492     

In reference to the following view expressed by jericho@dimensional.com:
> 
> 
> > All of what you are saying is probably true - but if you look at it, it
> > drives up the workload for the attacker - thus they can hit fewer systems
> > per unit time. For the attacker not willing or able to do this level of
> > sophistocation, we win.
> 
> I maintain that any halfway decent hacker will probe from one site, attack
> from another anyway. A common trend is to see a hacker use a "throwaway"
> account" to probe hundreds of hosts one night, only to attack from other
> sites over the next month.
>
> If you are talking about the script kiddies that think 'finger' is a
> halfway good chance of getting in a system, then the DTK isn't needed.
> Their own lack of system knowledge does it for you.
>
> I guess I am seeing this as a defense against a very small percentage of
> hackers.
> 

In my experience, even the simplest deceptions work against the vast
majority of so-called hackers, and even relatively sophistocated attackers
get caught by deceptions some of the time. But as far as I am aware, no
scientific study has been done of the subject. Many defenders, myself
included, often make the mistake of thinking that the attackers are as good
as they can be.  But in my experience, few of them are very good at all.

> > It's a lot of work to keep updating software for every change on every
> > system, most systems admins can't keep up, and perhaps more importantly, the
> 
> So you are adding to their workload, when that time can be spent securing.
> Why spend time giving the image of security rather than actual security?

Because it is more cost effective.

> > With deception you are detecting attempts and consuming attacker resources
> > during this window of opportunity. In addition, many attacks are just not
> > discovered for a long period of time after they are in active use by their
> > creators. Deception offers the potential for finding these earlier.
> 
> You mean new exploits that haven't been public announced? If so, how would
> DTK find those potentially?

Not undetected attacks. Detected and published attacks that have not been
properly defended against yet. This probably covers the majority of known
vulnerabilities today. But even unknown vulnerabilities can be detected by
deception because the attacker who doesn't know that they are running
against deception will try their attack and the deception system will record
what they do. This recording provides the means to learn about the new
attack.

> > In other words, you agree that it works, but it's not as easy as I make it
> 
> Yes and no. I ran them for fun because I have an open challenge for anyone
> to hack my machine. So I wanted to monitor those attempts a little more.
> If I hadn't made that challenge, I wouldn't have run the Deception style
> services.

And it worked for you, but you don't think it will work for others?

> > sound. Fair enough. Perhaps you would like to provide me with copies of some
> > of the better deceptions you have running so I can send them out with DTK?
> 
> Aside from fake banners on known services.. a fake copy of a passwd file
> in the ftp area (that was crackable and would give a funny message if they
> cracked all the words), a port open to catch portscanners, a fake daemon
> that offered the user a chance to input, so people were hip to trying
> buffer overflows, etc.

So what you did was effective and slightly less sophistocated than DTK and
yet you think that it's a bad idea to make a more sophistocated version
freely available to all?

> > > Really? If an admin has one hour to install a package, why install this
> > > over Tripwire? (being devil's advocate)
> > 
> > In my opinion, tripwire is a poor substitute for a real defense, but I think
> 
> So you think DTK > Tripwire as far as "real defense"?

No. Neither DTK nor Tripwire are very good defenses. But then neither are
most of the defenses available today. I think that DTK is another tool for
the defenders and that it is an important tool because of its psychological
effects on the attackers. According to Donn Parker, who has studied attackers
who have been caught at some length, uncertainty scares them and most of them
got caught because things didn't work the way they thought they worked.  DTK
offers a way to increase their uncertainty and get them caught.

> > it's fine to run it anyway. I have an internal audit tool that I run on
> > every system I set up (if I want to keep it relatively secure).
> > Unfortunately, the 10 hours that follow running tripwire where you try to
> > figure out which of the things it claims are problems are really problems
> > and which you need in place makes the 1-hour scenario a bit unrealistic.
> 
> True. I think Tripwire suffers the same problem Tiger does. Tiger gave me
> a 180k ascii log of problems it found on a machine that I had secured
> adequately. 179k of it was worthless.
> 
> > There's also TAMU which I think does a better job but produces more confusion
> > because it tells you about so many more of the potential flaws in your
> > system. But then none of these tools tells you about even a small percentage
> > of the actual flaws in your system, and none of them increases the workload
> > for the attacker. They are all aimed at making more work for the defender in
> > an effort to get closer to perfect defense - which we all know is just not
> > feasible today for the vast majority of systems.
> 
> True. Those tools SHOULD be aimed at looking for current problems.
> Something that Ballista and ISS do.

I don't know Ballista, but I am not a fan of ISS either. I also have a
scanner similar to ISS (started at about the same time as ISS, it led ISS
for some time but my marketing is not as good as theirs). The real problem
with scanners is false positives and false negatives. The false positives
come from the fact that they don't take your policies into consideration in
their scans (another 179K of trash with 1K of value). The false negatives
come from the fact that they don't detect most of the things that serious
attackers are likely to try.

> > I think that admins should keep up with security concerns, and that
> > deception is another way to do it. The question is, what gives more bang for
> > the buck? We have proven over a period of more than 50 years that preventing
> > every attack just doesn't work, and we have intrusion detection tools that
> > are poor after 10 years and hundreds of millions of dollars of investment.
> > Maybe it's time for cheap, fast, and easy to be considered as an alternative.
> 
> Making the DTK cheap and fast will be a task though..

It's pretty cheap (free to get and quick to install) and fast (takes little
sytem or human resource) but it's also just in its infancy.  If the
government spent 50 million dollars on deception (send $5Mil to me and I'll
by happy) over 10 years, we would likely have deceptive systems that were
extremely hard for attackers to detect, caught the vast majority of
attempts, and made technical attacks - by insiders as well as outsiders -
far more risky. The reason deception is a better investment is that - unlike
perfect defenses and intrusion detection - the problems are not undecidable
or even at the extremes of complexity. All we have to do is emulate (or
duplicate) portions of systems that we already have.

> > Not true. I have tested a variety of scans against DTK and it detects them
> > quite well. It prints out a log entry that says "PortScan". At least some of
> > these scans are reflected in the activation of a port where the initial read
> > fails, and when DTK sees this, it lets you know.
> 
> It catches FIN scans, half scans, etc? Have you tried to run nmap against
> it to see if it recognizes the portscan?

I have and it recognizes some quite adept scans. It's by accident of course.
It just happens that in testing DTK against the scanners I found out that
they cause part of the protocol to be triggered but don't finish the
connection.  It was causing infinite loops in DTK - and when I fixed the
problem I told DTK to put out the message "PortScan" when it encountered the
condition. I don't claim it will always work - I haven't had the spare time
to test it that thoroughly yet - but is seems to do the job - even against
Fin scans - at least under Linux Perl5 (latest).

> > As far as DTK goes, it will not protect you from overflows in a flawed
> > sendmail. But it will allow you to detect people trying to exploit this flaw
> > against the machines you have running deception, perhaps before it is
> > exploited on the machine running the flawed sendmail.
> 
> Does it modify sendmail to log all non standard commands and traffic? Or
> does it wrap sendmail and monitor "signature" attacks?

Neither. If a particular machine is running sendmail, you can't run DTK on
the same port unless TCP wrappers can differentiate legitimate from
illegitimate remote locations for you. DTK runs on the ports you do NOT have
legitimate services on. This it inherently detects only clearly unauthorized
activities by virtue of the fact that no authorized activity is on that port
for that remote IP address. Thus there are no false positives - any activity
is unauthorized - and there are no false negatives (that is - there is a
known level of coverage)

> > > I maintain that if you put up this big bad fence with barbwire and bright
> > > lights, people will go away long before an advanced trap will come into
> > > use. Follow?
> > 
> > I do, and what I think you are saying is that deception (i.e., perception)
> > is the right way to go.  As we both know, the big bad fence is not really
> 
> I dunno :)  I could be saying that closing down non-essential ports and
> keeping up with recent software presents the image of more security. :)

Yet another deception?

> How many people do you think you scared off with the fc.net telnet banner
> a while back? And then how many people did you get to telnet to you just
> to see it and challenge you? In the long run, was it worth it?

In the long run, we caught about 40 people who were breaking into sites all
over the Internet, got several of them punished, reduced the number of
attacks on other sites, traced back the first few major DCA attacks, and
caught hundreds of folks who were dealing in stolen software. Sting
operations work very well. Was it worth it? I think so. Would I do it again?
Sure - if it made me any money.

> In that case you weren't presenting the big fence really, but you can see
> how it may backfire.

I was really a very big fence - with a highly responsive guard force - just
no legal or political bite behind it.  I ran mathematically proven secure
servers and published the source code. I anounced the zero tollerance policy
and told them to keep away. During the attacks, I published lists of
attacker names and IP addresses for all to see. Not a single attacker liked
being put on the rogues gallery, and quite a few systems admins thanked and
supported my efforts. It was in a physically secure and secret location. We
had redundant connections and I had calculated worst case bandwidth
implcations to assure that it was not feasible to overload my system. I had
packet-level detection and analysis of every incoming packet that wasn't
explicitly permitted. I used redundant audit trails and automatic audit
comparrison software to verify that I knew precisely waht was going on and
that no inconsistencies were present. I tracked down every packet from every
source to determine what it was and how it operated. I has special filters,
some of which were later published by CERT (without citation) as the means to
eliminate IP address forgery and they are now in widespread use by ISPs. No
source routing, fragmented packets, packets with identical source and
destination ports, and on and on were allowed.  I ran deception on several
ports to detect thnigs I otherwise might not be able to detect. The list
goes on. It was a high fence indeed.

> > that much more secure than the defense you cannot tell is there. Neither
> > really works at all unless you have the active response capability behind
> > it, and a good response capability makes the big bad fence much less
> > critical. The sign at the door (on port 507) that tells them there are
> > attack dogs within and plays pre-recorded barks when they approach deters
> > the casual attacker, while someone who is really serious about it will try
> > no matter what kind of fence you have.
> 
> In which case a single port and five line script will do the DTK job :)

Indeed, against som eportion of the attackers it works quite well. But I
think we can do better and better if we try harder and harder and that it
will work at least as well as most of today's alternatives - probably better
in many cases.

> > > Like I said, I will check it out. And I will continue to play devil's
> > > advocate to make sure you explore all possibilities. :)
> > 
> > I welcome your interest and active participation. If you have tools you
> > would like to provide to enhance DTK, I would be happy to include them and
> > give credit - if desired. When you try it out, you will probably find it
> > fairly lame, but version 0.0 is only a beginning.
> 
> Right.. but what program was "good" during its first version? :)

Thanks for the discussion.

---
Fred Cohen & Associates: http://all.net - fred at all.net - tel/fax:510-454-0171
			Have a great day!!!
---------------------------------------------