old FC haceked system

bruce badouglas at gmail.com
Wed Dec 18 18:44:57 UTC 2013


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 at practichem.com> 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 at lists.fedoraproject.org
> 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


More information about the users mailing list