Having gone through the trouble of setting up your own website, it’s now imperative that you don’t let all that hard work go  to waste by not implementing some sense of security into it. Whether it’s a WordPress blog setup on a whim or business portal through which financial transactions take place and user information is aggregated, you need to take steps to protect your website from nefarious elements on the Web. Maybe your obscure blog — started on a whim — has a couple of blockbuster posts, goes viral, attracts lot of traffic and gets hacked or defaced by punks posing as hackers. Worse, what if sensitive user data and financial transactions taking place on your online business gets leaked or falls into the wrong hands? Our increased online presence means digital dangers have a far-reaching impact that could potentially hurt you in the real world. Therefore, in the 21st century, building any sort of online presence from scratch and not protecting it in any way is just madness. You’re just inviting trouble.

Don’t be that guy (or gal). Learn to protect your digital universe, however inconsequential it may be. While nothing can guarantee your online assets 100 per cent security, you can try to make life as difficult as possible for potential hackers or online thieves trying to deface, bring down, or break into your website. Here are some essential steps:

Hide your footprint

One of the easiest ways to secure your website is to make it invisible to prying eyes. Imagine a thief trying to break into a house guarded by a lock that he can’t recognize. Only a genius, badass master thief (one in a million!) could successfully break in, most “thieves” would just turn around and bolt away, cursing their luck. Similarly, by making it difficult for people to guess your website’s CMS or server details, you’d make your website that much more difficult a target to break into.

