Hi Mark, Thanks for the reply. 'ppreciate it. Basically, I'll be able to keep the corrupted system up/running, offline for a bit, so I'll be able to (more or less) really be able to see/recall what apps/functions are running, or should be running. And I'll be keeping a copy of the drive in a drawer just in case I get that "oh Christ moment months from now!!) A critical part of this whole process however, is that we're going to be creating a system of connected boxes/VMs that need to be tightly secured. IE, the systems will form a distributed network of boxes, each connecting back to the mother/master system via either a webservice process, or via ssh, so I'm going to be looking for a good approach to really securing the overall architecture. You up for a more indepth conversation on this??! Thanks ps. are you in the us/canada? -bruce On Wed, Dec 18, 2013 at 1:03 PM, Mark Haney <mhaney@xxxxxxxxxxxxxx> wrote: > See comments inline. > > On 12/18/2013 12:49 PM, bruce wrote: >> Hi. >> >> Got an old FC system that was hacked. - I know - my own fault >> (perhaps) should have updated, etc,,, > > How do you know you were hacked? > >> >> >> >> The system is vital, need to extract all/as much of the files from >> the 700G drive as possible. I'm going to blow away the corrupt >> system, replacing the system with centos 6.5. > > No backups? I'd be /very/ careful pulling data off the old system. > Depending on how recent the intrusion is, I'd almost go back to the > most recent /safe/ backup and start from there. > >> >> On the corrupted machine, when it was setup, the partitions where >> such that most of the data was written to the /apps partition - so >> hopefully most of what I really need will be there. However, I'm >> pretty sure that a chunk of other useful/critical stuff was placed >> on other dirs within the drive. >> >> I'd like comments/suggestions on my approach to resolve the issue: >> >> -Setup new machine with a couple of drive bays > > What I would do is setup the 'new' machine to boot from a flash drive > (like a live CD of CentOS) in order to recover the data. This way you > can at least be certain the installed OS on the new machine will never > see or use the hacked drive. (See comment above about backups.) > >> -take the corrupted drive, insert it in new machine's drive bay >> -insert clean 750G drive in the other drive bay -from the new >> machine, do a complete "find" on the corrupted drive to get a >> "complete" list of files/dirs/tree > > I don't know about anyone else, but I know what and where my critical > data resides. (Not a helpful comment as much as an FYI for the future.) > >> -go down the list, identifying the initial dirs/files that are >> important/data, that aren't part of the OS --copy these dirs/files >> to a tmp area on the clean drive, maintaining the dir structure >> -repeat this process untill I pretty much get the data files >> (txt/py/pl/php/etc..) --go through a complete process, trying to >> identify all the apps/functions that were added to the corrupt >> system. -identify these apps, as well as the rpms required to >> generate the functions -create a script to auto install these >> apps/functions from the associated centos/associated centos repos >> -handle all mysql stuff by doing a mysqldump from the good >> machine, > > IIRC, you'll need to attach those DBS to a mysql instance to do a > dump, which means potentially exposing your new system. If that's the > case, LiveCDs are the way to go. Be careful here though, MySQL > versions should be the same or close to it or they won't play nice. > >> reading the mysql data from the corrupted drive, and then copying >> reinserting the mysql data into the new mysql on the clean/tmp >> machine -identify any dev languages/environments >> (py/gearman/perl/php/etc..) and the required rpms to install or run >> to recreate the env on the clean/tmp machine >> >> -identify all of the "services" running on the corrupt >> system/drive, and clean/install the rpms/services on the clean/tmp >> machine/drive -change all ssh keys for the new clean/tmp >> drive/machine.. -change all passwds on the new machine -for any web >> sites, change all passwds > > You don't know what services you run on the hacked system? If you > don't, I'd probably start with the bare minimum of what I recalled I > ran and go from there. > >> >> >> -the goal is to recreate the file system/dirs/files from the >> corrupt machine/drive on the new clean/tmp machine as much as >> possible >> >> >> -however, once I've gone through all of the above, I still need to >> know how to lock down services, how to harden the overall system.. >> > > I'll be glad to help offlist if you like. I've rebuilt my share of > hacked systems, so I might be able to offer some ideas. > > > > -- > Mark Haney > Network Administrator/IT Support > Practichem > W:919-714-8428 > > -- > users mailing list > users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
