Hardening SSH on your Ubuntu Server

Hardening SSH on your Ubuntu Server

Secure Shell (SSH) is an amazing cryptographic network protocol, and it undoubtedly helps secure a huge slice of today’s Internet – giving sysadmins robust remote access to their servers, but also so much much more.

I’ve been using SSH on Linux Servers for longer than I can remember. Well, not quite. I do remember those “telnet” days when nobody had a care in the world, and Edward Snowden was a kid playing video games. Or something.

I’ve learned a thing or two about hardening SSH and locking it down, including generating certificates, and using it as a remote proxy in all kinds of ways. Here is a brief brain dump that I hope you enjoy.

General SSH Configuration Tips

Configuration of SSH starts with the sshd_config file.

sudo nano /etc/ssh/sshd_config

Change the Default Port

The first is the “Port 22” default that SSH listens on; I will usually change this to a different number other than the default, or run it on multiple ports depending.

# What ports, IPs and protocols we listen for
#Port 22
Port 2222

If you don’t change the port from 22 you’ll just be subjecting yourself to endless probes and brute-force logins from everywhere. While changing to something else is not guaranteed to stop any of that, in my experience it will reduce it. A lot.

Ensure you’re using Protocol 2 (SSH2)

The second thing to check, particularly if you have an older Linux server is the version of the SSH Protocol – the line “Protocol 2” does that. Ensures you’re using SSH2 which is far superior that earlier versions of the protocol and shouldn’t be an issue today.

Protocol 2

Don’t Permit Root Login

I’m a strong advocate of always connecting to a server using my own account, and if I need superuser access I’ll “sudo” to get it. This means there’s never a valid reason ever to login as the root user.

Unfortunately, some of today’s cloud VPS hosting providers will provide you with a root login straight away. Um, no thanks.

PermitRootLogin no

Turn Off Password Authentication (if using Certificates)

If you’re using certificate based authentication (which I highly recommend – here’s some useful information on that) you’ll want to turn off any kind of password authentication, by locating and modifying the lines below to “no”.

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Restrict to Known Users

Another thing you can do, which I think a lot of people never bother doing, but might be useful, is to restrict SSH access to certain known users on the system. Even with the right password or certificate a user not in this list (if the setting is present) will not be able to login.

AllowUsers john bob alice

Using the “AllowUsers” setting could be vital if your server is hacked and somebody tries to create a backdoor user – at least this will prevent them getting any remote access, and the failed attempts may show up in your log files.

Disabling Potentially Compromised Modulus

There is some conjecture that the NSA (and others?) could intercept TLS and SSH communications by obtaining the shared private key during the “Diffie Helman” key exchange process.

The speculation about this weakness with DHE is potentially feasible. The concern is that there exists the ways and means through supercomputing power to factor the large primes commonly used for DHE.

Here’s one example news story suggesting it’s possible, which led me to researching and discovering some practical hardening tips here that I’ve refined a little further.

You’ll have to edit the moduli file:

nano /etc/ssh/moduli

Comment any lines that have a value less than 2047 shown in the 5th field on each line – and then don’t forget to restart the SSH service.

I’ve also made this SED one-liner below that you can run as root which will comment out the lines mentioned in one hit as well.

sudo cp /etc/ssh/moduli /etc/ssh/moduli.bak
sudo sed -r -e '/[[:space:]](1023|1535)[[:space:]]/ s/^/#/' -i /etc/ssh/moduli

Restarting the SSH Service

If you’re connected to a remote server via SSH already, and you’re editing the sshd_config there is a real risk that you could inadvertently cut yourself off if you get something wrong.

The biggest tip I can give you is to NEVER logout from any existing sessions until after you have verified your new SSH config is working.

systemctl restart sshd

After you have restarted SSH, try a new connection to the server and if successful everything is fine. If you have any problems, you’ll need to go back to your existing logged in session and fix up the sshd_config (check the log files for reasons why if not clear). You’ll then need to repeat and restart the SSH service until you can login with a new session.

I hope these tips help you secure your SSH server, and until next time, stay safe out there.

 

AusCERT2016 CTF – 10th Place!

I recently finished competing in the AusCERT2016 Capture the Flag (CTF) challenge which ran for 48 hours. Coming in 10th place from dozens of active participants was very rewarding!

auscert2016_ctf_scores

I entered under the team alias “InsertCoin“- partly to protect myself if I performed terribly(!) but also because I’m currently looking for new work opportunities – and the name subtly describes my current state-of-mind 🙂

Capture the Flag competitions work by having people (usually teams) compete to carry out tasks in a limited time with the goal of finding a “flag” for each challenge.

A CTF flag is a string of text that is hidden or concealed in some way – you’ll only get it by solving a problem, hacking a system, decrypting something and so forth. There are many different types of challenges, and the problems can range from ridiculously easy to virtually impossible.

As is standard for most CTF challenges, in the AusCERT2016 challenge competitors had to find flags formatted in a special way – in this case:

flag{something_here_different_for_every_challenge}

The format of the flag is really important. Flags are like passwords and have to be entered precisely into a scoring website, otherwise you don’t get the points added to your score.

But knowing what a flag looks like also means you know roughly what you’re looking for, and this can come in handy! For example, looking for the letters f, l, a, and g to make the word “flag” means you’re probably looking in the right place; and can be a time saver.

Solving the challenge: “Law”

Let me be clear – this “Law” challenge was about as easy as a CTF challenge can get – but I’m writing this up because of how I’ve seen some other people attempt to solve it; and the different approaches you could use. Some good, some not so good.

The “Law” challenge begins by downloading a given Word Document. Have a look at the document below and see if you can identify what’s happening.

Law

It’s pretty easy to see something odd with the capitalisation of the letters. Look closely at the first line and you might see something familiar if you concentrate on those capitals.

… enForced … sociaL … behAvior.G{2] …

Oh, yes.. FLAG{ ..surely the beginning of the flag we’re looking for.

At this point, there’s a burning question that every CTF competitor asks themselves:

“What’s the easiest AND fastest way I can solve this problem?”

This is always the juncture point during a CTF where my heart skips a beat, and I feel the adrenalin rush. If you’ve ever participated in a CTF you’ll know what I mean! It’s that point where the only thing that sits between you and the answer is the HOW & TIME.

How? Here’s some of the instant choices of tools/approaches that sprung to mind:

  • [1] Use a feature built-into Word, like find/replace to remove lowercase letters, or extract the capitals or similar; or
  • Extract the text from Word and do this somewhere else, probably on a Linux box…
    • [2] Write a script or something to parse the text and give me what I want; or
    • [3] Rely on some command-line-kung-fu to extract and explore what I need

To be honest, staying in Word really didn’t enter my mind. I’m sure there are features that might do what we want, and if you’ve got suggestions please do leave a comment below and tell me, but prove to me your way is faster also).

So, this story is really about the last two options only: write a script, or do kung-fu.

If you know how to do kung-fu, is there ever any other option? No.

Be patient Grasshopper, we’ll get to the Kung-Fu part, but first what really intrigued me was the day after I had solved this challenge.

While attending a local SecTalk meetup I met some other competitors who were also attempting this same CTF challenge, so I quizzed them on how they were going about solving it…

Surprisingly, one of them had written a Python script to solve this!

My. Mind. Was. Blown. A Python script to solve THIS? Knowing how I had solved it (as you’ll see below) no doubt biased my judgement, but I just felt like using Python (or in fact anything other than a single command-line) was a heavy handed, and slow.

I didn’t look at the actual Python script, but if I had attempted such a thing it would have probably looked like this…

law-python

It outputs like this:

F
L
A
G
W
H
A
T
... and continues down the screen like that.

Sure, I could import sys and use sys.stdout.write() to fix that, but using Python isn’t the focus here.

Command-Line-Kung-Fu

On the command line, this is how I solved this “Law” CTF challenge on one line:

grep -o '[A-Z]' law.txt | tr -d '\n'

