foxpa.ws

I rebooted this blog a few years ago with the now oh-so-naive-seeming intent to use it as a sort of demo project, a bit of a widget if you will (and if you'll do me the honour of wincing in tandem) around which I would bootstrap the development of my brand new, very sexy, world-conquering, last-project-I'll-ever-design web and mobile app software framework. Things were good then. I could see the future as clear as day. I could see this day; this day when I was supposed to be well past the gruelling initial library building and poised smugly atop a throne built on elegance, standards and cutting edge programming concepts executed with time-tested conventions culminating in one of the finest hierarchical, extensible, flexible, optimal and cumulative platforms ever to dust encountering the availability monster off its sentient nanotech, weapon-of-mass-destruction, cult leading (and deserving!) shoulder.

Alas, today is not that day. It's not even not that day. Today is so far removed from what I ever could have expected a day in this, the year of our lord: 2022 to manifest that I am literally numb to registering even the sheer audacity in the dichotomy so posed. No, and furthermore this is not the place to wax heartbroken over the sins a capricious god has committed... not simply against me but indeed my entire species; confined - remarkably as they are - in the blurry yet so very sharp span of contemporary history. No, friends - and yet with no sense of irony at all that place IS but kitty-corner and two blocks down from where I bode thee direct thy undeserved, thy succulent, thy most deeply yearned for attention in this moment; if I may never again capture it from you for having abused it so mercilessly with such excessive verbosity as this, that I might convince you to spend it increasingly and evermore - though verily for now only in considerately apportioned part: in being a part of the latest additions to the furry.media urban sprawl:

Join the foxpa.ws Discussion [sfw] group on Telegram

Discuss topics and articles seen on foxpa.ws | SFW/All Ages! | A blog about software, electronics, security, virtualization, administration, linux, solaris, qubes and more!

https://t.me/foxpa_ws

Join the foxpa.ws downloads channel on Telegram

Companion downloads for foxpa.ws articles, also obscure, deprecated and difficult to find software and datasets. Topics including development, electronics, security, administration, virtualization, linux, solaris, qubes + time saving tools, tips & tricks!

https://t.me/foxpaws_downloads

Yes folks, I've finally thrown in the towel - after so many years with a broken comments button I'm shoehorning an off-grade instant messenger into their place. All joking aside, when I set out to write the commenting system my ambition was sky-high and I did not foresee putting the project on - admittedly a sarcastically long - hiatus. I wanted to support three kinds of markup, including safely handling user-supplied HTML even though I'd probably only end up enabling BBCode for foxpa.ws proper. A kinder man would have gone with a minimalist, working implementation and built off it iteratively so that comments would function here and then bells and whistles could be added later, indeed that would on its surface be in keeping with the design philosophy I have espoused for the framework. However I plan to stick to my guns on this one because the commenting system I have in mind is so comprehensive that simply starting off with it instead of dragging around several less-capable versions that only work with one or two increasingly historical sites is not, in fact, what I have in mind for this platform.

That being said I have a plethora of articles sitting hidden in the foxpa.ws private queue which I have already half-written and there are so many things I am planning to document while I continue to attempt to maybe, possibly, one day, sortakinda get my act together which could benefit from public discussion that it seems appropriate to implement a stop-gap measure to bring some level of interactivity to the pages of this blog - even if it's not delivered in the conventional package of conventional bottom-of-page pyramid-style comments. Anti-spam, moderation, eventual importation hurdles and user privacy concerns handily ruled out most of the third-party drop-in solutions out there and a Telegram group would continue to be a reasonable asset to carry forward after in-house commenting is launched. So there you have it; going forward and until I'm done writing in-house comments there will be a blurb at the bottom of articles encouraging you to join the discussion on Telegram or even just skim the (public!) group for discussions others have had regarding an article which captures your fancy.

Additionally, I have created the foxpa.ws downloads channel to leverage Telegram's file hosting capabilities (ironically only a few days after maximum file sizes were reduced to make the new paid tier enticing) and carve out a space I can rely on to archive and share with you all various bits of software and other data that (at least I, with my unfortunate, little peanut-sized fox brain) find difficult to obtain or suspect will soon become as such, plus other files that may supplement future articles which may not quite belong hosted directly under this domain or on this server... I suppose we'll just have to see how this little experiment develops.

Here, have a promotional video I lifted from the Telegram downloads site. A little bird in marketing told me they tend to foster adoption among consumers by illustrating the product's dynamism and utility!

When using Windows I have been a reliable PuTTY user for as long as I can remember. At the same time as deploying some new workstations for personal use I felt compelled to stretch my legs and see what other options Windows admins are using in case I'm missing out on any killer features and the like. The following is a list of Windowns SSH clients I will be trying out as daily drivers over the coming weeks; while I will likely follow this article up at the end with some thoughts on those that kept my attention, it makes sense to compile this list in advance so I can use it during my system builds as an addendum to my Favourite Windows Software shortlist.

If I'm missing a client you think I should know about please pop by the new foxpa.ws General Discussion Telegram Geoup and let me know! While I am interested in bonus features like SFTP support, tunneling and X11Forwarding only free (as in free beer) or non-crippling evaluation Windows-native clients that implement a PTY and support modern protocols, crypto and at least password AND public key authentication will be considered. Naturally I'll be skipping the PowerShell implementation of OpenSSH since that's what I use all day on *nix machines anyway.

A detailed, multi-platform comparison of SSH clients is available at https://en.wikipedia.org/wiki/Comparison_of_SSH_clients.

• Absolute Telnet
• Basbun
• Bitvise SSH Client
• KiTTY
• Essh
• MobaXterm
• mRemoteNG
• MTPuTTY
• SecureCRT
• SmartFTP
• SuperPuTTY
• TN3270 Plus
• TTY Emulator
• WinSCP
• wolfSSH
• XSHELL
• ZOC Terminal

Modern machines boot (god willing) like greased lightning. Sometimes it helps to know what key to hammer on for dear life in advance of POST because the configuration keys particular to a given machine aren't displayed for your convenience - and even if they were they might not display long enough for our puny mammalian brains to register them. The following tables have been compiled from various sources and will be updated as I encounter noteworthy additions.

Additional considerations:

• Since we are dealing with the pre-OS environment, software-configured niceties such as swapping the symbolic functions ("media keys" and the like) and the Function Keys proper (F1-F12+) on keyboards such as the Logitech K400 will not have been applied, as such consider hammering an alternating pattern of [Function Key], [Function Key] + [Fn Key] to ensure the correct signal at least some of the time...

Originally from Microsoft Tech Net: Tips for configuring your BIOS settings to work with Windows To Go @ https://social.technet.microsoft.com/wiki/contents/articles/12911.tips-for-configuring-your-bios-settings-to-work-with-windows-to-go.aspx...

Originally from LSoft Technologies' Active @ Boot Disk (shoutout to a Mississauga-based company, t.dot repruhzent!) @ https://www.boot-disk.com/quest_bootmenu.htm...

When performing an "Unattended Windows installation" with an Answer File, as outlined in Go Fast: Windows 10 and 11 Unattended Installation Answer File Template, you may encounter the following error:

Windows Setup

Windows could not create a partition on disk 0. The error occurred while applying the unattended answer file's <DiskConfiguration> setting. Error code: 0x80042565

This usually means you are using an installation medium with an answer file configured to create a GPT partition table, compatible with a UEFI boot environment, but the machine - while it may be UEFI capable - has booted in Legacy Mode (in which only an MBR partitioning scheme may be installed).

To fix this, reboot and reconfigure your boot settings such that the machine will boot into UEFI or "UEFI first then fallback to Legacy" Mode; alternatively if your BIOS is capable of supporting both modes simultaneously your installation medium may have two boot device entries; one for UEFI mode and one for Legacy. Either ensure the UEFI version of the device is attempted first or use your system's one-off Boot Device Menu (where available) to select the appropriate entry.

mod_security / ModSecurity / ModSec / whatever the kids are calling it today is a battle-tested Web Application Firewall that plugs into the Apache HTTP daemon's modular framework and has been the main mechanism for implementing Intrusion Prevention and DoS mitigation to the LAMP stack for even slightly longer than I've been doing this - way back in the Apache 1.3.x era 19 years ago. If you've never used mod_security but have implemented any sort of IPS/IDS or DoS mitigation technology before your mind's gears have already sputtered "gee I bet that takes a hella lotta resources," buddy - you better believe it. While I would never leave my house and venture into The Wild without smothering myself in a thick lather of mod_security it is prudent to apply it intelligently in situations where available resources, cluster nodes or funding in general is not unlimited. That's why on high-traffic installations you might be enabling and disabling it or at least running radically different configurations with content-appropriate rulesets on a per-vhost basis, separating things like static content away from interpreted scripts and other attack surfaces more susceptible to, say, getting tricked into running Bob's shellcode zero-du-jour.

These days mod_security comes with a lot of rules and that's great (other than the false positives). But as anyone who admins a Snort or Suricata instance knows the more rules the more resources are demanded. PCREs in particular are powerful tools for, well, pattern matching - and that's most of what we're doing in this type of situation. mod_security essentially acts like a proxy, sitting between the end user making a request and the server-side end point that will process it, keeping track of vital statistics so it can judge the intent behind and risk of each request and running pattern match query after query after query on the data going in and coming out. Unfortunately powerful tools are also power hogs, so to prevent mod_security from itself instigating a resource starvation Denial of Service condition default limits on the total number of PCRE operations that can be run on any given transaction are imposed. The default behavior when that limit is reached is to err on the side of caution, instead of processing the transaction mod_security will call the destination up yet provide no input, meanwhile throwing a 500 Internal Server Error to the client. Depending on your configuration it may be very difficult to detect when this particular condition is at fault for your seemingly aborted transaction; often you will have to resort to prying open your Apache error logs, either those configured globally or that which is configured for the vhost at hand.

ModSecurity: Rule 6fa404524850 [id "932105"][file "/var/apache2/template/etc/mod_sec3_CRS/REQUEST-932-APPLICATION-ATTACK-RCE.conf"][line "158"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "ychan.net"] [uri "/post.php"], referer: https://ychan.net/r/

As you can see I recently ran into such a condition with the upload processing script for our imageboard, Ychan (NSFW). I'm already doing a lot of my own security testing inside that script (including several PCREs, in fact), for obvious reasons, so I should be free to do any number of things:

1. I can change what mod_security does when it encounters a match by changing the SecRuleEngine Apache configuration directive's value to DetectionOnly:
   SecRuleEngine DetectionOnly
   This will take the teeth out of mod_security's response and only log the match instead of zapping the transaction. Obviously I would want to think long and hard about using this on a production system and then only apply it in a very limited perimeter - for example a specific <Directory>, <Files> or <Location>:
   <VirtualHost *:80>     ServerName ychan.net     ServerAlias www.ychan.net     <Location /post.php>         SecRuleEngine DetectionOnly     </Location>     ... </VirtualHost>
2. I can raise the limits themselves with the SecPcreMatchLimit and SecPcreMatchLimitRecursion directives:
   SecPcreMatchLimit 150000 SecPcreMatchLimitRecursion 150000
3. Going by Google, it seems I could add these lines to my php.ini file:
   pcre.backtrack_limit = 10000000 pcre.recursion_limit = 10000000
   or, where supported, to the relevant .htaccess file:
   php_value pcre_backtrack_limit = 10000000 php_value pcre_recursion_limit = 10000000

But there's a problem... as with SecRuleEngine above, I'd like to be able to make these changes to SecPcreMatchLimit and SecPcreMatchLimitRecursion with some specificity, i.e.:

• In my given vhost's configuration block (i.e. /etc/apache2/vhosts.d/mysub_domain_com.conf)
• In the .htaccess file of the relevant directory, where AllowOverride All is in effect

However, according to the documentation, these directives can only be configured globally! That is:

• In (/etc/[apache2|httpd]/conf.d/)httpd.conf
• In (/etc/[apache2|httpd]/modules.d/)(20_)mod_rewrite.conf

This effectively renders about 90% of the articles and answers I have encountered in writing this essentially useless, or misleading at best. What's more, these directives don't even apply in versions 3 and over, but it's not likely that you found this article if that's your situation. Good thing we read the manual around here, right? :D

Back to the solution, it begs the question: what do these values do exactly?

From https://serverfault.com/questions/408265/what-are-pcre-limits:

These appear to be settings internal to the PCRE engine in order to limit the maximum amount of memory/time spent on trying to match some text to a pattern. The pcreapi manpage does little to explain it in layman's terms:

The match_limit field provides a means of preventing PCRE from using up a vast amount of resources when running patterns that are not going to match, but which have a very large number of possibilities in their search trees. The classic example is the use of nested unlimited repeats.

Internally, PCRE uses a function called match() which it calls repeatedly (sometimes recursively). The limit set by match_limit is imposed on the number of times this function is called during a match, which has the effect of limiting the amount of backtracking that can take place. For patterns that are not anchored, the count restarts from zero for each position in the subject string.

The default value for the limit can be set when PCRE is built; the default default is 10 million, which handles all but the most extreme cases. You can override the default by suppling pcre_exec() with a pcre_extra block in which match_limit is set, and PCRE_EXTRA_MATCH_LIMIT is set in the flags field. If the limit is exceeded, pcre_exec() returns PCRE_ERROR_MATCHLIMIT.

The match_limit_recursion field is similar to match_limit, but instead of limiting the total number of times that match() is called, it limits the depth of recursion. The recursion depth is a smaller number than the total number of calls, because not all calls to match() are recursive. This limit is of use only if it is set smaller than match_limit.

Since the PCRE library built-in default is 10000000, my guess is that the lower setting is suggested for mod_security in order to prevent requests from being held up for a long time.

In fact, according to the documentation the defaut value for mod_security is 1500 - very low indeed, until we consider that it is expected to process up to several thousands of transactions per second.