Security in kiwitrees means ensuring your site is safe from unwanted intrusions, hacking, or access to data and configuration files.

The developers of kiwitrees regard security as an extremely important part of its development and have made every attempt to ensure your data is safe.

The area most at risk of intrusion would be the /data folder that contains your config.ini.php file, and various temporary files. If you are concerned there may be a risk there is a very simple test you can do: try to fetch config.ini.php by typing http:// url to your site /data/config.ini.php in your web browser.

The most likely result is an “access denied” message like this:

This indicates that the protection built into kiwitrees is working, and no further action is required.

In the unlikely event you do fetch the file (you will just see a semicolon), then that protection is not working on your site and you should take some further action.

If your server runs PHP in CGI mode, then change the permission of the /data directory to 700 instead of 777. This will block access to the httpd process, while still allowing access to PHP scripts.

This will work for perhaps 99% of all users. Only the remaining 1% should consider the most complex solution, moving the /data/ directory out of accessible web space. (Note: In many shared hosting environments this is not an option anyway.)

If you do find it necessary, following is an example of the process required:

If your home directory is something like /home/username,
and the root directory for your web site is /home/username/public_html,
and you have installed kiwitrees in the public_html/kiwitrees directory,
then you would create a new data folder in your home directory at the same level as your public_html directory, such as /home/username/private/data, and place your GEDCOM (family tree) file there.

Then change the Data file directory setting on the Admin –> Site Administration page from the default data/ to the new location /home/username/private/data

You will have two data directories:

• [path to kiwitrees]/data – just needs to contain config.ini.php
• /home/username/private/data – contains everything else

[small_full]Hypertext Transfer Protocol Secure (HTTPS) [/small_full]

Kiwitrees supports https access. If your website is configured with mandatory or optional https support kiwitrees will operate correctly in either mode.

If your website is configured with optional https support, kiwitrees can be configured to switch to https at login. To enable https at login, set the Login URL setting on the Admin –> Site Administration –> Configuration page to your https login URL, which is often in the form https://example.com/admin.php (substitute your domain for example.com). Warning: misconfiguration can disable your login links. If this occurs, access the login by typing the correct URL directly into your browser’s address input.

For more information read THIS BLOG POST.

[small_full]Spam and hacking attempts[/small_full]

Before you even start to consider these issues, ensure that your server, whether your own or a web hosts, has good server level protections to prevent unwanted attacks by the many hundreds of spammers and hackers trawling the internet every second of every day looking for gaps in website defences. The following features of kiwitrees can enhance server-level protections, but NOT replace them.

With that out of the way, lets now look at the definitions of “spamming” and “hacking”:

Spamming is the use of messaging systems to send an unsolicited message (spam), especially advertising, as well as sending messages repeatedly on the same site.

Ref: Wikipedia

Computer hacking refers to the practice of modifying or altering computer software and hardware to accomplish a goal that is considered to be outside of the creator’s original objective.

Ref: Cyber law

So, it is clear from these definitions that the primary place to protect against hacking is your web server. So talk to your web host if you are unsure how that is configured. But kiwitrees does also play an important role. Its code is designed to protect your site from intrusion via the software. Using industry standard methodologies, and (reasonable) restrictions on you and your user’s abilities to accidentally provide routes into your system for hackers. The majority of this is in the code, and cannot be modified or configured by you. However, there is the Administration > Site administration > Site access rules page to help in this battle. This can be used to limit access from a range of IP addresses and “user-agent strings”. More information on this complex tool is available at the FAQ for that page.

Spam attacks are generally more annoying (intensely) than dangerous, although you shouldn’t underestimate their risk.  Their major source is through kiwitrees itself, via either (or both) your new user registration page, or your “contact” page.

1. User registration. The key to preventing spam attacks such as multiple bogus registrations is administrative vigilance. Kiwitrees requires admin approval of all new registrations. Options for automatic or self-approval were removed from the system as one of the earliest changes after kiwitrees split from webtrees. Use that process to assure yourself the new user has a legitimate reason for accessing your private data. In addition, since kiwitrees 3.3.4 the “blocked emails” feature can also be used to limit attacks by known repeat offenders. (Administration > Site administration > Site configuration > Login & Registration tab).
2. Contact spam. Your contact pages or the links in your site’s footer area are popular spam entry points. These are harder to control, as one of their purposes for being there is to foster communication with potential new family members. Kiwitrees has always had a couple of features to help manage these. Attempts to include links in HTML code are blocked; contacts from non-existent email domain addresses are ignored, as are badly-formed email addresses (for example those without the necessary ‘@’ letter). As above, since kiwitrees 3.3.4 the “blocked emails” feature can also be used to limit attacks by known repeat offenders. (Administration > Site administration > Site configuration > Login & Registration tab).
3. For both of the above areas, from kiwitrees 3.3.4 there is additional error logging. This will help you see more clearly what is going on behind the scenes of your registration and contact processes, and the number of attacks being blocked. The simplest way to view these, at Administration > Site administration > Logs and just enter “spam” in the ‘Message’ filter box. You will see a range of entries indicating rejected attempts to access your site for spam purposes. Don’t be surprised if the list is long. It’s a sad but inevitable part of the internet these days, and better they are on that list than actually succeeding in breaching your defences!

[clear]