Similarly, while configuring your website from scratch (as we covered in some of the earlier chapters of this FT), change default settings. For example, if you’re running a WordPress.org installation on your web server, change the default username from “admin” to something else… that’s more obscure. Change the default URL for admin login, as well. If you’re making a LOT  of changes to a CMS’s default installation, don’t leave sensitive stuff in the comments section of the code – as anyone can read it easily while viewing the source of your web page through a web browser. For WordPress users (which is what a large number of self-hosted independent blogs and websites consists of), check out the Hide My WP plugin from Code Canyon (http://dgit. in/HideMyWP) which is an absolute must have for WordPress site owners, as it provides a whole host of features to make your website’s CMS hard to guess – it’s totally worth the money. And that’s a great start to minimizing your website’s recognizable footprint.

One site, one server

Real the temptation is, resist it you must. If Yoda wasn’t a Jedi Master, It’s a trap, but a Web Master (see what we did there, eh?), that would be his advice when it comes to inexperienced webmasters getting swayed by the spell of “unlimited” hosting space. What this means is that you should never (and we mean never ever) host multiple websites on the same web server, as it’s a virtual kiss of death when it comes to protecting anyone or all of the multiple websites in question.

Let’s just say it’s easier to manage an infected host server when there’s only one website hosted on it. If there are multiple websites, based on dif- ferent content management systems, all hosted on the same server, you’re basically leaving the door wide open for intruders to come in and wreak havoc on your web server. There are multiple fail points, in this case, where there are multiple websites hosted on the same server, and anyone being compromised ensures the infection spreads to other CMS installed and hosted in the same space. This is a webmaster’s worst nightmare, and should be avoided at all cost.

The worst part of hosting multiple websites on the same server comes when you’re left to deal with changing every single password associated with every single account that has access to the web server. This includes the CMS installation, MySQL (or any other) database, FTP, and more. If you managed to painstakingly get rid off the infection on your server but didn’t spend time changing all the passwords, it’s a job half done and you’ve left another gaping hole in your websites’ defence waiting to be exploited in due time. Duh!

Deny file permissions

Simply put, file permissions on a web server decide what an entity can do to a certain file hosted online. And no, we aren’t talking about preventing image files being hotlinked here! This is way more important than that, so pay close attention.

In web server terminology, each file hosted online has three levels of per- missions attached to it. Read (4), Write (2), Execute (1). The first permission allows for anyone to merely read the file contents, the second permission allows anyone to edit the file contents, and the third and final permission allows anyone to effectively run the program file on the server.

The types of users, who have access to these three types of file permissions, are also divided into three. Owner, Group, Public. An Owner is someone who creates the file for which a permission needs to be set – the values are given by default. Group is a cluster of users with common or shared permissions – any file in a group will give the same level of permissions to each and every user in that group. The final user type is Public, which is defined as not only any random user on the Internet, but anyone who’s not an Owner or part of a Group policy for web server files.

If you’re absolutely paranoid about your website’s security, and you should be (why not?!), you can go ahead and deny permission to anyone but yourself (as the Owner of all files) access to your web server files. For anyone else that’s not you, giving Read (4) level access should be fine, just to ensure that they don’t make changes to it or execute it at all.

Server configuration lockdown

You can’t call yourself a security-conscious webmaster if you haven’t gotten your hands dirty at configuring critical web server files for your online web- site. For most of you who’ve tried your hand at hosting your own blog before on an easy-to-install Apache web server, that .htacess file is the critical server configuration file. What’s a .htacess file, we hear you ask? Well, simply put, it’s a plain text file that contains the directory level arrangement of all web server files and its associated access permissions. By rewriting or editing the .htacess file, which usually sits in the root folder of the directory, you can essentially dictate access to different web directories under the tree, enforce password policies, 404 redirects, and more. Similar to Apache web server’s .htacess, Microsoft IIS servers have useweb.config and Nginx servers use nginx.conf as their respective server configuration files.

Some essential rules that you should enforce on your web server through the configuration files are as follows. Prevent directory browsing – prevents malicious users from browsing and cataloguing every directory on the web- site or server; Protecting sensitive files – especially the CMS configuration file, since it’s one of the most sensitive files on the web server, holding the database login details in plain text.

Install a web application firewall (WAF)

Just like you are keen to protect all your digital endpoints – PC, laptop, smartphone, etc. – with a security software (antivirus) of some kind, similarly you need to secure your website, too. Enter WAF or a web application firewall, which is a server plugin or a separate software appliance that sits between your web server and incoming / outgoing communication lines, monitoring the traffic that wants to establish a connection to your website.

Essentially what a WAF does is that it defines a strict set of rules when it comes to allowing who gets to connect to your website and who doesn’t. It’s typically sensitive to sifting through HTTP traffic and keeping an eye out for XSS (cross-site scripting) and SQL injection attacks – some of the most common hack attack vectors – but it can be configured to stay alert and vigilant about more sophisticated attacks as well. Most modern WAF solutions are capable of dealing with DDoS and other advanced potential web threats, too.

WAF can be deployed both at a hardware and a software level. Unlike very few popular and reliable PC security vendors, the market for WAF is inundated with a whole bevy of products offering different levels of on Web Services’ WAF offering (http://dgit.in/AmznWAF) which only debuted in October 2015, and offers web security at an attractive price.

TLS, not SSL

If you’ve ever delved into online network security then you’d have definitely come across acronyms like TLS and SSL – hey, you even see them advertised on domain registering and web hosting providers online! But for the uninitiated, TLS (Transport Layer Security) and SSL (Secure Socket Layer) are two protocols used for establishing secure, encrypted network connections between web browsers, apps, websites and web servers. So why are we saying choose TLS over SSL?

In many ways, SSL is considered as a precursor to TLS, and is therefore more widespread across the Internet. What’s concerning about SSL – espe- cially SSL 3.0 – is the fact that recently POODLE (a vulnerability that lets attackers gain access to private data of users on websites like passwords, cookies, and other information) has successfully circumvented SSL 3.0 with ease, effectively ringing its death knell. Most online business websites, which collect user data, are quickly shifting over to TLS as a result, which is more robust and at present one of the most widely available secure encryption protocol for public communication over the Internet. TLS 1.2 is the most recent version of TLS, offering a lot of advanced security and encryption measures over the now outdated SSL.

When you’re configuring your website, make sure you definitely con- figure a secure web server – especially if your website’s going to contain a username, password, and other user information. Definitely choose to go for TLS 1.2 even if it comes at an added premium (usually it doesn’t, it’s just a case of clicking one radio button over another). By doing this, you’ll ensure the security and integrity of communication between your website’s server and different users (or just yourself, be that as it may), not letting anything slip into the prying ears of online eavesdroppers.

CDN

Content delivery networks (CDN) are also worth evaluating in your quest to secure and safeguard your website online. Not only do they ensure super fast delivery of your web pages or online service all across the globe, through a vast array of servers all over the world, it can also be a line of defence in your security strategy when you’re website’s encountering DoS attacks — and especially if your website happens to go down for some reason.

A security-focused content delivery network (CDN), CloudFlare (among others) is worth looking into. It likes to describe itself as an online community watch, keeping the internet’s bad guys from disrupting your online busi- ness, and in a nutshell that’s true. By adding CloudFlare to your website, you essentially allow it to filter content requests flowing into your website, blocking out all the spam and DDoS elements in the process. It also caches all your website’s static and dynamic content across its network of web servers, so even if your website happens to encounter some down time (even for maintenance) a copy of it can always be online and accessible to users from around the world. What’s more, CloudFlare is free to use, and it also has paid plans for more serious businesses who don’t want to compromise with their website’s security and reliability.

While CloudFlare is the most popular free CDN (Content delivery network) out there (even the Pirate Bay uses it!), there are alternatives like InCapsula, Myra Cloud and CDNify that are also worth looking into.

Hack your website (before someone else does)

OK, so you’re not a hacker. We get that. And learning how to hack in meticu- lous detail will take time. We get that, too. But think how a hacker would – he or she wouldn’t really go out trying to hack a website from scratch, without gathering some early vulnerability report, would they? That would be mad- ness, if they did that! You need to do something similar to your website, find out all the chinks in its armour before the bad guys do.

Just like you can download a piece of software onto your PC or smart- phone and test it for viruses and vulnerabilities, similarly you can run malware and vulnerability scanners on your web host to readily find a gaping hole or loose brick in its defensive wall. This step’s important, because without this you’re essentially in the dark, and won’t know what steps to take to reinforce your website’s defence.

Wapiti (http://dgit.in/WapitiFzr) is an open-source fuzzer, and a good place to start testing your website’s security. Although a couple of years old, Wapiti tries to inject code into a website (through pages or forms) without thoroughly detecting its CMS (Content management system). Another neat online tool used to audit a website’s security is ScanMyServer (http://dgit.in/ScnMySrvr). It offers a vast and comprehensive report on a variety of parameters of security testing – SQL Injection, Cross Site Scripting, PHP Code and HTTP Header Injection, and lots more. Detectify (http://dgit.in/detectify) and SUCURI (http://dgit.in/SucuriSite) are other great website vulnerability testing tools available for your benefit, performing hundreds of automated tests to give you a robust report on your website’s security status. Do act on the findings of these online vulnerability scanning tools!

Backup without fail

An oft-overlooked aspect of running or managing your own blog or website is taking regular off-server backup of your CMS’ directory files. Why? Because when push comes to shove, and your site gets hacked against all odds, at least you can restore it back to some immediate point in the past, and not start from scratch (which is Day 0). Make sure you use some FTP app like FileZilla to copy and backup your entire website’s directory files (with all the subfolders included, obviously) and copy it onto a different online location (Google Drive or Dropbox or something similar). Along with all the CMS files, don’t forget to regularly backup the database associated with your website’s CMS, too. All of this over and above regular server-side backups that are done by your web host, obviously. If you’re in doubt, backup before doing anything else. And when you’re done doing that, backup some more. The value of backups cannot be neglected.

We know these are nothing but beginner level steps to pique your interest into securing and protecting your website. We are confident that after reading these tips, you’d want to go online and hunt for more robust, in-depth tips to protect your website. We hope that everyone who takes the pain of starting or running their own website doesn’t do themselves a disservice by ignoring its security and protection. Websites or any other online extension of our life needs to be guarded with the same level of seriousness and security as we safeguard our physical assets. Until we do that, the bad guys will always be a step ahead of us in this eternal game of cat and mouse.