Site Map Mara Editing Advanced Step by step

Security Enhancements

Mara is already designed with security in mind. The Web is a hostile environment, and the level of security which would be acceptable on an internal LAN is generally inadequate here. That said, the distribution package has to be supplied in such a format that it is reasonably easy to get started with it. Once the site is up and running, you may wish to consider making a few changes which further increase security.

The choice of a file-based CMS is one of the most positive steps you can take towards better website security, eliminating as it does the risk of SQL code injection. However, you should not be complacent about various other security concerns which apply to all websites.

It goes without saying that non-guessable passwords should be used. Words associated with your business, car  types or regsistrations, favourite sports or team names are all bad examples of passwords. Choose something which you can remember, but no-one else would expect to find as the password.

The fact that Mara does not load the online editing components at all when in site visitor mode makes fof better security than systems which do, at the expense of a small loss of convenience which we think is justified. As do the conventional, static URLs which leave little scope for cross-site content loading or the like.

Mara employs tarpitting, such that repeated bad logins will cause its response to become progressively slower and slower. This makes bruteforce guessing or dictionary attacks much harder. Passwords in-transit between the browser and server are salted and double-encrypted, using a challenge/response mechanism. Passwords are never stored in plaintext on the server, either in memory or on disk. This part of the system took a fair amount of coding time to get the results we wanted, but we feel it's worth it for the peace of mind it gives.  No-one can guarantee that a site will never be hacked, but we feel that any hacker having-a-go at a Mara site will probably decide to try somewhere easier instead.

A few additional changes will make the site even more secure:

Change the site administrator's username
By default this is 'admin' but if you create a new administrative user with a different name, test the new login and then disable 'admin' you have a more secure system since any intruder would then have to guess the name as well as the password. The odds of success are obviously much smaller.

Change the administrative key
By default you add '?login' to a URL to go into admin/editing mode. This value is determined by the editkey value in the siteini.php file, in the sitecfg directory. Changing this to something else will make it hard for an intruder to even put Mara into login mode, let alone login. This measure is highly recommended for any security-sensitive site, as it effectively provides two-factor login. A would-be intruder needs a user's password, but also needs an item of common knowledge to site editors, one which would probably not be mentioned along with the password since it is already known to staff.

Since v2.4 it is no longer possible to view php scripts in pages with only the admin key, hence in this respect there is no longer the same degree of need for a non-default key. However, it's still good security practice.

Reduce the session timeout  (and increase the keepalive ping rate to suit)
The timeout as-supplied has to allow for slow-ish hosts. If your site connection is fast and reliable than a shorter timeout should not cause issues, and will significantly reduce the risk of 'session resurrection' exploits. See the timeout page for more details.

Change the site hash
This is the 'salt' value in siteini.php - and it should be a number from 1 to 9999. This value is now automatically randomized the first time you change the admin password, so on new sites there should be no need for any special action other than ensuring that the admin password is changed after installation. If you have upgraded a pre-v4.1 site which still uses the old arrangments, you should perhaps ask for advice before changing the value.

Restrict the IP addresses the site can be administered from
This feature is controlled by the allowed_ips and prohibited_ips values in the siteini.php security section.
Values are a complete or partial IP address in dotted quad notation, for example is acceptable, and 123.123. will encompass any IP with those as the first two octets. Multiple values are separated by commas. Prohibition overrides allowance. With both values blank there is no IP filtering.  Linklocal addresses are filtered, therefore if you access the server internally via a LAN, any allowed list must contain your local range. IPv6 is not currently supported.

The main usage here would be to restrict access to your ISP's specific IP ranges. Though, you can also restrict access to the IP ranges in use in your World region. This offers some useful protection from regions where hacking is known to be rife. It is not of course an absolute protection, since proxies can be used to get around the restriction. But, it is a useful way of keeping hostile robots out.

To avoid giving away that an IP block is in effect, the response to an admin-mode  request from a  banned IP is to present an error message which makes it look as if the site is down with a perplexing bug.

IP restrictions do not prevent the site being viewed, only edited.