• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
  • Immediate Help
  • Login
  • Languages
    • English
    • Spanish
    • Portuguese

10 Tips to Improve Your Website Security

June 16, 2015Keir Desailly

548
SHARES
FacebookTwitterSubscribe

In recent years there has been a proliferation of great tools and services in the web development space. Content management systems (CMS) like WordPress, Joomla!, Drupal and so many others, allow business owners to quickly and efficiently build an online presence. Their highly extensible architectures, rich plugins, modules and extension ecosystems have made it easier than ever to get a website up and running without years of learning required.

This is undoubtedly a great thing; however, an unfortunate side effect is that now there are many webmasters who do not understand how to make sure their website is secure, or even understand the importance of securing their website. In this post, I want to share with you the top 10 steps all webmasters and website owners can (and should) take to keep their website secure.

1 – Update, Update, Update!

This is something we cannot stress enough here at Sucuri. Countless websites are compromised every day due to the outdated and insecure software used to run them. It is incredibly important to update your site as soon as a new plugin or CMS version is available. Most hacking these days is entirely automated. Bots are constantly scanning every site they can for exploitation opportunities. It is not good enough to update once a month or even once a week because bots are very likely to find a vulnerability before you patch it. Unless you are running a website firewall, you need to update as soon as updates are released. If running WordPress, I personally recommend the plugin ‘WP Updates Notifier‘. It emails you to let you know when a plugin or WordPress core update is available. You should also follow @sucuri_security on Twitter to get notified about important updates and security warnings.

2 – Passwords

Working on client sites, I often need to log into their site/server using their admin user details and am frequently disturbed by how insecure their root passwords are. It’s scary that I have to say this, but admin/admin is not a secure username and password combination. If your password appears in this list of most common passwords, it is guaranteed that your site will be hacked at some point.

Even if your password is not on that list, there are a lot of misconceptions about “strong” passwords. The lax requirements on most password strength meters are part of the problem. Our friends at WP Engine have put together some interesting research that debunks many of the myths surrounding passwords.

When it comes to choosing a password there are 3 key requirements that should always be followed (CLU – Complex, Long, Unique):

  • COMPLEX: Passwords should be random. Do not let someone hack your account just because they could find out your birth date or favorite sports team. Password-cracking programs can guess millions of passwords in minutes. If you have real words in your password, it isn’t random. You might think you are clever for using leetspeak (letters replaced with characters L1K3 TH15) but even these are not as secure as a completely random string of characters. Hackers have compiled some seriously impressive word lists for cracking passwords.
  • LONG: Passwords should be 12+ characters long. I know some in the security community would scoff at a 12 character password and insist that passwords should be longer. However, when it comes to online login systems, any system that is following simple security guidelines should limit the number of failed login attempts. If there is a limit on the number of failed login attempts, a 12 character password will easily stop anyone from guessing it in just a few attempts. Having said that, the longer the password, the better.
  • UNIQUE: Do not reuse passwords! Every single password you have should be unique. This simple rule dramatically limits the impact of any password being compromised. Having someone find out your FTP password should not enable them to log in to your email or internet banking account. Contrary to popular belief, we are not as unique as we believe ourselves to be; if you can randomly generate the password, even better.

Now I can already hear you ask, “how am I supposed to remember 10 random passwords which are all 12 characters long?” The good news is you don’t need to remember them all, and in fact, you should not even try. The answer is to use a password manager such as “LastPass” (online) and “KeePass 2” (offline). These brilliant tools store all your passwords in an encrypted format and can easily generate random passwords at the click of a button. Password managers make it much easier to use strong passwords than it is to memorize a couple of decent passwords.

Yes, these password managers can present challenges and a possible weak point. Just this week LastPass announced a compromise. Not all compromises are the same though (more on this another time).

3 – One Site = One Container

I understand the temptation. You have an ‘unlimited’ web hosting plan and figure why not host your numerous sites on a single server. Unfortunately, this is one of the worst security practices I commonly see. Hosting many sites in the same location creates a very large attack surface.

For example, a server containing one site might have a single WordPress install with a theme and 10 plugins that can be potentially targeted by an attacker. If you host 5 sites on a single server now an attacker might have three WordPress installs, two Joomla installs, five themes and 50 plugins that can be potential targets. To make matters worse, once an attacker has found an exploit on one site, the infection can spread very easily.

