Thursday, October 23, 2014

What do I do when I get a new server? A bare-bones simple guide to starting up a secure-enough server.

Lets say I spin up an instance in AWS, or Linode, or install a new OS in a VM at home to be a server of...anything. Each time it's a little bit different, but generally its Linux, although much of this applies to BSDs as well. This is assuming you know how to connect to your machine and have setup a non-root user and strong password for that account.

Step 1
If I can, encrypt the disk. On AWS this is already the case and they have solid disk-erasing as far as I know (TODO: link to the blog/whitepaper where researchers found a bug and amazon fixed it platform-wide afaik). On Ubuntu this is baked into the install script, which you'll probably have to run yourself since most automated/one-click/prepackaged ones don't do it for you.

Step 2
See what's running on the system and listening on the network and kill anything unnecessary. I run ps -ef (process list), top/htop (resource usage), and netstat -ant (network listeners) to do this. FTP doesn't need to be on. It is negated in necessity by the next step.

Step 3
UPGRADE ALL THE THINGS!! This should already be done, but sudo apt-get update && sudo apt-get upgrade -y will be sure you have everything on Ubuntu.

Step 4
Once done installing, use SSH as the sole means of communication and disable root logins.
4.1 Disabling root logins:
4.2 Use ssh-copy-id to get your key trusted by the server.
4.3 Test that sftp is configured. This way you have both SCP and SFTP as options for moving large numbers of bits to/from your server.

Step 5
Install fail2ban: http://www.fail2ban.org/wiki/index.php/Main_Page
-- I'm pretty sure this is in Ubuntu and many other Linux package repos by default, so sudo apt-get install fail2ban should work.
5.1 I up my failed connections form a single IP to 6 from the default of three because sometimes I make bad mistakes.

Step 6
Increase auditing from Ubuntu's default of holding it monthly to hold a year's worth of audit logs on logins and other helpful stuff.

Step 7
After I'm happy with the server's setup I install google-authenticator for 2 factor authentication by following the short steps I detailed in a previous post here: http://fiascoaverted.blogspot.com/2014/03/configuring-two-factor-authentication.html

At this point all you should only need TCP port 22 listening on the network. If you want to keep your log attempts quieter, you can change SSH to listen to an alternate port, like 2222, but this is security through obscurity and only possibly protects you from major stupidity.

From here I install whatever the server needs. This post was how to get me to a clean, safe state, from here I start adding/enabling more stuff until the server is ready.

NFSShell

How to build NFSShell on ubuntu:

wget http://www.cs.vu.nl/pub/leendert/nfsshell.tar.gz
cd nfs/
comment out lines 25-28 #this disables solaris specific compilation
uncomment lines 36-38 #this makes it work on linux
#not sure if the following command is necessary:
sudo apt-get install libtirpc-dev libncurses-dev
make
./nfs

The line numbers and stuff should Just Work(tm) since this is based off of the nfsshell from 1998.
Most that say they add nfsv3 support are broken and break some nfsv2 according to a friend, so they are not included here.

I should fix this up with a script later. And will add it to my github.



Sunday, March 23, 2014

Configuring two factor authentication using google-auth for SSH on Ubuntu 13.10

This is really simple, shouldn't take more than 2 minutes and only has 5 steps (read all of this):
Mostly taken and condensed from: http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/


  1. Install the package: sudo apt-get install libpam-google-authenticator
  2. Edit /etc/pam.d/sshd to have the line: auth required pam_google_authenticator.so
  3. Edit /etc/ssh/sshd_config to have the line: ChallengeResponseAuthentication yes
  4. Make sure you're no longer sudo'd or running as root and that your're whatever user you want to log in as and run google-authenticator from your home directory. Be sure to take down the secret, scratch codes, and/or the QR code.
  5. sudo service ssh restart
Now you should be good to go.

