xfs
[Top] [All Lists]

Re: XFS tree for Red Hat should be moved to at least kernel-2.

To: "Net Llama!" <netllama@xxxxxxxxxxxxx>
Subject: Re: XFS tree for Red Hat should be moved to at least kernel-2.4.20-20
From: "Simon Matter" <simon.matter@xxxxxxxxxxxxxxxx>
Date: Tue, 16 Sep 2003 18:22:27 +0200 (CEST)
Cc: "Ethan Benson" <erbenson@xxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
Importance: Normal
In-reply-to: <Pine.LNX.4.55.0309161127470.8603@xxxxxxxxxxxxx>
References: <Pine.LNX.4.44.0309140958220.17784-100000@xxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.44.0309141045391.15430-100000@xxxxxxxxxxxxxxxxxxxxxxxxx> <20030914214745.GD827@xxxxxxxxxxxxxxx> <46483.213.173.165.140.1063724939.squirrel@xxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.55.0309161127470.8603@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: SquirrelMail/1.4.1
> On Tue, 16 Sep 2003, Simon Matter wrote:
>> No please. There are better solutions than mkfs in most situations. Why
>> being so afraid about kernel modules and rootkit binaries? Boot from a
>> CD
>> like knoppix or similar. Then mount all filesystems and examine the
>> system. First check whether your rpm database has been touched. A recent
>> backup may help here. Then rpm is your friend by finding out which files
>
> How do you know that you can trust your rpm binary?  How do you know that
> you can trust your rpm database?  How do you know that you can trust
> *anything* on the system?

You boot from CD. Then you can use rpm2cpio running from the CD and
extract the rpm package which is installed on the target system. Diff all
the files and you're sure your rpm binaries are okay.

>
>> have been modified. You can also find out which files have not been
>> installed via rpm so you can check them manually. After identifying the
>> affected files, replace them with clean ones. Finally, diffing the
>> entire
>> system against backups may improve your confidence.
>
> How do you know if your backups are compromised as well?

No problem. I identify which files have been modified by the rootkit. Then
I go back in the backups searching for when this file hase been changed.
Now, I know which backup to use.

Of course one has to work carefully when removing a rootkit. If you have a
simple server like a NFS box or similar, you may be faster with the mkfs
method. On very complex boxes, starting from the ground can cost too much
time, at least much more than carefully identifying the compromised parts
of the system and replacing them with clean ones.

>
>> Now, it's time to fix the hole in your box before you put it into
>> production again!
>>
>> Regards,
>> Simon
>>
>> > oh please.  if there are peices of rootkit on your box then whether
>> > they installed it or not is IRRELEVANT, your box was compromised,
>> > period.
>> >
>> > you cannot know what they did or did not do, your only responsible
>> > recourse is a complete mkfs of all filesystems (i would dd the entire
>> > disk with zeros) and a reinstall, then to audit your latest backup of
>> > user data (do NOT restore ANY binaries).
>> >
>> > they could have installed a kernel module which will alter the
>> > behavior of arbitrary tools WITHOUT replacing any binary on your
>> > system, which means tripwire and the most expensive `antivirus'
>> > software will NOT be able to help you.  don't think that such a module
>> > will show up in lsmod output either, or that its file is visible to
>> > you on the filesystem.
>> >
>> > your box has been compromised, you need to rebuild it.
>> >
>> > --
>> > Ethan Benson
>> > http://www.alaska.net/~erbenson/
>> >
>>
>>
>>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Lonni J Friedman                              netllama@xxxxxxxxxxxxx
> Linux Step-by-step & TyGeMo                http://netllama.ipfox.com
>


-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@xxxxxxxxxxxxxxxx]


<Prev in Thread] Current Thread [Next in Thread>