That’s simply grep with the -o option to only return uppercase ‘[A-Z]’ piped through the tr command to delete -d any newlines ‘\n’

Output:

FLAGWHATWOULDAREASONABLEANDPRUDENTPERSONDO

Converting that to lowercase and inserting the { and } in the right places gave me the flag.

flag{whatwouldareasonableandprudentpersondo}

The magic of grep -o

I suspect that some people may not be aware of the -o option for grep which only returns the text that matches the given regular expression. This is great for extracting all sorts of things from files, such as domains, email addresses and all sorts of things.

And the power of tr (translate)

There’s another way of doing this also, without using grep at all, which is to only use tr which is the “translate characters” command. In this case we can start by deleting -d lowercase ‘[a-z]’ characters.

cat text | tr -d '[a-z]'

This gives one advantage of being able to see the whole file quickly, having removed only the lowercase chars, and we see the flag beginning to emerge. By repeating this process and eliminating characters one-by-one this technique can come in handy in other challenges.

prudent-using-tr

Once your brain has worked out which characters to remove, after a few iterations you get to the final result.

cat text | tr -d "\-\"\”[a-z][0-9]:'., ()\n"

Output from this is the perfect flag that just needs to be converted to lowercase:

FLAG{WHATWOULDAREASONABLEANDPRUDENTPERSONDO}

As you can see there are many different ways to solve this challenge, and each to their own. But when time is against you in these challenges you have to make sure you’re picking the fastest method possible!

Until next time, stay safe out there – and may your flags all come to you easily!

Huntercoin node on Ubuntu 16.04

Huntercoin node on Ubuntu 16.04

Following on from some recent research into Cryptocurrencies, I’ve been looking at the somewhat unique Huntercoin. It claims to be a so-called “human mine-able” cryptocurrency.

I’m not so much interested at the moment in actually playing what I presume is some kind of online game for mining the coins, as I see there is a core peer-to-peer client that can run on Linux, and I presume is a fork of Bitcoin anyway.

As with many of these emerging altcoin projects, this one too has a very sketchy compile guide, and since my preferred OS is Ubuntu 16.04 LTS Server 64-bit there’s unlikely to be anything else as up to date as what I’m about to leave right here.

Initial requirements

I’m starting with a fresh Ubuntu 16.04 Server running on VMWare hypervisor, in my case a standard 2 x CPU, 2048 Gb RAM, 48 GB HDD spec machine.

Whatever hardware you choose is up to you, if you just run the huntercoind just to keep a full copy of the blockchain and maybe even do some transactions, you’ll get by with any old machine.

I’m not doing any mining here, so I don’t have any advice for running GPU’s or anything like that.

Anyway, my new Ubuntu server is just a straight default install with only OpenSSH added to begin with, and set a static IP address because I’ll be port forwarding from my firewall later, and I do the usual updating things like:

sudo apt-get update && sudo apt-get -y upgrade && sudo reboot

Now to get started…

Step 1. Install required libraries

While getting Huntercoin up and running for the first time, I made careful note of all the required libraries you’ll need for a successful build – here they are:

sudo apt-get install build-essential libssl-dev libboost-all-dev

And there are a couple more, this next one took me a while to find for Ubuntu 16.04 when I kept getting this compile time error:

/usr/bin/ld: cannot find -lgthread-2.0
collect2: error: ld returned 1 exit status
Makefile:118: recipe for target ‘huntercoind’ failed
make: *** [huntercoind] Error 1

This error had me searching high and low for ‘gthread’ and ‘libg’ and all sorts of things, and even ‘libqt4-dev’ (but I hate installing that one because of all the X11 dependencies) until I found this:

sudo apt-get install libglib2.0-dev

This next one is also required, “libdb” which is actually the Berkeley DB library.  When compiling bitcoin-core and other forks of bitcoin this one can be a problem and you need to use the older 4.8 version – but installing this one (which is 5.3 in Ubuntu 16.04) appears to work just fine.  It you are wanting to move any *.dat files between systems though, this might be an issue (I explain more about this in my Namecoin build).

