Security-Why Not Watch The Crackers? 185
An Anonymous Coward asks: "Over the years I have heard the idea of luring in Crackers into a
honeypot, so you can watch them and see what they are doing. It has always seemed to me to be a better idea to keep the Crackers completely away with a low profile and a firewall. What do you think?" This is an interesting approach to security and one I have also thought about from time to time...assuming you can build a convincing enough trap so you can learn how they work. "Forewarned is forearmed", especially when it comes to Cracking. How likely would such traps fool really good crackers? Update: 04/07 03:09 by CT : originally this story misused 'hacker' quite offensively. I corrected it.
Re:Hackers, Hackers, Hakcers!!! (Score:1)
Re:Fooling? (Score:1)
Building a _hornets_ nest (Score:1)
So you have this honey pot that you've built, you are entertained by watching script kiddies crack the machine left and right. Meanwhile the time (and money) you should've spent hardening the rest of your network ends up getting breached. I personally don't know who has the time to set up decoy machines, when it's difficult enough keeping servers patched in a 24x7 production environment.
If you are looking for trouble then by all means build yourself a honey pot. Fix the bugs one by one so you can _learn_ how the cracker works. Just don't be surprised when you're honey pot of a machine bites you in the ass.
Bob Tribit
Re:Simulated environment is not a good idea (Score:1)
Oh yeah, and Shut Your Mouth.
Re:Honeypots can be illegal (Score:1)
It can't be entrapment if you are not interested in prosecuting. This guy is talking about setting up a system that looks attractive to crackers that is set up similar to his real hosts so he can find out what methods are being used to probe and crack so he can better protect his real hosts.
He puts the honeypot behind a firewall with rules set to deny outgoing connections that the cracker might use to attack other hosts. He keeps a close eye on it and kicks the cracker off and fixes the holes used to a) keep him from using it to stage attacks on other networks b) keep him busy trying to get back in rather than having time to launch attacks c) find out what other vulnerabilities this guy knows about and will try next.
>Honeypots encourage the hacker, while a closed door might frustrate them and they'd go away.
Read the article, please.
Re:chroot jail ?? (Score:1)
What? How do you chroot back further than what the current / is? chroot / /bin/sh would be redundant, and I highly doubt chroot ../../ /bin/sh would work. Granted, as root you can get whatever you want done (i.e. write a program to read data by sector), but I still think it's impossible to chroot below the current root in a chrooted environment.
..
Re:Simulated environment is not a good idea (Score:1)
"hacker" is as dead a word for programmers as "gay" is a word for describing happiness.
Deception Toolkit (Score:1)
The DTK is for poisoning the well. If you really have the time to watch what a cracker is doing, by all means put in a honeypot. But then you have to monitor it, figure out what is happening, and apply similar fixes to your production machines.
No matter what you do, you should have a firewall or two anyway. The main firewall should block everything that you don't need to let through. There can also be a DMZ firewall between your Internet server machines and the Internet which has weaker limitations, if needed by your services. (The standard configuration is a separate DMZ net for your Internet servers and a net for your internal company LAN, with a very strict firewall/proxy between the LAN and the Internet).
Solution: two firewalls (Score:1)
He also points out that he wants to make the honeypot irresistable so he names it something tantalizing like ns1.domain.com or mail.domain.com. Finally, he uses reboot (WALL "routine Maintenance") to kick the cracker off so he can examine the logs and fix the holes and modifications.
As one earlier poster said, the author tosses this off like its all in a days' work, while it leaves me shaking my head in impressed amazement. You really should read the article....its quite informative.
Who am I?
Why am here?
Where is the chocolate?
Re:Wild Weasel Facts (Score:1)
The Deception Toolkit is a tool for building honeypots, but with a twist. It listens at port 365 and just says something like "Smile, you're on candid camera". The idea being, that if enough DTK boxes are out there, if someone sees a port open at 365 they will aim their scripts elsewhere.
Ain't decoy's grand?
Two types of honeypots? (Score:1)
If you are looking for scriptkiddies, this type of honeypot is perfect for you. Scriptkiddies look for the easy kill, the box that shows the listening port that they can try the newest 'sploit on. However, the "professional" cracker generally has a specific target in mind, goes for that target and nothing else. The other thing is that he gets in, gets what he wants and gets out, and nobody is the wiser.
The other question that should drive your decision to deploy a dedicated honeypot (and your entire security policy) is what you are trying to protect. Are you using the honeypot for learning purposes? Then this is probably the type of 'pot for you. If you are setting it up as a tripwire or trigger to watch for untoward activities, then you might consider setting up something a little different. You should also consider what type of network you are setting this up on, and what the cracker stands to gain if he owns that particular box.
The second type of honeypot involves setting up scripts and whatnot on existing machines. It falls as much into the range of Intrusion Detection as it does Deception.
This method uses scripts which listen on common unused ports. Not running pop3? Set up a perl script on port 110 that logs activity occuring on it. As Lance Spitzner says in his whitepaper To Build A Honeypot [enteract.com], don't get too fancy, or you're setting yourself up for a DoS attack.
While I am not saying honeypots are inherently bad, I am saying some forthought can save you considerable work. Figure out what you want to do and whether a honeypot is your best solution.
Oh. (Score:1)
--
Re:Building a _hornets_ nest (Score:1)
Re:Fooling? (Score:1)
I disagree. The target can have their upstream provider figure out where the majority of the flooding packets are coming from and filter that half of the country, etc.
In order to get around this defensive tactic, the attacker would essentially have to flood the entire internet, DOS'ing everybody. At that point it would be more practical to simply use real weapons (or a backhoe) and blow up network infrastructure.
Re: definitely not entrapment (Score:1)
I assume you are doing this in a state where you are not violating any concealed carry laws in doing so. =) Statistically, concealed carry laws have the effect of lowering such crime rates, specifically because criminals are much more careful if they don't know whether or not a target is armed. But that's another matter. If you park a car in a "bad" neighborhood (or a "good" neighborhood, for that matter), and forget to lock your car door, can someone claim entrapment if they get caught stealing it? I think not. Besides, all that is required to get around the entrapment clause is that different officers make the arrest and set the trap. In this particular case, unauthorized use of my/my company's computing resources is still unauthorized use, regardless of whether I have left a diversion out there to attract the gullible.
The Best Honeypot (Score:1)
It works great :)
The wheel is turning but the hamster is dead.
Re:You need Gooood skills to make a goood honeypot (Score:1)
Re:You need Gooood skills to make a goood honeypot (Score:1)
Re:This is very wrong!!!! (Score:1)
with the "hacker" terminology first. It would
be obvious to some that it had changed, and
confusing to others when they read the comments
complaining about the "hacker" terminology. Why
not post it there - it's already public, this
just makes it clear.
Re:A better solution (Score:1)
Could Slashdot survive with its audience reduced to only about 100 users?
Re:Fooling? (Score:1)
If. If your ISP has more bandwidth than the attack and you set the border routers to drop the traffic, you should survive. Yahoo had enough bandwidth... they just hadn't configured their routers correctly. :(
As to the 'net being more fragile... well, yes.. a few bad BGP advertisements would take care of the whole eastern seaboard. Your point?
No worries, You already have a HoneyPot. (Score:1)
trying to get projects in on time, keeping Manglerment happy,
that you dont see the HoneyPot sitting right in front of you..
-IronWolve
That and hire another NetAdmin we would have 2.
Re:Honey Pot (Score:1)
Yer in for a world of disappointment in a few years, boy.
Re:Hacker != Cracker [OT] (Score:1)
But, whatever is done, mis-representing what is sent, to me seems far worse than anything else, for a "news" site.
Political Correctness hits Slashdot (Score:1)
Note that the entire post was edited, *including* the original AC submission!
Is Hacker to be to slashdot readers, what Nigger is to some other people? Is it to be a word that is "offensive" when others use it, but OK to use to each other?
Re:M*tnick got caught in one of these. -True story (Score:1)
Hey, I think I just figured out a reason why someone would want to run 41000 instances of Linux on a mainframe!
---
Re:A friend did something like this (Score:1)
This can be done with Internet Security System's RealSecure.
http://www.iss.net/securing_e-business/security
Cheswick & Bellovin did just that ... (Score:1)
I would warn you that special precautions are necessary, this is something you should think very carefully about before attempting.
Am I missing something here? (Score:1)
It seems like the whole point is to find out how the cracking attempt is being done, so it makes sense to me to do what others have done, which is to have cracking contests with tangible rewards, and then progressively harden the target machine to repel the attacks. As soon as someone cracks the machine, they get the reward/recognition, etc.
Of course, if the right company/person were in charge of the targeted machine, they would be able to advise, Apache, RH, M$, etc. of how the crack was done, and give the coders a jump on blocking the crack before restarting the whole process with the newly hardened target.
Hell, if I were in charge of one of the big OS/Software companies, I'd probably try to set something like this up just for that purpose. Cheaper than finding out about an exploit just after you received your new order of 10,000 CD-ROMS, don't you think?
Terminology (Score:1)
Re:A friend did something like this (Score:1)
Whilst this sounds like a good idea, and can be done using most IDS/firewall combos (e.g. RealSecure from ISS [iss.net] or NFR from... er... NFR [nfr.net], in practice most admins shy away from using it for fear of it being turned against them and their networks (think spoofed attacks that appear to be from the "victim's" business partners).
Re:Simulated environment is not a good idea (Score:1)
No, especially if it's a not a publicly accesible system.
If I have a fake safe at home to distract the thieves from a real one, that's not entrapment.
Kaa
Honeypots (Score:1)
If you don't allow access outside, it makes the system look kind of suspicious. And if they find out you've set them up, they will be determined to return.
Crackers, Crackers, Crakcers!!! (Score:1)
Shame, Shame on Cliff for letting this through, shame, shame on the AC for posting this to slashdot.
It is "Cracker" not "Hacker" in this context, and for this nonsense to show up on slashdot, I suggest we do what we have been told to do over the years, send esr's letter available form here [tuxedo.org] to slashdot.
Check out the Deception Tookit (Score:1)
Re:Honeypots can be illegal (Score:1)
---
Re:Monitoring employees (Score:1)
in corporate environments, the only employees who should be doing vulnerability assessments are those contracted specifically to do so, or those (network and security admins) who have this duty listed specifically in their job descriptions.
anybody who trips my honeypot sensors is obviously snooping around where they are not supposed to be - they have no valid reason to be hitting the honeypot. furthermore, they are most likely not doing the tasks/jobs that they were assigned to do.
when you get out into a large corporate environment, you'll quickly learn that the network admins do not want you to be snooping around, and probably that you don't have the time to snoop around anyway.
i do vulnerability assessments and security audits for a living, but if i contact one of the network admins here and tell him that i found a security hole, the first thing he'll ask is why the heck i was poking around HIS servers without HIS expressed, written, contracted permission in the first place. my poking around has created more work for him, and for the other ppl who check those logs, respond to the alarms, etc.
i personally found a security hole once in the censorware running in my the media center of my school library. i informed the librarian of the hole and was promptly banned from the library for the rest of the year. not having read the library's computer use policy, i didn't realize until years later that the policy specifically said to report any security holes found.
corporate life is very different. when you are working on a $500 million project, and the network admin notices that you're poking around in an R&D database that you're supposed to have only limited access to, or no access to at all, you'll be hung, drawn, and quartered, because you are now one of the zillions of people suspected every year of stealing and selling corporate secrets, or of sabotaging the company for whatever reason. after you die, they'll ask your next-of-kin why you were poking around that server in the first place.
if you work someplace where they actually pay you to perform random security audits whenever you get the urge to nmap or smurf all of your corporate nodes, and want you to report your findings, then that's great. i really doubt that any Fortune 1000 (or virtually any) company encourages their employees to practice corporate security audits on the company LANs as a hobby though, especially while working.
(posting anonymously because my employer has really bad security policies)
after you're done packet-fragging the company's production web servers, feel free to contact me to help you develop a more reasonable security policy.
[note: don't take the apparent harshness of my reply personally - i work _very_ long hours and weeks, and it's friday, so i'm using you as my venting scapegoat. i'll return to normal after my second cup of coffee monday morning. thanks for taking the time to comment on my post - you have raised thought-provoking, interesting points.]
Re:Honeypots can be illegal (Score:1)
Unless you are in law enforcement it can not be considered entrapment. This has been discussed on Bugtraq and many other lists. www.securityfocus.com, goto forums and then bugtraq, I don't remeber the title of the discussion though but it was within the last month or so.<BR>
Although you <I>might </I> be liable if they use your machine as a jump point to lauch more attacks.
The military uses them... (Score:1)
we had a former DOD info security person, the subjects of crackers came up via discussing java class decompilers.
He used to run a few systems that were in
In all, it was a pretty interesting discussion we had after one of our class sessions...
Honeypot (Score:1)
Before you even begin to work on setting up a honeypot, you should first secure your network as well as you can. The honeypot should only be used as a second(or third) line of defense.
it's called iplog and a perl script (Score:1)
Run iplog to stdout and use a perl script as a "wrapper", then manipulate your firewall rules based on the output.
BackOfficer Friendly (Score:1)
MS-Windows version is cashware, UNIX version is downloadable after you fill in a nosy marketing survey [nfr.net] ... I mean registration.
Re:An Evening with Berferd (Score:1)
Re:Honeypots can be illegal (Score:1)
I once heard someone say they would leave a $100 bill lying around in an obvious place in their house. Their idea was that encountering a burglar was potentially worse than actually being robbed. Their hope was that a burglar would take the easy reward and split, rather than linger, looking for the better (but harder to carry) goods, or risk encountering the resident.
Re:Honeypots, entrapment, and you (Score:1)
Can you send the logs through a direct serial connection to help prevent a sniffer from detecting it?
Re:Simulated environment is not a good idea (Score:1)
1. There's a crime already in progress.
2. Entrapment is when a law enforcement official temps you into committing a crime, or something like that.
... of course I'm not a lawyer and this is just how I understand things to be.
When I registered honeypot.net... (Score:2)
...I was completely unfamiliar with this usage of the term. Imagine my surprise one morning at finding the reason behind a million would-be haxx0r d00ds doing their damnedest to get past my firewall. Suddenly it all became clear.
Oh, and don't bother trying to get there right now. A router flash upgrade left my connection utterly dead, and I'm waiting for the replacement to arrive. FreeBSD has made for zero downtime, except for that which I've managed to cause along the way.
A friend did something like this (Score:2)
You see a small directory with interesting looking files. (eg passwords.gz).
So go to download and it goes ssslllooowwwlllyyy. (You aren't getting anything meaningful, just 100 bytes/second or so to make you go away and shut up.)
Worked quite well...
On a more serious note, what would be nice is if there was a set-up that noticed a portscan in progress and blocked that IP (plus notified the administrator etc). Anyone know of something like this?
Cheers,
Ben
Re:Hacker != Cracker (Score:2)
CT should have just eliminated the AC quote, if he wanted to remove the word Hacker.
Misrepresentations are no fun. What if it had been a registered user's submission, instead of an AC's?
Re:Detection (Score:2)
Re:Fooling? (Score:2)
If you kill ALL the bandwidth - with packets, then there is nothing the target can do. NOTHING. Nothing whatsoever.
All it takes, is enough clients to smurf, SYNflood and so forth. The bandwidth will be saturated, and nothing can stop it.
The Net obviously more fragile than you realize.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
Re:You need Gooood skills to make a goood honeypot (Score:2)
The best defence against crackers is to follow bugtraq and other security mailinglists. Closely.
otoh, I think it might be useful to set up honeypots VERY FAST after a new type of major bug is found. For example -- if you had set up some honeypots with exploitable BIND daemons just after the vulnerability was released -- my guess would be that you would catch the 'new and C00l' tools for breaking into bind faster.
That actually was a great idea. Next time there is a major Linux bug, i think i'll use a spare machine, install the buggy software on it, and monitor it CLOSELY. That was actually a swell idea. Thank you for leading me onto that thought-path.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
Re:Fooling? (Score:2)
There is no way to stop it. Your upstream will have to filter out everything - since the SYNpackets will be spoofed. They cannot know the difference between a forged SYN and a legitimate one. As for ICMP's, they can be filtered.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
Re:Fooling? (Score:2)
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
Re:Building a _hornets_ nest (Score:2)
-- Abigail
Re:Taking the TIME (Score:2)
Some people do. It just depends how important you find it to secure your network. Some companies employ people whose only task is network security.
A possible way to run the honeypot: Use VMware/virtual PC/bochs and have it run the honeypot environment. The honeypot then has the ports open to the outside world. To fix the pot-a simple file copy.
Not good for 2 reasons. First, it takes more work to set up, second, it doesn't resemble the way you have your other machines run, and that was the point. The point is to find out whether your own machines are secure. Having a honeypot that is configured differently doesn't help. If you're a sysadmin in a larger company, it shouldn't take much time to do a standard install of your machines; in my previous company we had it down to about 5 minutes of sysadmin work.
About all you may be able to add to the world of computer security is YOU might be lucky to report the 1st break-in of type X, or help trace back someone. But, most likely, any traceback will dead-end with people who don't want to take the time to care, and they will use a known hole you should know about via bugtraq/cert.
It's easy to say you should have known about holes via bugtraq/cert, but there's a difference between theory and practise. If you take a machine configured identical as your important machines, make it reachable for crackers, and monitor there success, you will find out whether your installation indeed doesn't have any known holes, or whether you've forgotten something.
-- Abigail
M*tnick got caught in one of these. -True story. (Score:2)
Back about ten years ago, a certain K**** M*tnick was hacking into the systems of a certain small California company that sells Un*x for x86 boxen.
They realized that they had an intruder, but couldn't catch him, so they set up a single 386 on the dialin network he was exploiting to look like an entire network filled with great goodies. They watched him enter the system and start poking around the "virtual network" while they traced the call and sent the police to arrest him. They caught him logged in, "red handed" at his girlfriend's place.
I don't think charges were ever pressed because said company was embarrased about being hacked, but the honeypot certainly got it's fly.
Its Fixed, and fast too. (Score:2)
I am not a Troll (Score:2)
I am offended.
Just setting the record less crocked.
Re:Honeypots can be illegal (Score:2)
Besides, if a hacker went through THAT much trouble to break into a system, which should be somewhat secure, what would have stopped them from hacking a different machine?
---
Words and meaning (Score:2)
It doesn't matter in the abstract, except that words convey meaning.
If you use the word cracker rather than hacker, what difference does it make? If we use the word hacker to denote crackers, what word would we use to denote hacker? Or if we do as we on Slashdot often do now and denote hacker as hacker and cracker as cracker, then what word do we use to replace the old meaning cracker -- the food. Perhaps someone can open up a dictionary and find a suitable word to use for "clever programmer".
Oh well.
But remember that English would be a far different language if it was governed chiefly by common usage.
If the above paragragh seems
Re:Honeypots can be illegal (Score:2)
Re: Cracked; rootkit - entrapment question? [securityfocus.com]
There was no real final resolution to the entrapment question. There's some good arguement for both sides, though.
Re:Dumb idea (Score:2)
Hey, it works for Charles Bronson.
Simulated environment IS a good idea (Score:2)
Didn't Computer Associates or some such actually create a system for this purpose? I even recall that it could simulate an entire network. Personally, I think it is more useful to use an actual server to learn the real exploits that are being put in use. Just make sure you have a good firewall between the fake system and the real network.
Later,
Thad
honeytrap werks as much as hewked en fonikz (Score:2)
1 finger
2 date
3 dir
4 help
5 d
6 list
7 ls
8 ls
9 ftp ftp.rootshell.com
10 pkunzip rootkit.tgz
11 tar -zxvf rootkit.tgz
12 gcc bda.c
13 gcc bad.c
14 edit
15 edit bad.c
16 edit.com
17 pico bad.c
18 gcc bad.c
19 a.out
20 a.exe
21 a.out -help
22
23
24 dir
25 shit@##$@#
26 ls
27
28 md
29 mkdir
30 cp
31 finger
32 cd \etc
33 cd
34 edit motd
35 pico motd
36 quit
37 exit
If the above logs is how you are going to learn how hackers operate, then go ahead and setup a honeypot. You will only attract script kiddies, we call them that for a reason. They can barely gcc and
Re:Simulated environment IS a good idea (Score:2)
This sounds like a good job for one of those old mainframes running 41,000 copies of Linux. Just set it up as a chain of virtual networks: that is, the first VM sees the internet and the second VM; the second VM sees the first VM and the third VM; etc.
By the time someone makes it to the 41,000'th VM, you'll have time to decide how to deal with them...
Some info (Score:2)
I'd recommend reading the above for a good write up of this sort of situation. I think it illustrates some of the difficulties in keeping up this charade quite nicely.
Notice that the author knows his stuff extremely well, and remeber that when you start thinking about doing this yourself.
-nme!
Wild Weasel Facts (Score:2)
http://www.wpafb.af.mil/museum/annex /an10a.htm [af.mil]
http://www.wpafb.af.mil/museum/annex /an10a.htm [af.mil]
I have a fond memories of the F-4G having spent a handfull of years working on and/or around the aircraft (Electronic Warfare - specifically the AN/APR-47 RHAW system, AN/ALE-40 Flar/Chaff, and AN/ALQ-131 or AN/ALQ-184 ECM Pods).
Interesting mission. There's a few bits of lore that aren't mentioned by the above resources that might be applied to this discussion (decoy / defensive hosts).
Wild Weasel aircraft didn't need a drone to be usefull. Quite often they flew in hunter/killer pairs with other airframes (the last teams to fly were F-16 and F-4G teams). This meant the Wild Weasel aircraft themselves were often the target for ground weapons systems. The first Electronic Warfare Officer who was approuched during Vietnam with the mission replied (forgive me if I murder the quote):
The first Wild Weasel patches have a picture of a weasel with a shocked expression and the letters YGTBSM.This quote seems to fit in with the question of how wise it is to deploy decoys in your environment.
However, there's also another interesting tidbit out of Wild Weasel history. At the beginning of hostilities during the Gulf War, Wild Weasel aircraft escorted most missions and decimated Iraqi air defence systems. This defense lead to a high demand for Wild Weasel escorts - more demand than available aircraft.
Commanders took a gamble. It was noted that enemy SAM and AAA sites would shut down immediately on discovering F-4 radar signitures in the area. So some missions got F-4C (unarmed reconnaissance aircraft) escorts. Since the F-4Cs were indistinguishable from their deadly F-4G cousins, F-4Cs were able to effectively supress enemy weapons systems by their mere pressence.
I suppose you could propose the question - if enough decoy systems show up in the environment, would it make potential attackers a bit jumpy if they couldn't tell the real from the decoys?
What, no pedantism? (Score:2)
Re:Fooling? (Score:2)
I work as a sysad at a university campus. We get portscanned at -least- a few times a week, and deal with breakins a couple of times a month.
So far, I have not been made aware of a single internal breakin. Every one I've gotten involved with has been external. Ok, except that student who forged a faculty member's e-mail recently, but that doesn't count as a breakin by a long shot.
The only way most breakins are internal (for us, and probably for you too), is if we've had a lot of internal crackers breaking into remote machines, and from there breaking back into internal machines.
I mean think about it: if you're on the internet, just how much huger is the internet than the population of your business or government agency or university?
Once, in a fit of pique about this oft-quoted bit of unlikely "wisdom", I did a survey. The number of respondents was small, but it did show that most respondents had suffered more external breakins than internal.
Solution: Hire a Hacker (Score:2)
A few other people have posted the idea that most of the people who actually know what they're doing aren't spending their time intruding into our systems. I believe this. Case in point is one of my co-workers, a truly brilliant hacker (and yes, I'm going to use this word as it was originally intended,) whose calling is in security. Yes, he roots our boxes on a regular basis. Yes, he tells us that he did so, and how. And then he helps us plug the holes. He has had me watch as he gets my password off what I thought was a secure system, (result: we got one that IS secure.) He also helps us find the holes in our new products, and is teaching the rest of us to do the same, (our work is in the early developement stages, so we're in a perfect position to find and fix the flaws.) I should probably add that I knew him before he worked here and had a good idea of his character before recruiting him.
The script kiddies grow up, and some of them do continue to learn. Those that do can be your greatest security asset. Why lure in the bad eggs and criminalize them, when there are so many out there who actually want to be legitimized?
a reference for previous work (Score:2)
Has a chapter about a breakin where they construct a faked environment to observe the behaviour of the hacker.
Perhaps a little out of date now, but generally still interesting (both the chapter, and the rest of the book).
Mike
Taking the TIME (Score:2)
Most sysadmin jobs have 10 hours of work each day to fit into 8 hours. So sysadminning become more like triage, or the gerbil on the excersise wheel. If you run fast or go slow, you end up in the same place at the end of a day of running. And some days, some jerk comes into your cage, rattles it or, while you are on the wheel running your little heart out for that paycheck, they jam something in the wheel to make it stop suddenly.
A possible way to run the honeypot:
Use VMware/virtual PC/bochs and have it run the honeypot environment. The honeypot then has the ports open to the outside world. To fix the pot-a simple file copy.
Will this help? Depends on if you have the time to drop EVERYTHING to watch the box when something happens. Me personally, I watched some dud break into my box. (It alerted me at the point of the break-in) At the point when s/he started deleting files, I typed in halt. About all I learned is they were using 2 porn sites and one at MIT. They used a known issue with BIND. (bad me, I didn't upgrade bind.) Had I been busy/at a client site, they would have been able to poke around on the box. This particular attack showed me I had a problem with bind. (big whoop. I KNEW that, and chose to ignore it.) And the ISP's who were used in the attack? One was rude "who the hell are you to call me that I have problems with my systems, I can't control the internet" and the other was "they are not affecting production, so I don't want to disturb them"
And, had they been GOOD, they would have not set off my alert system. But, they wern't GOOD enough. So, depending on how you work your system, they might just be better than you, and your honeypot becomes a host to launch the next attack from. The truly skilled break-in artist is nearly impossible to detect.
About all you may be able to add to the world of computer security is YOU might be lucky to report the 1st break-in of type X, or help trace back someone. But, most likely, any traceback will dead-end with people who don't want to take the time to care, and they will use a known hole you should know about via bugtraq/cert.
Lance Spitzner wrote some articles.
http://rootprompt.org/article.php3?a rticle=159 [rootprompt.org] is the start of his series
Re:Detection (Score:2)
And you could read the Spafford and Garfinkel book on Internet Security.
"Cuckoo's Egg" (Score:2)
Re:A friend did something like this (Score:2)
Dumb idea (Score:2)
Wouldn't a better approach be, if you had to be in the neighborhood, pick a route that provides the path of least resistance? Then go through the neighborhood in a car, with a couple of people with you etc.
Entrapment is entrapment, frankly I wouldn't want to put my firm through the headaches in the first place.
HoneyPots? Auditing? The key is resources. (Score:2)
During a period of increased threat, our primary internet web server effectively became a honey-pot without our consent. There was a great deal of activity in the media surrounding the department in question, and a heck of a lot of interest from the public about the organisation. As such, we believed that the web server would be the subject of significantly more attacks than normal.
We effectively halved our security section during the period of hightened activity - 3 were responsible for the normal IT security tasks, the other three were allocated full time to the task of securing and monitoring the system. We instituted significantly increased network and host auditing (pushing the data out via a one-way data diode to an auditing server, and then onto CD), and put a 'revolving checksum' alert on all web pages (again, sent out via the one-way comms circuit). Any modificatons to the checksum, or any cessation of the 'heartbeat' through the data diode, would set off an alarm in our communications centre, and an operator would literally pull the plug at our firewall to the internet, and call one of the security people. There were also a fair number of host security features enabled on the system - one of which was full C2-level auditing (with about 10,000 lines of perl to provide an intrusion detection facility for the logs).
Sure enough, the level of attacks on our server increased approximately 5 fold. Our logs by the end of 2 weeks were in the multi-gigabyte range, we'd had a couple of false alarms, but no intrusions. We'd provided management with analysis / summary reports for all attacks on the server, including graphical summaries.
So lets just review what it takes to effectively actively monitor a high-threat, high-risk system like the one I've described above:
* 3 experienced security staff, normal working hours - conducting audit analysis, extrapolation.
* A 24x7 monitoring cell
* 1 experienced security staffer, on call 24x7
* Custom development of intrusion detection code (about 4 months worth).
Now I'm not saying that every honey-pot is going to take these sort of resources. But if you want to make effective use of the tool, then you have to be prepared to put the time in.
* If you're putting in something someone else has developed, then are you sure there's no EXTRA risk to your system by installing it? (Remember FakeBO?)
* Do you have the time to analyse the results of the honey-pot logs?
* Is the information going to be of any use to anyone?
* Sure you may learn a few tricks here and there, but a majority of your probes are likely to be tradidional nmap/satan/nessus probes, or script-kiddies with the latest cgi scanner. Can the time that you have spent setting up the system be better spent on setting up a small test network, and playing with a few exploit scripts yourself?
There are several grades of security that you need to choose from based on the resources that you have available - and I'd put honeypots right at the end (ie: Security value per resource availability):
1) Patch / monitor security updates.
2) Patch + a network intrusion detection system.
3) Patch + NIDS + firewall log analysis
4) Patch + NIDS + firewall log analysis + host audit.
5) Patch + NIDS + firewall log analysis + host audit + honeypot.
The question that you need to ask yourself is: Am I getting value out of the tool, for the resources I'm putting in. If in your case, the answer is 'yes!', then go for it. But be sure that you know what you want to get out of it first.
Red.
is not about keeping them out (Score:2)
Honeypots, entrapment, and you (Score:2)
1. If someone scans the box they will find the false subnet; if they run a sniffer on the subnet they won't see any traffic.
2. They're very hardware intensive.
3. They send their logs to another system for 'safe keeping'; a sniffer will see this traffic.
Basically a careful and methodical cracker (read PARANOID) will notice something fishy and bail due to the way the network is responding (or not responding) to various tools and commands - it'll just be 'too good' and way too open. Script kiddies will just punch along and not do any real damage.
As for entrapment - for systems in the U.S. government, they are supposed to place a warning banner on all possible services that can be used to access the system warning you that: 'You are entering a government computer blah blah blah'.
So you know that you're not supposed to be there, that you are subject to monitoring if you choose to access the system, and that you will be prosecuted to the full extent of the law if you do something malicious. You were warned and are responsible for your actions after that point.
If the site doesn't have a warning then it's time for dueling lawyers, depending on what they try to tag you with. If it's a gov site without the banner they can't try to bury you for electronic B&E on a gov site (which is a federal offense), just electronic B&E in general (which can still just ruin your day).
If you're going to crack you can't whine about entrapment; John V. isn't holding a gun to your head and making you punch keys.
I'm going to do this (Score:2)
Here's the idea:
Since this is a switch, I'll just hang it off directly
It will have a different IP block range from the other internal LAN machines
The router machine (running *bsd) will be changed so the input rules redirect everything except a couple of services (DNS and SMTP) to the honeypot box
Other ipfw rules will drop any packets from that box to any other internal machine (ie, don't kill my soft internal machines)
Finally, If I'm really mean, I'll deny all SYN packets to "well known TCP scanning targets" so that scanning is tougher.
The goal is to record everything going to the honeypot machine.. unpublished exploits suddenly make their way unto Bugtraq, certain file caches get exposed and looted, other compromised systems are revealed.
Plus it's nice wholesome fun for the whole family! grin
Decoy... (Score:3)
Fooling? (Score:3)
Re:This is very wrong!!!! (Score:3)
It is, however, highly unprofessional to make public this correction. A private note to the submitter regarding the change would have been more than sufficient. I've submitted all of one story to slashdot (rejected, possibly on procedure grounds for choosing the wrong category). I'll think twice before submitting again.
Re:Simulated environment is not a good idea (Score:3)
"UNIX design flaws: There are number of inherent flaws in the UNIX operating system that frequently lead to intrusions. The chief problem is the access control system, where only 'root' is granted administrative rights. As a result,"
That's it. Seriously, the page had no more to say and seemed to end mid-sentance. Hrm. Very intereting, some l33t h4x0r must have deleted the text to cover his tracks while compromising the server.
Bad Mojo
Thank you Slashdot (Score:3)
Of course, in the future, in order to not offend anyone, I expect that M$/Microshaft/Microsleuth/Micro$soft etc. be changed to Microsoft Inc.
Slovaris be changed to Solaris (SunOS 6-> is also acceptable).
Linux will be changed to GNU/Linux or Linux/GNU in all text.
RMS will be changed ESR. Linus Thorvald will be changed to Richard M. Stallman.
EvilHat, the Next M$, whatever people wants to call RedHat, to RedHat.
Also, while we are at it, I find any mention of GNOME being better than KDE also highly offensive. Please substitute all GNOME articles with KDE articles.
I'm glad these features have been implemented, BECAUSE OTHERWISE I WOULD BE SO OFFENDED.
An Evening with Berferd (Score:3)
Sorry for the hyperlinked version, there's a PS file out there that makes for better reading IMHO.
This is half wrong (Score:3)
If the AC who submitted the story used the word "hacker", then in the part where he quotes the AC, he should use the word "hacker." I agree that changing someone else's words is a Bad Thing, even if those words are incorrect.
But in the headline and CT's own comments ("This is an interesting approach .. when it comes to cracking"), he should use real language. In spite of the submitter's linguistic error, the actual subject matter of the story is not about using honeypots to catch hackers; it's about using honeypots to catch crackers. For the headline, it is appropriate to "translate" their meaning into our terminology. Thus, the usage of "hacker" in the headline was misleading and inaccurate, and CT was right in correcting it.
---
Honeypot issues (Score:3)
Properly watching a honeypot can be challenging. You don't need one if you're not going to pay close attention to it. You also need to be concerned that ownership of the honeypot doesn't jeopardize any real systems, either due to network trust, or increased ability to do traffic monitoring. You also have to consider that you'll be a danger to other sites on the net. At least one poster to our Incidents forum claimed that when he contacted the admin of a box that was being used to attack him, the admin knew it was 0wned, and refused to take it down because he was monitoring the attacker.
You need to consider why you want a honeypot. It's probably an easy choice to put one up if you're in the business of watching crackers. If not, some folks think they want one to distract or act as early warning. What do you do when you catch a cracker? Unless you've got a clear trail back to the attacker in the same country as you, not much. You can notify his admin, which has mixed results. You can try law enforcement, which also has mixed results.. especially when you're talking about a honeypot, and can't really place a dollar value on "damages".
Consider whether you want to take a chance on pissing off a cracker. Lots of crackers are untouchable from where they are. Unless you already piss off the crackers by your very existence (MS, Antionline..) Most people don't want to be targeted by a cracker with no fear of being punished.
Most security folks believe that the intersection of sets of people who break into systems and people who are good hackers is small. That means that chances are small that you'll see some unknown attack against your particular honeypot. You can certainly set one up with the common holes, but then you'll be tracking common crackers.
The Berferd story was interesting because they caught a semi-skillful attacker. Stoll's case was interesting for much the same reason. In neither case did they start out with a honeypot. They built a jail for Berferd. In Stoll's case, he used production systems for his "honeypots". This was back in an age when these sorts of things were much less common, and you didn't have hundreds of script kiddies scanning the entire Internet looking for machines to own. The owning has even become much less interesting, due to the DDoS tools the crackers now want to install and move on..
If you want the excitement of an evening with Berferd on your system, don't run a honeypot. Watch your real systems very carefully, and polish your tools for tracking him when he shows up.
Re:Honeypots are NOT illegal... (Score:3)
That's totally irrelevant. By this logic, it's not your fault for stealing from the grocery store's cash register if the clerk is so silly as to turn away while the tray was open. It's not your fault for stealing from the shelves if the grocery store was so silly as to leave the merchandise out in plain sight and reach.
Either you're an adult able to control yourself when confronted with such temptations, or you're a legal infant unable to do so and not entitled to any of the rights of an adult - you can't vote, you can't drive (can't risk you deciding to run a red light because the city hasn't installed physical barriers to stop you!), you sure as hell can't own a gun, etc.
The *ONLY* issue with entrapment (vs. stings) is whether the cops somehow enticed the person to do something they wouldn't normally do. In countless cases the courts have held that merely presenting an *opportunity* to commit an illegal act is not, in itself, entrapment. There must be some overt act encouraging the criminal acts. E.g., an underage agent offering a citizen $20 to buy a six-pack of beer... and telling them they'll get to keep the change.
Re:Simulated environment IS a good idea (Score:3)
She lost a bunch of trivial stuff, and proved her point. However, somebody also got the keys from the bottom of her purse - the one thing that she really didn't want to lose.
The moral of the story - if you are doing this to acknowledge the fact that there really are crackers, purely for educational purposes, then you might learn something. If you are doing it because you think it will distract anyone from the stuff you really don't want to lose, you are probably sorely mistaken. It might even give you a false sense of security, which is a bad thing.
Re:Honeypots can be illegal (Score:4)
Unless you are in law enforcement it can not be considered entrapment. This has been discussed on Bugtraq and many other lists. www.securityfocus.com, goto forums and then bugtraq, I don't remeber the title of the discussion though but it was within the last month or so.
A bit of an oversimplification. In most states, it also is entrapment if you are acting as an agent of law enforcement (i.e. Police, District Attorneys, FBI, and a number of Federal, State and Local Government agencies). Basically, if the law gets involved, or if you have any special arrangements with a law enforcement agency, take down any uncompromised honeypots or they might get in the way of apprehending or prosecuting the invader. If you don't care about apprehending or prosecuting the invader, honeypots don't cause any problems here.
Although you might be liable if they use your machine as a jump point to lauch more attacks.
I am not a lawyer, but I'd say you probably would be held liable if it could be shown that you deliberately allowed the unauthorized user access to your system.
----
Simulated environment is not a good idea (Score:4)
Additionally, two points spring to mind:-
1. Define 'hacker'. As a slashdot editor, you shuold know better. 2. Isn't a honeypot considered entrapment?
Re:Building a _hornets_ nest (Score:4)
That, my friend, depends on what your goals are. There are several good reasons to build honeypots.
First of, if you are pretty sure about your network, and that you are an idealist -- creating a honeypot let you see where scans originate from. After that, you can contact the admin of the machine it originated from -- and tell him that he probably is cracked. You've made a friend.
Secondly, if you don't have important data on your network, and just want to catch some fish and watch the ruckus -- i'm sure it can be great fun.
In other words, it depends on your goals, what kind of person you are, and so forth.
Nevermind the fact that you have intentionally left an easily crackable machine on the internet, from which crackers can launch other attacks.
That depends on what you leave on the machine. It also depends on the firewall rules. Not to forget, if you monitor the machine, you may see what he attacks from the machine -- and thereby alert the machine new machine he just cracked into. Someone would've found that other vulnerable machine in time anyways -- so I don't see the damage.
And, if your firewall denies outgoing ICMP's (in heavy quata, and with spoofed ips..) it may not be used in a smurf attacks. Furthermore, if the firewall says "no more than 10 outgoing SYN requests per 5 seconds" we can forget about synflooding too:)
I personally don't know who has the time to set up decoy machines, when it's difficult enough keeping servers patched in a 24x7 production environment.
Not everybody who builds a honeypot is a security professional with little time on his hand to secure a large companys network. I totally agree with you if that is the case. Building honeypots on large companies networks is a Bad Thing (imho).
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
Honeypots can be illegal (Score:4)
Honeypots can be a form of entrapment.
Also, one might argue:
1) A bad honeypot can be detremental (ie if the user really does have control over the system)
2) Honeypots encourage the hacker, while a closed door might frustrate them and they'd go away.
Anyway- just some things to keep in mind.
You need Gooood skills to make a goood honeypot. (Score:5)
The problem is
But, back to the question. A good honeypot would be a system that didn't get cracked, but where you created an environment that - for the cracker - seemed to be a normal unix system. First of, you need to create the programs that listenes to different ports. You probably want to listen to port 21, 23, 25, 53, 80, 110, 6000, and probably a couple more -- so that it seems to be a regular system. You should also scan a redhat 5.2 box (or something) and find the exact banners they show. You need to recreate *Exactly* what happens, when someone executes "the" bufferoverflow that usually happens, and so forth.
The question "will it fool good hackers" or whatever the question was - is quite void in my eyes. Good crackers wont scan enourmous subnets for crackable hosts. Its the scriptkiddies that does that kind of thing. And yes -- you will catch them. You will catch hundreds of them. The problem is - the scans and breakins will originate either from wingates - or from other cracked hosts. Sure, its a nice gesture to notify them -- but you probably won't catch any fishes.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
don't waste your time on honeypots (Score:5)
that said, honeypots are a really cool concept, nevertheless. but a network or security admin needs to focus on more fundamental security issues though. those NT network admins, for instance, should be deploying a second, or third, or fourth firewall on BSDi or Linux, instead of wasting time and compromising their security with a misconfigured NT honeypot. honeypots are best left for IT security research environments, or for people who have too much time to waste.
a notable exception is NAI's Cybercop Sting. Sting emulates Cisco IOS 11.2, Solaris 2.6, and WinNT 4, running common services. with Sting, you can pipe all of your legitimate traffic thrugh Sting, and utilize the excellent logging capabilities of Sting for an added layer of security. additionally, Sting can be, should be, and often is utilized to monitor employees (i.e. internal hacking/cracking attempts). since most of the security incidents will be from internal sources, honeypots are an excellent way to monitor for suspicious LAN activity.
there was an excellent discussion recently of the honeypot concept, with a wide range of opinions and views from all sectors of the Net population, on the Security Focus Incidents mailing list. the thread was entitled "Cracked; rootkit - entrapment question?", and was back in late February and early March.
for those who have more interest in honeypots, check out the following:
To Build a Honeypot [enteract.com] - article by Lanace Spitzner
CyberCop Sting [pgp.com] - product by NAI
dtk [all.net] - Fred Cohen's Deception Toolkit
NFR's BackOffice Friendly [nfr.net] - product by Marcus Ranum and L0pht
and finally, a cool new product that i saw at RSA2000
ManTrap [recourse.net] - product by Recourse Technologies that is based on Solaris 7
This is very wrong!!!! (Score:5)
I must object, and I hope that many people object as well, You bring news to us, and you should bring it the way it came, raw and original, irrelevant of it is offensive to you or not. "hacker" used for a computer cracker might be an offensive term to you, but what about me? I work in the computer security industry, so have you more credits to tell me what to refer a computer criminal as? I call them hackers, why? because that is what it means now, till the media comes up with a new term, the original old term is lost, and you can't do shit about it. But I digress, I do not care what you call them or what anyone call them, I call them "script kiddies", "computer criminals or intruders", but back to the gist of my post. You should never never ever modify a post! I hope this is the last we see this on slashdot, because this is misinformation. I saw a comment by someone thinking that this guy had a clue because he refered to computer intruders as crackers, if only you had left the post as the original, the owner of the comment might have thought twice. What next? tomorrow andovernet will ask you to edit a news because it is offensive? You commited a big boo boo, but it is okay, we all make mistakes once, but I really hope that this doesn't happen again!!!
Re:Simulated environment is not a good idea (Score:5)
No. Here [robertgraham.com] is a good explanation.
Some good links on the sublect:
http://www.robertgraham.com/pubs/network-intrusion -detection.html#11 [robertgraham.com]
http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ .htm [sans.org]
Re:Honeypots can be illegal (Score:5)
You also need to take a good look at your security policy and determine what your security goals are. For most businesses, trying to catch the person who rooted your box is a secondary goal at best. The most important thing is to get the systems back on line and minimize the downtime. A honeypot only makes sense if you are trying to gather information that you will use to try to prosecute the attacker.
Getting decent evidence that will be admissable in court is extremely diffcult, so many people don't really try. For more information on gathering forensic evidence, check out this PDF from a recent SANS conference.
http://www.sans.org/TALKS/KRUSE.PDF
YMMV, but in my own opinion, the time and effort you put into a honeypot would be better spent securing your actual boxes.