Not only can this result in all your sites being hacked at the same time, it also makes the cleanup process much more time consuming and difficult; the infected sites can continue to reinfect one another in an endless loop.

After the cleanup is successful, you now have a much larger task when it comes to resetting your passwords. Instead of just one site, you have a number of them. Every single password associated with every website on the server must be changed after the infection is gone: all of your Content Management System (CMS), database, and File Transfer Protocol (FTP) users for all of those websites. If you skip this step, the websites could all be reinfected again and you are back to square one.

4 – Sensible User Access

This rule only applies to sites that have multiple logins. It’s important that every user has the appropriate permission they require to do their job. If they require escalated permissions momentarily, grant it, then reduce it once the job is complete. This is a concept known as Least Privileged.

For example, if you have a friend that wants to write a guest blog post for you, make sure their account does not have full administrator privileges. Your friend’s account should only be able to create new posts and edit their own posts because there is no need for them to be able to change website settings.

Having carefully defined access will limit any mistakes that can be made. It reduces the fallout of compromised accounts and can protect against the damage done by ‘rogue’ users. This is a frequently overlooked part of user management: accountability and monitoring. If people share a user account and an unwanted change is made by that user, how do you find out which person on your team was responsible?

Once you have separate user accounts for every user, you can keep an eye on user behavior by reviewing logs and knowing the usual behavior (when and where they normally access the website) so you can spot anomalies and confirm with the person that their account hasn’t been compromised.

5 – Change the Default CMS Settings!

Today’s CMS applications, although easy to use, are horrible from a security perspective for the end users. By far the most common attacks against websites are entirely automated, and many of these attacks rely on the default settings being used. This means that you can avoid a large number of attacks simply by changing the default settings when installing your CMS of choice.

For example, some CMS applications are writeable by the user – allowing a user to install whatever extensions they want. There are settings that you may want to adjust to control comments, users, and the visibility of your user information. The file permissions, which we discuss later, are another example of a default setting that can be hardened.

It is usually easiest to change these default details when installing your CMS, but they can be changed later.

6 – Extension Selection

One of the beautiful things about today’s CMS applications is its extensibility. What most don’t realize however is that that same extensibility is the biggest weakness. There are a massive number of plugins, add-ons, and extensions providing virtually any functionality you can imagine. However, the reality is that at times the massive number of extensions can be a double-edged sword. Often there are multiple extensions offering similar functionality, so how do you know which one to install? Here are the things I always look at when deciding which extensions to use.

The first thing I look for is when the extension was last updated. If the last update was more than a year ago, I get concerned that the author has stopped work on it. I much prefer to use extensions that are actively being developed because it indicates that the author would at least be willing to implement a fix if any security issues are discovered or reported. Furthermore, if an extension is not supported by the author, then it makes little sense to use it for your website as it may stop working at any time.

I also like to look at the age of the extension and the number of installs. An extension developed by an established author that has numerous installs is much more trustworthy than one that has 100 installs and has been released by a first-time developer. Not only is the experienced developer much more likely to have a good idea about best security practices, but they are far less likely to damage their reputation by inserting malicious code into their extension. More importantly, the larger the user base, the more incentive attackers have to invest in trying to break it.

It is incredibly important that you download all your extensions and themes from legitimate sources. There are many sites that offer ‘free’ versions that are normally premium and require payment to download. These ‘free’ versions are pirated and frequently infected with malware. The websites offering these ‘free’ versions are setup with only one goal: to infect as many websites as possible with their malware.

7 – Backups

Like anything in the digital world, it can all be lost in a catastrophic event. We often don’t back up enough, but you will thank yourself if you take some time to consider the best website backup solutions for your website.

Making backups of your website is very important, but storing these backups on your web server is a major security risk. These backups invariably contain unpatched versions of your CMS and extensions which are publicly available, giving hackers easy access to your server.

If you’re interested in learning how to make reliable and secure backups of your website, I recommend you read my website backup strategy guide.

8 – Server Configuration Files

You should really get to know your web server configuration files. Apache web servers use the .htaccess file, Nginx servers use nginx.conf, and Microsoft IIS servers use web.config. Most often found in the root web directory, these files are very powerful. These files allow you to execute server rules, including directives that improve your website security.

