ciphermethod.com

So, your company has been acquired. If climbing inside an escape pod and jettisoning your self into deep space is not an option, here is a list of things to expect:

• An order will be made to lower your firewalls and surrender your servers.
• You will be assimilated.  Resistance will only slow the process down.
• Assimilation is a means of adding or replacing spent drones.
• The Borg have no feeling, no emotion, no individual thought.
• Each Borg is part of a giant subspace communications network called Exchange Server.
• All communication is transmitted to the entire Collective via a process entitled Carbon Copy.
• Your present function and title is irrelevant.
• Strength is irrelevant.
• Negotiation is irrelevant.
• Freedom is irrelevant.
• Self-determination is irrelevant.
• Your life as it had been is over.
• From this time forward, you will service them.
• Your culture will adapt to service them.
• They will add your biological and technological distinctiveness to their own.
• Resistance is, and always has been, futile.
• You will become one with the Borg.

UNIX Administrators: Saving servers from nefarious end-users since 1969.

Make sure kernel modules are present:
modprobe aes
modprobe dm-crypt
Create a 256 bit key file containing random data:
dd if=/dev/random of=/etc/key bs=1 count=256
chown root:root /etc/key
chmod 600 /etc/key
Initialize device:
cryptsetup –verbose -c aes-cbc-essiv:sha256 luksFormat /dev/sdb1 /etc/key
answer “YES” if you would like to overwrite data on /dev/sdb1 irrevocably
Create device mapping in /dev/mapper:
cryptsetup –key-file /etc/key luksOpen /dev/sdb1 sftpusers
Format partition:
mkfs.ext3 /dev/mapper/sftpusers
Add partition to /etc/fstab:
/dev/mapper/sftpusers /sftpusers ext3 defaults 0 0
Create/update /etc/crypttab with device info:
sftpusers /dev/sdb1 /etc/key

Reboot to verify that volume is mounted automatically. This configuration has been tested on Red Hat Enterprise Linux 5.

Done in order to satisfy a PCI compliance issue with VMware volume files. Files should be encrypted when not in use. Of course, this only ensures an encrypted virtual disk file at the ESX file system level. Credit card data inside the virtual drive still needs to be encrypted so that it is not accessible when the system is live.

Note: Exclude the key parts if you want an encrypted partion with prompt for password at boot.

1. Download latest OPENSSH
2. Unpack tar file
3. CD to openssh source directory
3. vi version.h and remove VERSION_SSH information (if desired)
example: #define SSH_VERSION “OpenSSH”
4. run ./configure –with-tcp-wrappers
5. resolve any missing dependencies
6. login via a telnet session
7. disable ssh and remove existing SSH packages
8. run “make install” from openssh source directory
9. cp opensshd.init to /etc/init.d/sshd
10. add the following chkconfig information to top of ../init.d/sshd file:
# chkconfig: 2345 55 25
# description: OpenSSH server daemon
11. run chkconfig –add sshd

12 create sftponly group
groupadd sftponly

14. edit /usr/local/etc/sshd_config
update sftp subsystem to internal-sftp
# override default of no subsystems
#Subsystem sftp /usr/local/libexec/sftp-server
Subsystem sftp internal-sftp

add section to bottom of file:
Match group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

15. create sftp “jail” directory
mkdir /sftpusers
chown root:root /sftpusers
chmod 755 /sftpusers

16. create sftponly user accounts
useradd -g sftponly -d /sftpusers/user user
mkdir -p /sftpusers/user/data
chown root:root /sftpusers/user
chmod 755 /sftpusers/user
chown user:sftponly /sftpusers/user/data
chmod 700 /sftpusers/user/data
passwd user

user will now have complete control of the data directory, read access to /sftpusers/user, and be unable to cd past the root of /sftpusers/user.