Re: Re: Is my system compromised
Alvin Oga said:
> obviously i can spend the same 2-3 minutes doing exactly that too,
> but you're missing the point that one can spend a week to harden the
> server and verify that its been hardened ... the more paranoid you
> are, the more time will be required to harden the server...
No, you're missing the point. You said that cleaning up after a
compromise is easier and less time consuming than a reinstall. You then
go on to point out that you could spend 2-3 weeks to harden the
reinstall. Well, guess what, the compromised machine needs the same
thing. The difference is a person could take days to get the compromise
cleaned up and at the end you know what they have? They still have a
machine they need to harden *and* have no guarentee. *None* that they
have completely eradticated the compromise.
With a reinstall guess what you have. You have a far higher assurance
that the compromise is not there. Thousands of people install from base
CDs or netinsts. We're fairly confident the repositories aren't
compromised.
So it boils down to this. Our suggestion is to harden a known
uncompromised machine. Your troll is to harden a *known compromised
machine*.
BTW, there was also a presumption that a person has done some hardening
of their machine and those efforts are in the configuration files which
would come from a backup prior to the compromise. In that case they
would need to just reinstall, copy the known good configs, plug the
hole. That ain't 2-3 days of work.
>> Backup data areas, not areas in the path? Just a thought.
> not always reality ...
Yes, it is reality. Most, if not all, of the compromises go into the
system binaries. Those are reinstalled. Anything in the path and
supporting libraries should be considered suspect and dumped. At that
point you're only pulling over non-executable data. If it is executable
*it is not in the path and cannot be executed without a trojan in the
path*.
> and there's dozens of problems since
> users themself create scripts and that is usually the problem
> vs a well defined security policy for the system before users
> fiddle with it
Of course you're talking out your petard on this one because the OP has
not mentioned any users other than himself.
> that depends on if you're silly enuff to use the binaries on the
> cracked box or not and/or if you can legitamately verify it
> in the dozen different ways to the forensics
Well, how else are you going to do it?
> - once you power off, you're dead ... in that you;ll
> never find the good pieces of cracker info still in memory
I mean, you have to power off to boot to known good media... oops.
The point, Alvin, is that in the pragmatic reality 99% of the people who
are going to run into these problems are not going to have the expertise
to effectively diagnose, clean up and otherwise get into the guts of a
compromised box under the time constraints they work under. Furthermore
99% of the people who would attempt it, regardless of their experience,
would not do as well as a simple reinstall and certainly not in the
amount of time a reinstall entails.
It's called cost/benefit.
COST: my machine is spewing crap on the net, has defaced sites, whatever and
every minute it does that is causing problems.
Alvin's whack-job solution: spend 2-3 days trying to "learn" from the
experience, root out all of the corrupted and malignate binaries using the
self-same corrupted and malginate binaries and hope and PRAY I've got it
all.
BENEFIT: insecurity, lack of guarentees, lost time and revenue.
Realworld solution: Spend 2-3 HOURS to reinstall, restore, plug the hole and
carry on.
BENEFIT: Guarentee that the comrpomised binaries are purged, far less lost
time and revenue, greater assurance that things are hunky-dory.
BTW, Alvin, you've been repeatedly told, by myself and others, it is
against list policy to CC unless asked. But of course, as you continue
to troll this list with your FUD and lies I don't expect you to bother
with such trivialities.
--
Steve Lamb
Reply to: