After bruteforce attack, fsarchiver restfs errors out

Post here if you found a bug or something really not expected in the program
Post Reply
MiroRovis
Posts: 2
Joined: Sun Oct 27, 2013 5:10 pm

After bruteforce attack, fsarchiver restfs errors out

Post by MiroRovis » Sun Oct 27, 2013 6:49 pm

The usb-stick-deployed sysresc is:

systemrescuecd-x86-3.8.0-beta002.iso

which I used for the following:

mybox # fsarchiver restfs /my_backup_dir/vg_r-root.fsa id=0,dest=/dev/loop2 &
[errno=0, Success]: archreader.c#157,archreader_read_data(): read failed: read(size=4)=0
oper_restore.c#800,extractar_restore_obj_regfile_unique(): queue_dequeue_block()=-5=FSAERR_ENDOFFILE for file(/lib/modules/3.10.5-grsec-130807/kernel/sound/pci/au88x0/snd-au8830.ko) failed
oper_restore.c#847,extractar_restore_obj_regfile_unique(): queue_dequeue_header() failed: cannot read footer dico
oper_restore.c#877,extractar_restore_obj_regfile_unique(): removing /tmp/fsa/20131027-134215-00/lib/modules/3.10.5-grsec-130807/kernel/sound/pci/au88x0/snd-au8830.ko
oper_restore.c#994,extractar_extract_read_objects(): queue_check_next_item() failed: cannot read object from archive
mybox #

fsarchiver is:
0.6.17 (2013-02-25)

The /dev/loop2 is where I:

losetup /dev/loop2 EMPTY_23G.vol

which EMPTY_23G.vol was made with:

dd if=/dev/zero bs=2M count=11100 of=EMPTY_23G.vol

This is the first time I am seeing this error, and I often backup the Debian OS
in question (actually I have two same architecture same MBO clone-suitable
boxes, of which only the one that goes online ever gets into trouble :-). The
Debian is testing branch relatively regularly updated through jigdo downloads,
always apt-get update/upgrade'd offline.

Generally fsarchiver savefs and restfs faultlessly.

But this backup is effectively useless.

I was however able to backup the device(s) (that one /dev/mapper/vg_r-root
device and other devices of the LVM2 setup of the bruteforce-attacked OS; grsec
said that in syslog and in kern.log, not me...)...

I was however able to backup the device(s) of the entire now broken/hacked into
system with:

dd if=/dev/vg_r-root of=some_name_vg_r-root.dd

(similar lines for other LVM2 devices, sure)

I have the system under sysresc still, but only to ask you if you are
interested in finding out how this bug(?) or possibly other misbehavior (of
something other than fsarchiver, but which influenced fsarchiver) came to
effect.

For me, it would be easier if it is just the same for you whether you would try
to find out more about it from the working disk-dump dd backups and from the
broken fsarchiver .fsa's (which I could do any necessary testing with following
your advice), and if you wouldn't really need the broken system under sysresc
itself to find out more from. Because if the former is fine then it would be
possible for me to zero out the broken system and restore it from pretty
probably non-infected older backups (remember I said the online ones are the
only Debians of mine that ever get into trouble...), and still do the necessary
testing with the fsarchiver and the dd dumps from the backups.

I am not really advanced user... but rather invest stubbornly into my
poor-user's defences (consists in simply keeping clean backups, and
separating/quaranteening my internet browsing time from the regular no-internet
time of the machines on my SOHO)...

Since some of the events here strictly belong to http://forums.grsecurity.net I
will post there what is of concern and all the minutia of the bruteforce attack
that pretty obviously has taken place in the concerned machine. There I am user
timbgo (anyway I'll try and always sign my future posts with my name, if I
sometimes forwent doing so in the past). There may be more there in the time
following the date/time of this post. How soon depends also of how well I will
be. Im not a very healthy person.

Also there is some hint about what took place, in the Mutt mailing list,
archives are on marc.info I think, at the end of the thread of the subject:

Pages wrongly displayed on Mutt wiki

( http://marc.info/?l=mutt-users&m=138269801407404&w=2 )

Well there should be. I successfully sent a mail describing the attack two days
ago, but then the system, upon long exposure to open internet (I downloaded my
Debian jigdo CDs with a few GB of updates), and the aforementioned events,
broke... (And also I am often censored in my country with invented reasons and
for no reasons whatsoever.)

Well there should be, I wrote. Because I can't spend longer online for
understandable reason given all the context of this message, and I am preparing
this ahead of time offline. Anyway that what is described there in that thread
on Mutt mailing list, mutt-users, is what I was doing in the time of concern.

Of course I will also search for keywords from my fsarchiver error that I
reported above, before I post this... But I don't really undestand those
functions...

Miroslav Rovis
Zagreb, Croatia

P.S. I did check for string "extractar_restore_obj_regfile_unique" and found 7 matches on http://www.fsarchiver.org but I don't understand so much, and only on this one:
http://www.fsarchiver.org/forums/viewto ... ique#p2828
is there some meaningful (for me, and only to some extent) conversation.
I'll post this just in case, but given the circumstances, it is probably not malfunctioning in the fsarchiver but it is very probably a system too broken by the attack to surrender to regular fsarchiver work... But I don't know...

MiroRovis
Posts: 2
Joined: Sun Oct 27, 2013 5:10 pm

Re: After bruteforce attack, fsarchiver restfs errors out

Post by MiroRovis » Tue Oct 29, 2013 6:55 am

I am notifying this forum that I'll be around for some more time in case there will be need for my attention regarding this thread.
I'm making slow headway on the wider issue of concern that I exposed, but I am not at all fast in solving things like these and neither, very often, in replying.
(the offer to have the system as was at the time that fsarchiver took the FILES.fsa can stand for not many hours longer, from now. The disk dump images,. and the FILES.fsa faken of the system will be around much longer)
Thanks!

Post Reply