Secure access to a Magento server
Today the biggest threat to your Magento production server are external threats – of being hacked. While you may not be a high value target, hackers run crawlers on the internet to discover servers with weak security and attack. In this article we discuss secure access to a Magento server. An OS level attack if successful can only be fully repelled by re-imaging the server. But preventing a OS level attack is easier than you think – if you follow some simple guidelines.
A Magento production server should have restricted access for all. Insecure, password based access should be disabled. If more than one server is used in a constellation, ssh access to the setup should be restricted to only one server.
Depending on the configuration we recommend the following incoming ports to be open :
On the only app server without load balancer
Port of external interface | Protocol / usage |
80 | http, main site open to the world if site not fully secure. |
443 | https, main site open to the world |
22 | ssh, possibly open only to specific IP addresses |
On the db server
Interface / port | Protocol / usage |
External / 22 | Only if you must to restricted IP addresses |
Internal / 6603 | Restricted to internal IPs that run app servers |
Internal / 22 | Ssh access from the other servers |
Constellation of app servers, a db server and a nginx load balancer
Host / Interface / port | Protocol / usage |
Load balancer / external / 80, 443 | http and https open to the world |
Load balancer / external / 22 | ssh, possibly open only to specific IP addresses |
Load balancer / internal /2049 | Nfs server |
Db server / internal / 6603 | Mysql, for app server access |
App server / internal /1110 | Nfs, for file access across all app servers |
Note : If using a load balancer device or service, port 22 access should be given to only the main app server, possibly the nfs host.
Ssh configuration for a secure access
Ssh needs to be configured to a more secure mode. (Refer linux man page)
- Change default port to non standard port (say) 2020. This will thwart an obvious attempt to breakin. However, an attacker can find the port using a port scan.
- Disable root ssh access. This is crucial. This means that someone can never login to the server directly as root.
- Disable password access. Weak passwords are the most common way a breakin is successful. It is common that a server being attacked will have multiple password generators trying to access the server.
- Enable only key access. With this setting only a private key holder who has a public key stored in the .ssh/authorized_keys file will be allowed access.
/etc/ssh/sshd_config :
...
# set port to non standard 2020
Port 2020
...
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin no
...
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication no
...
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
Note : First enable key access, exchange keys, ensure ssh to keys works before disabling password
Note : When changing ssh configuration ensure a ssh session to the root server is separately running. This will prevent from being locked out of the server when changing ssh configuration.
What users are needed
We recommend the following users
- Login user
° This user has sudo access (without password)
° Ssh key exchanged
° Admin logs in as this user
- Site user (production)
° Website will be hosted under this users (/home/production/www NOT /var/www/html)
° This user may have ssh access to deploy code
° This user does not have sudo access
° If using multiple app servers, this users id will be shared across all app servers
- Web server user (apache)
° Nginx and php processes will be run as this user
File and Directory Permission settings
- All directories under /home/production/www should have 770 – including magento’s media and var folders.
- All files under /home/production/www should have 660
- production user should be in apache group
https (and http/2)
We will assume you have the checkout flow and login pages use a secure (https) URL.
It is highly recommended to convert your entire set to secure (https) access.
Refer our article on http/2 on the benefits and steps.
Use of a Web Application FIrewall (WAF)
Web Application Firewalls (WAFs) help in keeping the good traffic in and bad traffic out. The promise can be achieved through commercial plans for companies such as Web Scale Technologies or CloudFlare. Alternatively they can be built using mod_security into your apache or nginx servers.
There are additional security settings and we will continue to write about them. If you need a security audit for your Magento production servers email us at audit@luroconnect.com