Issues with modsecurity OWASP and false positives.

rclemings

Well-Known Member
Nov 5, 2007
51
5
58
My server vendor has now consulted with cPanel and cPanel had this to say:

-----

I did confirm I am seeing the same issue when attempting to add the rules, which appear to be an issue noted here as well :

SecRuleUpdateTargetById not working inside VirtualHost scope · Issue #89 · SpiderLabs/ModSecurity · GitHub

This would entail that this requires the configurations be added manually in a separate configuration as you had suggested, which I added in the file the specific rule ID to be updated is present in at /etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf and confirmed that it did allow the directive to be added without issue.

-----

So I added my two SecRuleUpdateTargetById directives to a new file (/etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_20_customrules.conf) and restarted Apache.

Everything works fine now.

Since this bug (or whatever it is) is more than three years old, I think cPanel should note it on the "add rule" page or at least in the documentation (ModSecurity Tools - Documentation - cPanel Documentation). If that had been done already, I would have saved several hours of work.
 

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
Danielpmc,

I still receive a lot of false positives using the current set of rules that ship with cPanel. I've whitelisted my server, which stopped one of the big ones that was showing up every minute. I wouldn't mind testing the new CRS3 ruleset, at least until it cPanel implements it. Do you know if there's any cPanel instructions on how someone like myself might be able to implement on the CRS3 ruleset on my server? I think if I could do it, it'd have to be done in such away where when cPanel gets updated, it doesn't get replaced. I'd also have to keep an eye on the cPanel changelog, so when cPanel does update the CRS to the latest version 3, I can undo my changes and just use the one that ships with cPanel.

A long time ago, I found away to install a more up-to-date version of RoundCube than what was shipping with cPanel. Roundcube was fairly outdated. I downloaded, installed and configured RoundCube, Horde, and Squirrelmail with the latest versions. I think one of them I had some issues with. Anyway, I setup cPanel so whenever it installed the mail programs, it'd install my newer version, not the older versions that were shipping with cPanel.

I ended up forgetting about it and one day I noticed the version that cPanel was shipping was actually newer than the version I had installed! So I would definitely have to keep an eye on the change logs for cPanel to see when the CRS3 rulesets are finally implemented. The developers seem to really be encouraging everyone to update to the CRS3 now that it's stable. I had hoped cPanel would have implemented it by now.

One guy, he has a forum and someone tried typing the post, "I want to curl up by the fire". The current rulesets blocked that though, because of the word curl. It thought maybe it was some sort of attack. Just updating to CRS3 seemed to fix the issue for him.

The current logs are filled with sooooo many false positives, it's almost impossible to find real threats by looking at them, so essentially, with me at least (and I suspect other admins), we simply don't look at the logs unless something has gone wrong. If the new rulesets do away with 99% of the all the false positives, than we could monitor the logs for real threats and go from there. What's sad is with all these false positives, legitimate users could be blocked from our sites and we might never even know.
 

danielpmc

Well-Known Member
Nov 3, 2016
78
33
18
usa
cPanel Access Level
Reseller Owner
Hello Spork,

As far as updating OWASP ModSec to CRS3 by yourself, possibly at their site they have a method for you to try.

Code/sql injections happens a lot by a registered member of a site/forum. This is where they will write code and try to submit it to the site/forum by posting or uploading. Of course, do not forget about the talented hacker throwing command lines at your server and/or site(s). As you mentioned ModSec has blocked the word Curl although it was used in a post about curling up by a fire. So how do you filter good Curl versus bad Curl word usage?

Now think about a developer or techies site. They may have actual raw code samples or examples displayed on their sites. So how can ModSec even begin to filter code symbols properly?

ModSec will never be a works for all security application. There are way to many gray areas for it to be all encompassing. There are thousands of Website builders, CMS, Forums etc... for it to be compatible with. But when a person throws in a half dozen or more plugins, add-ons, apps or widgets to their site that just becomes a nightmare to write security for.

I think ModSec is one of those types of software that needs daily development and testing by the people that code it. That is maybe why cPanel crew does not want to get too deep into the approving and maintaining of ModSec updates. Even by using the current OWASP ModSec rules it is so time consuming for their staff to write security rules, that the internet updates faster than ModSec can. A never ending battle against the hackers.

When my site goes public i will be there reading through the mass of false positives simply because its smarter to use ModSecurity than not to.

danielpmc
 

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
Hello Spork,

As far as updating OWASP ModSec to CRS3 by yourself, possibly at their site they have a method for you to try.

Code/sql injections happens a lot by a registered member of a site/forum. This is where they will write code and try to submit it to the site/forum by posting or uploading. Of course, do not forget about the talented hacker throwing command lines at your server and/or site(s). As you mentioned ModSec has blocked the word Curl although it was used in a post about curling up by a fire. So how do you filter good Curl versus bad Curl word usage?

Now think about a developer or techies site. They may have actual raw code samples or examples displayed on their sites. So how can ModSec even begin to filter code symbols properly?

ModSec will never be a works for all security application. There are way to many gray areas for it to be all encompassing. There are thousands of Website builders, CMS, Forums etc... for it to be compatible with. But when a person throws in a half dozen or more plugins, add-ons, apps or widgets to their site that just becomes a nightmare to write security for.

I think ModSec is one of those types of software that needs daily development and testing by the people that code it. That is maybe why cPanel crew does not want to get too deep into the approving and maintaining of ModSec updates. Even by using the current OWASP ModSec rules it is so time consuming for their staff to write security rules, that the internet updates faster than ModSec can. A never ending battle against the hackers.

When my site goes public i will be there reading through the mass of false positives simply because its smarter to use ModSecurity than not to.

danielpmc
It's definitely not easy trying to filter out the false positives, from a programming sense, and some, you probably never could filter out completely. With curl, for example, perhaps someone could test for command line options that might be passed to curl. Running just the curl program by itself doesn't really do much, except for telling you to type --help. When you don't find a valid option being passed to curl, you could scan for what curl would return with invalid options and see if any data's coming back. But that's a whole nother headache, because now the developers have to keep an eye on curl and look for whenever new options are added or removed. It's definitely not easy.

I don't think cPanel really updates the rules that often. The reason I say this, I have had that false positive (the one that gets triggered every minute) going on for I'd say over a year now, or close to it. In situations where the developer has code on their site, they could always do what I did, and whitelist the server. I couldn't see this being a problem really, but it very well might not have been the best approach. I couldn't figure out how to write a rule just for the whm-get-status stuff or whatever it was, so I decided instead of disabling the entire rule, I'd just disable it for traffic that's coming from 127.0.0.1.

If I were cPanel, I'd probably look at it this way. How many tickets and forum posts do we have about issues with the current rule set? Would most of those tickets / forum posts disappear with the new rule set? What are the benefits to updating? What are the disadvantages? I think because the actual developers of ModSec and the CRS3 recommend everyone switch, including companies like cPanel, I think that isn't something they'd say lightly. I think their reasons are valid for wanting people to switch.

Granted, ModSec with a ton of false positives is better than no ModSec, but when your site goes public, why not try the CRS3? Do you just like to keep a more unmodified installation of cPanel? Or do you think there are some bugs with the CRS3 that aren't fixed yet?

I believe cPanel might actually be currently using a beta version of the CRS3. Perhaps now that it's stable, maybe that's the best reason out of all to update?
 

danielpmc

Well-Known Member
Nov 3, 2016
78
33
18
usa
cPanel Access Level
Reseller Owner
Hello Spork,

I am only guessing, but i think cPanel crew is waiting a guarantee that the new ModSecurity rules are indeed working as best as can be, before offering the CSR3 version.

ModSecurity, and also cPanel, have to take into account these scenarios when creating and updating security software.

