FOSSwire

Accessing your desktop from a remote location is fun. But anyone who wants to protect their data knows that it has to be secure. In a lot of cases, doing this requires configuring an SSH server with X11 forwarding.

Vino, GNOME's remote desktop (VNC) server, is nothing new. It has been around since GNOME 2.8, over three years ago. The only problem with it is the fact that there is slim to no security exposed in the interface. Thankfully, with the release of GNOME 2.22 in a little over a month, we can hopefully stop compulsively worrying about the state of our computers.

The biggest security features are highlighted, with encryption being the key factor here. No longer will you have to tunnel over SSH to set up a simple remote connection, as it is now accessible with a few clicks. And when you are done with your session, you can also have your screen automatically lock to keep others off.

Other notable features include the ability to restrict connections to your local computer, which is probably only useful for a multi-user system, and the option to use another port (security through obscurity).

See also: Part 1.

Welcome back! In the first part of this multi-part tutorial on FOSSwire, I look at some simple ways you can boost your security for the Apache web server. In this part, I'm going to look at securing the OpenSSH server, which is used for remotely logging in to your server.

OpenSSH is pretty secure as it is, but it never hurts to tweak a few settings here and there to make sure the most commonly exploited vectors are covered. So, without further ado, let's jump in and look at what we can do.

1 - Disable SSH protocol 1

This one's a very basic step and one that everyone should be doing. The SSH protocol, version 1, has known insecurities in it and can be a way for someone malicious to get into your server.

There's almost zero reasons why you need to keep allowing the use of protocol 1 on your server nowadays, so disable it.

You'll need to open up your /etc/ssh/sshd_config file in your text editor of choice, and search for the line beginning with Protocol (although it's normally near the top).

The Protocol line should read:

Protocol 2

That means - accept version 2 of the protocol, and nothing else. Save your config file and restart sshd.

2 - Enable key-based logins

Logging in with a password is all well and good, but you can get better security by using a private and public key pair. I've covered how to generate your key in a previous tutorial, so read up on that here.

To enable key-based logins on the server, make sure these directives are set in the configuration file:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Once that's done, you need to copy your key to the server.

3 - Don't enable password-based logins

Further from setting up key-based authentication, you can go the next step, which is to allow only key-based logins. By disabling all password logins, no-one can remotely attempt a brute force attack against any account passwords on your system. The downside is that all users that need to log in need to have a key set up and working properly.

If you're ready to take this step, make sure you can log in with a key properly (so you don't lock yourself out), then set this directive in sshd_config:

PasswordAuthentication no

Save and restart sshd, and anyone without a key gets thrown straight back out.

4 - Don't run on port 22

The default port for SSH is 22. Everyone knows this, which is a bad thing. The potential attacker will go out, and probe as many machines as they can find, to see if port 22 is open. If it is, they'll start knocking.

Even if they don't get in, you can save yourself the hassle, by moving to a non-standard port. Pick a number above 1024, and use that as your port number in the config file. For example, if I want port 1617, I would put:

Port 1617

Now, I just need to remember when connecting to specify the port in what ever software you're using to connect. For SSH's command line client, for example, like so:

ssh -p 1617 myserver

5 - No remote root logins

This one is pretty much common sense. Don't let root log in via SSH. That doesn't mean you can't get root privileges remotely, as it's easy enough to set up a user with permissions to use su or sudo.

Almost every Unix system has the superuser called root, so attackers will use this as a username they know exists on your system, and try to brute force the password.

To deny root logins, set this directive in your sshd_config:

PermitRootLogin no

See you next time!

See also: Part 2.

First of all, I'd like to wish all FOSSwire readers a very happy new year! Hope it's a good one. Now, the task of keeping a server secure can be a difficult one at times. Getting the compromise and balance between security and convenience right isn't easy to do.

In the first part of this multi-part series, I'm going to show you how to lock down your Linux-based server setup and make it a little bit more secure with a few easy, practical steps that you can take. So without any further ado, let's begin.

In this part, I'm going to focus on steps you can take with your web server software. I'll be focusing specifically on Apache, but many of these steps can be adapted for other software.

1 - Hide your exact version number

By default, Apache throws out the exact version number of itself with every reply to every web request that gets to your server. This isn't necessarily a problem, but it does give the potential attacker lots of information about your setup. If they notice your version is out of date, they might be able to exploit a security hole.

To change what Apache, reports, go to the configuration file httpd.conf and change the line starting with ServerTokens. I recommend setting it to Major, so that only the major version of your server software is reported (e.g. Apache/2):

ServerTokens Major

I know, it's security by obscurity - but every little bit helps. It's more important of course to keep all your software up to date with the latest security fixes as soon as they are available.

2 - Don't enable directory indexes

A directory index is a page that appears when you don't have an index.html or other file set for a directory in your web server's root. The index shows anyone out there on the internet all the files in that directory, and allows them to browse through your web server's contents where you don't have index.html files.

There are some occasions when this behaviour is desirable, for example, a download site, but in most cases it can expose things you don't want exposed, so turn them off.

The default setting for directory indexes is in the Options directive of your main Directory tag in httpd.conf.

What that means is that there will be something starting like this:

<Directory "/var/www/html">
Options Indexes FollowSymLinks

You need to make sure the Options line does not include the word Indexes. Also, if you have manually specified Indexes for any other directories your web server is configured to serve, you will need to check there too.

3 - Make sure backup source files don't get served up

If you work directly on your server with some programs and you are editing things such as PHP scripts or other source code that shouldn't be exposed to your users, you might be unaware that those programs are creating backup files.

Backing up is always a great idea, but it's not so great when those backup files could expose your code, passwords and other information to users, or worse, malicious people.

These files usually end in a ~ symbol. For example, a lot of KDE programs will save index.php~ as a backup when you work on index.php. Aside from cleaning up your backup files at all times, you can also make it so that even if you do leave one of these backup files on the server itself, it will be executed rather than dished out as plain text.

With PHP using mod_php, for example, you can set the AddType directive to parse and execute .php~ files.

AddType application/x-httpd-php .php .phtml .php~ .phtml~

If the worst comes to the worst and you leave a backup file in a live directory, all that will happen if someone browses to it will be - it will execute and run as it should do, not giving your code to everyone in the neighbourhood.

4 - Turn off error reporting

If you use a server-side language, like PHP or Perl or anything else, you've got an added layer of complexity where things can go wrong. If something does go wrong when one of your dynamic scripts runs, it's best not to show the world the details about that error.

It could be that error was caused by a malicious person, and the details from that error message could help them to do more bad stuff on your system. So instead of showing error messages, hide them.

Of course, we don't suppress them completely, or that would mean we wouldn't get notified when something breaks. Instead, have them dumped into your log file, where you can check later and fix things knowing that your users don't know all the details about what went wrong. After all, most of them don't want to know, and some of those that do might not have good intentions.

The steps to do this will vary with what server-side technology you're using. With PHP, you need to go into php.ini and make sure you have the following line set to Off, not On:

display_errors = Off

5 - Remain alert

It's common sense, yes, but it's all too easy to fall into a false sense of security and believe everything is fine. You should be aggressively checking log files for errors and suspicious activity and making sure you know exactly what's going on. If you don't, go through and check that everything is in place and how it should be.

Keep passwords and other authentication mechanisms secure and change them often. Know your server inside and out, so that you know when something is wrong.

See you in Part 2!