Securing Ubuntu 14.04 on DreamCompute



Ok so I’m really curious about securing Ubuntu. I’ve deployed rails apps and none of the tutorials talk about installing firewalls and what not. For my current project I will be using Ghost blogging software which runs on node.js. One of the tutorials has a lot of information regarding security. I was wondering how valid these security measures are on DreamCompute.


Steps to Take

SSH Hardening - disable root login and change port - I don’t think we need to do this since it’s already taken care of for us, correct? This is why we use keys with dashboard and have to login not using root. Am I understanding this correctly? When I follow the instructions and make user use 1010 I time out trying to connect and still connect the same way without defining a port to log into.

Install and configure Firewall - ufw
Is this something I should be doing on all of my projects? I’m really new to this and am happy to configure a firewall. I tried it yesterday without much luck but I’ll give it a whirl again today.

Secure shared memory - fstab
Protect su by limiting access only to admin group
Do I really have to do these two steps on this platform? How come in rails tutorials it’s never been expressed before?

Harden network with sysctl settings
How useful are his edits on dreamcompute? Is there things we can do without? Maybe some rules are very necessary but which ones?

Scan logs and ban suspicious hosts - Fail2ban.
Fail2Ban so far is working fine. It wasn’t a debug error. it just calls itself an ‘authentication failure monitor’

i officially can’t get fail2ban to work. I’m going to have to look for it’s log fails and find out why it’s giving me authentication failure monitor

The NGINX file is very detailed as well. Any comments, feedback and guidance would be greatly appreciated. I just want figure out what the best way is to setup a stack for ghost on dreamcompute. i’m tracking my findings so I can share the data later in a blog article or whatever.

Locked out of DreamCompute instance, laughing at my own ignorance

By default access is already pretty restricted on DreamCompute. I’ll go through some of your examples:

SSH hardening - By default we disable password login in /etc/ssh/sshd_config, so only ssh keys can be used. That is already a huge security help, and while the SSH port can be changed we don’t do this by default. To change it edit /etc/ssh/sshd_config and change the Port value, then restart ssh with “service ssh restart” (depending on OS).

Firewall - Security groups are already a kind of firewall, and by default only allow port 22, 80, 443 and ping. A firewall to block ports would duplicate the efforts.

The rest are possibly good ideas but on the extreme side of things, especially given modern operating systems. For example in harden network, they block pings, which may or may not be useful or increasing security.

If you have any good error messages we can see if we can point you in the right direction.


You answered my questions thank you Justin! I ended up completing the setup of the stack and was able to run ghost and visit the domain and it resolve. I used whatever it was in the article to keep the ghost process running and that was working.

Logged out and attempted to log back in, got timed out. Tried specifying port but the same thing happened. I even tried logging on through the console in the dc dashboard and that didn’t work. Finally terminated instance, lol.

Setting the stack up now I will dial back the security measures.

There is one part of the article i’m confused about. The password is in the config file for ghost. Is that ok? I remember when deploying a rails app with capistrano I had to use environment variables to keep the pw to db secure. obviously a big part of that is because it goes to a repo before deployment.

So in this case if I’m not deploying from local to server I can just hardcode the db pw? Maybe it’s better to keep it in an environment variable anyway?


You probably forgot to add an exception to your firewall rule for SSH. Also, ghosts config file only tells ghost how to boot, so chmod 600 the config file and DO NOT RUN GHOST AS ROOT.

The “I used whatever it was in the article to keep the ghost process running” should be something you revist. You are playing with fire, it’s good to learn though. I suspect you will spend a lot of time terminating instances and rebooting them. From your previous post I can see you know about cloud-config so save your image once it’s running (Take a snapshot after you log in the first time) and if you’re trying to be thorough you will want to document every change.

Every time you get something else working take another snapshot, don’t remove previous snapshots, your new snapshot might be broken in unknown ways. If you have to revert from the previous snapshot your notes should take you back to where you need to go in short order.

Good luck!


In the new stack I didn’t setup the firewall or fail2ban. I think that’s something I should look into again. ty

I was using forever which wasn’t so great. Terminated the instance and started over. I had ghost running nicely and I redid the articles. Basically I combined the two into my own findings so now I can do a clean install with ghost np. Albeit next time I’ll just deploy the app like I would with a rails app. So to keep the process running instead of using a cron job I’m using pm2 which is really nice and has some sleek outputs. Thank you for recommending cloud-config I was looking for it this morning before implementing the process manager but couldn’t find it and just dove in. Thankfully nothing broke, haha.

great advice! Thank you! Everything is good today but I need to scp a zipped theme over to the server and it won’t work. I’m getting a permission error. I’ll do a new thread for that in the forum. Thank you for the help.



Happy to hear you’re having more success. Did you create the theme yourself or is it another theme from the net? If it’s from the internet you could use wget or curl to get the files you need. If you’re getting a permissions error did you chown the directory of the ghost install (I assume that’s where you’re trying to scp to).


well i changed chown for the ghost user but then realized that user doesn’t have ssh access. so I made a ghost group and put dhc-user and ghost in the ghost group. then gave the group ownership of ghost. or i think i may have even of gave ownership to var/www with -R for recursive. I shared the error in a seperate post. i’ll check the folder permissions again the morning.

the theme is from themeforest so yeah maybe I can do that but also scp should just work.


I’m going through the Original Post and I 'd like to make edits and quotes so people don’t have to dig past the first post. Anyway you can give me some edit rights that exceed 360 minutes to clean up posts and make them more readable and informative.


Unfortunately that’s not something we can change on a user-by-user basis. The discussion forum is primarily intended for discussion, not for authoring how-tos; if you’d like to put one together, please do that on the wiki!


even better!