1. A person who has decided to go beyond all the free sites and learn how to serve the internet by using cPanel.
This is a beginner and generally does not know much about hacker methods and if they do, how to prevent them. ModSecurity is a wonderful security tool for a person running a site that asks/requires input from a guest/member. Such as a search box, contact form or an upload of a photo or document. I am appalled at how secure some sites are, yet have little or no filtering on the search box and contact forms. These are two areas if i was a hacker would use to create mayhem on a persons site. There are well known methods of code injections specifically used in search boxes and contact forms. This is where ModSecurity shines. It will block most injections in these areas.

2. A person who is currently serving the internet with a cPanel and thinks the only security needed is a strong password.
Well this person is like an Ostrich with its head sticking in the sand. They do not think they will get hacked. But they do not understand that most hacks, in the millenial years at least, are done by automated bots. So now ModSecurity has to protect this person from all types of attacks, because they choose not to be pro-active in their site security.

3. A person who feels necessary to add multiple addons, plugins, apps and/or widgets to their site and expect them to be secure.
This person thinks that unless they have a bunch of addons on their site, nobody will visit/interact/buy from their site. So they will go on the internet and find the first code they can find to make their site look like a golden palace. But they do not understand that every code added to their site is a potential door or access point for a hacker to create mayhem. So now ModSecurity has to protect them against themselves.

4. A person who is using cPanel and understands that there are multiple methods required to secure a site online.
This person is like you and i and millions of others online. We understand that security is a combination of Firewalls, Server Tuning, Anti-Virus Software and lots of tweaks. But mainly we know not to add unverified or untested codes, apps etc.. to our sites. So ModSecurity is there only as an additional tool, not the only tool to rely on.

As you can see ModSecurity has a lot of varied roles to fullfill, and is very difficult to keep updated in todays world of internet changes. The way i gauge if a product or tool is proper to use is by the amount of UNPAID reviews online. One or two reviews is not enough to qualify a code or tools effectiveness. When i go public with my site i will evaluate wether or not OWASP ModSecurity CRS3 is able to live up to its claim of vastly reducing its false positives. They do great work and definitely have earned my respect for their hard work and time.

As a suggestion:
Open a thread and ask why cPanel crew can not or will not update Modsecurity.
OR
Open a thread and ask how a person can update ModSec by themselves and if there are any pitfalls by doing this.

danielpmc
 
  • Like
Reactions: Spork Schivago

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,216
463
Hello,

I do want to note that the "Report this hit" option is available on the ModSecurity Tools page when “More” is pulled down. You also have the option to disable the rule as you submit the report. This is currently the best way to address false positives, as those reports go to the ModSecurity vendor (E.g. SpiderLabs).

You can find additional discussion of this topic at:

OWASP - mod security and wordpress

Regarding an overall change to the frequency of rule updates and cPanel's involvement with the rule adjustments, our feature request website is the best outlet to seek those changes.

Thank you.
 
  • Like
Reactions: Spork Schivago

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
Hello Spork,...
As a suggestion:
Open a thread and ask why cPanel crew can not or will not update Modsecurity.
OR
Open a thread and ask how a person can update ModSec by themselves and if there are any pitfalls by doing this.
...
We actually have a feature request asking for this, so I think it's just a matter of time. I think maybe two of the biggest reasons cPanel hasn't implemented them yet is 1) They're busy. They're always making cPanel better, adding new features, stuff like that. I bet they have some sort of priority list and maybe the CRS3 isn't the top priority right now?

But 2) Like you said, it's gotta be secure. You make a very valid point. Even though it's listed as stable, it's just finally being widely implemented on servers across the world, or, we could probably at least say a lot more people are using CRS3 now that it's out of beta testing stage. In Deposit, when I worked as a computer programmer, I'd always thoroughly test my code before putting it in production, but until it really gets out there, it's usually almost impossible to think of all the situations that can break the code. As a programmer, I always try to think of the unexpected. If my program needs the user to enter a number, make sure they enter a number and not just spell the number. Even though CRS3 is listed as stable, I bet they already have some new bugs coming in. Maybe you're right and cPanel is just waiting until the stable version becomes more stable? I know cPanel always has this policy of thoroughly testing the software before including it in their production builds. I've always kinda liked that, you know?
 

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
Hello,

I do want to note that the "Report this hit" option is available on the ModSecurity Tools page when “More” is pulled down. You also have the option to disable the rule as you submit the report. This is currently the best way to address false positives, as those reports go to the ModSecurity vendor (E.g. SpiderLabs).

You can find additional discussion of this topic at:

OWASP - mod security and wordpress

Regarding an overall change to the frequency of rule updates and cPanel's involvement with the rule adjustments, our feature request website is the best outlet to seek those changes.

Thank you.
I was using the feature request. I found the ModSec CRS3 rules a while back on there and voted them up and added to the discussion a bit.

I don't like disabling the rules because of false positives, unless there's no other option. I feel whenever we disable a rule because of a false positive, we're essentially allowing real positives through. I've always liked the idea of trying to write a custom rule that looks for that false positive and catches it. You know what I'm saying? I'll give an example.

That cPanel whm-server-status or whatever, that comes every single minute and fills the logs very quick like. There's a lot of minutes in the day. But the rule that's getting tripped, it's protecting our servers for a certain type of attack. So instead of just disabling the rule all together, try to rewrite it to exclude the whm-server-status.

If we report this to SpiderLabs using the Report this hit button, if they fix the rule, how long does it take for cPanel to implement that fix? I know on the mailing lists for ModSec, when people start talking about problems with false positives, the general response is always something along the lines of, "We suggest you upgrade to CRS3. This problem is fixed in CRS3".


It seems someone reported the whm-server-status to SpiderLabs already and it's been fixed. I just don't think cPanel updated the rules yet.

cPanel and its GET /whm-server-status · Issue #620 · SpiderLabs/owasp-modsecurity-crs · GitHub
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,216
463
It seems someone reported the whm-server-status to SpiderLabs already and it's been fixed. I just don't think cPanel updated the rules yet.
That's correct. We do have an internal case open to update the curation for ModSec CRS version 3. I see it's an active project that looks to be nearing completion, but I don't yet have a time frame to report on it's implementation. We'll update the feature request page with more information once it's available:

Update ModSecurity Vendor OWASP to OWASP ModSecurity Core Rule Set (CRS) 3

Thanks!
 

danielpmc

Well-Known Member
Nov 3, 2016
78
33
18
usa
cPanel Access Level
Reseller Owner
Last edited by a moderator:
  • Like
Reactions: cPanelMichael

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
The reason so many people are having so many problems with false positives is because this older version of the CRS that cPanel is using was released (by OWASP then by cPanel) with the configuration set to use Tradition or Self-Contained mode blocking (one hit equals a block) rather than Collaborative Detection mode (which increments a score with each rule hit until a score threshold is reached).
If you read the rules they were quite obviously written to be run in Collaborative Detection mode.
It only needs three lines of modsecurity_crs_10_setup.conf to be edited to turn on Collaborative Detection mode in cPanel's current version of the CRS rules.
- lines 74 and 75...
Code:
SecDefaultAction "phase:1,log,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
SecDefaultAction "phase:2,log,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
replace with...
Code:
SecDefaultAction "phase:1,pass,nolog,auditlog"
SecDefaultAction "phase:2,pass,nolog,auditlog"
- line 135 uncomment rule 900004...
Code:
SecAction "id:'900004', phase:request, nolog, pass, t:none, setvar:tx.anomaly_score_blocking=on"
I copied the file modsecurity_crs_10_setup.conf then renamed it before making these edits to the new renamed file.
Then go to WHM=>Security Center=>Modsecurity Vendors=>OWASP ModSecurity Core Rule Set=>Edit Button
Turn OFF the modsecurity_crs_10_setup.conf file.
Turn ON your new conf file.
Thats it.

