FreeBSD 4.4 - Rerverted Itself!!

M

marshall28

Today I was thrown into a downed mail server situation which happened to be running FreeBSD 4.4. It had sendmail, webmin, and apache. Everything was working fine upto Saturday and when they came in today none of the afformentioned services were working. So we had them do a hard shutdown on the server with a restart and still none of these services came up. So I was called on-site and ended up finding that all the "data" for webmin and apache had disappeared (not visible in /etc or /usr/local or /usr or log files in /var/log) as well as most of the current email users were not listed under /home. The server was also not pingable from the normal IP it had been assigned to of 10.0.0.4/24. the rc.conf showed 10.0.0.2. And constant messages were coming up on the console saying that rloy, jjays, pbreyer, and other users had an incorrect password. These were the email outlook clients trying to connect but failing due to wrong passwords or incorrect users trying to fetch their email.

So from all of this I can see that the current settings are from a different time on this server. What would cause everything to "revert" to these old settings as well as actual directories and services, which I know were working fine the week before, to suddenly be missing?

This server amazingly enough is running a p3 350mhz and must be from the mid to late 90's. Such a dinosaur. We ended up moving all their email to godaddy but still are trying to find a way to recover their lost website.

any help would be appreciated
 
wblock said:
Somebody ran a restore. How many users had root?
Click to expand...

Hmm... how does that work in FreeBSD? I didn't know you could do that. and I know that none of the users there would know howto do that.

Is this something that can be done accidentally?
 
restore(8). They would have needed access to an old dump file, and root access to be able to restore it. Or it could have been some other backup utility other than dump(8)/restore(8). Either way, the symptoms are consistent with a restore of at least /etc/ and /usr/local/etc/.

Accidental? Depends on how the system is set up. A restore could be in a script, for example. Whoever did it had root access, which should limit the number of possible guilty parties.
 
wblock said:
restore(8). They would have needed access to an old dump file, and root access to be able to restore it. Or it could have been some other backup utility other than dump(8)/restore(8). Either way, the symptoms are consistent with a restore of at least /etc/ and /usr/local/etc/.

Accidental? Depends on how the system is set up. A restore could be in a script, for example. Whoever did it had root access, which should limit the number of possible guilty parties.
Click to expand...


ok thanks. much appreciated. I guess this is the only logical explanation although I have no idea how/why this would have been done.

would doing a hard shut down (unplugging the machine) and turning it back on cause this?
 
Probably not, no. There are exotic scenarios where old deleted file trees, still on disk in deleted sectors, are somehow re-linked into the real filesystem. Or some weird virus/rootkit/malware does that. But Sir Ockham has a point, and a restore(8) or even a cp(1) could copy old files back into their previous locations.

Yanking the power should not do this.
 
This was a manual operation. Someone connected a backup drive/tape/filesystem, did a restore, and then rebooted the system, bringing it up with the old data.

Or, possibly, they screwed up /etc/fstab and have mounted an older filesystem overtop.

Or something along those lines. There's no way for this to happen accidentally nor automatically.

Someone in the server room did something.
 
I was thinking of overlaying mounts as well, with either the newer files being on a mountpoint that is now no longer mounted (exposing older files that were still present), or older files being on a mountpoint that is now mounted (obscuring the newer files under them). This could have been triggered by an unforeseen reboot, because 'someone' who, at one point, mounted filesystems manually did not actually make sure they were also in /etc/fstab (a typical "I'll get to that later" type error).
 
It could even be multiple hard drives, like an external USB with a higher boot priority in the BIOS. But that would also mean that the other drive was a full copy of the main drive, not a dump or other backup format. Or removable disks.

Another possibility is maybe it really isn't old files, but a webmin exploit and someone more subtle than the average Timmy The Hacker.
 
You must log in or register to reply here.
Back
Top