Secure access to a Magento server

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

social position

Share this post