Recovering data from a compromised VM: Difference between revisions
Jump to navigation
Jump to search
m (Shuber moved page Recovering from a compromised VM to Recovering data from a compromised VM without leaving a redirect: Part of translatable page "Recovering from a compromised VM") |
No edit summary |
||
| Line 11: | Line 11: | ||
==What happens when we detect a compromised VM?== <!--T:3--> | ==What happens when we detect a compromised VM?== <!--T:3--> | ||
* the compromise is confirmed by looking at network traffic logs and other sources | * the compromise is confirmed by looking at network traffic logs and other sources, | ||
* the VM is | * the VM is shut down and administratively locked, | ||
* you will be notified when a ticket is created via OTRS | * you will be notified when a ticket is created via OTRS. | ||
==Why do | ==Why do you 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, | ||
* you are required to build new VM | * you are required to build a new VM, | ||
* you will need to recover your software, settings, and data | * you will need to recover your software, settings, and data. | ||
==What steps should | ==What steps should you 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 | ||
* | * log in to the OpenStack admin console, | ||
* create a new volume and launch a new instance with the new volume | * create a new volume and launch a new instance with the new volume, | ||
* under | * under <i>Volumes</i> select <i>Manage Attachments</i> near the old volume and select <i>Detach Volume</i>, | ||
* under | * under <i>Volumes</i> select <i>Manage Attachments</i> near the old volume and select <i>Attach To Instance</i>, | ||
* boot | * boot in to the new volume, | ||
* mount the old volume from /dev/vdb to /mnt | * mount the old volume from <code>/dev/vdb</code> to <code>/mnt</code>, | ||
* recover files as necessary | * recover files as necessary. | ||
<!--T:7--> | <!--T:7--> | ||
[[Category:Cloud]] | [[Category:Cloud]] | ||
</translate> | </translate> | ||
Revision as of 20:52, 24 May 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 shut down and administratively locked,
- you will be notified when a ticket is created via OTRS.
Why do you need to rebuild?
- you cannot start an administratively locked VM,
- unfortunately, a compromised VM is no longer trustworthy,
- you are required to build a new VM,
- you will need to recover your software, settings, and data.
What steps should you 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
- log in to the OpenStack admin console,
- create a new volume and launch a new instance with the new volume,
- under Volumes select Manage Attachments near the old volume and select Detach Volume,
- under Volumes select Manage Attachments near the old volume and select Attach To Instance,
- boot in to the new volume,
- mount the old volume from
/dev/vdbto/mnt, - recover files as necessary.