Recovering data from a compromised VM: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<languages/> | <languages/> | ||
<translate> | <translate> | ||
| Line 17: | Line 15: | ||
* you will be notified when a ticket is created via OTRS | * you will be notified when a ticket is created via OTRS | ||
==Why do I need to rebuild?== <!--T: | ==Why do I need to rebuild?== <!--T:4--> | ||
* you cannot start an administratively locked VM | * you cannot start an administratively locked VM | ||
* unfortunately a compromised VM is no longer trustworthy | * unfortunately a compromised VM is no longer trustworthy | ||
| Line 23: | Line 21: | ||
* you will need to recover your software, settings, and data | * you will need to recover your software, settings, and data | ||
==What steps should I take to recover?== <!--T: | ==What steps should I take to recover?== <!--T:5--> | ||
* contact the support team and outline your recovery plan | * contact the support team and outline your recovery plan | ||
* if access to the filesystem is required the Cloud support team will unlock the volume | * if access to the filesystem is required the Cloud support team will unlock the volume | ||
Revision as of 16:57, 18 April 2023
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