Recovering data from a compromised VM: Difference between revisions
Jump to navigation
Jump to search
m (Add CC-Cloud flag) |
mNo edit summary |
||
Line 34: | Line 34: | ||
* recover files as necessary | * recover files as necessary | ||
[[Category: | [[Category:Cloud]] | ||
</translate> | </translate> |
Revision as of 20:59, 27 February 2023
This article is a draft
This is not a complete article: This is a draft, a work in progress that is intended to be published into an article, which may or may not be ready for inclusion in the main wiki. It should not necessarily be considered factual or authoritative.
Parent page: Cloud
On the cloud, you are responsible to recover from a compromised VM.
This document is not a complete guide, but will set out some things you need to do when your VM is compromised.
What happens when we detect a compromised VM?
- the compromise is confirmed by looking at network traffic logs and other sources
- the VM is shutdown and administratively locked
- you will be notified when a ticket is created via OTRS
Why do I need to rebuild?
- you cannot start an administratively locked VM
- unfortunately a compromised VM is no longer trustworthy
- you are required to build new VM
- you will need to recover your software, settings, and data
What steps should I take to recover?
- contact the support team and outline your recovery plan
- if access to the filesystem is required the Cloud support team will unlock the volume
- login to the OpenStack admin console
- create a new volume and launch a new instance with the new volume
- under "Volumes" chose "Manage Attachments" near the old volume and chose "Detach Volume"
- under "Volumes" chose "Manage Attachments" near the old volume and chose "Attach To Instance"
- boot into the new volume
- mount the old volume from /dev/vdb to /mnt
- recover files as necessary