I’m working on a home server what will be my router, gateway and firewall as well. After the system and daemon installation I have to make the whole system secure. I achieve that with multiple steps, here is a short description how to implement it.

1.) Securing SSH

Later, on the firewall all SSH traffic will be enabled from everywhere. But we have to protect our server, so I made a few changes in the /etc/ssh/sshd_config:

PermitRootLogin no
PermitEmptyPasswords no
AllowGroups ssh-group

The most of the attacks are simple brute force attacks. In the most of the cases, the hackers want to log in with root user. So let’s disable root login.

For the same reason we disable Empty password logins.
Then we should create a group expressly for the SSH, and add the relevant users to it. After that we should limit the SSH access only for this group.

Log in as a user and run “google-authenticator” command to generate the key for this user.

During the key generation type “y” and increase the key availability time.

If the key installed, this will be prompted, together with the scratch keys. Please note these keys to a safe place. In case you loose your phone, or any issue happen, you can use these keys for authentication.

Then open the Google authenticator app on your phone, and type the secret key.
Now you get a constantly changing verification code on your phone.

Last step is to activate the authenticator.

Edit the file /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Add the authenticator to /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes

Finally restart the SSH daemon, and enjoy your new feature.

2. Firewall setup

Strongly recommended to modify the default iptables rules in our system, because it enables everything!

Iptables setup depends on the daemons/services we are running on the server, but I’ve created an example file with some basic services.

I booked an IP range from Hurricane Electric, and I got the IPv6 connectivity to my server.
It’s a free system, where you can book IPv6 address, domain names, and you can learn about IPv6. For more info visit this site: http://he.net/

If you successfully get connected to the IPv6 cloud, you can start to play.
I’ve booked a /48 subnet as well to my LAN devices.

First you have to get the the IPv6 connectivity from HE. It’s only working if you are globally reachable from the internet with the IP protocol 41. So your server have to be the edge of your network of if it’s behind NAT, you have to play with your firewall. If you have a sophisticated one, you can enable on it, but if not, you just need to put your server to the DMZ.

Then you will be able to set up your 6to4 tunnel interface(/etc/network/interfaces):

That will be a little bit bigger topic, what I’ve started today 30.10.2014. I have 1 router, 1AP+switch and 1 Raspberry Pi for the server functions at the moment. I decided to replace these devices with one simple PC. Why? Because it’s easier to manage only 1 device, and it’s much more powerful than the RPI.

So I bring my old PC and put 2 network to the PCI slot of it. The setup looks like:

CPU: DualCore AMD Athlon 64 X2, 2600 MHz (13 x 200) 5000+

2GB DDR2 800Mhz memory

LAN interfaces(2 option):

First time, I’ll have less wired connected device, so no additional switch is necessary. I’ll use 2 PCI Gigabit module, with 2 port on that.(4Gigabit ports)

Later on, if I need more ports, I’ll use a Nortel Baystack425 or a Cisco 3550 (1 Gigabit port to server, 24Fast ethernet for the hosts). Because the uplink is less than 100Mbit we don’t need to use Gigabit interfaces(Just if we would like to copy big files internally)

Some cases, if you are in the workplace for example, you’ll be a part of a fully filtered network, with firewall and IDS-s, and the most of the cases the SSH is not enabled. If the local IT guy are not so clever, they just filter the port 22. In this case it’s easy to connect to your server on a different port.

But when the firewall guys are clever enough to filter the SSH protocol completely, they will kill your connection as well.

Here is a workaround how to use another (encrypted) way to connect to your server.

It’s called shellinabox. It’s a web based SSH access to your server.

Combine it with apache and openSSL, and you will get a secured SSH connection via browser.

With this command, you will create the self-signed SSL certificate and the server key that protects it, and placing both of them into the new directory.

The most important part of the key generation is the “Common Name (e.g. server FQDN or YOUR name)” you should put your domain name or public IP address to this field.

Set Up the Certificate

OK, our new certificates are ready, next step would be to set up the virtual hosts to display the new certificate. Open up the SSL config file:

vi /etc/apache2/sites-available/default-ssl

Within the section that begins with <VirtualHost _default_:443>, quickly make the following changes. Add a line with your server name right below the Server Admin email:

ServerName example.com:443

Replace example.com with your DNS/IP approved domain name or server IP address (it should be the same as the common name on the certificate). Find the following three lines, and make sure that they match the extensions below:

Configure shellinabox

First edit the init.d config file:

vi /etc/default/shellinabox

Add this line to the end of the file:

SHELLINABOX_ARGS="--localhost-only"

It should looks like:

# Should shellinaboxd start automatically
SHELLINABOX_DAEMON_START=1
# TCP port that shellinboxd's webserver listens on
SHELLINABOX_PORT=4200
# Parameters that are managed by the system and usually should not need
# changing:
# SHELLINABOX_DATADIR=/var/lib/shellinabox
# SHELLINABOX_USER=shellinabox
# SHELLINABOX_GROUP=shellinabox
# Any optional arguments (e.g. extra service definitions). Make sure
# that that argument is quoted.
#
# Beeps are disabled because of reports of the VLC plugin crashing
# Firefox on Linux/x86_64.
SHELLINABOX_ARGS="--no-beep"
SHELLINABOX_ARGS="--localhost-only"

Enable some apache proxy modules:

a2enmod proxy
a2enmod proxy_http

Make things easier

Open the following file for editing

vi /etc/apache2/sites-available/default-ssl

AFTER the VirtualHost, but before the end of IfModule put something like this:

I always prefer to use PKI authentication to my devices, if I have a chance to configure that.

Advanatges:

– We don’t have to type password every time, it decreases the risk to type your passwd to the chat window for example.
– It’s much more stronger than the your dog’s name or your date of birth
– Not necessary to change it periodically