If you aren’t sure which web server you use, you can run your website through Sitecheck and click the Website Details tab.

Here are a few rules that I recommend you research and add for your particular web server:

  • Prevent directory browsing: This prevents malicious users from viewing the contents of every directory on the website. Limiting the information available to attackers is always a useful security precaution.
  • Prevent image hotlinking: While this isn’t strictly a security improvement, it does prevent other websites from displaying the images hosted on your web server. If people start hotlinking images from your server, the bandwidth allowance of your hosting plan might quickly get eaten up displaying images for someone else’s site.
  • Protect sensitive files: You can set rules to protect certain files and folders. CMS configuration files are one of the most sensitive files stored on the web server as they contain the database login details in plain text. There may be other locations that can be locked down such as admin areas. You can also restrict PHP execution in directories that hold images or allow uploads.

There are many more rules and options that you can look into for your web server configuration file. You can search for the name of your CMS, your web server and “security” but make sure to confirm your findings are legitimate before implementing anything. Some people post bad information online with malicious intent.

9 – Install SSL

I’m actually of two minds as to whether or not to include this point because there have been so many articles incorrectly stating that installing SSL will solve all your security issues. SSL does nothing to protect your site against any malicious attacks, or stop it from distributing malware. SSL encrypts communications between Point A and Point B – the website server and browser. This encryption is important for one specific reason: it prevents anyone from being able to intercept that traffic, known as a Man in the Middle (MITM) attack.

SSL is especially important for E-Commerce website security and any website that accepts form submissions with sensitive user data or Personally Identifiable Information (PII). The SSL certificate protects your visitor’s information in transit, which in turn protects you from the fines that come along with being found noncompliant with PCI DSS.

If you are thinking about installing SSL on your site, you can follow our guide to learn more and get a free SSL certificate.

10 – File Permissions

File permissions define who can do what to a file.

Each file has 3 permissions available and each permission is represented by a number:

  • ‘Read‘ (4): View the file contents.
  • ‘Write‘ (2): Change the file contents.
  • ‘Execute‘ (1): Run the program file or script.

If you want to allow multiple permissions you just need to add the numbers together, e.g. to allow read (4) and write (2) you set the user permission to 6. If you want to allow a user to read (4), write (2) and execute (1) then you set the user permission to 7.

There are also 3 user types:

  • Owner – Usually the creator of the file, but this can be changed. Only one user can be the owner.
  • Group – Each file is assigned a group, and any user who is part of that group will get these permissions.
  • Public – Everyone else.

So, if you want the owner to have read & write access, the group to have only-read access, and public to have no access, the file’s permissions settings should be:

Write Read Execute
Owner 2 4 0
Group 0 4 0
Public 0 0 0

When you view the file permissions this will be shown as 640.

Folders also have the same permissions structure; the only difference being that the ‘execute’ flag allows you to make the directory your working directory (so you usually want it on).

Most CMS installs have all the permissions correctly configured by default, so why did I just spend so much time explaining how permissions work? When searching for solutions to permissions errors, all over the web you will find people advising you to change file permissions to 666 or folder permissions to 777. This advice will usually fix any permissions errors, but it is terrible advice from a security perspective. If you set a file permission to 666 or folder permission to 777 you have just allowed *anyone* to insert malicious code or delete your files!

Conclusion

So there you have it! The top 10 relatively simple steps you can take to dramatically increase the security of your website. While these steps alone will not guarantee that your site is never hacked, following them will stop the vast majority of automated attacks, reducing your overall risk posture.

Being aware of these issues and understanding them will provide you with valuable insight into how the underlying technology works and help to make you a better webmaster/site operator.

548
SHARES
FacebookTwitterSubscribe

Categories: Ask Sucuri, Security Education, Website Firewall, Website SecurityTags: Best Practices, PCI Compliance, Permissions

About Keir Desailly

Keir is a Firewall Analyst at Sucuri. He has been playing with computers since the C64 and his main technical interest is in security and web development. He loves to think about web security so that users don't have to. He shares his time between Australia and Thailand and on his off hours he geeks out over music. Follow him on Twitter at @KeirD20.

Reader Interactions

