The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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!

Security Myths

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 Six Dumbest Ideas in Computer Security

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 crap.

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 a rtificial 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 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.

The Six Dumbest Ideas in Computer Security


Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.