Slashdot Mirror
Searching For Backdoors From Rogue IT Staff
WHiTe VaMPiRe writes "When IT staff are terminated under duress, there is often justification for a complete infrastructure audit to reduce future risk to a company. Here is an exploration of the steps necessary to maintain security." Of course the first piece of advice is to basically assume you've been rooted. Ouch.
>That seems a bit risky. I cannot see any manager worth his salt giving authorization to purposely destroying data "to
>see if the backup works".
We do it routinely, but it's not chaotic or risky like your choice of words makes it sound. OTOH we have invested a lot of money and brainpower into getting the redundant system we need to have in order to fail over a production system, tear one down, build it up again, verify it and put it back into production. That costs money... and probably not something the IT manager that had to be "fired under duress" actually accomplished.
Unless you can deploy your standard configuration with nothing but the LTO tape from Iron Mountain and a charge account at your server vendor, you don't have a Disaster Recovery plan. (A fire in our facility probably takes out 4 city blocks. We seriously take this under consideration, and we do drill for it.)
-fb Everything not expressly forbidden is now mandatory.
to audit your system under the assumption you've been rooted should happen once a year at a minimum anyway ....
I'll get right on that in my copious amounts of free time....
I'm sorry, but that's the a**hole way of running a network... make the place unnecessarily complex so you're the only one who knows how any of it works so "they don't dare fire me." That rarely works out well -- and often encourages firings. Having been the replacement and consultant called in to sort it all out, I support the death penalty for such people.
You could easily just badly document or fail to document passwords and configuration info and stuff. As long as you're around and working with the systems daily, everything runs smoothly. If you get fired, there's confusion with the new guy and your memory fades... it's not like they can really tell exactly what isn't a matter of the new guy not being up to speed for weeks. And you're not responsible for giving them consulting services for free after they fire you. If they can't figure out the non-standard port numbers you used, then that's their problem.
Childs took an idiotic stand where he admitted he knew the passwords and refused to hand them over. That's not the most lenient case, that's the worst case I can think of other than destroying data.
Even worse, he deliberately setup the routers so he'd have to manually reconfigure them if/when they rebooted - in other words a deadmans switch.
Wrote the answer to that above, before I saw your post here. To repeat: if it's a hostile environment, you need your own CYA audit, with witnesses. Your replacement could be Evil, or simply Incompetent. And either way, you don't want the blame falling on you.
Most employers will only confirm the dates you worked for them now, for fear of lawsuits.
Everywhere I've been inserting complexity to ensure job security is the number one (or at least in the top 5) way to find yourself without a job. Making something intentionally complex to the point that only you can fix it is unprofessional and, at least in the case of engineers, unethical. The only reason these firings are done without cause as opposed to for cause is because it's more paperwork if you're actually fired for being unprofessional.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
What about actually applying some reading comprehension skills to the portion quoted? Take note that things were not deliberately complicated but ended up that way to solve problems.
Arcane performance tweaks by people that know the stetup backwards are quick while well documented proceedures designed for newbies take time to develop. You can aim to get there in the end, but the above post appears to be about what would have happened if things were stopped part way through.
I take it, then, that you didn't follow the link I gave, because the whole point of the hack was that none of it was in the source code. The compiler was hacked to add code to login when it compiled it, and to add code to itself (if it were recompiling itself) to do the work.
Good, inexpensive web hosting
With Unix-family systems it's easy to stream syslog to another server, and that other server should be used for nothing else. Firewall it so it seems down from everywhere (except perhaps a monitoring server) and so that you only access it in two ways: Inbound udp on port 514 (syslog streaming) and inbound ssh on a different port than 22 only from a single access point (another server, a workstation or similar) using a key not stored on that access point and not used anywhere else.
I'd say that it is extremely difficult for someone to compromise another server (webserver typically) and then gain access to the logging server (name or IP evident in /etc/syslog.conf) to erase his tracks there as well.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Of course there was source for the hack at some point. However, this source "disappeared" (i.e. was reverted) after having been compiled once. Subsequent recompiles (of login, or the compiler itself) by an already contaminated compiler propagated the hack.
In practice, there was no way to get rid of it without compiling the compiler with a compiler that was known to be uncontaminated - something you had no easy way of verifying (or even suspect that you would need to verify).
Remember that at some point, you need to start with a binary (compiler) that you simply have trust (well, at least in practice - in theory you can build your own computer from the scratch with twigs and bubble gum), and unless you're God himself, that binary was probably built by Ken.
May we live long and die out