Things evolve and change. So we’d like to outline some security basics you need to follow this year. They will help you to implement and maintain a secure website environment.
Web Hosting
The web hosting plan of choice is either VPS or dedicated server. Rationale:
- Shared hosting plans should never be considered. Their architecture is inherently insecure and
hacks are possible. - VPS of type KVM type provides for maximum isolation from other hosting clients. Providers of
choice of VPS KVM plans: Linode, DigitalOcean, Vultr. Linode is the company that’s been
around for years and has more stability over others. By default it uses its own Linux kernel
builds; clients can choose or build any kernels they wish. - For maximum security, dedicated hosting plans should be considered. This negates “bad
hosting neighbour” problem completely. Recommended provider: OVH.net. Their kernels
include GRSecurity which is alternative to SELinux.
Operating system
CentOS 7 (or its paid equivalent, RedHat 7) is the recommended operating system of choice. It
provides security fixes on a regular basis and considered more stable than Ubuntu.
RedHat 7 provides easy way to update server automatically with the latest security fixes – it
provides security errata in their yum repositories.
Web server setup. Permissions
Since it is the weakest part of any web site, proper configuration is required. Dynamic applications
like PHP websites should be setup to be run by proper Linux user accounts. The following server
application stack allows to achieve desired user separation.
Nginx + PHP-FPM
- A website (file ownership) has to have its own dedicated user account on the system, i.e. site1
- Web server (nginx) has to be run with a different user account, i.e. www-data
- PHP code (PHP-FPM) has to be run under site user account (site1) and all files should be owned
(chown) by that same account - The secure setup assumes that www-data should be member of site1 group, thus allowing web
server to read website files through group sharing. Example commands for secure permissions
inside public_html directory where website files reside:chown -R site1:site1 /path/to/public_html
chmod -R g=r,o= /path/to/public_html
The above ensures owner of website files, allows web server user (group bit) to read the files and
disables access to the files by all other system accounts.
Naturally you’d have to add write permissions on directories where uploads have to take place,
i.e.:
chmod -R g+w /path/to/public_html/uploads
Common mistake here is when uploaded .php files are allowed for execution. This provides
hackers with easy way to implant backdoors and deface websites. Configuration to mitigate the
risk (nginx example):
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
SSL
SSL is required to protect identity theft through man in the middle attacks. The provider of choice
for SSL depends on whether EV type of certificates is required.
Certificate: EV or not EV
For non-EV certificates: use LetsEncrypt. The certificates generated by this provider are in no way
less secure than their paid alternatives. A great advantage of LetsEncrypt is ability to
automatically renew certificates, which ensures constant and human-error prone presence of valid
certificate for the website at any time.
EV certificates provide no extra security encryption wise. EV (Extended validation) provides for
better recognition of the company by showing its name along secure padlock (green bar with
company short name found in modern browsers). This has a positive effect on customers,
ensuring their trust that the company spent a great deal of efforts on security.
Recommendation: EV certificate (Comodo, Digicert, etc).
SSL protocols
Some SSL protocols are no longer safe to use. Web server has to be configured in a way that
those protocols are disabled. Secure configuration for nginx:
ssl_protocols TLSv1.1 TLSv1.2;
SSL ciphers
Some SSL ciphers are weak and not secure. cipherli.st has a great reference of secure ciphers.
Secure configuration for nginx web server:
ssl_prefer_server_ciphers on;
ssl_ciphers “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
HSTS header
The HSTS header ensures that client browser will send requests over secure channel only. Nginx
configuration to add it:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload”;
Read more about implementing HSTS preloading correctly.
Avoid SSL mixed content issue
A common mistake while implementing SSL is that some website assets (CSS, JS, images files)
are linked via http:// as opposed to https://. This makes complete page insecure and browsers
flag it as such by removing secure padlock from the address bar. All assets should be linked via
https:// !!!
Add SSL redirect
All website’s pages should be accessed only via https://. To achieve this, web server has to be
configured to redirect all requests from plain http protocol. Example nginx configuration:
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
X-Frame-Options HTTP header
This header ensures that browsers will not attempt to display this site within frame of other
websites:
add_header X-Frame-Options DENY;
SELinux
SELinux ensures application access control. SELinux is enabled by default in CentOS 7, however
some providers ship server with SELinux in disabled state for simplicity. It can and should be
enabled to ensure better security.
Firewall
FirewallD is the standard firewall software for CentOS 7 and should be used to allow activity only
on SSH port (22) and web ports 80 and 443.
Fail2ban
Fail2ban is a great intrusion prevention system. Depending on the web app in use, special filter /
action configuration can be used to monitor access log files and block hackers at early stages. It
uses native system firewall (FirewallD for CentOS) to block intruders.
ModSecurity
ModSecurity is intrusion prevention system that is coupled with web server (Apache or Nginx). It
prevents SQL injection and application specific exploits. There are 2 primary rulesets for it:
OWASP (freeware) and commercial ruleset by Trustwave. Both can work together at the same
time.
ModSecurity can be coupled with Fail2ban in the following way: ModSecurity denies access with
403 Forbidden (its default behaviour), then upon repeated attempt which fails ModSecurity
checks, Fail2ban will find the repeated security offence and block intruder in firewall for a lengthy
period of time.
Logging
System has to be configured in a way that logs are retained for 365 days. This ensures that in
case of break-in attempts, offending IP addresses / hack entry point can be found and
investigated.
Root SSH account
SSH root account direct login should be disabled. A sudo user has to be used instead.
First, add SSH sudo user, then in sshd_config, disable root login:
PermitRootLogin no
Test, test and test
There is a great deal of online tests which are very thorough in their checks. Great resources are: