Support

I'd imagine this must affect a lot of Admin Tools users, since this seems to be a common way that hosts set up cPanel to do scans.

No, this is NOT the common way hosts using cPanel perform scans. To wit, our own site is hosted on such a (managed, not dedicated!) server and is still up. Same goes with thousands of sites using Admin Tools. Only very basic hosts who lack network engineers who know what they are doing will ever institute such an IDIOTIC measure as automatically cutting all inbound traffic to the server when a file is flagged as possibly malware. More so when you are scanning source code files which makes it impossible to have a good accuracy against false positives.

For me that's a clear indication that your host doesn't know how to properly secure their server and chooses the easy solution of offloading the burden to its clients. The only course of action I recommend is moving away from that host, fast.

How about an option or setting in Admin Tools, that if enabled, would cause it to write these logs slightly differently

Partial logging: That's effectively turning off logging. This is a terrible idea from a security standpoint. It renders you blind. If you remove the actual part of the request which triggered the protection (which is exactly what triggers the attack) your log cannot help you a. understand the difference between legitimate and malicious request; b. understand if you are looking at a false positive and c. give you any insight on the attack vector the attacker is trying to leverage. That's about as useful as a book with blank pages.

Signatures: I can write the same simple SQL injection attack in 15 different ways which yield a different hash. Therefore a hash in this context is a useless piece of trash. It will only tell you that something triggered the protection, but not what or if it's a legitimate threat. That's about as useful as a book with its page content replaced by the count of words in each one.

CVEs: Admin Tools is a web application firewall, not an external web application vulnerability assessment tool. It doesn't probe your site with known attacks published in CVEs. And of course it doesn't naively rely on CVEs to classify the request. That would be catastrophic for the security. I'll let you think about it; it's pretty obvious why. Oh, well, it's the same reason "bath salts" drugs that kill people were legal for so long despite the raging war on drugs: when you implement an exact match blacklist the attacker will modify their attack ever so slightly to avoid detection (or discover a whole new class of attacks your narrow, nearsighted blacklist doesn't try to block).

I can think of more solutions which are equally bad. Trying to base64-encode the log will trigger the scanner in BOTH the PHP file that handles logging and the log file itself (large chunks of base64 encoded data are considered suspicious). Even reversible encryption would make no sense because the binary data in an otherwise text file would trigger all sorts of red flags.

The fact remains that this is a stupid host issue. They don't know how to implement security on their server and they put the burden on you. As I said there is exactly one way to solve this problem: use a good host with actual engineers who understand how to set up a server.

Blocking inbound would kill the website. That would be crazy for a host to do, and you'd be right in everything you said

I know it's hard to believe, but we've seen hosts do even worse things. Three and a half years ago some hosts started deleting files they considered "suspicious" without asking the client. Of course that brought down websites.

Blocking outbound ports based on the results of an automatic scanning with a very high chance of false positives due to the nature of the content being scanned is equally idiotic. Modern websites are not isolated islands of information like they were twenty years ago. They communicate with external services for diverse things like payments, spam mitigation, secure authentication, file and data storage and so on and so forth. Blocking outbound ports is, therefore, just as idiotic as blocking inbound ports.

A real network engineer monitors the outbound traffic of the server for signs of anomalous traffic. A paranoid network engineer has a blanket firewall for outbound connections and only opens traffic to ports and hosts explicitly requested by the client, once the client explains why they need that traffic to go through. Only an idiot who's not a network engineer and doesn't know anything about security will block all traffic on a site which might, maybe have a small chance of possibly being potentially infected with some unconfirmed malware which has a distant chance of creating outbound traffic. To give you an example, it's like having a house alarm which saturates the house with halon gas if it thinks someone has possibly violated the perimeter. Yes, that would kill all occupants in case a window gets shattered. That's the kind of "security" offered by your host...

To make matters worse, they don't even secure their server against real hackers. If I were to attack a server I'd upload non-obfuscated code, disguised by means of inconspicuous filenames inside either Joomla's libraries or a popular component's folder. Being a really sneaky bastard I would even try to mimic their coding style and conventions to further throw humans off the scent (humans look for anomalous patterns, they can't go through all the code in Joomla). The only subtle change I'd do is an otherwise innocent abstract or helper class that I know gets called on every page load to load my code. This attack will not be detected by any security software. You know the worst bit? What I described is not a theoretical attack, it's something that I've seen in the real world.

Funny thing, I originally changed hosts for this exact reason... to my current host. *sigh*

I have used different hosts which are generally very good in keeping a secure enough server without getting in your way - and when they do you can discuss with an actual engineer to make sure this doesn't happen again. In no particular order these are SiteGround (we're currently hosted with them), Rochen (my blog is still hosted with them, they were the previous host of our business site), CloudAccess.net and EuroVPS.com. I don't include links to prove that we don't do affiliate links and we make no money from referrals. These hosts are just my personal pick. I'm pretty sure there must be other good hosts out there.