The best solution when faced with a known security vulnerability is to upgrade to the latest version of the product where the issue no longer exists. However, that is often a heck of a lot more complicated than it sounds. Although performing an upgrade is typically the most secure option, all hope is not lost. There are many steps you can take to limit common application attack vectors, regardless of the platform used. Let us dive into a few of these options, many of which are overlooked.
Disclaimer
I cannot state this loud enough, or enough times. This post is only discussing possible mitigations, things you can do to prevent security exploits from being executed. This article is NOT a recommendation, in ANY capacity, to leave an application with known security vulnerabilities in production. There are many reasons that you might not be able to apply a patch to an existing system; this post is designed to highlight a few things you might be able to do in the interim.
This post is not about any particular platform either. However, I'll use a few DNN references for illustration purposes.
Manage Server Configuration
A few years ago I created a White Paper on a few practices for hardening security configuration of applications. Although the information is readily available, I still regularly encounter servers that are lacking some basic hardening.
By applying security at the server level, you can either prevent access or isolate the impact, should a malicious user exploit one of your applications.
Manage Default Documents
We live in an age of easy configuration, all systems are designed in a manner that allow you get up and running with little configuration. A downfall to this is that often people overlook simple changes. The default document list is one of these items, and it applies to environments of all types.
Default documents tell the web server what content should be displayed when a folder is requested. For example, in the DNN/.NET World, that document is default.aspx. The default server configuration often includes things such as index.htm, index.php, or other file names as well. Why are we concerned about this?
Well, if the other documents appear BEFORE your needed one, all malicious users need to do is place a file with that name in the root. Yes, the ability for them to write to the root is horrible, but let us not make their job easy. Remove ALL default documents other than the ones you utilize!
Don't Install or Remove Unused Services
Server environments can support a plethora of technology; .NET, PHP, Java, others. It is essential to review server environments to remove any unnecessary technologies. If you are running a .NET Application, there is no need for PHP or Java. Similar to the Default Document risk the idea behind this hardening practice is to ensure that if a user gains system access, don't allow them to upload anything and execute, make them work for it.
Disable Services Not Used
Often a website is created, and once created the needs to edit are limited. One practice we have found to help secure environments is to secure or disable services that are not used. Including items such as FTP, Remote Desktop, or other services. Either by disabling them at the configuration level, or turning off public access at the firewall, you can close off an easy attack vector.
Consider a Web Application Firewall
When I encounter websites running with known security vulnerabilities, I look to include a Web Application Firewall, or another provider of security, as part of the solution. CloudFlare is a great example of a low-cost, or even free, service that can do everything from simple DDoS prevention to complex application firewall implementations. The goal of these tools is to sit between your application and the internet and block traffic that is suspicious.
This blocking could be for several reasons, including those looking to exploit with malicious URLs or simply trying to be aggressive with accessing the website. Additionally, these tools can be used to restrict access to the site from regions where known malicious traffic comes. For example, if you are working on a website targeting the US only, you could easily shut-off the site for those from all other locations.
Remove Un-used Application Extensions
Similar to how we work to secure the actual servers by not installing things we don't use, such as PHP etc. We should do the same with regards to any extensions or plugins. It is easy over time to install something and change direction to no longer use that item, however, you just leave it out there in case you might need it. These types of situations can leave a hidden backdoor and is often something individuals are not watching for. Regular audits and cleanup are suggested.
Monitoring the Environment
This almost goes without saying, however, complacency when operating with installations with known defects is the number one bad habit. Even for sites that are not used often, set up a regular review interval to look for unusual activity. The sooner you can spot a new file, or something changed, the faster you can lock down the environment.
Extend Logging Retention
Part of monitoring involves keeping logs, so you can investigate the actions that occurred. It is my recommendation that logging should be kept for at least 30 days, if not longer, for installations that have known vulnerabilities. Storage is cheap, and having the logs to go back and review what happened and what a malicious user did could be the difference between a "small issue" and a "major incident."
Extend Backup Retention
Similar to logs, it is often that a site is exploited, but not identified until a later date. Keeping daily backups for an extended duration offers an ability to restore further back should something malicious occur. For example, keeping backups for 30 days allows restoration for a longer time and might only cost you $3 or $5 per month more for storage. It is always better to have more information than you need, than the opposite.
Understand The Application & Exploits
Lastly, it is important to understand the exploits that exist for the platform you are using. By following the security notices, you can better gauge your potential impact. For example, if an issue is reported that impacts sites with public registration; however, you do not allow users to register on your site, the concern is less. Don't forget any third-party solutions that you might use either in this review.
Be Vigilant & Get Upgraded
At the end of the day, it isn't the end of the world typically if you haven't upgraded. Proper security protocols can help overcome some platform limitations and exploits for some time. However, it is often easier to plan for regular updates than to become horribly out of date and have multiple security holes impacting you.