I had the same problem as Ken Swarthout with cPanel's whm-server-status Requests from 127.0.0.1 where rules were triggered by poorly written HTTP Headers.
this rule is more specific than Ken's
Code:
# Rule to allow cPanel whm-server-status requests with missing mandatory headers.
  SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
  "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 960008 960009 960015 and 981204',\
  phase:1,\
  id:8888777,\
  t:none,\
  pass,\
  nolog,\
  chain"
    SecRule REQUEST_URI "@contains whm-server-status" \
      "t:none,\
        ctl:ruleRemoveById=960008,\
        ctl:ruleRemoveById=960009,\
        ctl:ruleRemoveById=960015,\
        ctl:ruleRemoveById=981204"
WordPress load-scripts issues were fixed by the rule...
Code:
# Rule to allow /wp-admin/load-scripts.php requests without triggering rules.
#
SecRule REQUEST_URI "@contains /wp-admin/load-scripts.php" \
  "msg:'Disabled rules 981247 981176 and 981204 for /wp-admin/load-scripts.php',\
  phase:1,\
  nolog,\
  pass,\
  ctl:ruleRemoveById=981247,\
  ctl:ruleRemoveById=981176,\
  ctl:ruleRemoveById=981204,\
  id:'8888778'"
All other log events were basically all True Positives even though most were non blocking due to not reaching the Collaborative Detection mode thresholds.
 

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
The OWASP ModSecurity Core Rule Set team have changed the default configuration of the current version of the CRS to run in Collaborative Detection mode.
That is the main change to achieve the 90% reduction in False Positives.
They have also rewritten most of the rules to take into account (not trigger) most of the false positives.
They have also renumbered all the IDs.
The project is here if anyone wants to read through it.
I downloaded it deleted the cruft files (.git etc.), renamed the config file from...
crs-setup.conf.example to
crs-setup.conf
zipped it, created a vendor meta_packagename.yaml file (instructions) for it and uploaded the two to my server into a directory named modsec.
I then went to...
WHM=>Security Center=>Modsecurity Vendors=>Add Vendor button
the entered the url of the yaml file into the Vendor Configuration URL textfield.
Load then Save.
The new vendor will now be available in the Vendors section.
Disable cPanel OWASP CRS.
Enable Third Party OWASP CRS.
Thats it.

If you want to try mine, yaml is at...
- Removed -

That is stock standard configuration. (Looking good for when cPanel gets this ruleset)

The only False Positive I have had to deal with is once again the whm-server-status requests.
All the rule ids have changed so it needs a new rule to make this work...
Code:
# Rule to allow cPanel whm-server-status requests with missing mandatory headers.
#
  SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
  "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 920280 and 920280',\
  phase:1,\
  id:8888776,\
  t:none,\
  pass,\
  nolog,\
  chain"
    SecRule REQUEST_URI "@contains whm-server-status" \
      "t:none,\
      ctl:ruleRemoveById=920280,\
      ctl:ruleRemoveById=920350"
I'm running mostly WordPress sites but the logs are quiet with this config.
All hits so far have been True Positives.
 
Last edited by a moderator:

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
Here is a more reliable version of that rule for matching the request file.

Code:
# Rule to allow cPanel whm-server-status requests with missing mandatory headers.
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
  "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 920280 and 920350',\
  phase:1,\
  id:8888777,\
  t:none,\
  pass,\
  log,\
  chain"
    SecRule REQUEST_FILENAME "whm-server-status$" \
      "t:none,\
      ctl:ruleRemoveById=920280,\
      ctl:ruleRemoveById=920350"
 

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
Here are better versions of the two rules above (more reliable at matching the request filename)

