Tag Info

New answers tagged

0

Try using Ubuntu Privacy Remix. Its a live usb with encrypted persistent data storage on your usb. And is permanently offline. It is live iso boot so that your linux system cannot be altered or infected by rootkit etc. Only the persistent files are writable but are also encrypted in your usb. It can be used to open, edit, and store your sensitive files ...


0

With single-board computers (SBCs) such as the Raspberry Pi 2 (or B+, collectively referred to as "RPI", based on the Broadcom chips) and the USB Armory (based on the Freescale chips), you have to make decisions about how to proceed forward. First of all, Kali on ARM supports LUKS with NUKE -- ...


3

Why not install however you want, then mark the disk immutable, then take a snapshot? Every time it restarts, you'll get back to the disk image as you set it up. This way you can use FDE if you like, and still not have any persistence session to session.


3

If openssl uses a lot of CPU then it is not blocked waiting for "entropy". OpenSSL is actually sane in that respect, and uses a cryptographically secure PRNG to extend an initial seed into as many bits as it needs. When you use dhparam, OpenSSL not only generates DH parameters; it also wants to assert his social status by taking care to use for the modulus ...


0

Here are 2 more advantages (assuming you use new encryption keys each time you re-install): If you run file recovery tools that scan the full block device, e.g. PhotoRec, you do not have to checks tons of old files that are no longer of interest. If you run filesystem repair tools that scan the full block device, you do not run the risk of confusing ...


19

The commands themselves don't seem particularly concerning - they're a few random-looking searches for particular substrings. However, if your shell history has unexplainable entries, that's a sign that you've been hacked. At this point, what I would recommend is to check your SSH logs to find out when this occurred (and from what IP), and secure your ...


16

It's several text searches. The first one searches for update.creditcard (the dot is a any-single-character wildcard) across all subfolders. (More detail about grep -rnw on StackOverflow.) And if you or another admin didn't run these commands then I'd be very worried and wipe and reinstall that server. The searches themselves are harmless. But if anybody ...


1

Truecrypt works with linux, it just doesn't work with full disk encryption. Within linux, you can mount a Truecrypt volume that features plausible deniability, and then simply chroot it. Or if you feel fancy, have the volume contain a Docker image, and "Dock" it.


0

I assume what you mean by "live forensics" would be what the infosec community usually refers as memory forensics, eg. taking your machine while it is active and unlocked and proceeding to dump all data from it. The solution to your problem would be twofold: First you need to have good physical security, so that attackers can't access your unlocked ...


0

The best/most accurate way to test for things like this is in a white-box security assessment approach, by checking the version of Java installed on the system. So on a redhat system something like rpm -qa would provide the version installed, then check the changelogs for the package which should list what CVE's have been addressed. To automate that, ...


1

The TPM support is very rudimentary at this time. You'll need a bootloader that can extend the chain of trust and I only know of TrustedGRUB which is a pretty old version of GRUB with TPM-related functionalities added. On the other hand, I believe the TPM is just all hype related to Bitlocker, practically it provides very little security (maybe that's by ...


0

For luks particularly there is a way to detach the luks header from the rest of the data. I've often used it as a sort of 2fa for fully encrypted systems. First copy the luks header somewhere else: cryptsetup luksHeaderBackup windows.vdi --header-backup-file header.img Then erase it from the original location: dd if=/dev/urandom of=windows.vdi bs=1M ...


2

What you are looking for is called steganography, it is a branch of cryptography. You can read wikipedia just for a fast start: http://en.wikipedia.org/wiki/Steganography Thereafter, you can find that there are a couple of open-source tools to "stego" any container into .jpg or even .avi. Such a stego-container looks like a .jpg or .avi file. Moreover, ...


2

You could append the encrypted LUKS partition to any streamable file that is significantly larger than it, such as an mp3 file: $ cat beethovens_9th.mp3 windows.vdi > beethovens_9th_with_partition.mp3 The file will still play in most MP3 software, and will show as an MP3 file when using the file command. You will need to know the exact size of the ...


1

The whole of your story consists in: The idea is that in a situation where one can not resist a demand to provide passwords (for instance if he is captured physically and tortured), he should be able to deny the very existence of any encryption. Your goal, even if you reach it, is seriously criticized using rubber hose cryptanalysis which could ...


15

What you're looking for is called deniable encryption. There are two forms of deniable encryption. The first sort is "information-theoretic" deniable encryption: encryption where no mathematical analysis an attacker can perform can prove that a file is encrypted data and not a collection of random bytes. The second sort is "real-world" deniable ...


5

Reading at your answers, what you want is called deniable encryption. It's done by hidding an encrypted container in another encrypted container. That is because when you encrypt, the cipher text looks like random if you don't know the key. Just by searching random in your harddrive, someone can have a good guess that you have encrypted some data and ask ...


2

You could encrypt the file with a second type of encryption, say 'GPG' or similar, and then the file command would not be able to determine the 'inner' file type. Alternatively, just do something really simple like XOR-ing the file with the same file content with a one byte offset (for example), or base64 the file etc. It depends on how much you want to ...


2

Actually no matter the filename and file type is changed, the content still gives the fingerprint of the file type. So if you want to hide something in a system, you better store it in your own folder, assigning the permission of access/write to the file. Although root user can still access the file, however it can prevent other users (normal users) ...


1

Alasjo already provided a good answer, but I think some additional information could help you grasp the difficulties you have and how to address them. In you question you suggested encryption. Just encrypting the uploaded data cannot be enough to secure them. Since encrypted data is useless without a mean to decrypt them, your application would have to ...


0

I think Docker would be a possible solution for this. I am not an expert on Docker. So this is a concept idea solution. I am thinking that you could create a few containers for the database and fig up. So say you build 3 containers (1-master, 1-internal and 1-webapp) with containing the same database in each. Then you could get them to be scanned before ...


1

This can probably be done with the Snort Intrusion Prevention System, though Snort rules for SSH are generally used for things like brute force login detection and seeking SSH exploits. However, I think you'll find that being too draconian, especially on sysadmin-type employees, will likely trigger attrition. Set a corporate policy if you must, but don't ...


2

There are numerous questions with answers on this site as well as Owasp guidelines that cover the risks of allowing file uploads and how to store files properly. You may want to check the legislation that applies to your application and take necessary action to store files accordingly (encryption, access rights, data integrity, logging). As for your idea ...


2

One trick you can use in Linux is to create a file, keep the pointer/handler and delete it immediately. You can then use your file's handle to write and read to it. Linux won't show the file to nobody because you removed it from the OS's file table. Unfortunately you would have to write back the file in a "normal" file when you program closes since you did ...


0

If you don't trust your employee, fire him. If you trust him (in general), give hime some NDA with fine penalties to sign, to motivate him to think twice what he's doing. And focus on protecting from external threats. My point is, there is no real protection against well-motivated insider with admin rights and enough time to slowly/carefully do some rogue ...


4

Yes, this is possible and it is often used in practice. The certificate is only bound to the private key and not to a machine. And the private key is not bound to machine too so you could take it to more machines. But you should be aware that the wider you propagate the private key the harder it will be to protect it. And without proper protection it might ...


0

You can safely store encrypted database credentials in user data using KMS to encrypt and decrypt the credentials. Setup: Create an IAM role with permissions to allow kms:Decrypt on resource * (example below). Encrypt (using other AWS credentials) your database credentials by calling encrypt. Put the encrypted database credentials in the spot instance ...



Top 50 recent answers are included