Stackahoy

´╗┐Security Best Practices

Our first priority is to make sure your files are being transferred as securely and safely as possible. We take every precaution on Stackahoy's end to make sure we are using the most up-to-date and tested practices.

For applications that require maximum security, there are several strategies one can implement on the hosting server when using Stackahoy.

Block all SSH access except for Stackahoy

Blocking all SSH (port 22) traffic helps prevent types of DDoS attacks and other forms of malicious techniques used to gain access to the application. This is one of the cheapest and most effective ways of hardening a server.

The static IP address for Stackahoy is: 104.196.136.100

Using iptables, first whitelist Stackahoy:

sudo iptables -A INPUT -p tcp -s 104.196.136.100 --dport 22 -j ACCEPT

Then block all other traffic:

sudo iptables -A INPUT -p tcp --dport 22 -j DROP

And save:

sudo iptables-save

Enable password-less SSH access (Use SSH-keys)

When configuring your server, not only is it more maintainable to use ssh-key authentication, but it's more secure. Since the authentication is made without a password, we can simply disable SSH passwords all together on the server.

To disable password authentication on the server:

Open /etc/ssh/sshd_config in your favorite text editor:

vim /etc/ssh/sshd_config

You must replace the line: PasswordAuthentication yes with PasswordAuthentication no

Then restart the SSH service: sudo service ssh restart

More information on how to use SSH keys is described here.

Create a system user specifically for deployments

For making your deployments, we recommend creating a system user with the appropriate access and permissions for executing the deployment. Giving Stackahoy root access is almost always inappropriate.

Clean up after builds

While allowing Stackahoy to build/compile the application on the server is a great way to keep a clean repository, it's a good idea to remove any artifacts that don't need to be there. This will also keep the footprint of the application small on the server.

For example:

npm i
gulp build


# Assuming the application doesn't require node_modules to exist after a build.
rm -rf node_modules