Secure your site

Last update by Elxis Team

Things to do to strengthen security on an Elxis powered site.

Web site security is a complex subject that depends on many factors, human included. In this article we will focus mostly on the application security (Elxis CMS). Which features does Elxis have to strengthen your site's security? What configuration options are available? What else you can do to feel safer? In Elxis we consider security as our first priority. Elxis should first be secure and then anything else. Please read this article carefully and take any necessary steps to strengthen your Elxis security. Don't forget that no matter how strong Elxis is against web attacks, it is you, the web site administrator, the most important security factor.

Factors that affects site's security

Some sites are more likely to be attacked while others not. There are some basic factors that affect this risk level. These factors, based on my personal experience [1], can be seen bellow.

  1. Bad luck.
  2. Site profile.
  3. Site administrator.
  4. Application security (Elxis in our case).
  5. Web server.

You might be surprised but the most common reason for a web site to be attacked is bad luck. Most web attacks are blinds attacks (initiated by google search, scanners, etc). The second more common reason for a site to be attacked is its profile. Here you will find 2 kind of hackers, ethical and unethical. If, for example, your site express hate against other people it is very likely that one day you will be attacked by "crusaders" from the other side. The administrator plays a key role on a site's security. Does he keeps basic security rules? Is he informed about web site and server security rules? Is his computer virus free? How securely uses the internet in general? Some of his habits might be lethal to his site! The application, Elxis in our case, is the next security factor. Is it secure? Is it updated? Is it well configured? Finally the web server should be properly configured and unnecessary features that may be used as Troyan horses disabled.

An interesting thing to notice on this list is that starting from the bottom and moving up, the previous factor can be the cure for the next one in case of a security hole. For instance the application (Elxis) can be a protection layer for the administrator bad habits. Unfortunately the opposite can happen too. For instance the web server can maximize a security hole in the application. So, lower things in the list affects upper ones. Think of it.

Security related configuration options

  • Repository path Elxis stores temporary and other private files in a folder by default named as repository. It is strongly recommended to rename this folder and/or move it to a location not accessible from the web. After you do so edit Elxis configuration and set the absolute path to the new location of repository.
  • Technical manager Elxis will send error and security related email alerts to this person.
  • Users registration If you dont want visitors to create new accounts on your site disable users registration.
  • Account activation Set it to e-mail or manually by the administrator.
  • Registration allowed domain Fill in a domain name only from which Elxis will accept registration emails. If for example you fill-in your organization email domain example.com then only users having email account at example.com will be able to register new user accounts.
  • Registration exclude domains Comma separated email domains to exclude from registration (example: badsite.com,hacksite.ru,etc...)
  • Password recovery If you don't wont users having forgotten their passwords to reset their passwords by themselves disable this option. In this case you will have to reset their password by your self by editing their profile.
  • SSL You can enable the SSL switch (from http to https) for Elxis administration section only or for both Elxis administration and frontend sections. In the administration area the SSL will be permanent while in frontend it will be switched to ON only on pages where privacy is important (Elxis will do this automatically).
  • Debug On online sites always have debug disabled!
  • Error report If enabled it will echo errors on the browser. On online sites always have it disabled!
  • Error alert Error messages will be send to the site's technical manager via email. There are 3 alert levels, Errors: send notifications only for fatal and security errors, Warnings: send notifications for Error + Warnings and Notices: send notifications for Errors + Warnings + Notices.
  • Error log Same as for Error alert but instead of sending emails to the technical manager logs them into the log files. By checking your error log files regularly you can fix errors happening in your site even by non existing images. It is an good way to keep a site producing absolutely zero errors.
  • Session handler Prefer picking database
  • Session encryption If enabled session data will be stored encrypted. So even if someone access session data he wont be able to read them. Encryption will slow down a little the session handling process.
  • Session match IP Enables session validation by checking user IP address.
  • Session match browser Enables session validation by checking user browser signature.
  • Session match browser Enables session validation by checking user HTTP referrer.
  • Security level You can pick one of the 3 Elxis security levels: Normal (recommended), High and Insane. The higher security level is the tighter security restrictions will be applied. Read the security levels comparison table shown bellow for more.
  • Elxis Defender Protects Elxis against web attacks by filtering user input. Elxis Defender has several options you can enable. Read more about Elxis Defender.

Security levels comparison


