Over the last decade, Distributed Denial of Service (DDoS) attacks have continued to proliferate, becoming one of the primary threat types facing virtually every industry and business area that is exposed to the public Internet.Therefore, DDoS protection must be at the core of a successful security strategy.
DDoS attacks attempt to bring down and infiltrate Web sites by flooding the site's origin server with bogus requests, often from multiple locations and networks. If allowed to proceed unchecked, this DDoS attack traffic can produce results ranging from slow page loads to a complete blockage of legitimate site traffic.
These types of attacks can originate from a variety of sources, including 'hacktivists,' for-profit hackers, state-sponsored hacking groups, and others. In many cases, DDoS attacks leverage the force multiplication advantage of 'botnets,' essentially armies of computers that are penetrated and recruited to generate attack traffic unbeknownst to their own user or administrator.
DDoS Mitigation
Given the growing number and scale of DDoS attacks, planning for DDoS attack detection and mitigation is a critical IT function. Since it's virtually impossible to build out sufficient infrastructure to scale in response to a large DDoS attack, solutions like Akamai's Kona Site Defender are increasingly being deployed by owners of Web properties across virtually every industry. Cloud-based solutions like Kona Site Defender offer built-in scalability and global reach to defend against most common types of DDoS attacks, as well as attacks against web applications (SQL Injections, Cross Site Scripts, etc.) and direct-to-origin attacks.
How Kona Site Defender Blocks DDoS Attacks
Kona Site Defender mitigates DDoS attacks by absorbing DDoS traffic targeted at the application layer, deflecting all DDoS traffic targeted at the network layer such as SYN Floods or UDP Floods, and authenticating valid traffic at the network edge. This built-in protection is "always on", and only Port 80 (HTTP) or Port 443 (HTTPS) traffic is allowed. Bursting fees can be capped so users are protected from DDoS traffic running up service fees, and flexible caching maximizes offload from origin.
For added protection, many organizations add a defense layer that protects the Domain Name Server from being overloaded and compromised by Denial of Service attacks, such as Akamai's Fast DNS solution. Both of these solutions leverage the power of the Akamai Intelligent Platform™, which consists of more than 160,000 servers deployed across over 1,200 networks in more than 95 countries.
Akamai's Global Scale Helps Combat DDoS Attack Traffic
The worldwide distribution and massive scale of the Akamai Intelligent Platform™ enables Web sites to stay available without re-routing traffic or impacting performance. Akamai handles 5.5Tbps of traffic daily on average and has handled peak traffic flows of over 8Tbps. And DDoS mitigation capabilities are implemented natively in path so protection is provided only one network hop from the point of request—NOT at the customer origin.
CSRF - You need to have protection in place to prevent cross site request forgery - or requests to login, signup, or other actions from other sites. This can be used to trick users into performing actions they didn't intend to.
CAPTCHA on signup - It's often recommended to use a CAPTCHA on your sigh-up form to reduce automated signups. How important this is depends on your threat model.
Secure login - The login needs to happen over HTTPS to reduce the risk of the user's credentials being captured via a MiTM attack.
Cookies - While login over HTTPS should be seen as a minimum, everything else really should be over SSL as well to protect the cookies (remember Firesheep?). Though just using SSL isn't enough, you need to set the Secure flag and HttpOnly flag whenever possible.
Email Confirmation - You need to make sure that you verify a user's email address as part of the sign-up process (I'd suggest not letting them login until it's confirmed). You'll need to have this for use in password resets.
Bruteforce protection - You need to protect against an attacker bruteforcing user accounts. There are various ways to do this, locking accounts (which can be used as a DoS attack by locking out large number of users), limiting failed attempts from a given IP (either via ban, or additional CAPTCHA). There are pros and cons to each method, but it's important that you have some form of protection in place.
Secure password reset - You need to make sure that you have a secure method for resetting passwords. This one is more complicated than most people think, and is easy to get wrong (as Apple recently found). The biggest risk is that an attacker finds a way to abuse the feature to reset accounts that they don't own.
I'd strongly suggest that you read the OWSAP Authentication Cheat Sheet, it goes into detail on these and many other potential issues; and as always, when building new systems, it's a good time to take another look at the OWASP Top 10 and make sure you have taken the proper precautions.
As a webmaster, is there anything more terrifying than the thought of seeing all of your web-developed work being altered or wiped out entirely by a nefarious hacker? You’ve worked hard on your website – so take the time to protect it by implementing basic hacking protections!
In addition to regularly backing up your files (which you should already be doing, for various reasons), taking the following three easy steps will help to keep your website safe:
Step #1 – Keep platforms and scripts up-to-date
One of the best things you can do to protect your website is to make sure any platforms or scripts you’ve installed are up-to-date. Because many of these tools are created as open-source software programs, their code is easily available – both to good-intentioned developers and malicious hackers. Hackers can pour over this code, looking for security loopholes that allow them to take control of your website by exploiting any platform or script weaknesses.
As an example, if you’re running a website built on WordPress, both your base WordPress installation and any third-party plugins you’ve installed may potentially be vulnerable to these types of attacks. Making sure you always have the newest versions of your platform and scripts installed minimizes the risk that you’ll be hacked in this way – though this isn’t a “fail safe” way to protect your website.
Step #2 – Install security plugins, when possible
To enhance the security of your website once your platform and scripts are up-to-date, look into security plugins that actively prevent against hacking attempts.
Again, using WordPress as an example, you’ll want to look into free plugins like Better WP Security and Bulletproof Security (or similar tools that are available for websites built on other content management systems). These products address the weaknesses that are inherent in each platform, foiling additional types of hacking attempts that could threaten your website.
Alternatively – whether you’re running a CMS-managed site or HTML pages – take a look at SiteLock. SiteLock goes above and beyond simply closing site security loopholes by providing daily monitoring for everything from malware detection to vulnerability identification to active virus scanning and more. If your business relies on its website, SiteLock is definitely an investment worth considering.
Step #3 – Lock down your directory and file permissions
Now, for this final technique, we’re going to get a little technical – but stick with me for a moment…
All websites can be boiled down to a series of files and folders that are stored on your web hosting account. Besides containing all of the scripts and data needed to make your website work, each of these files and folders is assigned a set of permissions that controls who can read, write, and execute any given file or folder, relative to the user they are or the group to which they belong.
On the Linux operating system, permissions are viewable as a three digit code where each digit is an integer between 0-7. The first digit represents permissions for the owner of the file, the second digit represents permissions for anyone assigned to the group that owns the file, and the third digit represents permissions for everyone else. The assignations work as follows:
4 equals Read 2 equals Write 1 equals Execute 0 equals no permissions for that user
As an example, take the permission code “644.” In this case, a “6” (or “4+2”) in the first position gives the file’s owner the ability to read and write the file. The “4” in the second and third positions means that both group users and internet users at large can read the file only – protecting the file from unexpected manipulations.
So, a file with “777” (or 4+2+1 / 4+2+1 / 4+2+1 )permissions would then readable, write-able, and executable by the user, the group and everyone else in the world.
As you might expect, a file that is assigned a permission code that gives anyone on the web the ability to write and execute it is much less secure than one which has been locked down in order to reserve all rights for the owner alone. Of course, there are valid reasons to open up access to other groups of users (anonymous FTP upload, as one example), but these instances must be carefully considered in order to avoid creating a security risk.
For this reason, a good rule of thumb is to set your permissions as follows:
Folders and directories = 755
Individual files = 644
To set your file permissions, log in to your cPanel’s File Manager or connect to your server via FTP. Once inside, you’ll see a list of your existing file permissions (as in the following example generated using the Filezilla FTP program):
The final column in this example displays the folder and file permissions currently assigned to the website’s content. To change these permissions in Filezilla, simply right click the folder or file in question and select the “File permissions” option. Doing so will launch a screen that allows you to assign different permissions using a series of checkboxes:
Although your web host’s or FTP program’s backend might look slightly different, the basic process for changing permissions remains the same. If you have any questions about modifying your folder and file permissions, please see this helpful link. Don’t put off taking this important step – securing your site using all of these different strategies is a big part of keeping your site healthy and safe in the long run!
It may seem obvious, but ensuring you keep all software up to date is vital in keeping your site secure. This applies to both the server operating system and any software you may be running on your website such as a CMS or forum. When website security holes are found in software, hackers are quick to attempt to abuse them.
If you are using a managed hosting solution then you don't need to worry so much about applying security updates for the operating system as the hosting company should take care of this.
If you are using third-party software on your website such as a CMS or forum, you should ensure you are quick to apply any security patches. Most vendors have a mailing list or RSS feed detailing any website security issues. WordPress, Umbraco and many other CMSes notify you of available system updates when you log in.
02. SQL injection
SQL injection attacks are when an attacker uses a web form field or URL parameter to gain access to or manipulate your database. When you use standard Transact SQL it is easy to unknowingly insert rogue code into your query that could be used to change tables, get information and delete data. You can easily prevent this by always using parameterised queries, most web languages have this feature and it is easy to implement.
Consider this query:
"SELECT * FROM table WHERE column = '" + parameter + "';"
If an attacker changed the URL parameter to pass in ' or '1'='1 this will cause the query to look like this:
"SELECT * FROM table WHERE column = '' OR '1'='1';"
Since '1' is equal to '1' this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed.
03. XSS
Cross site scripting is when an attacker tries to pass in JavaScript or other scripting code into a web form to attempt to run malicious code for visitors of your site. When creating a form always ensure you check the data being submitted and encode or strip out any HTML.
04. Error messages
Be careful with how much information you give away in your error messages. For example if you have a login form on your website you should think about the language you use to communicate failure when attempting logins. You should use generic messages like “Incorrect username or password” as not to specify when a user got half of the query right. If an attacker tries a brute force attack to get a username and password and the error message gives away when one of the fields are correct then the attacker knows he has one of the fields and can concentrate on the other field.
05. Server side validation/form validation
Validation should always be done both on the browser and server side. The browser can catch simple failures like mandatory fields that are empty and when you enter text into a numbers only field. These can however be bypassed, and you should make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted into the database or could cause undesirable results in your website.
06. Passwords
Everyone knows they should use complex passwords, but that doesn’t mean they always do. It is crucial to use strong passwords to your server and website admin area, but equally also important to insist on good password practices for your users to protect the security of their accounts.
As much as users may not like it, enforcing password requirements such as a minimum of around eight characters, including an uppercase letter and number will help to protect their information in the long run.
Passwords should always be stored as encrypted values, preferably using a one way hashing algorithm such as SHA. Using this method means when you are authenticating users you are only ever comparing encrypted values. For extra website security it is a good idea to salt the passwords, using a new salt per password.
In the event of someone hacking in and stealing your passwords, using hashed passwords could help damage limitation, as decrypting them is not possible. The best someone can do is a dictionary attack or brute force attack, essentially guessing every combination until it finds a match. When using salted passwords the process of cracking a large number of passwords is even slower as every guess has to be hashed separately for every salt + password which is computationally very expensive.
Thankfully, many CMSes provide user management out of the box with a lot of these website security features built in, although some configuration or extra modules might be required to use salted passwords (pre Drupal 7) or to set the minimum password strength. If you are using .NET then it's worth using membership providers as they are very configurable, provide inbuilt website security and include readymade controls for login and password reset.
07. File uploads
Allowing users to upload files to your website can be a big website security risk, even if it’s simply to change their avatar. The risk is that any file uploaded however innocent it may look, could contain a script that when executed on your server completely opens up your website.
If you have a file upload form then you need to treat all files with great suspicion. If you are allowing users to upload images, you cannot rely on the file extension or the mime type to verify that the file is an image as these can easily be faked. Even opening the file and reading the header, or using functions to check the image size are not full proof. Most images formats allow storing a comment section which could contain PHP code that could be executed by the server.
So what can you do to prevent this? Ultimately you want to stop users from being able to execute any file they upload. By default web servers won't attempt to execute files with image extensions, but it isn't recommended to rely solely on checking the file extension as a file with the name image.jpg.php has been known to get through.
Some options are to rename the file on upload to ensure the correct file extension, or to change the file permissions, for example, chmod 0666 so it can't be executed. If using *nix you could create a .htaccess file (see below) that will only allow access to set files preventing the double extension attack mentioned earlier.
deny from all
<Files ~ "^\w+\.(gif|jpe?g|png)$">
order deny,allow
allow from all
</Files>
Ultimately, the recommended solution is to prevent direct access to uploaded files all together. This way, any files uploaded to your website are stored in a folder outside of the webroot or in the database as a blob. If your files are not directly accessible you will need to create a script to fetch the files from the private folder (or an HTTP handler in .NET) and deliver them to the browser. Image tags support an src attribute that is not a direct URL to an image, so your src attribute can point to your file delivery script providing you set the correct content type in the HTTP header. For example:
// Fetch image filename from database based on $_GET["id"]
...
// Deliver image to browser
Header('Content-Type: image/gif');
readfile('images/'.$fileName);
?>
Most hosting providers deal with the server configuration for you, but if you are hosting your website on your own server then there are few things you will want to check.
Ensure you have a firewall setup, and are blocking all non essential ports. If possible setting up a DMZ (Demilitarised Zone) only allowing access to port 80 and 443 from the outside world. Although this might not be possible if you don't have access to your server from an internal network as you would need to open up ports to allow uploading files and to remotely log in to your server over SSH or RDP.
If you are allowing files to be uploaded from the Internet only use secure transport methods to your server such as SFTP or SSH.
If possible have your database running on a different server to that of your web server. Doing this means the database server cannot be accessed directly from the outside world, only your web server can access it, minimising the risk of your data being exposed.
Finally, don't forget about restricting physical access to your server.
09.SSL
SSL is a protocol used to provide security over the Internet. It is a good idea to use a security certificate whenever you are passing personal information between the website and web server or database. Attackers could sniff for this information and if the communication medium is not secure could capture it and use this information to gain access to user accounts and personal data.
Use an SSL certificate
10. Website security tools
Once you think you have done all you can then it's time to test your website security. The most effective way of doing this is via the use of some website security tools, often referred to as penetration testing or pen testing for short.
There are many commercial and free products to assist you with this. They work on a similar basis to scripts hackers will use in that they test all know exploits and attempt to compromise your site using some of the previous mentioned methods such as SQL injection.
Some free tools that are worth looking at:
Netsparker (Free community edition and trial version available). Good for testing SQL injection and XSS
OpenVAS. Claims to be the most advanced open source security scanner. Good for testing known vulnerabilities, currently scans over 25,000. But it can be difficult to setup and requires a OpenVAS server to be installed which only runs on *nix. OpenVAS is fork of a Nessus before it became a closed-source commercial product.
The results from automated tests can be daunting, as they present a wealth of potential issues. The important thing is to focus on the critical issues first. Each issue reported normally comes with a good explanation of the potential vulnerability. You will probably find that some of the medium/low issues aren't a concern for your site.
If you wish to take things a step further then there are some further steps you can take to manually try to compromise your site by altering POST/GET values. A debugging proxy can assist you here as it allows you to intercept the values of an HTTP request between your browser and the server. A popular freeware application called Fiddler is a good starting point.
So what should you be trying to alter on the request? If you have pages which should only be visible to a logged in user then I would try changing URL parameters such as user id, or cookie values in an attempt to view details of another user. Another area worth testing are forms, changing the POST values to attempt to submit code to perform XSS or to upload a server side script.
Use a debugging proxy to root out vulnerabilities
Hopefully these tips will help keep your site and information safe. Thankfully most CMSes have a lot of inbuilt website security features, but it is a still a good idea to have knowledge of the most common security exploits so you can ensure you are covered.
