What's in DTK? DTK currently has the following components:
How does it work? DTK simply listens for inputs and provides responses that seem normal (i.e., full of bugs). In the process, it logs what is being done, provides sensible (if not quite perfect) answers, and lulls the attacker into a false sense of (your) insecurity.
What kind of fancy features does it have? Some of them include:
Where do we send grattitude/money/updates/other nice and helpful stuf? To me (fc at all.net).
Where do we send complaints? Our official complaint desk and help service is available 24 hours a day, 7 days a week and can be reached at nobody@nowhere.org via email, at the web address http://nowhere.org/complaints, via telephone or FAX (dial 0 and explain what you want), or via ephemeral communications at - you know where.
From: dtk@all.net Reply-to: dtk@all.net Organization: Deception ToolKit FAQ Subject: Deception ToolKit FAQ 980311 --------------------------------------------- I apologize in advance to any of you who did not want to get this FAQ on DTK. If you wish me to continue to feed you such information, I will do so without further action on your part. If you let me know that you don't want to hear more, I will remove you from further distributions. Thank you for your comments and assistance, and I hope we will continue to improve DTK for all to use. FC --------------------------------------------- > I noticed the announcement of the DTK in the RISKS digest. Neat! I look > forward to giving it a try. It does beg the next question, of course: > if hackers actually *do* start looking to see if anything is running on > port 365 before attempting to break into the machine, do we even need > to run the DTK? Why not just put something on port 365 to make it look > like we're running it? That's the best part of it. If enough people use deception, you don't need it any more because the attackers are so unsure, they cannot proceed. --------------------------------------------- > Interesting idea. However you might want to pick a port other than > 507, as that's been assigned by IANA for at least a year: Done: > dtk 365/tcp Deception ToolKit > dtk 365/udp Deception ToolKit --------------------------------------------- > Your ideas for a deception defense against hacker > attacks are novel. Certainly such defenses are > more effective when lots of people are practicing > deception, which is why I decided to write to you. > ... > After reading your description of your DTK in Risks > 19.62, I immediately thought that enabling this > service on future NICs would be a good idea. We > will eventually publish an API so third-parties > can develop their own "snap-in" modules to our > NDIS "Wedge" architecture, which works on many > flavors of Windows (95, NT 3.51 and 4.0). ... --------------------------------------------- > G'day Fred, > > I saw your message in Risks re: Deception Toolkit and thought it's a > good idea to sit something on port 507, but ... > > [root@ultraman /root]# telnet www.all.net 507 > Trying 207.222.214.225... > telnet: Unable to connect to remote host: Connection refused > > Hmm, so does that mean you're running DTK on www.all.net or not? :-) A deception is only useful if it keeps you guessing. I would guess that www.all.net is not running DTK, but then I am not running www.all.net - another deception. It is run by Netcom. I, on the other hand, am running DTK on several computers, soon to be more than 50, but if I told you which ones, how would you know I was telling you the truth? > FWIW I started running intrusion detection systems here a year or two > ago. I want to know when somebody's scanning my network. Hit the wrong > port or the wrong IP address, and I find out about it. --------------------------------------------- > Can you tell me the address of a computer which _is_ running DTK then? > I merely want to see what it says when I open tcp to port 365. If you do telnet365 it will respond The Deception ToolKit is running on this system and then hang up. You can run DTK yourself - it is available at the all.net Web site. --------------------------------------------- > DTK has patterns which can be detected. E.g. too much buggy software > apparently running on a host whose sysadmin is otherwise clueful will > be suspicious. Indeed, but by the time you can tell the difference, we have recorded your illicit entry and, optionally, reported your activities to the systems admin. But even more importantly, if you back off when you find DTK running, then DTK has done its job. There's no getting around the fact that in order to find out if the defense is there, you have to trigger the defense, and by that time it is too late. --------------------------------------------- > Where is DTK on all.net? It is DTK - The Deception ToolKit - look at http://all.net/ - in the top banner area before Books and Papers in red foreground with yellow background, the words "Deception ToolKit" appear. Press those words and it will take you there. Alternatively, try http://all.net/dtk.html - but that URL is subject to change, whereas the banner presence is more likely to remain viable for longer. --------------------------------------------- > Hello. > > I just downloaded dtk to install on a BSD/OS machine. I noticed that > two of the Perl modules had $PERLLIB="/u/local/lib", while two had > $PERLLIB="/usr/lib/perl5". I assume that all of these should be the > same. On BSD/OS 2.1 these library functions are in > /usr/contrib/lib/perl5, by the way. Thanks for the update - I will fix this. In fact, they don't user PERLLIB, so I should just remove it. --------------------------------------------- > I read only the introduction, but it seems to me that you have > to give up using all the services you are baiting. What did I miss? > > George That's exactly right. The point is to make it hard for the attacker to know which services you are really using and which are deceptions. In a future edition I may find a way around this, the gopher and Web servers are actually secure servers that work, and the internal deception tools (coming someday) will run the real services and act only as wrappers. --------------------------------------------- > Hi. I was just reading your DTK home page following your comp.risks > announcement, and I have a question. If I defend a service with DTK, > does the service still operate for those that use the service for it's > intended purpose? The example script in the README file shows > interesting ways to handle someone trying to exploit sendmail to obtain > the password file. Does this script turn off real sendmail processing? > or does it pass through requests that it doesn't recognize as attacks? If you use it via TCP wrappers, you can allow sendmail from some places and prevent it from others. In my case, I have one machine that has real sendmail and the other machines use POP3 to get mail from it while forging sendmail ports. Unless the attacker knows which machine to attack, the odds are that I will pick up the attempt before they succeed. --------------------------------------------- > DTK looks like good entertainment, and possibly a security benefit, > especially if lots of people start using it. > I looked through the description, and didn't see what platform > it runs on - is this for Unix, or NT (which has users more desperately > in need of protection.)? > > Does it need a stand alone machine, or run on the same machine > as your real sendmail, etc.? DTK runs on anything that has IP and Perl. I haven't tried it on NT yet but I will when I get a chance. It works best if it is installed widely. --------------------------------------------- > Am I to understand that DTK will not interfere with the "normal" operation > of a system? (ala, tcp-wrappers). I assume it must. Right. You just do deception on the ports you are otherwise not using or on ports you would otherwise do tcp-wrapper deny on. Thus it doesn't change normal operations. > It would be very interesting to catalog the means by which DTK distinguishes > normal/nominal port accesses from (potential) malicious exploits. Any port that would otherwise not be active reflects an unauthorized use. The general purpose pattern matching can be used to look for requests for passwd, etc. and this gives you a bit more. > This represents a sort of gray-area regarding the philosophy "don't show > people how to conduct exploits, only how to close them." Whereas the former > often involves a logical chain of accesses, one can (I assume) detect an > exploit based upon a limited signature. DTK doesn't include any details of exploits - although you certainly can do that if it is desirable. It looks for unauthorized port usage, attempts to get passwd files, you can detect portions of known attack patterns, and so forth. The real point is that the attacker cannot tell what is real and what is memorex until you have an extensive trace. --------------------------------------------- > It occurs to me that attackers will soon recognize the crypt-strings in any > standard "fake.passwd" file. > > Remedy: It would be easy to write, (and for each user to run upon > DTK-install) > a "generate-fake-passwd" file, with a varied number of accounts, names, and > of course *hard* passwords. Then hackers could never build up a catalog of > strings they could check to see quickly if the system employed DTK. Good idea - I will build one in unless you have one hanging around. How about some easy and some hard - to try to find out how good they are by how long it takes? ... > The problem with easy and hard ones is it depends upon the dictionaries they > use. True random passwords should take them awhile, varying upon the kind > of horsepower they have. Easy ones could take a little or a lot, depending > on how they sort their dictionaries, might not give as good a measure. I will scrap one together from my password guessing program later today or tomorrow. > Lots of variables. Maybe they go on vacation after fetching the PW file, > and stark hacking it days later. Unlikely, but... ... > Generating a good pw-file generator has sticking points that need to be > addressed. I thought I would list some here: > > 1. It must include the major "system" accounts that would be expected. Clearly > 2. The "system" accounts would have to have reasonable UID, GID, HomeDir > and Shell assignment, consistent with the type of platform the user > is installing DTK on. (Some systems give different HomeDirs to the > standard services, varied GID assignments perhaps, Shell is sometimes > left empty, sometimes is set to "/bin/false" or "/bin/true". Yes, it will be a real password file slightly modified for the purpose > 3. The "user" accounts must have reasonable (and unique) UIDs, and a > consistent HomeDirPath (all /home, or /usr/home, or /local/users or?) > > 4. The "user" account names would have to appear realistic, perhaps a > mixture of TLA's like "azb", (some with _r and UID 0) and a random > selection of "human" names with prefixed or suffixed initial. > > 5. Then there is a world of things one might need to do to make the > GECOS field appear authentic, and yet not "copycat". Not AI - just a real copy of the password file with some changes - given to the user for modification to remove sensitive information. > Geez, this starts looking like AI. ___TONY___ Just NS. (natural stupidity) --------------------------------------------- > [snip] > > >Yes, it will be a real password file slightly modified for the purpose > > >Not AI - just a real copy of the password file with some changes - given to > >the user for modification to remove sensitive information. > > I fear that many sysadmins will opt to make as few mods as NS dictates. > Clearly the crypt-strings need to be generated and replaced. But it seems > a security concern to allow *any* of the (user) account names to remain, > and there may be other clues of value to the attacker in GECOS field data. > (Phone numbers, building numbers or project acronyms aid in giving credence > to a potential human-engineering effort, and may even lead an attacker to > the real passwords thru good guessing. Much of this data may appear to be > "harmless, non-sensitive" to a typical sysadmin.) So you think I should include options for how fake the password file is? I could include a substantial list of names that I have gleaned over the years and generate random first name last name pairs along with room/suite numbers and phony phone extensions. It wouldn't be hard to do - but is it worth the effort? --------------------------------------------- > >The basic idea is not new. We use deception to counter attacks. In the > >case of DTK, the deception is intended to make it appear to attackers as > >if the system running DTK has a large number of widely known > > > It increases the attacker's workload because they can't easily tell > > which of their attack attempts works and which fail. For example, if > > You later say "This deception is port 507 - which we have staked a claim > for as the deception port. Port 507 indicates whether.." Doesn't putting a > standard on this give it away? A stealth port scan would reveal this port > as active and warn a would be attacker. Yes, but... the deception port can also be used as a deception. If enough people use DTK, simply running the deception port will keep away the attackers. Then we have succeeded. In addition, some of us will not use the deception port even though we use DTK so we can still gather data on attackers. > > It allows us to track attacker attempts at entry and respond before > > they come across a vulnerability we are susceptible to. For example, > > when the attacker tries to use a known Sendmail attack against our > > site, we record all of their entries to track their techniques. With > > this deception in place, we have no problem picking up port scans, > > password guessing, and all manner of other attack attempts as they > > happen. > > This can be done with the OS as is, no further mods needed. What would the > toolkit entail? It can be, but it is difficult and introduces potential complexity for the defender. The goal is to make it harder on attackers, not defenders. You might try downloading DTK to find out what it entails. > > It sours the milk - so to speak. If one person uses DTK, they can see > > attacks coming well ahead of time. If a few others start using it, we > > will probably exhaust the attackers and they will go somewhere else to > > run their attacks. If a lot of people use DTK, the attackers will find > > Securing the server would also make someone go elsewhere. Unfortunately, few people know how to secure servers - but anybody can run deception and get a large portion of the same effect for far less time and effort. > > up to date, we will eliminate all but the most sophisticated > > attackers, and all the copy-cat attacks will be detected soon after > > they are released to the wide hacking community. This will not only > > Keeping up with the security concerns and your own system will do the > same. If we could only get people to do that, it would make security work far better. But perhaps for those in the world that are unable to do so, DTK provides a viable option. > > avoid deceptive defenses, so... the attacker's level of uncertainty > > rises, and the information world becomes a safer place to work. > > >Your positive and helpful comments are appreciated. FC > > It seems like this is more work than benefit. Like I said above, keeping > up with recent security concerns and applying fixes to an already secured > box will take care of a lot of those concerns. A five line shell script > and a single port opened on an "off" port will tell you if someone is > port scanning you. A little modification to sendmail will log all non > standard commands if it is that much of a concern. Even then, does it > really help you? To any halfway serious attacker, you only stand a chance > of mailing the admin of one of their hacked accounts, if that. No? As I said in the beginning, deception is nothing new. DTK just makes it easier and more reliable for the masses. A five line shell script on a single port has low probability of detecting many attacks and high probability of containing a flaw that introduces a new vulnerability. The little modification to sendmail will not protect you from buffer overflows in the inputs to sendmail. The idea of DTK is not to eliminate the serious attackers directly. It is designed to make things less certain for all the attackers and to make the lamers go away. This improves the signal to noise ration so we can go after the serious attackers without all the other stuff distracting us. DTK is not the end all to information protection. It's not strong protection against serious attackers. Today, it's not even very good against lamers. But it's a beginning that serves some reasonable value. It works, it is reasonably secure, and it definitely increased the uncertainty level for the bad guys. If you don't want to use it you don't have to, but you might consider running the deception port anyway - just to make the attackers less sure. By the way, the deception port is only a 1-line C program, and the whole DTK today is only 100K. If you are interested in a copy, it is free to download for the all.net web site. --------------------------------------------- > > I would like to announce and introduce a new security tool available for > > free > > And worth every penny of it! I like the idea, Fred. It's not up there > with those tiny little experts I recall working on modules of complex tasks, > but I like it. Matter of fact, I did some writing on intrusion spoofing > some years ago (probably around '90), the idea being that you made it look > like an intrusion worked so you could keep the intruder connected long > enough to track him down and/or provide planned misinformation. ... The real question is what of your code to do this do you want to contribute for the good of all. It's not a new idea, but it is a new idea for lots of people to run deception as a matter of course. > DTK looks like a really powerful concept. Thanks for reducing it > to a program. > > However, I noticed that YOU'RE not using it yet :-) Actually, I am using it. But whether to indicate it on the port is optional depending on whether you want to notify the attackers or collect data on them and take their time. ... > (4)% telnet all.net 507 > Trying 207.222.214.225 ... > telnet: connect: Connection refused > (5)% telnet www.all.net 507 > Trying 207.222.214.225 ... > telnet: connect: Connection refused 207.222.214.225 is not my computer - another deception. --------------------------------------------- > The concept is great! The Hackers could waste a lot of time > chasing after a Fake vulnerability. But it just seems to me that > the effort to create a really good DTK that will really fool people > is about the same as the effort to fix the vulnerabilities in > our systems. DTK doesn't have to really fool people at all. If it increases uncertainty for the attackers, it can do a lot to reduce attacks - both inside and outside. DTK does not have to fool all the people all the time. It is doing great if it fools some of the people some of the time and scares some of the people some of the time. But even more importantly, once a lot of people use it, how do the attackers know whether they are being fooled or not? How do they know how good your deception is - or mine? And for those who don't create original attacks, we only have to keep up with the published attacks to trick them most of the time. In terms of the difference in defender effort, it is enormous. If one of us makes a new deception, we can all share it with little or no effort. But if we try to secure each and every service on each and every port on each and every machine, we will spend enormous resources and never complete the job. Perfect defense is a pipe dream, but probabilistic deception is easily attained. > We all know that many systems are poorly configured, never patched, > never monitored for break-in attempts, etc, etc. After fixing > the problems, there is less need for the Deception ToolKit unless > you are the FBI or CIAC. Deception benefits us all when any of us use it. The more people use it the more we all benefit. DTK offers near zero-cost monitoring of unused ports. Since only legitimate users typically know which ports are legitimate in most systems, only illegitimate access attempts tend to trigger DTK - so we have few false positives. But the chances of the attacker getting caught in the attempt goes from near zero to the ratio of deceptions to actual services for each attempt to break in. For 10 deception services and 10 real services, the first attack attempt has a 50% change of generating a detection. If the attacker guesses right and the service doesn't have the specific vulnerability they may be looking for, they have to risk it again to get in. So 50% deception and 80% removal of vulnerabilities generates a 90% chance of being detected on every try! The mean time till entry is 10 tries, so the likelihood of undetected entry is very low. Once warned, the systems administrator can act to increase defenses, turn off services, watch carefully, and so forth. Add to this the extra effort by the attacker to differentiate legitimate from deception ports and the virtual elimination of undetected attack tools such as port scanners, and so forth, and you have a strong case for DTK. DTK is free to get, easy to install, operate, and maintain, simple in concept and execution, and dramatically improves the effectiveness of protection against insiders and outsiders. Perfect defense has been tried for 20+ years, no perfect defense has been devised yet, and no perfect defense appears to be looming on the horizon. DTK attacks the weakest link of the attackers. Their fears of being caught, their uncertainty about whether they are being detected and watched, and the bursting of their egos when they find out they have been fooled. DTK is a psychological defense more than a technical one, and that is the real reason it has a good chance of succeeding. ---------------------------------------------