rootninja

Generate a gpg keypair

$ gpg –gen-key

gpg: directory `/home/user/.gnupg' created
gpg: new configuration file `/home/user/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/user/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/user/.gnupg/secring.gpg' created
gpg: keyring `/home/user/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection?

DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Then you’ll need to enter you name, email, and a comment.

If you get to the random number generation and it just dies there, hit ctrl-c

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 283 more bytes)

gpg: Interrupt caught ... exiting

Check /dev/random to make sure you’re getting some output. If you dont get any standard output when you run this, ctrl-c and you will see 0+1 records in/out. This means there is a problem with your /dev/random device.

$ dd if=/dev/random

0+1 records in
0+0 records out

My fix for this was to use urandom in place of a hardware random device. /dev/hw_random does not exist, so I just went with pseudo random instead. To do this, you’ll need the rng-utils package installed. After doing this, test again with dd to make sure you get garbage sent to standard output then go back and retry creating the keys. You should have no problem getting entropy…

Export the public key

$ gpg –armor –output brokey.gpg –export admica@rootninja.com

Copy /home/user/.gnupg/brokey.gpg to the bro host and import it.

$ gpg –import brokey.gpg

gpg: key 047E07CD: public key "Fname Lname (admica) <user@host.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

security dsa, email, encryption, gpg, private, public, random, RSA, urandom

How to create an encrypted volume on top of a regular file system in Fedora using ecryptfs.

Install ecryptfs if it’s not already on your system.

$ sudo yum install ecryptfs-utils

If you want to use a key and a password, follow the next set of steps. If you just want to use a password, you can skip the ecryptfs-manager section and jump right to making the directory.

$ sudo ecryptfs-manager

eCryptfs key management menu
-------------------------------
        1. Add passphrase key to keyring
        2. Add public key to keyring
        3. Generate new public/private keypair
        4. Exit

Make selection:

Generate a new public/private keypair

Select key type to use for newly created files:
 1) openssl
Selection:

Choose openssl, accept the default path to write out the key.pem file.

SSL key file path [/home/ninja/.ecryptfs/pki/openssl/key.pem]:

Choose a passphrase if you want (something you know), or just leave it blank to rely solely on the key (something you have).

Passphrase:
Returning to main menu

Exit the management menu.

Now make and mount the encrypted volume.

Create a directory where you want to store encrypted data. I’ll make a folder called crypt_vol in my home directory.

$ mkdir ~/encrypted_vol

$ sudo mount -t ecryptfs ~/crypt_vol ~/crypt_vol

Select key type to use for newly created files:
 1) openssl
 2) passphrase
 3) tspi
Selection:

Choose your key.pem location, if you created it with the default, you can just hit enter here because it should be the default here too.

PEM key file [/home/ninja/.ecryptfs/pki/openssl/key.pem]:

Now you have to provide the password you used when you made the public/private keypair. If you didn’t create a password, choose openssl_passwd and just leave it empty. (the default option below)

Method of providing the passphrase:
 1) openssl_passwd: Enter on Console
 2) openssl_passwd_file: File Containing Passphrase
 3) openssl_passwd_fd: File Descriptor for File Containing Passphrase
Selection [openssl_passwd]:
Passphrase:

Choose your favorite encryption cipher, aes…

Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:

Pick the default key size of 16.

Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:

If you want to store a mix of encrypted and unencrypted files under the same area, choose plaintext passthrough, otherwise choose the default, no. I suggest an all or nothing approach, as it can get confusing as to which files are encrypted especially when they’re binary! (With ascii text files you can just cat a file and tell if it’s encrypted or not.)

Enable plaintext passthrough (y/n) [n]:

The first time you create and mount something, you will get this message:

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [fa0757b1] to
[/home/ninja/.ecryptfs/sig-cache.txt] yes

If all went well, you’ll see one last message before returning to your shell.

Successfully appended new sig to user sig cache file
Mounted eCryptfs

Now when you check your mounts, you should see the encrypted volume overlaying one of your other file systems. In my case, I have an ext3 home partition with the encrypted volume on part of it. Anything you put under /home/ninja/crypt_vol will be encrypted. When you unmount crypt_vol, you will still be able to see the directories and file names, but the contents of everything will be scrambled.

/dev/sda4 on /home type ext3 (rw)
/home/ninja/crypt_vol on /home/ninja/crypt_vol type ecryptfs
(rw,ecryptfs_sig=fa0757b1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,)

Since i’m not using a password at all, i’ll move the key.pem to a remote mount and link it back in place, or i’ll make the pki directory a mount point on some remote disk (via nfs probably). If the computer ever gets stolen, the encrypted volume will not be mountable. This is just one example of how to use keys and/or passphrases to protect your encrypted data. If you’re not going to put the key.pem on a remote mount or provide a passphrase, you should consider the encryption worthless since anyone using your machine will be able to find your key and mount the volume after a little searching around.

Linux, howto, security ecryptfs, encryption, fedora, key, mount, pki, private, public

I really like eCryptfs, an encrypted file system supported in kernel able to encrypt right on top of the already supported file systems. No kernel-user-kernel-user swapping required. I like the selective ability of encrypting individual files and I especially like the interchangeable key structure.

While eCryptfs sounds great, there are a few downsides of stacked file system encryption. You can’t encrypt swap space, Oracle ASM volumes, or any file system not already supported by the kernel. Since eCryptfs encrypts file-by-file, it will be easy to figure out the file sizes, the number of files, permissions, superblocks, and other information about the underlying file system. This also means the knowledge that encrypted data exists in the first place cannot be hidden. Block encryption such as TrueCrypt can be completely hidden and can encrypt any file system. Swap space, no problem. File system xyz, no problem.

security cryptography, ecryptfs, encryption, file systems, swap, truecrypt

I’m going to test on a remote machine that I have a shell on, so lets see how many processors it has.

# grep Intel /proc/cpuinfo

vendor_id       : GenuineIntel
model name      : Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz
vendor_id       : GenuineIntel
model name      : Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz

It’s a dual core, so i’ll use -multi 2 so it will work them both, otherwise i’ll only get 1/2 the performance.

# openssl speed rsa4096 -multi 2

Forked child 0
Forked child 1
+DTP:4096:private:rsa:10
+DTP:4096:private:rsa:10
+R1:331:4096:10.02
+DTP:4096:public:rsa:10
+R1:326:4096:10.03
+DTP:4096:public:rsa:10
+R2:22973:4096:10.00
+R2:22932:4096:10.00
Got: +F2:3:4096:0.030755:0.000436 from 0
Got: +F2:3:4096:0.030269:0.000435 from 1
OpenSSL 0.9.8g 19 Oct 2007
built on: Wed Jan  7 10:26:51 EST 2009
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used:
                  sign    verify    sign/s verify/s
rsa 4096 bits 0.015255s 0.000218s     65.6   4592.4

I wonder how many connections it can handle with its current 1024 bit certificate. You could test by retrieving a file accessible from the encrypted web server if you wanted (to see how many requests for something specific that the server can handle for example) I’ll try this from a different machine.

# openssl s_time -connect webserver.domain.com:443 -www /

No CIPHER specified
Collecting connection statistics for 30 seconds
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
8534 connections in 2.94s; 2902.72 connections/user sec, bytes read 0
8534 connections in 31 real seconds, 0 bytes read per connection
Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
23061 connections in 3.86s; 5974.35 connections/user sec, bytes read 0
23061 connections in 31 real seconds, 0 bytes read per connection

If you’ve got a few minutes to spare and like lots of pretty numbers, you could test all the encryption algorithms to see which ones work fastest:

# openssl speed

built on: Wed Jan  7 10:26:51 EST 2009
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2               2458.07k     5089.37k     6894.93k     7590.23k     7841.31k
mdc2                 0.00         0.00         0.00         0.00         0.00
md4              47327.87k   151968.15k   386570.75k   621349.55k   763865.77k
md5              35986.46k   110714.13k   261389.74k   395455.15k   468353.02k
hmac(md5)        38959.56k   112169.51k   262056.62k   395517.95k   465447.59k
sha1             35669.73k   100816.87k   215981.99k   300893.18k   339815.08k
rmd160           26496.42k    67477.06k   129295.87k   167140.69k   183642.79k
rc4             189715.02k   205440.73k   208567.21k   209034.92k   209436.67k
des cbc          46232.50k    48165.20k    48471.04k    48689.49k    48750.59k
des ede3         18221.70k    18466.13k    18522.28k    18549.42k    18557.61k
idea cbc             0.00         0.00         0.00         0.00         0.00
seed cbc         54065.39k    55218.54k    56056.32k    55951.36k    56126.12k
rc2 cbc          26351.53k    26860.07k    27004.42k    27230.89k    27241.13k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00
blowfish cbc     86801.48k    94550.31k    96936.53k    97497.43k    97853.44k
cast cbc         69679.26k    73961.77k    75234.65k    75818.81k    75751.42k
aes-128 cbc     130082.66k   138499.11k   141378.95k   139385.86k   140429.99k
aes-192 cbc     115406.87k   121816.87k   123616.34k   121751.21k   123030.19k
aes-256 cbc     103143.77k   108549.31k   109794.73k   108976.47k   110164.59k
camellia-128 cbc    82057.05k    86232.21k    88002.13k    88119.30k    88394.41k
camellia-192 cbc    63719.78k    66243.14k    66918.40k    66911.23k    67059.71k
camellia-256 cbc    62688.63k    66469.99k    66919.08k    66896.90k    67048.79k
sha256           23866.99k    55023.55k    96156.50k   119234.90k   127945.39k
sha512           17457.25k    70387.97k   115490.47k   169411.58k   197104.98k
aes-128 ige     133509.02k   143881.15k   146220.29k   145246.55k   145932.29k
aes-192 ige     118329.85k   124980.84k   127653.12k   127013.67k   127183.53k
aes-256 ige     106322.68k   111628.44k   113122.90k   112395.95k   112984.06k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000214s 0.000015s   4663.7  67323.3
rsa 1024 bits 0.000832s 0.000040s   1201.9  25101.5
rsa 2048 bits 0.004717s 0.000128s    212.0   7793.0
rsa 4096 bits 0.030215s 0.000436s     33.1   2293.0
                  sign    verify    sign/s verify/s
dsa  512 bits 0.000154s 0.000166s   6497.6   6035.4
dsa 1024 bits 0.000395s 0.000465s   2530.2   2150.9
dsa 2048 bits 0.001244s 0.001484s    803.9    673.7

security 1024, benchmark, benchmarking, certificate, encryption, https, openssl, webserver

For basic dm-crypt mappings, there’s four operations: create, remove, status, resize. But create and remove are the old way of doing things. LUKS (Linux Unified Key Setup) is a a disk encryption specification for a method that facilitates compatibility and interoperability.

You’ll need to use a device that’s empty, or one you don’t mind wiping out, because this will not encrypt the existing data. You will use an encrypted mapping to transparently read and write encrypted data so that you and your applications don’t even need to worry about handling any encryption at all; it will just work, trust me. If you need to save data that’s already on the device, then copy it somewhere else, encrypt the storage device, and copy it all back after encrypting.

To figure out which devices are already encrypted:

Now create a new device:
I’m using UUIDs because I think they’re the best way to make sure you’re identifying the correct drive, especially when it’s a networked device. I mean how can you go wrong when the acronym even means “Universally Unique Identifier”. You can just use a regular old device name or label like “/dev/sda3″ or “/HOME” if you want.

If you didn’t add “–verbose –verify-passphrase” when you created it, like I just did, then you better get the passphrase right the first time, because it’s not going to hold your hand and ask twice. If you mess up, don’t just delete the mapping in /dev/mapper and start over because “cryptsetup status blog.rootninja.com” will still show it as active. If you need to start over, just use cryptsetup to remove the mapping and it will handle it for you. Then use the switches when you start over so you don’t mess it up again.

How to remove an encrypted mapping:

At this point you’ll have a new block device named “/dev/mapper/blog.rootninja.com”. You can check the status like this:

Now create a file system on your device using the encrypted mapping:

Don’t use -m 2 if you’re encrypting something heavily used such as /usr as it’s going to reserve only %2 of the blocks for special use super-user stuff, the default is 5%. dir_index makes it use hashed b-trees to sped up lookups in large directories. uninit_bg skips initialization of the block groups. (you’re going to write through the whole thing in a minute anyway, and this is for ext4 only, so if you’re not using ext4, leave this one out). sparse_super saves space by creating fewer superblock backup copies.

Since you’re operating on the encrypted blog.rootninja.com mapping, everything gets written out encrypted. Easy stuff huh… Now that the file system is on there, you should fill it out with garbage data. But instead of using urandom or random as a data stream, just write out zero’s to the encrypted name and let the encryption do its job!

And that’s it… You’re done. Here’s all the options to cryptsetup when you just run it from the command line with no arguments for the heck of it:

If your system was mounting /dev/sda3 (or /HOME, or whatever it was), in /etc/fstab, then change that to /dev/mapper/blog.rootninja.com and make your rc.local prompt you for the password to mount that home partition, or better yet, have it look for a key file on an external drive!. Think of it like one of those little RSA tokens you need on government laptops. If you keep it on your keychain, no one can even boot your machine unless they have your keys, literally.

Linux, security device, diy, encryption, howto, LUKS

I wouldn’t do it this way for a production network, but i’ve set up similar configurations for testing in vmware, in a research environment, and in a production environment.  So instead of a step by step, here’s a quick run through… It should clear up some of the missing pieces when you try to go from a basic ldap server to multiple servers with startTLS encryption.

If you haven’t done this before, you might want to break it into pieces like getting just the primary LDAP  server up with no encryption first.  But you can find those how-to’s anywhere.  Go big or go home right?

On the Server, become root and install OpenLDAP packages.

The machine you designate as the ’server’ will need “openldap-servers” and “openldap-clients” because you’ll want the server to be a client of itself. You’ll also need “nss_ldap” which, from yum info, allows LDAP to be used as a primary source of aliases, ethers, groups, hosts, networks, protocol, users, RPCs, services, and shadow passwords, and contains PAM support for password changes, V2 clients, Netscape’s SSL, ypldapd, Netscape Directory Server password policies, access authorization, and crypted hashes.

Generate a master password using slappasswd, copy and paste this password into slapd.conf

My LDAP primary server’s hostname is “server1″.  I’ll also set up a replica server named “server2″.  My network’s domain is “mydomain.com”.  So your /etc/openldap/slapd.conf.  I’m going to setup both servers and the encryption all at the same time.  If you run into issues after all this, you might not know which part you’ve messed up at, but starting ldap using lots of logging will let us figure out where it’s hung up.  This should all come out fine and work like a charm, so just go for it. But if you really don’t like that approach, feel free to skip the encyption and/or replica server parts (comment them out and delete the “tls_ssf=256″ parts iin slapd.conf) and come back to them later.  Only the last section stating with comment “Replica” will be different on your replica server2.  They’ll point to your primary server, server1, of course!

The finished version of /etc/openldap/slapd.conf should look like this:

The replica’s slapd.conf will include this part instead of the last section:

updatedn "uid=Manager,dc=mydomiain.com"
updateref ldaps://server1.mydomain.com

Create a self signed certificate on server1 and do it again on server2.

Put both pem files on both servers and on all clients.  Clients need the public part so they can talk to either server in case one goes kaboom! and a replica server has to take over for awhile.  Make sure you use the server’s hostname for “Common Name” when you’re creating them.  You can fill in the rest with whatever junk you want.

You’ll get a server.pem file with the private key and certificate together.  The clients only need the certificate part in their /etc/openldap/cacerts/ directory in order to communicate with the servers.  If you want to save time and it’s just for demo installation, you can just leave the keys in there and copy the files to everyone.  NO I DO NOT RECOMMEND THIS FOR ANY TYPE OF PRODUCTION ENVIRONMENT!  I’m just saying that if you want to save time and you’re just testing this stuff out in virtual machines or a private network, then it will work!

Import the local accounts into the LDAP database.

It’s easiest if you just create all the local accounts you want to start with, using whatever method you normally use to make them.  I use useradd from the commandline.

Run the migration script to fill the ldap database with your accounts.

Don’t panic!  They’re not actually migrating, they’re replicating.  Your local accounts will still be there and they’ll actually be looked at first on any machine because you’ll put “ldap” at the end of any lines in /etc/nsswitch.conf.  This means ldap will be considered after everything lese defined.  Think of it like how /etc/hosts supercedes DNS lookups.

Make sure the ldap user (automatically created by your openldap package installation) owns the files in your database directory and the certificates.

Edit /etc/sysconfig/ldap

You want to make it start LDAP and LDAPS so it will listen on ports 389 and 689.  It’s probably not necessary, but maybe you’ll run into a legacy application that uses encryption but doesn’t like StartTLS.

Copy DB_CONFIG.example to the database directory.

If you don’t have this file or something like it, renamed to “DB_CONFIG” in there, you will see warnings when you try to start the ldap service.  So just copy and forget about it.

At this point, the server side of things is done, however, you won’t be able to verify this until you set up the server as a client.  So continue on with server1.  Edit /etc/ldap.conf and tell it the server, where in the tree to start searching from, and where to get encryption info from.  Or you can just run /usr/bin/authconfig-tui which is provided by package “authconfig”.  This will prompt you for all the fields necessary to configure the machine for ldap.  I use “localhost” for the server, but the actual dns name or ip address for the server for the clients.

Configure /etc/ldap.conf on the clients (and the server so it can be a client of itself)

Configure the OS to actually acknowledge LDAP’s existence

Add “ldap” to the passwd, shadow, and group lines in /etc/nsswitch.conf and edit PAM settings. If you used authconfig-tui, this will get added automagically for you. When you’re done nsswitch should include this:

Start the ldap service on the primary and replica servers.  You should see the primary server start both slapd and slurpd while the replica just starts slapd.  That’s it.

Linux encryption, howto, ldap, replica, starttls