Code:
# (cPanel old CRS rulset)
# Rule to allow cPanel whm-server-status requests with missing mandatory headers.
#
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
  "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 960008 960009 960015 and 981204',\
  phase:1,\
  id:8888777,\
  t:none,\
  pass,\
  log,\
  chain"
    SecRule REQUEST_FILENAME "whm-server-status$" \
      "t:none,\
        ctl:ruleRemoveById=960008,\
        ctl:ruleRemoveById=960009,\
        ctl:ruleRemoveById=960015,\
        ctl:ruleRemoveById=981204"
And a better version of the WordPress load-scripts issue...
Code:
#(cPanel old CRS rulset)
# Rule to allow load-scripts.php requests without triggering rules.
#
SecRule REQUEST_FILENAME "load-scripts.php$" \
  "msg:'Disabled rules 981247 981176 and 981204 for load-scripts.php',\
  phase:1,\
  nolog,\
  pass,\
  ctl:ruleRemoveById=981247,\
  ctl:ruleRemoveById=981176,\
  ctl:ruleRemoveById=981204,\
  id:'8888778'"
 

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
FuzzyLogic,

Why did you remove the yaml URL? I want to try it. Is it because it could be a security threat? For example, you could modify them in such a way where you could allow yourself to bypass anyone's modsec configuration, if you wanted to, even though you wouldn't, and decided against sharing, thinking maybe other people who were malicious would get the idea and do exactly that?

Thanks for sharing. I'll update my configuration for the 127.0.0.1 whitelisting stuff. I don't know a lot about the rules, and I've written a couple, but I think it takes a good amount of time to truly understand modsec and all the configuration variables and how it works, and that's just something I don't really have now, free time.

Thanks again!!!!
 

fuzzylogic

Well-Known Member
Nov 8, 2014
149
90
78
cPanel Access Level
Root Administrator
Hey Spork,
The .yaml link was moderated (not by me). It is understandable I guess, the .yaml has a link to a .zip of the rules directory located off-site from cpanel.net, so could be considered a support hazard or even worse a security risk.
I started off writing a how-to, then had a rush of blood to the head and thought it would be easier to just link to my setup.

I'm glad I took the time learn how to create my own vendor and will curate my own rule set from here on.

cPanel has released their curated version of the CRS version3.0.0 with the cPanel 64 update.
It has rules 920350, 942110 and 942150 commented out, and 4 .conf files deleted from the CRS.

REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
Needs a rule to turn it on.
Copy 900130 from crs-setup.conf, uncomment it, add it as a new rule to
WHM=>Security Center=>Modsecurity Tools=>Rules=>Add Rule

REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
Needs a rule to turn it on. Same as DRUPAL

REQUEST-911-METHOD-ENFORCEMENT.conf

REQUEST-932-APPLICATION-ATTACK-RCE.conf

I'm sure someone must have had False Positives to justify these changes, but I have not experienced any problems with these rules or .conf files so I will continue using them.
 

Spork Schivago

Well-Known Member
Jan 21, 2016
597
64
28
corning, ny
cPanel Access Level
Root Administrator
I know this is a bit older of a thread now, but isn't there a way for cPanel to just add a proper header to whatever script is accessing whm-server-status? Than we wouldn't need to add an exclusion to conf files for 127.0.0.1?

Everyone running cPanel right now that has ModSec enabled will either get their logs filled with these messages or they'll have to create the conf file and enable the ruleset. Wouldn't it just be easier if cPanel updated their scripts to provide the proper header?

I had the old conf file in, before cPanel updated the ModSec rules and I just realized that it was no longer working, because the rule IDs have changed a bit, so I had to come back here and refresh my memory on how we worked around the problem originally.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,216
463
I know this is a bit older of a thread now, but isn't there a way for cPanel to just add a proper header to whatever script is accessing whm-server-status? Than we wouldn't need to add an exclusion to conf files for 127.0.0.1?
There's an internal case open to address that issue. You can monitor the following thread for updates:

Apache Status page fails after 64 update

Thank you.
 
  • Like
Reactions: Spork Schivago