Category Archives: Cryptography

Change the default SSH port and alter SELinux context to match

Security through obscurity is not something one would generally recommend. But to thwart the effort of automated scanners changing the default OpenSSH port will yield you less pain in every day life. This will not fend off directed attacks or nullify vulnerabilities or bad security design.

Should you see an error message such as

shd[14221]: error: Bind to port 9898 on 192.168.0.50 failed: Permission denied

it indicates that the system prevented the daemon to bind that port. Most likely SELinux.

The instructions provided will be valid on Fedora 14/15, CentOS 6, RHEL 6, Scientific Linux 6 and newer versions.

To change the default SSH port you need to do the following.

  • Stop the SSH daemon
  • Alter the /etc/ssh/sshd_config with your new port
  • Alter the SELinux context with semanage
  • Start the SSH daemon

Stop the SSH daemon

# service sshd stop

Alter the /etc/ssh/sshd_config with your new port

Alter the configuration file with your favorite editor, in my case “nano”.

# nano /etc/ssh/sshd_config

Alter the port configuration parameter change the following line

Port 22

to

Port 9898

Alter the SELinux context with semanage

# semanage port -a -t ssh_port_t -p tcp 9898

Initially you would think the following would work. But it will not. For it to work you would have to alter the policy in the selinux-policy package, rebuild and install it. So skip it, but now you know why.

# semanage port -d -t ssh_port_t -p tcp 22

Start the SSH daemon

# service sshd start

// CrashMAG

Self-signed certificate for Apache

These instructions are distribution agnostic. However I used CentOS during my tests, so file paths will match that of CentOS, RHEL, Scientific Linux and Fedora. For any other distribution you’ll have to look that up yourself.

The tools required are OpenSSL, Apache and mod_ssl for Apache. To accomplish this I had to run

# yum install mod_ssl

on my CentOS 5.6 box. Which already had Apache up and running.

Setting up a self-signed certificate using certificate and key

Generate your key and certificate

Most of these parameters explain themselves, see beneath for those who do not.

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout website.key -out website.crt

-nodes
don’t encrypt the output key
-x509
output a x509 structure instead of a cert. req.

Copy the key and certificate

# cp website.key website.crt /etc/httpd/conf/

Set permissions and ownership on your key and certificate

This way nobody except root has read access.

chmod 440 /etc/httpd/conf/website.key /etc/httpd/conf/website.crt
chown root:root /etc/httpd/conf/website.key /etc/httpd/conf/website.crt

Alter the apache configuration file, also known as httpd.conf

Edit /etc/httpd/conf/httpd.conf with your favorite text editor, in my case, nano. Add the following text at the bottom of the file.

      <VirtualHost *:443>
        SSLEngine on
        # Change the next two lines according to where you've actually
        # stored the certificate and key files.
        SSLCertificateFile /etc/httpd/conf/website.crt
	SSLCertificateKeyFile /etc/httpd/conf/apache2/website.key

        ServerName domain.tld
        SSLOptions StrictRequire
        SSLProtocol all -SSLv2

        DocumentRoot /path/to/ssl/enabled/site
        <Directory /path/to/ssl/enabled/site/>
          SSLRequireSSL
          Order Deny,Allow
          Allow from All
        </Directory>
      </VirtualHost>

StrictRequire
This forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a “Satisfy any” directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that’s how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an “SSLOptions +StrictRequire”. Then an additional “Satisfy Any” has no chance once mod_ssl has decided to deny access.

Enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2

Setting up a self-signed certificate with the certificate and key in one file

Generate your key and certificate

Most of these parameters explain themselves, see beneath for those who do not.

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout website.pem -out website.pem

-nodes
don’t encrypt the output key
-x509
output a x509 structure instead of a cert. req.

Copy the key and certificate

# cp website.pem  /etc/httpd/conf/

Set permissions and ownership on your key and certificate

This way nobody except root has read access.

chmod 440 /etc/httpd/conf/website.pem
chown root:root /etc/httpd/conf/website.pem

Alter the apache configuration file, also known as httpd.conf

Edit /etc/httpd/conf/httpd.conf with your favorite text editor, in my case, nano. Add the following text at the bottom of the file.

      <VirtualHost *:443>
        SSLEngine on
        # Change the next line according to where you've actually
        # stored the certificate and key file.
        SSLCertificateFile /etc/httpd/conf/website.pem

        ServerName domain.tld
        SSLOptions StrictRequire
        SSLProtocol all -SSLv2

        DocumentRoot /path/to/ssl/enabled/site
        <Directory /path/to/ssl/enabled/site/>
          SSLRequireSSL
          Order Deny,Allow
          Allow from All
        </Directory>
      </VirtualHost>

