Sunday, March 23, 2008
Tracking script kiddies
Last month I wrote a program that wraps around the Perl executable, and all it does it copy files given to Perl, and then passes on control to Perl. I did this because we at The Office kept running into sript kiddie Perl scripts consuming resources on our servers.
Checking the process wouldn't reveal much—they always start in
/tmp and would be owned by the web server process, so we knew how they were coming in, just not where (i.e. which site was exploited). Worse, these scripts would be started up, then deleted once running, so viewing said scripts was impossible.
Thus, by wrapping the Perl executable to record as much information about each running script as possible, we could gather information about how they might be getting in.
And tonight, we finally caught one! And better still—we know which site was exploited!
Now, begins the process of finding out which PHP script (sigh—it figures) is poorly written.
Oh, by the way, Happy Easter!
Let me introduce you to the six dumbest ideas in computer security. What are they? They're the anti-good ideas. They're the braindamage that makes your $100,000 ASIC-based turbo-stateful packet-mulching firewall transparent to hackers. Where do anti-good ideas come from? They come from misguided attempts to do the impossible—which is another way of saying “trying to ignore reality.” Frequently those misguided attempts are sincere efforts by well-meaning people or companies who just don't fully understand the situation, but other times it's just a bunch of savvy entrepreneurs with a well-marketed piece of junk they're selling to make a fast buck. In either case, these dumb ideas are the fundamental reason(s) why all that money you spend on information security is going to be wasted, unless you somehow manage to avoid them.
The first two myths listed, “Default permit” and “Enumerating
Badness,” are hard for me to accept since I basically believe in an open
network. I'm a programmer by training, and I like playing around with
stuff, and having a closed “default deny” attitude towards the network
would make it too annoying for me to
play work. I'm also lazy
and just want things to work without having to configure a bunch of
In his second myth, “Enumerating Badness,” he also talks about restricting execution of programs to those that are required to run. I doubt he's ever worked with something like SELinux. I have, and if it's ever running, I turn it off since it's a bitch to get anything working (and our support costs would go up as well as our customers try to install scripts and can't get them running).
But I'm also getting tired of clearing out script kiddies out of our servers. It might actually be worth it to adopt a “default deny” stance on things (but perhaps not as far as running SELinux—I don't think it's cost effective with our setup).
His advice on artificial ignorance is great though, and is something I would like to do. “Artificial Ignorance” in this case, is scanning through log files throwing out everything that is not of interest (read: “is a known quantity and can be ignored”); anything left over is by definition “interesting” and should be investigated. It would certainly beat the log summaries that LogWatch produces.
And some of the best advice on that page?
One extremely useful piece of management kung-fu to remember, if you find yourself up against an "early adopter" is to rely on your peers. Several years ago I had a client who was preparing to spend a ton of money on a technology without testing it operationally. I suggested offhandedly to the senior IT manager in charge that he should send one of his team to a relevant conference (in this case, LISA) where it was likely that someone with hands-on experience with the technology would be in attendance. I proposed that the manager have his employee put a message on the “meet and greet” bulletin board that read: “Do you have hands-on experience with xyz from pdq.com? If so, I'm authorized to take you to dinner at Ruth's Chris if you promise to give me the low-down on the product off the record. Contact, etc …” The IT manager later told me that a $200 dinner expense saved them over $400,000 worth of hellish technological trauma.