A LOT of MODSEC false positives since WHM upgrade? Rule #920280 ?

Benjamin D.

• November 05, 2020 07:08

Hi, I hope I'm posting this question in the correct thread, but since I upgraded WHM to the most recent stable version about a month ago (wasn't that far behind) I now have a bunch of MODSEC false positives under different rules but one is particularly shocking to me. The hists list is full of 127.0.0.1 (W-T-F!!!) WARNING 200 GET / Operator EQ matched 0 at REQUEST_HEADERS, rule #920280 The server is super slow on many sites and web apps, including WHM, tough not all sites and not all the time, some are constantly speedy while others often hang. I'm thinking it has something to do with MODSEC. I have checked the RAM, CPU and HTTPD workers and sometimes when the server takes 30 seconds to display a simple page, the server is actually sleeping and almost nothing is happening on it. I have seen complex pages served in 0.1 second under heavy load so I know what this machine is capable of and it's not normal at all since the upgrade. After seeing hits from 127.0.0.1 in MODSEC hists list, I've observed that WHM becomes extremely slow and unresponsive, for instance if I go to MultiPHP Manager, the ajax thing that loads the page normally now spins forever and if I try to go to a different page, it shortly blinks this error in the top/right corner "The API request failed with the following error: 0- Unknown Error." The thing is if I do not do anything in WHM for 10 minutes and then I click on MultiPHP Manager, the page, along its ajax list loads instantly, like in 0.1 second. It's extremely fast when it's not hanging onto something (presumably MODSEC?) Anybody knows what could cause that many false positives under MODSEC? Especially 127.0.0.1 hits!? And is rule #920280 even necessary to begin with? Might be related to

• 

  cPanelAaronH

  • November 06, 2020 02:31

  Hey there, That does appear to be the same issue and I can reproduce that on my server. There is a workaround posted in the following forum post: below 920280 - I recommend you try and keep your Custom rules below 900000) 2) Click on the Add Rule blue button 3) Paste the following code into the Rule Text Box # # This chained rule looks for the whm-server-status script being called from localhost # If both the rules validate, the rule id 920280 is disabled for this transaction # SecRule REQUEST_URI "whm-server-status" id:1000,phase:1,t:none,pass,nolog,chain SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" t:none,nolog,ctl:ruleRemoveById=920280
  4) Check the Enable Rule and also the Deploy and Restart Apache boxes. 5) Click Save
  

  0
• 

  Benjamin D.

  • November 11, 2020 11:10

  SecRule REQUEST_URI "whm-server-status"

  
  OK, but the request URI's in the hits list were simply "/" not "whm-server-status". I disabled the rule altogether. It seems to have taken care of most of the hangs. I still get some but much less often.

  0

Please sign in to leave a comment.