Security levels comparison
Feature Normal High Insane
Session hash algorithm MD5 SHA1 SHA1
Access cookies protocol Any Any HTTP
Force enable session match browser No No Yes
Force enable Elxis defender No Yes, rules G, C and F Yes, all rules
Force enable session encryption No No Yes
Session regeneration On login On every click for logged in users On every click for logged in users
Access level required to access backend >=70 >=70 100
Install extensions Allowed Only by admins Only by admins
Uninstall extensions Allowed Not allowed Not allowed
Password recovery Yes Yes, no for admins Not allowed
Repository in Elxis root folder Allowed Allowed Not allowed
Block users Allowed Allowed Not allowed
Delete users Allowed Not allowed Not allowed
Users can change their email Yes Yes No
Manage ACL lists Any group allowed by ACL Only admins Only admins
Delete user groups Any group allowed by ACL Only admins Only admins
Delete ACL elements Any group allowed by ACL Only admins Only admins

More on Elxis Defender

Filtering options for Elxis Defender

  • G (general) generic filters mostly against SQL, XSS and directory traversal attacks.
  • C (custom) custom filters added by the site administrator.
  • P (post) extends check on POST variables.
  • H (hostname) Check if the visitor's hostname belongs to one of the blocked networks.
  • I (ip) Check if the visitor's IP address belongs to one of the blocked networks.
  • A (user agent) Check if the visitor's user agent belongs to one of the blocked user agents.
  • F (files) Locks Elxis filesystem. If a protected file is deleted or modified a security alarm is triggered and the site becomes non available till the site administrator restores the original file.

The F option

After enabling the Defender's F (files) option Elxis will generate a fingerprints file in Elxis repository containing the hashes for all protected files. The protected files are index.php, inner.php, Elxis loader, all template's index.php files, and all Elxis libraries. If any of these files is modified Elxis Defender triggers a security warning. If you need to modify a protected file (for example a template's file) after you do so, delete the fingerprint file in order for Elxis Defender to re-generate it and re-calculate the new hash value of that file. If you don't do so Elxis Defender will be triggered as the new hash value of the modified file wont match any more the saved value. In case of a security alert in order for the web site to turn back online either replace the modified file with the original one (in case of a real attack) or (if you accidentaly banned yourself) either disable the F option by editing the configuration file or delete the fingerprints file in order Elxis to re-generate it with the new hashes.

Ban and unban

Depending on the severity of the security alert Elxis Defender might ban someone on the first attempt or wait till the third. Bans list are stored in a special file in Elxis repository (logs/defender_ban.php). You can open this file and delete the line that corresponds to the IP you want to unban. You can also clear this file and remove all bans from Elxis Logs manager in the administration console.

Actions to strengthen security even more

Other things you can do to increase your Elxis powered site security.

  • Rename the administrator folder from estia to something custom (eg. mysecretadmin). If you have SEO PRO enabled you should edit the .htaccess file and change the admin folder there too.
  • Rename and/or move Elxis repository folder (repository/) to something custom. After this, edit configuration file and write the full path to the new repository to the REPO_PATH configuration variable.
  • If you have an SSL certificate installed enable the SSL switch at least for the administration section. Dont enable SSL switch for the frontend section unless you know how to work on a mixed http/https site.
  • Enable error logging for notices and inspect logs files regularly. Fix any warnings you see there.
  • Take regularly files and database backups. You can easily take backups from within Elxis administration console and download them in your computer.

Access Control Lists (ACL)

Elxis controls access to various elements with a system called ACL. Elxis ACL is built specifically for Elxis, it is powerful, easy configurable and extendable. Each ACL rule describes the element for which we grand or decline access. These elements are grouped into categories. Some elements can have more than one instances (modules for example can be copied) so it is required for those to define their exact id. A schematic representation of an ACL rule can be seen bellow.

Category -> Element -> Identity -> Action -> Who -> Grand/Decline access

As an example implementation of the above format we will provide view access to component Sample to registered users and above (users having a minimum access level = 2).

component -> com_sample -> 0 -> view -> Access level >= 2 -> 1 (allowed)

And the PHP code required to check someone's access to this element.

if (eFactory::getElxis()->acl()->check('component', 'com_sample', 'view') > 0) {
	//provide access
}

Common security mistakes

  • Forget to logout when finish working as a logged in user.
  • Having multiple tabs opened in the web browser with mixed secure and insecure sites. For example dont login in Elxis admin when you simultaneously visit a porn site.
  • Add content immediately after Elxis installation without first configuring Elxis it self and the built in extensions to match your needs.
  • Use of an insecure / outdated web browser.
  • Having installed in the browser toolbars and plugins from untrusted vendors. The web browser is a tool, not a game. Dont install crap on it. All toolbars are spy tools. Third parties track your browsing habits and if the toolbar/plugin developer wishes he can easily get your passwords...
  • Having weak passwords or use the same username/password everywhere you keep a user account. Use different credentials at least for the important services.
  • Publishing your e-mail in clear text
  • Visiting porn, hack, and other suspicious sites without private browsing enabled (Firefox).

Notes

  • [1] The article presents the opinion of its author, Ioannis Sannos.
It has been read 14128 times
Getting backups
Next article
Getting backups