sudo apt-get install libdb++-dev

Step 2. Download the huntercoin source

Now it’s time to fetch (or should I say clone) the latest source from the Github repository.

cd ~
git clone https://github.com/chronokings/huntercoin.git

Because I’m using a dedicated machine only for Huntercoin in this case, I’m not going to bother moving the source to somewhere like /usr/src or /usr/local/src as I know some people like to do.  It just sits in my home folder on this server.

You should end up with something like this.  In the /src folder is where we’ll be building.

huntercoin_dir

Step 3. Compiling huntercoind

You’ve done all the groundwork, now it’s time to build!

cd ~/huntercoin/src
make

That’s pretty much it, there is not “make install” like you might expect, so to make the shiny new huntercoind binary (mine was version 1.3.01) available I did this.

sudo ln -s ~/huntercoin/src/huntercoind /usr/local/bin/huntercoind

Step 4. Test huntercoind

You should now be able to start the huntercoind in daemon mode with:

huntercoind -daemon

Unlike some other crypto core clients, this one doesn’t seem to mind running without any configuration file at all, and it will happily start up.

You can check the progess of what it’s doing with:

tail -f ~/.huntercoin/debug.log

(Use Ctrl+C to exit it)

Feel free to have a look at some of the other commands you can issue.

huntercoind help

Once it has created the .huntercoin file in your home directory, I would recommend stopping it gracefully and downloading the blockchain in advance to same some time.

huntercoind stop

Step 4. Download blockchain (optional)

Your hundercoind core client is going to take a while once you fire it up as it begins to ask the peer-to-peer network for all the blocks in the blockchain. This process can literally take days.

My up and running Huntercoin client has around 12 GB of blockchain data in the ~/.huntercoin/ folder to give you some idea. Letting your huntercoind client retrieve this in many individual P2P requests is inefficient (but arguably more failsafe from a security point of view if you’re really paranoid).

So, if you want to shortcut this process you can download an archive of the blockchain database in advance from here: http://chain.huntercoin.org/

 

huntercoin-huc-zip

I can’t speak for the legitimacy of it, so make sure you follow the instructions and check the SHA256 hashes that have also been signed with a PGP key.

Once you have downloaded the zip file, simply unzip all the files into your .huntercoin folder and overwrite any other files.

Step 5. Port forward at your Firewall

If you’re doing this from a standard home gateway/router chances are this has been taken care of via the UPNP protocol, but if not you’ll need to port-forward TCP externally on Port 8398 to the internal IP of your Huntercoin box.

I’ll leave you with the rest, feel free to comment below.  Happy Hunting. Or something.

Building a Namecoin server with Ubuntu 16.04

Building a Namecoin server with Ubuntu 16.04

In what has turned out to be an in-depth look at multiple cryptocurrencies recently, I’ve been having a deeper look into Namecoin.

This research has meant having to spin up test virtual machines and since Ubuntu 16.04 is my server OS of choice (the 64-bit LTS server version) here’s how I’ve setup a Namecoin node.

Your results may vary, and I make no promises or guarantees on the outcome of these steps, other than to say it worked for me.

Initial requirements

You’ll need to start with a freshly installed Ubuntu 16.04 LTS 64-bit server (in my case running on a VMWare hypervisor with 2 x CPU, 2048 Gb RAM, 48 GB HDD; hardware/platform is up to you).

I simply installed it from scratch, creating a user account for myself, changed the IP address to a static configuration (I have instructions for that here) and also did a full update and reboot.

sudo apt-get update && sudo apt-get -y upgrade && sudo reboot

The steps following assume you have SSH’d into the box (or at the console) using your own account.

Although I do have a bad habit of using “sudo -i” to get a root prompt, when it comes to building projects from source code I always stick to using my own account.

Step 1. Install required libraries

There are a bunch of packages you’ll need to install, the most important of which begins with all the essential build tools included in the “build-essential” package.

sudo apt-get install build-essential

Then there are a bunch of other packages you’ll need later on, I compiled this list from trial-and-error the first time I did this.

sudo apt-get install autoconf libtool pkg-config
sudo apt-get install libboost-all-dev libssl-dev libevent-dev

Step 2. Download the namecoin-core

cd ~
git clone https://github.com/namecoin/namecoin-core.git

This will retrieve a clone of the git repository that contains the latest version of the namecoin-core project.

I simply run this from my home folder and it creates a namecoin-core/ folder in my home directory.  I know some people like to put source code into /usr/src and other such places, but since this is a single purpose built test-server I don’t bother.

We’re not going to do anything with this just yet, but you’ll need it in the next step.

Step 3. Getting BerkeleyDB 4.8 libs

This was a stumbling block that I encountered caused due to Ubuntu 16.04 being so new. I kept getting this error during the configuration of the namecoin build.

If you have no version of Berkeley DB installed:

checking for Berkeley DB C++ headers… no
configure: error: libdb_cxx headers missing, Namecoin Core requires this library for wallet functionality (–disable-wallet to disable wallet functionality)

Or if you’ve somehow already installed libdb++-dev (or libdb5.3++-dev) which you’ll need to apt-get remove to proceed further:

checking for Berkeley DB C++ headers… default
configure: error: Found Berkeley DB other than 4.8, required for portable wallets (–with-incompatible-bdb to ignore or –disable-wallet to disable wallet functionality)

Let me quickly explain what this is all about.

Namecoin, like Bitcoin, provides a wallet for your coins. This functionality is provided by storing encryption keys in a special file called “wallet.dat” – which is a Berkeley DB file (a type of file-based database), and in the early days of Bitcoin it was the 4.8 library version that was originally used.

The problem is that Ubuntu 16.04 is created to only provide a package for the Berkeley DB library 5.3 and while this would normally be fine, it means your wallet.dat file would not work on other systems if you were to move it elsewhere.

Once a Berkeley DB file (i.e. wallet.dat in this case) is accessed by a program using a later version of the Berkeley DB library the file being accessed is upgraded automatically – and the file can never be converted back to the previous version. Hence, most wallet.dat files are using 4.8 so we should probably stick to that for peace of mind.

The solution at it turns out isn’t that hard, like most things when you eventually find the correct answer!

wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz

If this download doesn’t work, maybe visit the Oracle website and find the link that does.

tar xzvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC/build_unix/
../dist/configure --enable-cxx
make
sudo make install

My sincere thanks to the discussion on this Github page for the steps above.

In addition to compiling and installing the Berkeley DB 4.8 lib, I still had issues and had to create the following symbolic links so the headers and lib files could be found. Thanks to the thread here for that.

sudo ln -s /usr/local/BerkeleyDB.4.8 /usr/include/db4.8
sudo ln -s /usr/include/db4.8/include/* /usr/include
sudo ln -s /usr/include/db4.8/lib/* /usr/lib

Once you have compiled and installed the Berkeley DB 4.8 library from source, you now need to edit a file in the namecoin-core source to help it find the header files that are needed for the compile of Namecoin.

cd ~/namecoin-core/
nano build-aux/m4/bitcoin_find_bdb48.m4

Look for the line starting with bdbdirlist= and add the full path to that /build_unix/ folder from earlier. In my case it was in /home/mjm/db-4.8.30.NC/build_unix but it will no doubt be different for you.

bitcoin_find_bdb48.m4

Step 4. Compiling namecoin-core

Now we being with the build of the namecoin-core binaries.

cd ~/namecoin-core/
./autogen.sh
./configure
make
sudo make install

Note that these steps may take some time, especially the make command above – it took about ten minutes or so for me.

Once this is complete you’ll have the following files in your /usr/local/bin/ ready to go.

  • namecoind
  • namecoin-cli
  • namecoin-tx
  • test_namecoin
  • bench_namecoin

You’ll want to start up namecoind to run in the background and in a separate article I’ll cover the best-practice of using systemd to keep that up and running in the background.

You should also create a separate ‘namecoin’ user with less privileges to run the namecoind daemon.

Hopefully this has been some help to you.