• State Suggested Answer
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 9717 views
  • Users 0 members are here
Options
Related

Ransomware protections

jordanl
over 3 years ago

like most companies we are trying our best to NOT get infected by Ransomware, but....  assuming we do get infected.

I understand that RR core service locks the backup files from being encrypted, that's a great start.  but if it's human operated and they get into the core server... game over.  Are there any built in replication type protections that people are using?   what are people doing so they can sleep at night?  my first step was to remove both source and target RR servers from the domain and give them strong local admin passwords.  I see that these servers have Admin share and c$,d$ shares turned on, do I need those turned on for RR to function?    thanks!   Quest could put together a simple document like, "10 things to do to help prevent backup encryption". that's what I need!

Parents Reply
  • 0 over 3 years ago in reply to phuff

    @phuff  Thanks for the reply but we are already pushing an archive to AZURE. This archive runs regularly but it is not "offline" per se. It is offsite in AZURE but any one that gains access to the admin console could 'delete" it at any time.   What I want is an archive that is literally offline as in inaccessible even from the console until required.

    Thanks!

Children
  • 0 over 3 years ago in reply to alaric battle

    Gotcha. Just to clarify, are you talking about the Azure console? If so, then yes you are correct. If you're talking about the RR console, you can only delete the job, not the data. 

  • 0 over 3 years ago in reply to phuff

    "If you're talking about the RR console, you can only delete the job, not the data. "

    Interesting. I did not know that .I figured the delete would work just the same as when I delete a repository. So a job could be deleted in the console but I could still recover the data from AZURE and reconnect if I have my keys and such? That changes things a bit.

    Thanks!

  • 0 over 3 years ago in reply to alaric battle

    Correct. Deleting the archive job DOES NOT destroy the archive itself. I encourage you to try it on something trivial (as I did before I replied on 6.4 and 6.5 just to make sure I was correct in that thinking). Same with deleting a replication job, on the source the data stays, the target asks 'do you want to delete?' For archives though, deleting the job, that just deletes the job, nothing else.