Simple Server Security

Adam Frame - Full Stack PHP Developer

At The Escape, we take our clients’ website security very seriously. We have over 10 years of experience in implementing strategies and practices which help ensure our clients’ data is protected and secure, according to the evolving and progressing best practice and industry guidelines. We are primarily a PHP/JavaScript house, so all examples referenced in this blog will be with regard to these languages. We also use Ubuntu or Debian Linux distributions. 

The internet is a minefield and there are always people out there looking to exploit servers for monetary gain or malicious purposes. So, how do you ensure that your website stays protected and secure?

Here are some of the more common web server and application vulnerabilities to look out for:

XSS (Cross Site Scripting) Attacks

XSS attacks are where unauthorised content is injected into a service (webpage), exploiting flaws in code which allow for the upload of content without properly validating and sanitising the request. The most common way is to include JavasScript code in a form post that is likely to be displayed on the site itself, such as a comment box or review.

In order to mitigate this kind of attack, the application developer must ensure that all content posted to the website, whether it be via a web form or via an API, is filtered. Doing this by using rules that remove any malicious code means that the result is just benign content, and cannot be executed on the server or in the browser.

See PHP Filters, Symfony Validator

SQL Injection

Another very similar attack is the SQL injection attack. This is when an attacker specifically targets the database behind the web application with code that will expose content that would otherwise be unavailable on the visible web. It can also be used to modify content so as to add script tags that facilitate XSS attacks.

As before, this is mainly mitigated by sanitising all content from external sources. Developers should also return as little information in any error message as possible so not to give the attacker any ammunition they can use to alter their attack to best exploit the specific setup of the target server. 

Modern PHP frameworks mitigate SQL injection by using an Object Relational Mapper (ORM) which helps validate and sanitise input, and use templating engines that will, by default, escape all content, thus not allowing HTML code and JavaScript code to be executed on the page. Best practices are never to use $_GET, $_POST and $_REQUEST variables directly, rather use the Request object that the framework provides.

More reading


To quote Gregoire on Stack OverFlow:

If you use parameters instead of concatenation when creating a request, the program is able to tell SQL keywords and values apart. It can therefore safely escape values that may contain malicious SQL code, so that this malicious does not get executed, but stored in a field, like it should.

HTML code injection is another problem, which has nothing to do with databases. This problem is solved when displaying the value, by using automatic output escaping, which will display eduardo instead of eduardo. This way, any malicious js / html code won't be interpreted : it will be displayed.

MitM (Man in the Middle) Attacks

A man-in-the-middle (MitM) attack is when an attacker intercepts communications between two parties to either secretly eavesdrop or modify traffic travelling between the two.

Methods that attackers use include setting up fake WiFi towers, spoofing DNS entries, and phishing links that point to similar looking domains. Greater adoption of HTTPS and more in-browser warnings have reduced the potential threat of some MitM attacks.

In the last few years, Google has been the main supporter of every website using SSL certificates and https instead of http traffic. SSL certificates are used to encrypt traffic from the browser to the server and vice versa. That means that anyone trying to eavesdrop on any communication will just see the garbled encrypted message and not anything valuable such as passwords and credit card details. SSL has been used on e-commerce sites for many, many years and it is what enables the green lock icon on your browser address bar. You should never provide your credit card details to sites that do not show that lock icon.

Major web frameworks such as Symfony, Laravel etc. already use what is commonly called a CSRF (Cross-Site Request Forgery) token to verify that forms posted to the server actually originated from the server. This is done by the application creating a seemingly random string called a token and adding it to the form’s code. This string is then passed back to the server when the form is posted and is compared to the string that was originally created. If it doesn’t match, it causes an error and the form is never posted. If it does match, then the form is posted as normal.


What is CSRF?

How to implement CSRF


So, what should you be doing?

There are certain best practices that go a long way to ensure that your application and server are as secure as you can make them. A few of those are detailed below:

Access server only using SSH keys. 

SSH keys are a pair of cryptographic keys that can be used to authenticate to an SSH server as an alternative to password-based logins. A private and public key pair is created prior to authentication. The private key is kept secret and secure by the user, while the public key can be shared with anyone.

Disable root access, disable access via password.

