What does forge in terms of security?

@Osqui Forge isn't meant to provide security. However it does install a firewall and cancels the option to ssh via root which is also important. Beyond that it's on your own to decide if you want to add extra security.

You can also check out laravel/settler to get a better understanding of what happens when a Forge server is provisioned. Anything beyond that you'll need to manage yourself.

Hello, thanks to the two by answering :)

Hi All,

Thanks for the answers.

As a followup question,

1. how do I manage server upgrades?

As any OS, Ubuntu is periodically updated with security fixes. How do I get these updated to my server?

• Do I need to apt-get, aptitude, or dselect by myself?
• Is there any Forge way?

2. what is the proper way to extend laravel/settler

Bernard

Hi, I've been struggling with the fact that there is not much information on the forge-end on this matter myself for a while. The only answers I got was on other forums related to Debian/Ubuntu. I've always been wondering why what best practices are used by experienced Forge users. Other than that, Forge is awesome! Love it!

This is one of the best answers I've found:

Run regular package upgrades manually.

sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get autoremove && sudo apt-get clean && sudo apt-get autoclean

Install and configure apticron to be notified of (security) updates.

sudo apt-get install apticron && vi /etc/apticron/apticron.conf

I'm just looking to figure out if there is a way to restart services that are automatically updated without rebooting the entire server. Haven't figured that out yet.

Thanks Stefr

To your question: apt-get is taking care of restarting the services it updates. You should only need to reboot when the kernel is updated.

I install some of the following software to help me debug and make it more secure.

sudo apt-get install fail2ban bwm-ng htop iotop iftop nethogs tcptrack

• fail2ban - blocks failed logins for a number of services (a must for me)
• bwm-ng - bandwidth monitor (generally good to see the traffic on a server)
• htop - updated top command to see CPU/RAM/processes running (just nicer)
• iotop - see disk usage and the process (handy for checking problems)
• iftop - connections and their traffic in/out (can toggle hostnames and ports etc)
• nethogs - another network software to see traffic and process/user/IP
• tcptrack - ability to quickly see SYN floods or unwanted traffic

@bderubinat Thanks, this is useful information!

@bashy Thanks, this is really useful! I will check it out!

@bashy great indeed.

fail2ban is great indeed. Be sure to "vi /etc/fail2ban/jail.conf" and "enabled = true" the services you need to be monitored.

@bderubinat Yeah as with anything, there's always config files which need to be setup. Also to use iptables or another method along with ban time :)

@bashy Thanks for the list of security services. I setup fail2ban after reading Fideloper's SfH book. Do you recommend any other sysadmin books or websites for working with Forge / DO servers?

If you only ssh in from certain IP's you can also either use tcpd or iptables to limit where connections are allowed from. For tcpd that's as straightforward as :

/etc/hosts.allow :
sshd: 120.100.55.22
sshd: 74.55.123.99
/etc/hosts.deny :
sshd: ALL

@neovive Forge/Cloud servers are mostly the same. It's a Linux environment and if you're running Ubuntu, you can use most of Debian packages because it's basically the same system. There's loads of different options but that's a main one I use to stop SSH brute-force.

@ohffs That's great advice but I and most have dynamic IPs so it's quite hard to keep that secure across places you want to connect from. I know about that option but haven't used it before for SSH, do you have a dynamic IP and have that setup?

@bashy I have fixed IP's mostly - but there's also one location I use where I get a dynamic DHCP address but it only changes the last network segment so I have an 'sshd: 11.22.33.' rule in to allow for that - limits the chances at least :-) I guess a tiny cheap-as-chips VPS with a fixed IP as a gateway (or acting as a VPN - I use streisand for instance to faff about) would help too :-)

I generally like the hosts.allow/deny as it's so easy to handle in a provisioning script without having to worry which iptables/ufw/firewalld/ipfw/whatever is handling the kernel layer :-)

Howdy folks!

There's more to it than the firewall, although that is certainly an important first line of defense.

Here's what I see when I log into a Forge server:

Firewall

IPtables is setup (via ufw):

forge@my-host:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22 (v6)                    ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

These are a good set of defaults for a web server - only allowing in SSH and web traffic.

SSH / User Security

• Password-based login it turned off (SSH-key only)
• Forge user requires a password to run sudo commands

Checking out file /etc/ssh/sshd_config, we can see the relevant sections:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin yes

Personally, I'd turn off the ability for the root user to SSH in. If you ever need to, you can login to the root user using DOs or Linode's terminal provided in the control panel of those systems. (AWS does not provide this).

Update: It looks like based on this that Forge uses user root to perform sudo actions (hence it doesn't need a password via user forge to run privileged tasks). Therefore on forge servers, don't disable root user login.

Web Server / PHP

Nginx and PHP is set to run as user forge, which makes file permissions easier to handle when your application files are all owned/run as user forge.

There isn't too huge of a downside for this, but you'll often see that web apps are not run as a user who can also login via SSH. (Although that's how cPanel works, which is a huge % of PHP sites, so it's not like Forge is unique in this). IMO an acceptable trade-off in terms of potential security vulnerabilities (Typical example of a hack making use of this would be PHP running arbitrary code, something you see on Wordpress sites fairly oftenish).

Fail2Ban

Fail2Ban is installed and monitoring bad SSH attempts. After X attempts in N seconds, it bans that IP address from attempting more logins for Y minutes.

Check /var/log/fail2ban.log to see how glad you are this exists :D

Unattended Upgrades

Automatic security updates are setup out of the box. See here for more information on how that's setup. The server is setup to NOT restart automatically, so if you login and see a message similar to "Server requires restart", then it may be a good idea to do a quick reboot to ensure security updates are in place.

Check out files within /var/log/unattended-upgrades to see logs related to unattended upgrades, and the linked article in the paragraph above to see more on how that's all setup.

To add info from a whitehat course I took - one should remove/uninstall "mlocate/locate" and "find" to help protect against someone finding files within your system.