Comments

  1. Dan Procter

    June 17, 2015

    Thanks for this Keir will definitely be referring to it with my customers

  2. Earl Grey

    June 17, 2015

    SSL is NOT a great idea. SSL works by sending you the certificate, if you get it, so does someone else if they’re monitoring the network. SSL proxies have been around for at least 10 yrs and they ARE the man in the middle. SSL also requires more data to be transferred and puts more load on the server (and the receiver). To put it bluntly, SSL is a scam perpetuated by the SSL certificate issuing companies, no one has actually bothered to sit down and question it, people just blindly say what has always been said, even Google are now perpetuating this myth by increasing rankings for SSL sites. You could say that SSL is actually WORSE than no security at all, because it makes people think they are secure when they’re not.

    • Jeff

      June 17, 2015

      Regardless of what you might think about SSL Google will begin favoring sites that use it. There’s also a movement gaining steam (see Electronic Frontier Foundation) to encourage all site owners to encrypt their traffic using SSL signed with soon-to-be freely available SSL certificates.

    • Todd

      June 17, 2015

      Earl,

      You are very misinformed about the way SSL works. You are correct about the additional load that it places on the server however the rest is incorrect. Some people claim that EV SSL’s are scams, but that’s because of the additional cost for no additional security. In the case of an EV the insurance is much higher. You’re paying for an insurance policy.

      As for your claim of SSL proxies, here’s how it works: A secure connection is based on public/private-key cryptography. The public key is used for encryption and the secret private key is required for decryption. A certificate is a public key with a label identifying the owner. When your browser connects to an https server, the server will answer with its certificate. The browser checks if the certificate is valid.

      In the case of a malicious proxy, the proxy is not in the possession of the matching private key. So if the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver.

      The proxy server may try to forge the certificate and provide his own public key instead. This will, however, destroy the signature of the certification authorities. The browser will warn about the invalid certificate.

      The problem is truly the end user that ignores the warning that their connection is or might be insecure. It’s not the premise that SSL doesn’t work.

      Todd

  3. Todd

    June 17, 2015

    Keir,

    Thanks for the article. The only thing I disagree with is the verbiage of #3, One Site = One Server. Any form of shared hosting is more than one site on one server. Furthermore, any VPS is more than one site on one server. The only way to truly have one site on one server would be to purchase a dedicated server and only put one site on it. I think what you mean here is One Site = One Container.

    Web design companies are especially to blame for placing multiple websites in one container or “package”. Many of them offer hosting to their clients which is only a single shared hosting container with multiple sites. The container shares the same user to authenticate across any of the domains. This leaves the door open for all kinds of bad things.

    As you mentioned, the difference between the sites are usernames and passwords to FTP accounts and databases. That can multiply the mess of just a website infection to a slew of account and database infections.

    On a side note, there is no such thing as unlimited hosting. All web hosting providers have limits on their “unlimited” usage. Read the fine print for any shared hosting plan and you’ll see that they have the power to disable your account for excessive usage. Point being, you not only put the security of all websites at risk, but you put the sites at risk of being terminated for, not so unlimited, “unlimited”.

    While all of the points are great the ones that we see most breaches with are outdated plugins and weak passwords.

    For those that don’t have the time or knowledge to update your site and plugins there’s a handful of companies out there that offer update services for a nominal fee. WireFlare (our company) is one of those that will provide daily checks for updates of your website and plugins.

    As for passwords, use something like LastPass to generate and store secure passwords, you can also subscribe to the Sucuri WAF which has the option to prevent admin logins and brute force attempts on the website.

    Todd

    • Keir Desailly

      June 18, 2015

      +1 great comment Todd.

      Yes, I agree, container is a better way to describe it. ‘Unlimited hosting’ is also a pet peeve of mine, I much prefer hosts that clearly define the resource limits. Not only do you know exactly what you are purchasing but they also tend to perform better.

    • Cathy Tibbles

      March 13, 2016

      I couldn’t agree more Todd. I’m one such designer. And although I’m very unqualified to handle server administration, I at least can open up a reseller account, and give everyone their own legal account. Not only does that separate containers, but it also makes them legally responsible for their content, and not me!

  4. Andy Kinsey

    June 17, 2015

    Great article Keir!

  5. replentor

    June 17, 2015

    One site – one server

    Are you suggesting the demise of platforms such as cPanel & plesk despite site segregation via secure linux accounts & db logins?

    My understanding is that a compromised site cannot compromise further sites in such a setup unless it can gain elevated access to a root account and there’s no reason to think wp installs, compromised or otherwise, would facilitate that

    • Keir Desailly

      June 18, 2015

      cPanel and Plesk are fine, the problem occurs when multiple sites are hosted in one container.

      • Salvador Aguilar

        August 12, 2016

        Elaborating further, on cPanel if you have addon domains and host several websites on the same cpanel account you are subject to a cross site contamination. A good analogy is having 3 kids on the same room, one gets sick with a cold, it is very very likely that the other 2 will be cross contaminated. And if you only provide medication to one, it will still get sock after the medication duento the other two. Same case with websites, 3 websites on the same cPanel can be infected & compromised if only of them is hacked.

  6. Arthur Pemberton

    June 17, 2015

    In reference to #3, “One Site = One Server”, the use of `php_admin_value open_basedir` will significantly mitigate this problem.

    • Keir Desailly

      June 18, 2015

      Very nice tip, thanks.

  7. Jatin Waichal

    June 17, 2015

    Great article Keir. You have included simple and basic techniques which most of the website administrators ignore. I myself also have seen big organisations having admin passwords which you have mentioned above. For some reason they tend to ignore the warning of changing the password. Thanks for the article mate!

  8. Mohamed Ayad

    June 29, 2015

    “3 – One Site = One Container” No longer issue with cloudlinux, many shared hosting company using visualization with their shared hosting service.

    • Todd

      June 29, 2015

      The point is not to put more than one website in a single container. Regardless of how those containers are provisioned. If you have more than one website in a single container you are asking for problems. I think you’re misinterpreting the point here.

  9. Jaintechnosoft

    December 29, 2015

    Nice one,For every websites Security is must and all should know how to keep our sites safe and protect from hackers.

  10. Marko Heijnen

    February 11, 2016

    Ask your host what they do to protect you.
    People like to add security plugins (which can have security issues) and some rewrite wp-login.php to something else. Which means that they could not be protected anymore by there hosts who already was securing that one (as good as they can).

  11. Mayuresh

    February 11, 2016

    Every application that accepts user input and has a backend database should have a different user with the least privileges possible and should not be your root user.

  12. Sameer Singh

    August 2, 2017

    Security forms the foundation of financial services industry. Aside from convenience, keeping customer information secure is biggest responsibility and your blog is going to help us for this so thanks for this.

  13. Shwetha

    December 11, 2017

    Great Article Keir

  14. Humble & Rich Boutique

    January 16, 2018

    Are you suggesting that we should not host 10 websites under a dedicated server? What should we do then.. to get 10 different shared hosting? I mean, isn’t shared hosting the same theory.

    And do you have any idea how to change the default wordpress login: /wp-admin or wp-login ?

    Any advise and suggestion will be greatly appreciated 🙂

    • Todd

      January 16, 2018

      They are not the same. What is really being discussed here is that many people put multiple domains or websites under a single tenancy within a shared hosting environment. In other words you purchase shared hosting for $xx from a hosting provider and then you place multiple websites in that shared hosting instance. This exposes all of those websites to the same vulnerabilities as they are all within the same tenancy and accessible by the same user. If a malicious script is executed in one website the ownership of the other websites is the same and therefore can be exploited as well.

      This is mainly an issue with smaller web development firms that often times purchase a small hosting package from hosting provider and then cram multiple customers into that single instance to maximize revenue at the expense of the customer. This exposes all of said customers to the same risk. I have been able to access files and databases through this method to prove the ease of exploit a number of times. I’ve blogged about it as well.

      If you have a dedicated server and understand how to setup a server to host multiple tenants then bravo. Another option would be to purchase a dedicated server and then a license to Plesk or CPanel and let those applications control the chrooted environments of the tenants. If you don’t want to go this route then I, and many others, would strongly recommend that you place each website in it’s own shared hosting environment unless they are all owned by you and you don’t care about them being jeopardized.

      As for your other question about changing the WordPress login URL, well Google is your friend here. There’s a ton of articles and plugins to assist with this.

      • Humble & Rich Boutique

        January 31, 2018

        Thank you for your thorough reply 🙂 Really appreciate it!

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Sucuri website security

Join Over 20,000 Subscribers!

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2018 Sucuri Inc. All rights reserved