Backup Central

Hey guys.
One of my servers was compromised the other day. I backup the system using rdiff-backup. I was thinking that it is a GREAT tool for auditing what the hacker did to the files on the system. However, I'm not really certain on the best ways of getting that information about of rdiff-backup

I know at this time there isn't some web GUI that I can install to see what has changed. However, I'm not even sure how to do it using the command line arguments. What commands would you guys do if you knew that your system was compromised... and had rdiffbackups with an idea of when the breakin occurred?

--------------
I've been waiting for someone to step up and develop a free web GUI for the rdiff-backup system... but it looks like there are no real takers yet. Some commerical ones... but I really think a free tool deserves a free GUI. So maybe I'll give it a whirl.

I remember reading somewhere that there was a XML output option for rdiff-backup but I don't see it in the man pages. Can someone please let me know what is the best way of getting information about the backup from rdiff-backup? (I would like to use the XML interface if this exists... just doesn't seem to be documented if it is) I could simply read the data directory... but I don't think this is the way to go because if the data directory changes or major restructuring happens... the GUI becomes useless.

If rdiff-backup doesn't have an XML output, would someone be willing to write some XML routines into rdiff-backup for use in my GUI?

Lemme know,
Dave Horner

I know at this time there isn't some web GUI that I can install to see
what has changed. However, I'm not even sure how to do it using the
command line arguments. What commands would you guys do if you knew
that your system was compromised...

If your system has been compromised the commands you need include
'[sc]fdisk', 'mke2fs' and similar, followed by a data restore. I would
not try to restore from a backup to a compromised system. If you wish to
ignore that advice then carry out a full restore to another disk and do
a recursive diff between the two filesystems.

I've been waiting for someone to step up and develop a free web GUI for
the rdiff-backup system...

That's one of the shortcomings of Open Source Software: there are far
more people waiting for someone else to write the software than there
are people who will actually take steps to solve their perceived need.

Lemme know

Yes sir. Immediately sir.

Keith

<taintedham-mailinglists < at > yahoo.com>
wrote the following on Thu, 24 Nov 2005 23:17:03 -0800 (PST)

One of my servers was compromised the other day. I backup the
system using rdiff-backup. I was thinking that it is a GREAT tool
for auditing what the hacker did to the files on the system.
However, I'm not really certain on the best ways of getting that
information about of rdiff-backup

Can you use --compare[-at-time] to see how your current files differ
from the backed-up files? Note that this is relatively fast but not
totally safe because it only checks the metadata. An attacker may be
able to modify a file while keeping it the same size, and then reset
its mtime.

To get around this attack, the devel version keeps sha1 checksums of
all the regular files, and you can use --compare-hash[-at-time] to
check those. This should be a more secure way to expose any attacks.

I've been waiting for someone to step up and develop a free web GUI
for the rdiff-backup system... but it looks like there are no real
takers yet. Some commerical ones... but I really think a free tool
deserves a free GUI. So maybe I'll give it a whirl.

Someone has started one at http://rdiffbackupweb.sourceforge.net/ but
I don't know how usable it is.

I remember reading somewhere that there was a XML output option for
rdiff-backup but I don't see it in the man pages. Can someone
please let me know what is the best way of getting information about
the backup from rdiff-backup? (I would like to use the XML
interface if this exists... just doesn't seem to be documented if it
is) I could simply read the data directory... but I don't think this
is the way to go because if the data directory changes or major
restructuring happens... the GUI becomes useless.

Currently rdiff-backup doesn't use XML. I looked into using it for
the mirror_metadata file but thought it was overkill. So far at least
I'm satisfied with that decision. The mirror_metadata format can be
considered pretty stable---I don't think you need to worry too much
about it changing because I'd have to worry about all the existing
repositories in the legacy format.

Sometimes the format of the data files get extended (like additional
fields in the mirror_metadata file, or the addition of the
access_control_lists file) but as far as I can remember all of these
have been backwards-compatible. So in theory rdiff-backup v0.4 should
work on a repository created by v1.1.2.


--
Ben Escoto

>If your system has been compromised the commands you need include >'[sc]fdisk', 'mke2fs' and similar, followed by a data restore. I would >not try to restore from a backup to a compromised system. If you wish >to ignore that advice then carry out a full restore to another disk and do >a recursive diff between the two filesystems.Keith, Where did you get the idea that I'm restoring from the backup? I never said that. I said I wanted to audit the system!The reason I'm interested in this is because rdiff-backup would allow me to see file changes over time...I'm NOT looking for restoration.--Dave

Can you use --compare[-at-time] to see how your
current files differ
from the backed-up files?

Thanks I'll check into that.

To get around this attack, the devel version keeps
sha1 checksums of
all the regular files, and you can use
--compare-hash[-at-time] to
check those. This should be a more secure way to
expose any attacks.

Ya, at this point... if the attacker was that clever
I'll miss it... but I think the majority of things
will change size ... and most attackers aren't that
smart Thanks for the input though.

Someone has started one at
http://rdiffbackupweb.sourceforge.net/ but
I don't know how usable it is.

Thanks for the link, but this looks a little simple
for my taste. I'm looking to make something a little
more full featured. I'd like to have visual diffs of
files and be able to browse the tree revision by
revision, backup by backup.

Currently rdiff-backup doesn't use XML. I looked
into using it for
the mirror_metadata file but thought it was
overkill. So far at least
I'm satisfied with that decision. The
mirror_metadata format can be
considered pretty stable---I don't think you need to
worry too much
about it changing because I'd have to worry about
all the existing
repositories in the legacy format.

Is the mirror_metadata documented? and if so can I
get a link to that documentation? I'm assuming the
mirror_metadata format you are referring to is the
data that is written to the disk by rdiff-backup?

I was thinking that there was an interface in the
rdiff-backup program itself, that would read the
internal (maybe mirror_metadata) and have it stream
out XML for programs to parse the output. But if the
mirror_metadata is already well defined and not going
to change in the future I guess that will work.... if
there is some documentation somewhere on how to read
it. I was just thinking XML would be best because
most languages have ways of parsing it. [course you
can parse anything in any language ]

But I suppose if we do XML output, we are really
re-developing the whole metadata formats...

Thanks so much for the input Ben... and thanks for a
wonderful tool.
--Dave Horner

<taintedham-mailinglists < at > yahoo.com>
wrote the following on Fri, 25 Nov 2005 01:12:56 -0800 (PST)

Is the mirror_metadata documented? and if so can I get a link to
that documentation? I'm assuming the mirror_metadata format you are
referring to is the data that is written to the disk by
rdiff-backup?

There's currently no documentation (other than that in the metadata.py
file). The file is pretty simple though, you will probably
immediately understand the record format immediately after zlessing
it.

I was thinking that there was an interface in the rdiff-backup
program itself, that would read the internal (maybe mirror_metadata)
and have it stream out XML for programs to parse the output.

There's nothing like that now, but it's not a bad idea. What kind of
functionality would you require? Something like an 'rdiff-backup
--get-metadata[-at-time XXX] <file>' command, which would output the
metadata record on stdout?

BTW, I have to take back what I said about no non-backwards compatible
changes. I just remembered that recently I added metadata diffing.
The format of each metadata record is the same, but the new format
allows for metadata .diffs, not just metadata.snapshots.


--
Ben Escoto