While examining flow records for a compromised host, I observed several connection attempts from various Chinese IPs, all in the same /24. The source port was always 80, the destination port always 33824. I don’t see anything obvious on the googles or sites like the Internet Storm Centre, so now there will (eventually) at least be something Google-able. I’d appreciate hearing from any other ITSec types about what this might be, either specifically or in general. My suspicion is this is probing for some botnet or another, with source port 80 to try to get by stupid firewalls, but I lack full content data to prove or disprove this theory.
Joel Rosenblatt describes methodology used at Columbia for tracking abuse complaints as automatically as possible.
Developuction: when a service or host intended for development gets pressed into production. Usually this is done in a reaction to some external event, and nearly always results in fail somewhere down the road. If sysadmins are lucky, it just means the service collapses under a load it wasn’t designed to handle. If they’re not lucky, it means that somebody took a shortcut that compromised security somewhere, and the box gets well and thoroughly pwned. This is nearly always the fault of the sysadmin and not the developer who wrote the code, or the manager who caused the service to be pressed into production.
Developuction is a fact of life for many system administrators, and points to one or more serious issues in their shops. For instance, they could lack professionalism. This is generally ignorance, which is sometimes willful. They could be not granted any authority over technical decisions, in which case management needs to understand why it is that professionals are hired. But ultimately, it’s a sign that short-term answers are favoured over sustainable long-term stability. Sometimes shops get lucky with developuction, and later they run into trouble when this luck is confused with competence.
We’ve all done developuction at some point or another. Sometimes it really is the best way to solve a problem. The key is understanding when it’s acceptable, and being able to properly analyze the risks involved. It helps if you’ve not treated the development machines as a place where processes don’t matter because “it’s just a dev box.”
Actual conversation I just had with a new Windows XP box:
XP: O HAI U R NOT UPDATIN
me: yeah, I’d like to go upd-
XP: OH HAI U R NOT UPDATIN AND U HAZ NO AV
me: yeah, I was about to –
XP: O HAI, WOULD YOU LIKE ME TO UPDATE?
me: ok, so go upd-
XP: O HAI WOULD YOU LAIK A TOUR?
Dealing with Windows is just like dealing with an ADHD child who also has HIV and you have the cure except you can’t inject it into the kid because it’s whirling around in a circle showing you the new dance it just made up.
And then when you’ve just about caught it, some dude in a black hat walks in and shoots your ADHD HIV+ kid in the head and the kid turns into a zombie and tears your throat out just before turning all your other kids into zombies too.
Life with Windows: like life with zombies, only infinitely more exciting.
Interested in risk metrics in IT security? Matthew Rosenquist on the sad story.
Having looked into this (in a cursory manner) for Job Stuff, I can relate to the multiple bodies with different, competing metrics.