Server Security

Preprocessor

Traditional website exposes it's set of HTML files to the world wide web where each file renders as a web page in your browser. OTOH, I use the PHP preprocessor on the server. This generates parameterized HTML on the fly that is then sent to your browser. Thus I create consistent representation using higher level functions that I've coded for my web engine and then I implement my pages as include scripts that call those functions as they are processed. The preprocessor has access to the whole file structure on the server so I place my coded functions in a separate file path that is not accessible to the world wide web at all. There they are safe from snoopers, (in particular protecting my database name and password).

All the user need do, is select an entry point to my scripts. I have one for each of my website themes. In my angelica theme, for instance, you can mouse over the theme icon, then select the one you want from a drop down menu. Note: Clicking the icon itself toggles between dark and light mode.

The actual page to be displayed is specified with an additional path, but only the entry points for the themes need to be public on the internet. Those all point to the very same two line script just using a different name for it. That script then diverts to my hidden actual engine that the name it was invoked with to select the corresponding set of functions for the theme.

The include files that define my web pages, being processed by the preprocessor, could equally have been located beyond reach of the web, but other files they might use, like images, videos and audio files, will need to be accessible. Thus I decided to keep the include scripts online as well, so that pages and topics can be organized as self contained folders. This makes it easy to zip them up, archive install or restore individually.

Multi lingual capability I implement by affixing the ISO 639 two letter language code as file type for these include files. Typically there is "en" for English. It's just not worth my time to actually produce translations for my blog here as nobody would read it anyway. The capability has been implemented and tested should anyone want it one day. The point is that to protect my page definitions from hackers all I have to do is deny access to any file with two letter suffix: the pre processor can read them anyway. I had to make an exception for "js", Javascript and also excluded access to hidden files (by Linux convention have a name that starts with dot). It's a bit cryptic, but concise, in the site .htaccess control file.

	Options -Indexes
	<FilesMatch "^\.|\.(?!js)(..)$">
		Deny from All
	</FilesMatch>

IP ban hack attempts

With conventional websites one needs to devote a lot of time plugging all the gaps to eliminate vulnerabilities and the number of bots scouring the world wide web looking for known mistakes suggests many fail. On my site, all they will get is a 404 (file not found) error, because access is always via my theme scripts and I don't provide any of the folders or pages that they might be looking for. None the less, I decided to curtail exhaustive hack attempts by IP banning them: My 404 processing script appends their IP address to a deny list in the .htaccess site configuration file.

I do realize that regular users can make mistakes and also that the hackers often use VPN services that at a later time might be used by a bonafide visitor who just has legitimate privacy concerns, so my ban is only temporary and I only ban when their query matches suspicious patterns. For this I maintain a database that has a ban list and a table of patterns. I simply rewrite the whole .htaccess file each time I add a ban, excluding the ones that have been there for more than 24 hours. It eliminates sequences of hundreds of attempts and cuts down immensely on web overhead dealing with them. Note for instance in the above capture how the fuquit at 198.91.94.29 is back again and again with yet another futile attempt, but I do need to check why the ban didn't last 24 hours and fix that.

Recently I discovered that some were forcing a database security exception and so it didn't screen their request for the banned patterns and wasn't able to add them to the ban list in the database.

IDK how they achieve that although they appear to be using an IP address that is on the same web host as mine. I am 198.91.94.54 and they are 198.91.94.29. I suspect a vulnerability with my web host rather than my site, but my solution is simple: Any security exception on my database gets them banned and that will remain until the block list is successfully updated with a new ban seeing as I couldn't record theirs.

Note: My 404.php script does a lot more than just inform the user they tried to access something that doesn't exist. In particular the generation of reduced size images in a separate path allows me to use them on protected web pages even though the original may be stored where they have no access to, but more about that on my intro page to thius section where I explain image handling.