Disable root access by editing the configuration of sshd (Secure Shell Daemon). (/etc/sshd/sshd_config). The PermitRootLogin value should be set to false to disable access completely or prohibit-password if you still want to allow access using an SSH key. We’d recommend disabling the root access completely and allowing access to permitted users to whom you can then give sudo access to enable privileged commands.

Whitelist IPs

Use a firewall such as Linux’s iptables or the simpler UFW (uncomplicated firewall) to whitelist certain IPs in order to access vulnerable services such as SSH (22) and MySQL (3306).

First, lock it down to deny access to any non-specified port:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Then limit services by IP:

sudo ufw allow from to any port 22
sudo ufw allow from to tcp port 3306

Only open the ports you need to be publicly accessed:

sudo ufw allow web
sudo ufw allow https


Use a VPN

If you are likely to be working from home or out of the office (which is becoming increasingly common), use a VPN to connect via the office and whitelist its public IP address. Alternatively, if you have another server that has a fixed IP address then you should whitelist that IP instead and SSH into that box prior to accessing the application server. 

Run vulnerability scans

Use a tool like Nessus to run scans on your server. This exposes flaws in your code, as well as known exploits which need to be patched on your server.

chroot users

If you do have to allow access for users, you can use a technique called a chroot jail which restricts their access to only certain folders on the server.

Minimum password complexity

Follow best practices and ensure your passwords throughout have a minimum complexity so that they are not easily exposed using brute force attacks. One popular method is to use a combination of three or four unrelated words which are easy to remember, but hard to crack - ‘glowing-penguin-topsoil-patio’, for example.

Hide server information

Ensure that your application is not exposing the technology used to create it. In php.ini set expose_php to false to hide the fact you are using PHP. In Apache you can add ServerSignature Off to either apache2.conf or your site’s .htaccess file.

There must be some tools that can help me?

Yes, there are.

There’s a number of software/service solutions and tools available that will help you secure your server, and it only takes a few commands to set up.



One of these tools is fail2ban ( This tool intelligently monitors system logs to catch any attempt to exploit the system, or to brute-force passwords.

sudo apt update
sudo apt install fail2ban
sudo systemctl start fail2ban>
sudo systemctl enable fail2ban


Copy /etc/fail2ban/jail.conf to jail.local :

awk '{ printf "# "; print; }' /etc/fail2ban/jail.conf | sudo tee /etc/fail2ban/jail.local


Edit jail.local with your preferred editor:

sudo vi /etc/fail2ban/jail.local


First of all, whitelist your own IP address so that you will not be banned by the tool, and set a few defaults (uncomment each section you edit, using the jail.conf as a guide):

. . .
ignoreip =
. . .
destemail = root@localhost
sendername = Fail2Ban
mta = sendmail


The config file is split into sections that describe which logs to monitor, with defaults set for levels for different possible exploits. Each of these sections can be enabled by uncommenting the header and changing the enabled line to be “true”:

# Ban hosts which agent identifies spammer robots crawling the web
# for email addresses. The mail outputs are buffered.
enabled = true
port = http,https
logpath = %(apache_access_log)s
bantime = 48h
maxretry = 1


Once finished, restart the fail2ban service to enable these protections

sudo systemctl restart fail2ban



If you have a suspicion that your system might have already been exploited, it may have been facilitated by using a rootkit.

“A rootkit is a collection of computer software, typically malicious, designed to enable access to a computer or an area of its software that is not otherwise allowed (for example, to an unauthorized user) and often masks its existence or the existence of other software.” (Wikipedia)

There’s a couple of tools which can help you detect if your system has been compromised by this method: chkrootkit and rkhunter.

Security Mailing Lists

Subscribe to the security mailing lists for the distribution of Linux that you use; for Ubuntu:

There is a number of configuration settings in the most popular web servers (Apache/Nginx). These don’t really affect the security of the server but they make attacks more difficult in some cases. These are best explained by following the links below:






This is by no means an exhaustive list of things you should think about when dealing with the security of your new server, but it should help train your mind to be aware of what is possible and what you should do when faced with this common problem.

Begin your move to more

We can build your competitive advantage and achieve your business ambitions through brand-led, multi-channel customer experiences