StrictRequire
This forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a “Satisfy any” directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that’s how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an “SSLOptions +StrictRequire”. Then an additional “Satisfy Any” has no chance once mod_ssl has decided to deny access.

Enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2

// CrashMAG

Public key authentication with SSH. Both with and without a password.

This article will run through quick and easy examples for setting up public key authentication with SSH. I will include one example that requires a password and one that does not. Typically used for scripts.

I will assume you know why you want to either use the one or the other. Public key authentication can only be set up on a per user/system basis, keep that in mind.

Public key authentication without a password

This the least secure option. It all boils down to how well secured your private key is. (.ssh/id_dsa)

  1. Create a key pair. (Private & public key)
  2. Copy the public key to the remote system.
  3. Log on the remote system.

Create a key pair

[user@localsystem ~]$ ssh-keygen -t dsa

Here’s what you’ll see when you run through this procedure. (“Press [ENTER]” are my comments)

[user@localsystem ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER]
Created directory '/home/usr/.ssh'.
Enter passphrase (empty for no passphrase): Press [ENTER]
Enter same passphrase again: Press [ENTER]
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem
The key's randomart image is:
+--[ DSA 1024]----+
|       .o..      |
|       o+o .     |
|      ..*..      |
|       = o       |
|      . E        |
|       *         |
|   .  o o        |
|  . .+.+         |
|   ...*+.        |
+-----------------+

Copy the public key to the remote system

[user@localsystem ~]$ ssh user@remotesystem

If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.

[user@remotesystem ~]$ mkdir .ssh
[user@remotesystem ~]$ touch .ssh/authorized_keys
[user@remotesystem ~]$ chmod -R u=rwx,go= .ssh
[user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys

Enter your password when asked, and you’re done.

Log on the remote system

[user@localsystem ~]$ ssh user@remotesystem

Public key authentication with password

This is the route you want to go. Once done, you should also disable logins with passwords only. Do this by editing the /etc/ssh/sshd_config file and add/modify the following parameter “PasswordAuthentication no”. Also make sure “PubkeyAuthentication” is set to “yes”.

  1. Create a key pair. (Private & public key)
  2. Copy the public key to the remote system.
  3. Log on the remote system.

Create the key pair

[user@localsystem ~]$ ssh-keygen -t dsa

Here’s what you’ll see when you run through this procedure. (“[Your Password]” and “Press [ENTER]” are my comments)

[user@localsystem ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER]
Created directory '/home/usr/.ssh'.
Enter passphrase (empty for no passphrase): [Your Password]
Enter same passphrase again: [Your Password]
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem
The key's randomart image is:
+--[ DSA 1024]----+
|       .o..      |
|       o+o .     |
|      ..*..      |
|       = o       |
|      . E        |
|       *         |
|   .  o o        |
|  . .+.+         |
|   ...*+.        |
+-----------------+

Copy the public key to the remote system

[user@localsystem ~]$ ssh user@remotesystem

If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.

[user@remotesystem ~]$ mkdir .ssh
[user@remotesystem ~]$ touch .ssh/authorized_keys
[user@remotesystem ~]$ chmod -R u=rwx,go= .ssh
[user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys

Enter your password when asked, and you’re done.

Log on the remote system

[user@localsystem ~]$ ssh user@remotesystem

Tip

You can later change the password for your keys by using

[user@localsystem ~]$ ssh-keygen -p

// CrashMAG

Storing your data safely using Dropbox and TrueCrypt

The idea is simple, combine both the ability to store data in the cloud with cryptography. In an easy and manageable way. Which you can use on any system you might own, and by any, I mean Windows, Linux and OSX.

Two products are involved to accomplish this in a truly secure manner.

  1. Dropbox
  2. TrueCrypt

By default Dropbox will set itself up as a folder in your home directory. Be it “My Documents” on Windows, your home folder on Linux and OSX. From there on once you drop files into that folder it syncs with the Dropbox backbone. (Amazon S3).

It will still be available on your local drive as well. Even though Dropbox says:

All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.

there’s still the possibility of the unknown. Even if the data stored in the cloud should be safe, there’s still the issue about local access.

Enters TrueCrypt. An open source and easy to use cryptography software package. We will create a volume, a file container that we will store in our Dropbox folder and mount as a usable drive.

Once it’s created you can mount it using the password you chose, and start using it to store data. Dropbox will allow up to 2GB of free storage.

I personally use this for everything I store in plain text.

// CrashMAG