3 ms·
If you have full root access - then you don't go at the customer data directly, that's amateur hour. Think about how the data is stored... is it within LVM of
by module0000 10y ago
If you have full root access - then you don't go at the customer data directly, that's amateur hour.
Think about how the data is stored... is it within LVM of some sort(this is likely)? If so, create a new LV mirrored from the volumes containing customer data. Since you're root, make sure this new block device is absent from tools like 'lsblk' or walking through /dev/mapper.
That's just one (poor) suggestion. Never think about bee-lining right towards the valuable data though, that's precisely what every IDS is "best" at detecting. Come at it sideways, so to speak :)
- module0000 10y agoReplying just to add another idea that came to me after hitting submit. Use the network-namespaces feature of linux(assuming this data resides on linux). Then you can create the equivalent of a hidden span-port, letting you inspect all the IP traffic at your leisure - including the traffic that contains customer data.
- Johnny555 10y agoIf someone can snoop traffic and see confidential data, you're not very serious about security - no confidential data is sent off-server without being encrypted. (SSL mostly, with point to point VPN tunnels for a few apps that don't support encryption natively)
- module0000 10y agoThat's very true - if data is leaving unencrypted then they have made a mistake. This is an easy mistake to make though if you bank on your LAN being truly private. However, on the other side of the coin...lots of traffic is unencrypted by design(NFS 1x,2x,3x, and 4x unless you use krb5p, and iscsi).
- Johnny555 10y agoGreat, so now I have an encrypted volume that I can't read unless I can compromise the HSM that stores the keys.
- module0000 10y agoIf you have the access to the encrypted volume, then you'll also have access to the key the moment the volume is unlocked and the key is stored in memory.