"You don't just restore a server"
-
Client gets infected with cryptoware, a surprising conversation went as follows:
Person: "Please tell me $client has healthy backups."
Me: "Yep. I receive health reports every day and mitigate issues as soon as I receive faults."
Person: "Well they just got hit with cryptoware."
Me: "Yikes. Time to break out the backups."
Person: "Are you joking? You don't just immediately think to restore a server."
Me: "Well that's why we have backups, and it's the only way to sanitize the server... What do you recommend?"
Person: "Isolate the server and go through the logs. Clean it up, don't restore it."
Me: "That doesn't make any sense... Clean WHAT up? The files are all encrypted."
Person: "Have you even looked for a decryptor?"
Me: "No... that wastes more time than just restoring for around the next hour."
Person: "Seriously, do not restore servers as a go-to. That's just lazy."
I'm lost here... I don't think I missed something. You get hit, you restore. Server crashes, you restore. That's why we have backups...
-
Is person the boss? Or a coworker?
-
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
-
@BBigford said in "You don't just restore a server":
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
Then I would explain that restoring from backup is the least costly and most effective means of ensuring that the server is clean when you are done. Sanitizing and decryption leave you with a dirty server that you can't trust.
There is a significant difference between being secure and being lazy.
-
@BBigford said in "You don't just restore a server":
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
https://media.licdn.com/mpr/mpr/shrinknp_200_200/p/7/005/06e/190/10c6129.jpg
-
@Grey said in "You don't just restore a server":
@BBigford said in "You don't just restore a server":
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
https://media.licdn.com/mpr/mpr/shrinknp_200_200/p/7/005/06e/190/10c6129.jpg
Oh god not the son of Dracula.
-
@BBigford said in "You don't just restore a server":
You get hit, you restore. Server crashes, you restore. That's why we have backups...
More importantly waiting to restore can actually cause harm. Whoever is wanting to dig thru the server for logs and clean it up must be paid for overtime.
-
@BBigford said in "You don't just restore a server":
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
Maybe he washes off and reuses his toilet paper too?
-
Backups are the only reliable option to do this, if you have snapshots it is even better. You can backup all the bad (encrypted) files and then worry about what Ransomware infection is. Usually I do gather though all the information necessary related to the attack before restoring or wiping
-
@dbeato said in "You don't just restore a server":
Backups are the only reliable option to do this, if you have snapshots it is even better. You can backup all the bad (encrypted) files and then worry about what Ransomware infection is. Usually I do gather though all the information necessary related to the attack before restoring or wiping
Yes, the cause of infection is important. What if the infector is a client or admin PC somewhere in the company... you restore the server, and it just gets encrypted again. The source must be found first. Then bare-metal backup the infected server (to look at later)... and restore it from a clean backup.
-
I would poke around it long enough to figure out if the server had been logged in to, or if a user's computer encrypted all the files. You don't want it coming right back. Like others said, figure out how it got infected and then restore back before the infection.
-
@BBigford said in "You don't just restore a server":
@coliver said in "You don't just restore a server":
Is person the boss? Or a coworker?
Without airing dirty laundry... I'll just say they are in a technical, non-managerial role.
And will stay that way. I would guess.
-
@DustinB3403 said in "You don't just restore a server":
@BBigford said in "You don't just restore a server":
You get hit, you restore. Server crashes, you restore. That's why we have backups...
More importantly waiting to restore can actually cause harm. Whoever is wanting to dig thru the server for logs and clean it up must be paid for overtime.
Right. Actively creating risk and downtown so that they can "play tech" as if they were at Best Buy.
-
@Mike-Davis said in "You don't just restore a server":
I would poke around it long enough to figure out if the server had been logged in to, or if a user's computer encrypted all the files. You don't want it coming right back. Like others said, figure out how it got infected and then restore back before the infection.
If you want to do that, in 95% of cases, take a fresh backup, isolate it and do that offline in a forensics lab after you deal with getting production back. Just leaving it alive could result in more data leaving the environment.