In Ubuntu 13.10 for step 2, there will not be that line already in the file.
For step 3, ChallengeResponseAuthentication will be set to 'no'. Just change it to 'yes'.


No promises for other linux distros, but the above should work. If it doesn't you'll have to grab source and compile from the google-authenticator project on google-code.

Note: if you don't even want to have to enter the password (seriously stupid, but could be fun for a CTF or for learning purposes) comment out the following line in your /etc/pam.d/sshd file: @include common-auth

This was the first line of code in my sshd file and the helpful comments explain that it controls "Standard Un*x authentication". Fun stuff. For the love of all that is bacon and blue skies, don't do this in prod unless you're using a different auth mechanism in addition to 2FA.


Next up, google-auth for open-vpn.

Monday, February 17, 2014

MD5 and other useful stuff in powershell

Lots of posts coming up shortly, anyway recently I was reading about how OTA updates for CyanogenMod run over plaintext HTTP and don't sign their binaries. Lame. The MD5sum it, and send that over the same plaintext channel, so trivially mitm'able, like evilgrade.

Shortly after reading this, I downloaded an update for CCleaner, which came plaintext from filehippo and decided that I should check its hash. The hash offered is MD5, which while it has collisions, my current understanding is that it takes about a day with a bunch of PS3s in a cluster to make an known good hash collide with a malicious binary. Anyway, with nothing else offered as a reasonable hash for this file, I set out to compare the known hash with the binary's hash.


Previously I've used the Microsoft File Checksum Integrity Verifier utility, but I'd rather have it more smoothly integrated into PowerShell since I'm learning that currently.


I want to find a good powershell way of doing this and here was my thought process:


PS> Get-Command -Name *md5*
--no results

PS> Get-Help *md5*
--nothing

PS> Get-Help *hash*
--nothing useful

Ok, on to the googles.
First hit for "powershell md5": http://stackoverflow.com/questions/10521061/how-to-get-a-md5-checksum-in-powershell

Bingo. A few different methods, and I tried two of them:

Method 1:
$someFilePath = "C:\foo.txt"
$md5 = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$hash = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($someFilePath)))
This initially gave me an error because I used a relative path for my file (I was currently in my Downloads directory, and did ".\foo.exe" instead of the full path starting with "C:\". After fixing this, it returned a match to the hash provided by filehippo (which of course is also provided via plaintext, so...shit). 
Method 2: 
Install the Powershell Community Extensions (http://pscx.codeplex.com/), which also feature useful commands such as base64 encoding and decoding, gzip/bzip/tar/zip archive support, set/get-clipboard, tail, and get-httpresource, a nice package.
I was all set to dig into my profile and set that up, but it comes prepackages in an MSI that is pretty much a single-click install. 
Both worked.
Looked into it and I couldn't get an HTTPS connection to download the file without cert errors. Found this forum post which mentions that filehippo publishes the MD5sum, that the files are Verisign signed (good deal) and that piriform (the authors of CCleaner) and filehippo are the preferred download methods: http://forum.piriform.com/?showtopic=23834


Checking the signature:
GUI method: 
Find executable in Windows Explorer (not Internet Explorer) > right click > Properties > Select the Digital Signatures Tab > Select the only option there (Should say Piriform Ltd, which is something of a check) > Details 

At this point you see the message "This digital signature is OK" which is a level of assurance. If you wanted to, you could check out its certificate against...I'm not quite sure, but would look for a list of published code signing certificates to see if MSFT has them. Additionally, its countersigned by Symantec for a specific timestamp, which is nice, and Symantec is pretty legit, again, presumably this can be looked up, but I'm assuming that it's in the Windows Certificate Store, and can look that up to prove it as well.

Or using powershell:

PS> Get-AuthenticodeSignature .\ccsetup410.exe
SignerCertificate                        Status  Path
-----------------                        ------  ----
46EE5C92C7BCD7B2D2E937DCD1FB9FDA30D1E753 Valid   ccsetup410.exe