Re: chkrootkit has me worried!
hi ya thomas
On Wed, 30 Nov 2005, Thomas Hochstein wrote:
> Alvin Oga schrieb:
>
> > - fresh installs means you have to configure everything
> > again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week
>
> No, you don't; you can just review the configuration file(s) manually
> or check them against a known good backup.
manually checking thousands of files is prone to error
i run scripts to compare old vs new files, especially when looking
for critical info
- but one does assume that the script is "puurrfect" vs buggy
> > always push backups, since remote machines should NEVER have access to
> > root-read-only files
>
> That is not a good idea in a typical hosting environment; if you push
> your backup and the machine to be backupped is compromised, the
> attacker has access to your backups too because the automatic backup
> process has to have the necessary credentials (unless you want to type
> in the credentials every hour/day/week by hand, which is not very
> feasible).
it's "feasable" to me, and i do backups daily vs the risk of loss of
data.. it's what's important to you and how you want to protect your
data
i always assume the main server is rooted and i try to protect data
within those contraints reason ( ie .. i do NOT trust other machines .. )
- you can crack one box.. but hopefully you can't go anywhere else
- i also assume that cracked box will run " rm -rf / "
( so don't even think about automounting backups :-) )
- i assume the cracker is in the primary box or any random box ...
- they may NOT be able to run the backup scripts since they'd
also need to type something ( pass phrase or password or voodoo )
- passwdless login and process for backup is a bad idea
> Your backup host can and should be quite locked down so it
> should be much harder to attack - I would prefer to allow remote
> access to root-read-only files from a backup machine that is
> presumably safe to giving an attacker from the "front-end" machine
> access to the backups.
if you pull files ... the primary system is allow a remote machine
to read and backup root owned (protected) files which is an obvious
secruity violation to allow non-root or root on other machines
to remotely read root protected files
- any random machine can also pretend to be the credentialed
backup machine wanting to backup say /etc/shadow
which probably requires special care ( encrypting backups )
if you push files ... you assume your backup is secure
and you should encrypt and santize the backup ..
- you have to trust your backup machines if it claims to
be who it is or have a way to verify it too
( unique host info that is NOT copyable or fakable )
- when pushing, the remote backup machine CANNOT read and
does NOT need access to read the primary machine's root protected
files
- whether backup is pushed or pulled, you can always read root owned files
on the backups ... thus backup should be encrypted
- secure backup methodology doesn't care if you are a colo user or all
inhouse or all outsourced
- everybody backup strategy will be different, ask 10 folks how they do
backup and you will get 10 different ways
- which is better will depend on what you're trying to
protect and your paranoia level of trust (who and which machines)
c ya
alvin
Reply to: