Securing your Magento site
Executive Summary
Owning a Magento website means you have a resource you own and control on the internet. Keeping it secure in all aspects is a responsibility. You need to ensure
- your business data is secure.
- your customer data and privacy is secured.
- your customer’s computers are protected when accessing your website.
Your privacy policy indicates your desire to keep your customers’ data secure. You would intentionally not violate the policy but a cyber attack on your infrastructure can cause a violation.
It is not required to be a famous to be in the eyes of the attacker – most attackers today prowl the internet looking for vulnerable sites and automatically get to work. New types of attacks are being designed and hence keeping a site protected is a continuous battle.
As a person ultimately responsible for your website, you need to periodically review your security processes and see they are enhanced for new vulnerabilities.
This article has an overview of the aspects of security you need to worry about. In addition it goes in depth as well to make it actionable.
Aspects of security infrastructure for a Magento Website
- Protection of the web edge infrastructure. Ensure you keep the bad guys out and the good guys in. Using a Web Application Firewall (WAF) with appropriate configuration will help.
- Server protection. Ensure access to the server restricted, preferrably without a password, limit port access and protect files and folders with permissions that are just needed. Also ensure the server has the latest security patches installed. Need to know access should enforced. Code updates should be automated. A staging site should be used for updates from vendors. Plugins should be acquired from known and reputable vendors.
- Code protection. Ensure your code is patched with the latest Magento (or any platform and plugins). In addition train developers to use safe practices to not leave holes.
- User data protection in transit. Ensure https access to the entire site so all access is secured against in transit hacking as users use your website. Ensure all admin access is restricted either with dual password or two factor authentication or IP restricted.
- Review all access periodically Change passwords and admin URLs regularly.
- Run vulnerability scanners Vulnerability scanners are available for testing many aspects of security. Blackbox scanners such as Trustwave, Secure Works, help in checking if they can find external vulnerabilities. Static analyzers such as Fortify scan the code to find code level vulnerabilities.
Protecting Web Edge Infrastructure
The key role of this protection is to keep the bad guys out and allow the traffic you want in.
At the minimum configure nginx or apache (your webserver) to
- rate limit hits from a single IP address
However, if you get legitimate hits from behind a firewall these may generate false positives. We recommend to log the IPs that get restricted and review. Whitelist the ones that are ok. - rate limit admin server access if you cannot IP limit the access to admin
Many bots are trying passwords to get acsess to the admin panel - Have a mechanism in place to block IPs.
As with any protection of this nature, detecting bad is a key. OWASP is an online community which has come up with a core rule set (CRS). A Magento site needs a WAF protection either on the nginx server level or with an external service such as Webscale Networks, Cloudflare, Sucuri.
The OWASP ModSecurity Core Rule Set (CRS) provide protections against the following category of attacks.
- SQL Injection (SQLi)
- Cross Site Scripting (XSS)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Remote Code Execution (RCE)
- PHP Code Injection
- Metadata/Error Leakages
- Project Honey Pot Blacklist
- GeoIP Country Blocking, etc
System Admin Note
mod_security is a open source project available for apache and nginx. Installation is not difficult. However, you need to tune the rules to your environment. Some rule tuning may require developer or marketing input.
Protect the admin panel login
- Change the admin URL periodically. Do not use the same name as in test or development environemnts
- IP restrict admin access to only your known IPs
- Put a simple http access in front of the admin URL – so there are 2 levels of usernames and passwords and it makes it non standard for automatic hacks
- 2 factor authentication to admin panel – may need a plugin
- Change all admin user passwords frequently
- Monitor log file for frequent unsuccessful attempts to login
Server Protection
A hacked or broken in server – popularly shown in movies – gives access to your server to the hacker. Web prowlers are continuously trying to see what ports are open in the server and what access they can get. Being a very traditional form of hacking, it is highly automated. By the very same count, protecting a linux server is not very difficult either. Follow some guidelines and review process.
- Keep only known ports open and limit which IPs can access these ports
- Disable any form of password access (like ftp, ssh). Use keys instead.
- Keep server patched with latest security patches
- Run only services that you need. For example never run ftp as it gives password based access to the server.
- Follow very strict rules on file / folder permissions as well as linux groups and users
- Periodically scan servers for viruses signatures
- Periodically review access keys
- Automate routine processes and restrict with keys including code update
- If a db server is a separate server further restrict access to this server . If using a autoscale architecture, further restrict access to app servers as well.
- Allow no exceptions – even for a critical fix do not give access to a developer for example.
The following system admin note has technical details for linux system administrators to execute the strategies above
System Admin Note
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.
System Admin Note : ssh configuration for 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.
System Admin Note : 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
System Admin Note : File and Directory Permission settings
- Only media/pub and var folders should have 770 permissions
- All other folders in should have 750
- All files under var should have 660
- All other files should have 640
- production user should be in apache group
Protect your code
- Ensure Magento code is patched to the latest. Subscribe to Magento updates and setup process to check for patch releases on a monthly basis.
- When the plugin vendor. Many simple looking community plugins can be weak on security and leave the site prone to attacks.
- Train developers to use safe practices.
- Keep the code repository (svn / git) access secure and passwordless for developer access.
- Ensure external respository provider web access is secure and with 2-factor authentication.
- Ensure backup servers are protected with access to write only given to automatic backup process
User Data Protection in Transit
Customer data in transit is the protection of data sent and received from your website to their browser. Internet connections to websites are not direct – the data hops from server to server in between. A server compromised on the way can tap into your data without anyone knowing it.
- Using https for the complete site is an obvious requirement. Using higher security options in https is even better.
- Emails sent should not contain sensitive data. A recent Magento patch fixed such an issue – passwords were earlier sent in emails.
Review all access periodically
Setup a security task force that reviews and reports on security once a month.
The charter of the task force would be evaluate the following
- Who has access the the server and do they yet require this access. The access may be via keys and when a employee or contractor leaves, the key should be removed
- Who has access to development environment. Have required access been withdrawn appropriately.
- Who has access to version control systems. Have required access been withdrawn appropriately.
- Admin access Are all admin users yet needing access?
- Were admin passwords reset at agreed frequency?
- Magento Patch status
- OS patch and update status
- External security scan (if arranged) status
- Action taken report for the last period on any security issues
- Backup and restore process review to ensure data and code is appropriately backed up
Conclusion
Protecting a eCommerce asset like a website in these times of automated hacks is a major challenge. Periodic reviews is a must as the attacks and defenses are quickly evolving. Being a small site is no excuse – the attackers, typically robots do not care.
