3 - Configuration and Security

There are eleven settings within the configure file that have to be correctly filled in before you can get wtfm to run. They are:

users	The ID of the user, or a comma-separated list of IDs of users, that are authorized to use the documentation system. The number of user IDs listed here must match the number of passwords.
passwords	The password, or a comma-separated list of passwords, corresponding to the user or users. The number of passwords here must match the number of users. Passwords cannot contain the comma character or a newline.
logtime	The number of seconds that a login remains valid. 3600 is one hour, and 86400 is 24 hours. As a safety precaution so that you do not lose your work after leaving the documentation system open, always log out of the system when done. Otherwise, your session could time out while editing, and the information on the page would then be lost instead of saved. If you generally don't want your sessions to time out, use a very large number here, such as ten years (315576000 is 3,652.50 days) and simply log out of the system at least once within that duration so that the session time is reset.
domain	This is the root of the web address the system is using. For instance, if I was using it here on ourtimelines.com, it would be set to either ourtimelines.com or www.ourtimelines.com, depending on how I wanted to access the documentation system. Some browsers, such as Internet Explorer, behave very badly and will arbitrarily strip www. off the front of a web address. This will break anything that is looking at the domain name and expecting www. for security purposes. Because of this, I recommend not using the www. domain name prefix.
timezone	Set this to EST, CST, MST, PST, etc.
iplimit	Set this to: None You'll have no IP security if you do this A single IP address 192.168.1.90 A comma-separated list of IP addresses 192.168.1.50,192.168.1.60 A single range 192.168.1.100-150 A comma-separated list of ranges 192.168.1.70-75,192.168.1.100-150 A comma-separated list of ranges and single IPs 192.168.1.70-75,192.168.1.100-125,192.168.1.130 If not set to None, the system will only perform operations when the user is working from one of the specified IP addresses, or from an IP within one of the specified IP ranges. As an example, you might only wish to operate from IP 192.168.1.100 on your LAN. So with iplimit=192.168.1.100 set, no access from any other IP, even with the correct user and password combination, can access the system. You can elect to use a range in the last section of an IP's quad. So you can specify an IP range that extends from 192.168.1.100 to 192.168.1.150 this way: 192.168.1.100-150 You can do this with multiple IPs to set multiple ranges, and you can mix IP ranges with single IPs. Multiple IPs and/or IP ranges must be separated by commas.
xprefix	Where the CGI executes, in web context
xsystem	This will be the name of the doc system CGI. You should change this to something totally non-obvious, and rename the main wtfm CGI to that name, as this provides a measure of security-by-obscurity. If you don't do this, you'll have all manner of bots and black-hats trying to hit the CGI, and that's no good at all. Never expose a link to this CGI on any public-facing web page. That's just a good all-around policy. It's also a very good idea to keep access to it limited to within your LAN, never accessing it from outside the LAN. This prevents interception of the URL(s) and imposes one layer of security. wtfm is well suited for this; it can place the output of projects in a completely different filesystem location than where wtfm is located. I actually run my copy on a website that doesn't face the WAN, and generate to one that does. That makes my setup very secure. If you can arrange something like that, it is ideal.
dprefix	This is where editdb.py and the database are to be kept, as described in the server's filesystem context. This should be a non-obvious, custom location.
dname	The name you want used for the database. Again, this should be utterly and completely non-obvious, just as one of those security things. And again, otherwise, you'll have all manner of bots trying to hit the CGI. To use the supplied database, change this, then rename the database to the name you entered here.
config file name	If you'd like to change the name (and/or location) of the configuration file itself, you can (probably should) do that too. Once you have changed it, edit the doc_system.py (or whatever you've renamed it to) file and change the name there to match; you will see that the docsystemcfgname variable setting for it is right at the top of the Python code. That way wtfm will be able to find its configuration file under the new name. Here it is: Where to change the name of the config file

The configuration file itself also contains examples and guidance.

3.1 - Layered Security

Here are the layers of security you can utilize with wtfm:

3.1.1 - Security by Obscurity

The idea here is simple enough: Rename the doc_system.py and doc_system.cfg files so that no one can find them.

3.1.2 - Non-obvious User Names

You might think, as my name is Ben, that I'd use "ben" as my user ID. You'd be very, very wrong. Consequently, before you could move along to guessing at my password, you'd have to figure out what user name I do use.

3.1.3 - Non-obvious and Long Passwords

If your password is your birthday or your pet's name or something equally obvious, you can expect to be hacked. If your password is long, random, and you have to copy and paste it from a text file because you can't even remember it, you might have a secure enough password. Maybe.

• This is a lousy password: fido
• This is a good password: hfyrn#d83jF6xr4eh30dmE$gcx5eh(fry

3.1.4 - IP-restricted Access

If the only IP the system will accept input from is within your LAN, you just reduced your attack surface by an incredible amount. I highly recommend this. If you want to be able to get at your system from elsewhere, then if "elsewhere" has a static IP, that's easy enough to do, and it still keeps your attack surface down. If, on the other hand, you want to be able to get to the system from anywhere, then you can't use IP-based security. And your risk factors rise a great deal. So unless you absolutely have to, don't do that.

3.1.5 - HTTPS

HTTPS is reputed to provide secure identification. That's debatable. But what it does do is encrypt the conversation between the browser and the server. So if you use https to talk to wtfm, then things like your password and user ID won't go flying across the network in unencrypted form. This seems like a good idea... because it is.

3.1.6 - Physical Access

This one is dead-simple: Don't let other people use your computer. If possible, physically restrict access to it using a securely locked door. Some people think this is going too far. It really isn't. The risk of problems of many kinds drops precipitously when people unfamiliar with, or with bad intent towards, your computer system can't actually walk up to it, sit down, and start changing things you didn't intend to be changed.

3.1.7 - Operating System Access

Also simple. Don't provide "guest" accounts, and establish exactly one user account, your own. Use a password on your computer to gate access to your user account, and consistently sign out before you walk away, signing in only when you are going to use the computer. Don't let others use your system for anything. If you want to provide computer facilities to others, use a different machine on an isolated network.

Like restricting physical access, this may seem like overkill, but it isn't. Fundamentally better outcomes arise from circumstances where other people can't break your system, than from circumstances where they can. So aim for the former, rather than the latter.