Using Honeypots to Fight Worms
scubacuda writes "Laurent Oudout, an active member of the French Honeynet Project (part of the Honeynet Alliance), has written a paper evaluating the usefulness of using honeypots in fighting Internet worms. (Imagine a well-constructed honeypot framework capturing a worm, redirecting worm traffic to fake services, and launching counter attacks to clean infected hosts!)"
nevermind... RTFA :)
here's what it says in the article:
Honeypots are computer elements helping to delude aggressors. On a production network, evil hackers will attack some kind of fake system, losing time in doing so and giving information about themselves and their methods [ref 4].
When a honeypot is a dedicated host uniquely used to delude aggressors, it is supposed to play no role linked to systems in production. This implies that every request directed to the honeypot is suspect.
While honeypots are often thought to be used for passive analysis, they can also play an interactive role to deal with worms. Two kinds of honeypots are often used :
high interaction: a kind of real host is usually almost sacrificed (called a "sacrificial lamb") on a network while waiting for any aggressor.
low interaction: services and/or hosts are simulated (for example, Honeyd by Niels Provos).
Just because I don't care, it doesn't mean I don't understand. Homer J. Simpson
A honeypot is a server that is intentionally left unsecure to lure a cracker in to trying to break in to it.
It is kind of like leaving your car doors unlocked in the middle of NYC and pointing a video camera at it to see who tries to steal it.
The flying hamster of DOOM rains coconuts on your pitiful city.
1) Shooting is only justified if you feel your life is in danger and you are incapable of running away. Pretty arguable point when the attacker is only weilding a bat.
2) Unless your Iron Lung is hooked to the internet, no internet attack is an attack on your life. If I steal your laptop from your trunk, you are not confered the right to break into my car. So its a pretty different situation.
You are in a maze of twisted little posts, all alike.
This script, given strictly as an example, can be improved upon by using evolved programming languages such as VBS. A longer example [ref 13] has been tested on a research network, cleaning our infected hosts in a few minutes.
Some SysAdmins were recently polled to determine if it is ethical to take active defense measures in such a targeted, counter offensive way, within a network their organizations owns. The results can be seen here [ref 14, page 29 & 32] (76 respondents).
wait, here it is.
Overall a very good article. The article could have touch upon the ability for honeypot to help create IDS signature. At current technology level, IDS are mostly still signature based and early detection with honeypot to help with creating IDS signature is very important.
For active countermeasure (or attack), this has to be done VERY carefully. Remember Max Vision? It's good to fix your own machines, and make sure you only attack and fix yours. Access to unauthorized machines are almost always illegal. If one of your boxes got hacked, the incident response team should get involved and do their investigation, auto-patching without investigation can be a risky thing because you just don't know the extend of the problem. When you fix it, the hacker could have backdoor installed on your box.
Actually, there's some good sense in these honeypots. By redirecting the worm to fake services you make the worm waste time, which stops it from propagating, and perhaps just as important, congest network traffic (the honeypot can use vhosts to accomplish this). As an additional bonus, you'll be able to study the behaviour of the worm without actually compromising a machine. The point is not so much to find the original culprit, but preventing it from doing more damage.
Also, on the subject of counter-attacks, it should be noted that article quite clearly mentions that this should only be done where the infected host is under the legal control of the administrator of the honeypot. Although this won't really help for your home computer, it may prevent spreading of the worm on business or school networks, for example.
What AOL did was not wrong, they used there software to patch a bug. It wasn't like they opened up excell and downloaded your files. Mind you, aol could have told the users what they were planning/doing. Back to this discussion... If I'm running a network of 5000 computers, and 500 of them are dsl, or cable or dialup connections I have everyright to patch those computers on MY network, so long as I devulge this information in the Terms of the contract.!!!
No, this is
We got caught out by Welchia by someone kindly connecting an infected laptop directly into the network behind the firewalling. Ironically this was possible due to a mistake in SMS package deployment (was done hastily - my fault).
My solution was to deploy honeypot windows machines running snort which reported into a central SQL server database.
Using Windows scripting host, I then wrote a script that ran periodically on a network management workstation which queried the database, creamed off the last machine that was an infector and using the wonderful free PS Tools from Sysinternals automatically determined what OS the machine was running (PSInfo), updated its antivirus signatures (PSExec), de-wormed the machine using the Symantec "FixWelch" utility (again using PSExec), decided if the machine was up to service pack spec (data from PSInfo) and if not service packed it (PSExec) then applyed the patches to prevent re-infection (PSExec).
All worked a treat.
I'm kind of glad we got hit because as a result I can now insist machines get patched (previously people would complain about a "box on the screen" (SMS installer)) while also being able to remove machine admin rights across the board and ban any machines that are not ours from being connected on pain of a disciplinary offence.
A lot of work but ultimately, I WIN. MOO HAR HAR!!
I have recently begun beta testing of an extended-functionalty version of my original Open Source application, LaBrea, mentioned in the article. The new software, known as LaBrea Sentry, uses the same methods of trapping and holding connection attempts by worms and scanners. It also proactively defends real machines from attack from those same worms and scanners as well as communicating all log information to a central server which provides updated "Bad Guy" lists to the entire network of Sentry boxes. Scanning IPs that make it onto the "Bad Guy" list are blocked from access to all monitored networks while they continue to scan. (And before you even ask, yes, there are many safeguards on the system to prevent spoofing...)
In initial tests, the system knocked down 94.7% of the scripted, scanning attacks against a live webserver, BEFORE those attacks ever made it to the server or IDS logs. That's what it's designed for: not to replace firewalls or IDS systems, but to simply cut down on all of the crap that they see...
Note: There seems to be a great deal of confusion about the "countermeasures" mentioned in the article. In the case of both LaBrea and LaBrea Sentry, these are "passive" countermeasures, consisting of trapping or tarpitting connection attempts. I agree that the idea of "actively" attempting to patch a machine is frought with legal issues.
More information on LaBrea Sentry can be found here.
The page I linked also listed the relevant law in other jurisdictions. Of the states they list there, Delaware seems to have the most onerous requirement for the victim, in that he must retreat if he can do so "safely". All the other states either use the term "complete safety", or don't have a requirement for flight to be considered at all. That means that a victim in those states is never required to run away before wounding/killing his attacker.