I want to encrypt our VM's disk in our KVM virtualization platform, and refer to: https://libvirt.org/formatstorageencryption.html#StorageEncryption.
We can do it as simple steps:
Create a secret
Create a encrypted volume
In VM definition, point to the secret uuid, like
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/vg/test-vm01'/>
<target dev='vda' bus='virtio'/>
<encryption format='luks'>
<secret type='passphrase' uuid='ebb28309-fb26-4a2a-a5a8-e25adea4bc8c'/>
</encryption>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</disk>
However, actually, libvirt stores the secret's value as base64 encode at /etc/libvirt/secrets on hyper, if attacker has physical access of hyper, he can easily get secret value.
I assume that hacker cannot get in remotely, but if having physical access, anyone can reset root password, then login hyper to get everything.
Is there any method?
Or this threat does not exist at all.
Thanks.
If the attacker has root access on the local host, you've already lost. Even if libvirt encrypted its secrets on disk, the attacker can just grab the decryption key out of libvirtd memory. Or they can just access the guest VM memory to grab the LUKS master key directly.
The libvirt disk encryption is primarily designed to protect disk images when they are stored on network storage (NFS, etc). In this case it protects against a network MITM attacker, or an attack from the NFS server admin. It can protect images stored on the local host when that host is powered off - assuming the main host root FS is also encrypted.
The only thing out of scope is protecting against root on the local virt host.
Even a network MITM can't be really stopped if non-trivial, as there are several methods to grab the decryption key then too.
It really isn't much one can do vs. non-trival (e.g. repeating), mitm attack, be it network, or local/(remote-local).
Related
For our product we have decided to implement a Secret Management tool (AWS secrets manager) that will securely store and manage all our secrets such as DB credentials, passwords and API keys etc.
In this way the secrets are not stored in code, database or anywhere in the application. We have to provide the AWS credentials - Access Key Id and Secret access key to programmatically access the APIs of Secrets manager.
Now the biggest question that arises is, where to keep this Initial Trust – the credentials to authenticate the AWS secrets manager.? This is a bootstrapping problem. Again, we have to maintain something outside of the secret store, in a configuration file or somewhere. I feel If this is compromised then there is no real meaning to store everything in a Secret management tool.
I read the AWS SDK developer guide and understand that there are some standard ways to store AWS credentials like – storing them in environmental variables, credentials file with different profiles and by Using IAM roles for Amazon EC2 Instances.
We don’t run/host our application in Amazon cloud, we just want to use AWS secrets manger service from AWS cloud. Hence, configuring the IAM roles might not be the solution for us.
Are there any best practices (or) a best place to keep the initial Trust credentials?
If you're accessing secrets from EC2 instance, ECS docker container, Lambda function, you can use Roles with policy that allows access to Secrets Manager.
if IAM Role is not an option, You can use Federation Login to get temporary credentials (IAM Role) with policy that allows access to Secrets Manager.
As #Tomasz Breś said, you can use federation if you are already using an on-premis Auth system like Active directory or Kerberos.
If you do not have any type of credentials already on the box, you are left with two choices: store your creds in a file and use file system permissions to protect them, or use hardware like an HSM or TPM to encrypt or store your creds.
In any case, when you store creds on the box (even AD/Kerberos), you should ensure only the application owner has access to that box (in the case of a stand alone app and not a shared CLI). You should also harden the box by turning off all un-necessary software and access methods.
I was wondering if custom metadata for google compute engine VM instances was an appropriate place to store sensitive information for configuring apps that run on the instance.
So we use container-optimised OS images to run microservices. We configure the containers with environment variables for things like creds for db connections and other systems we integrate with.
The VMs are treated as ephemeral for each CD deployment and the best I have come up with so far is to create an instance template with config values loaded via a file I keep on my local machine into the VM custom metadata, which is then made available to a systemctl unit when the VM starts up (cloud-config).
The essence of this means environment variable values (some containing creds) are uploaded by me (which don't change very much) and are then pulled from the VM instance metadata server when a new VM is fired up. So I'm just wondering if there's any significant security concerns with this approach...
Many thanks for your help
According to the Compute Engine documentation :
Is metadata information secure?
When you make a request to get
information from the metadata server, your request and the subsequent
metadata response never leaves the physical host running the virtual
machine instance.
Since the request and response are not leaving the physical host, you will not be able to access the metadata from another VM or from outside Google Cloud Platform. However, any user with access the VM will be able to query the metadata server and retrieve the information.
Based on the information you provided, storing credentials for a test or staging environment in this manner would be acceptable. However, if this is a production system with customer or information important to the business, I would keep the credentials in a secure store that tracks access. The data in the metadata server is not encrypted, and accesses are not logged.
I'm working on an application in VB.NET that has to connect to a MySQL database and FTP. How secure is it if I used it in an application that I gave to other people. E.g. if I was to let other people use this application would they be able to find out the MySQL and FTP connection details through intercepting packets or something like that?
If that's the case how can I work round this? Also, part of my application is an uploader for users to upload files, is FTP secure for that or are there better alternatives ways in doing that? My server is a Windows Server 08 if that makes any difference.
Thanks in advance.
FTP is plaintext. It is very easy to get user names and passwords just by packet sniffing. If the ftp is supposed to be secure rather look ay sftp or ftps solutions. These use SSL type encryption on the network layer. Never ever use a ftp server for sensitive information.
MySQL traffic can also be sniffed though it is considerably harder to reverse engineer the protocol. If data has to flow between client and mysql in a secured fashion you can configure mysql to use SSL certificates to encrypt the information. This will ensure security is of highest standards.
It depends, but as per Accessing SQL Server with Explicit Credentials article and it is applicable to MySql as well:
The recommended method is to store the predetermined user name and
password on the server, and then read it and add it to the connection
string at run time. An advantage of this technique is that your
application can access the database using different credentials under
different circumstances, depending on what it needs to do in the
database.
Security Note Never hard-code credentials as strings into programs in your application. Anyone who can get access to the code
file, even the compiled code, will be able to get at the credentials.
Security Note Always give a predetermined user name the minimal access privileges to a resource. Never use "sa" or any other
administrative-level user name. Always use passwords
I was wondering if someone could tell me if there is any potential security breeches that could occur by connecting to a MySQL database that does not reside at 'localhost' i.e. via IP address?
Yes, breaches do occur by not protecting the connection to your database. This is a network secuirty question more so than an Application secuirty question. Thus this answer is entirely dependent on your network topography.
If a segment of your network maybe accessible by an attacker, then you must protect yourself with cryptography. For instance you have a malicious individual who has compromised a machine on your network, then they can conduct an ARP Spoofing attack to "Sniff" or even MITM devices on a switched network. This could be used to see all data that flows in and out of your database, or modify the database's response to a specific query (like a login!). If the network connection to your database is a single rj45 twisted connection to your httpd server all residing inside a locked cabinet, then you don't have to worry about a hacker sniffing this. But if your httpd is on a wifi network and then connecting to a database in China, then you might want to think about encryption.
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transferred is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
It's usually the other way round that the bigger problem lies, vulnerabilities in the MySQL server being exploited by untrustworthy clients.
However, yes, there have also been client vulnerabilities in the past (eg.) that would allow an untrustworthy server to attack the client.
Naturally you should keep your MySQL client libraries up to date to avoid such possibilities, as well as updating the server.
If your connection to the server is going over the internet (rather than a private network), you should consider running it over an encrypted link (either MySQL's own SSL scheme or using a tunnel). Otherwise any man-in-the-middle could fiddle with the data going in and out of the database, and if there are client or server vulnerabilities those could also be targeted.
If the servers are in the same rack, you can use dedicated high-speed MySQL cable, or use switch VLAN isolation, and protect the database OS. In cloud with the virtual cloud network you can connect it the way that arp spoof is not possible, and for the geo-ip replication, you can use user/password and firewall, and then measure the performance, and then setup a tunnel and measure performance again, if it's not bad, it might be worth against unknown threats or just useful in using spare cpu cycles.
Simply SQL servers has to be on isolated network, and not into the public, as rule of thumb, you never publish open database connection to anyone, and keep it with seriously good firewall filtering on separate subnet made for handling sensitive data with very good arp spoofing protection, otherwise it's crackable and the major parts of the system can be compromised using several techniques, and it's very nice and sometimes very easy to handle it this way, e.g. to control, monitor and policy the MySQL traffic with hardware layer - and it really does the job and makes a real difference.
Optionally you can keep it on encrypted hard-drive in physically safe place along with the switch, so upon breaking the power its switched off, and the private key erased, hence both layer-1 and layer-2 are secured.
On the switch to use the static ARP table plus the filtering for the static entries versus the port is very easy to do because it's also physical layer - the port number.
I have a windows service that reads from app.config
I want some settings to be encrypted, however, I don't want to use the ProtectedConfigurationProvider classes provided in .NET because they encrypt files based on the machine they are running on using DPAPI.
What I wanted was a way for our administrator to deploy the config file already encrypted to many machines and have each machine decrypt them when needed.
I don't want to hardcode a password into the assembly either so I'm not sure how I can go about this.
Perhaps your central server can maintains a database of the private keys for all the end points, then it could use the specific machine key for that.
A shared private key for all the machines is not going to be that secure.
You can use user-level RSA keys and export them to each machine. then the config file can be encrypted ahead of time, and the target machines already have the key.