Captcha - WordPress login
Forum
  1. Forums
  2. Imunify360
  3. Imunify360 and Imunify Sensor
  1. Morten
  2. Friday, 10 March 2017
  3.  Subscribe via email
I noticed that Comodo WAF stopped working after Imunify360 was installed. It's not reporting any hits in WHM anymore.
Bug? (CSF and LFD is enabled)

I also did a brute force attack, but CWAF did not stop it. But after alot of attempts IM360 did stop it.

I got this message in WP login page:
Error: 405 Method Not Allowed

Sorry, the requested URL 'http://fakedomain.com/wp-login.php' caused an error:

Method not allowed.

Shouldn't captcha show when refreshing?
I had to manually change URL to fakedomain.com and captcha was showing there.


INFO:
Fri Mar 10 02:52:35.644660 2017 fakedomain.com /wp-login.php WordPress login attempt

Sensor:
ossec

Rule:
10605

Abuser:
185.137.18.xx

Is there any possibility to change ossec rule 10605? To block faster?
Rate this post:
  1. 10.03.2017 15:03:53
  2. # 1
Alexandr Accepted Answer
Posts: 0
Joined: 21.11.2019
0
Votes
Undo
Dear Customer,

Regarding the blocking rate, currently we block a user if there are 10 login attempts in 2 minutes. We find this reasonable in the first iteration of the rule to avoid many false positives. In the future we may decrease this value if there are no complaints from the customers. If you are eager to do this right now you can tune these parameters in /var/ossec/etc/rules.d/defence360_rules.xml line 39 followed by '/var/ossec/bin/ossec-control restart'.

Regarding the automatic captcha redirect, we are looking to implement this in one of our next releases in about 2 weeks. This would be helpful indeed.

Regards,
Imunify360 staff.
  1. 11.03.2017 15:03:14
  2. # 2
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
Thanks for your reply. I will check that .xml file and see if I do some changes or not.

But about Comodo WAF issue you didn't find anything on that? I tried changing the logging from Serial to Concurrent and that didn't work.
Seems like Imunify did take over mod_security on the server:

--11e7d75f-B--
POST /wp-login.php HTTP/1.1
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1
Content-Length: 52
Host: domain.tld
Cookie: wordpress_test_cookie=WP+Cookie+check

--11e7d75f-H--
Message: Warning. Pattern match "^POST$" at REQUEST_METHOD. [file "/etc/apache2/conf.d/modsec_vendor_configs/imunify360_rules/i360.conf"] [line "25"] [id "33332"] [rev "1"] [msg "WordPress login attempt"] [severity "WARNING"] [maturity "1"]
Stopwatch: 1489244594741842 103920 (- - -)
Stopwatch2: 1489244594741842 103920; combined=3900, p1=444, p2=3114, p3=61, p4=26, p5=171, sr=66, sw=84, l=0, gc=0
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache
Engine-Mode: "ENABLED"

--11e7d75f-Z--

When I asked Igor last time, he said that Imunify360 should not do any WAF rules and will not function as that as it was hard to compete and invent the weel again.

In /etc/apache2/conf.d/modsec_vendor_configs/imunify360_rules/i360.conf I only see 3 rules.
  1. 11.03.2017 15:03:37
  2. # 3
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
CWAF seems to still be working and logging to:
/usr/local/apache/logs/modsec_audit.log

--0ffe2e30-B--
GET /test.html HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)
Accept: */*
Accept-Encoding: deflate, gzip
Host: http://www.domain.tld

--0ffe2e30-H--
Message: Access denied with code 403 (phase 2). Matched phrase "AhrefsBot" at REQUEST_HEADERS:User-Agent. [file "/var/cpanel/cwaf/rules/02_Global_Agents.conf"] [line "34"] [id "210832"] [rev "2"] [msg "COMODO WAF: Blacklisted by userdata_bl_agents||http://www.domain.tld|F|4";] [data "AhrefsBot"] [severity "WARNING"]
Action: Intercepted (phase 2)
Stopwatch: 1489245322672179 685505 (- - -)
Stopwatch2: 1489245322672179 685505; combined=717, p1=562, p2=121, p3=0, p4=0, p5=34, sr=82, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache
Engine-Mode: "ENABLED"

--0ffe2e30-Z--

But logging inside WHM->
Home »Security Center »ModSecurity™ Tools »Hits List
Stopped logging when installed Imunify360.

If you need to check this you can follow up in the email on friday and get access if you need to replicate this when installing IM360.
  1. 13.03.2017 12:03:27
  2. # 4
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
It is a bug. We are working on fixing it.
  1. 13.03.2017 15:03:04
  2. # 5
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
Thanks Igor :D
  1. 13.03.2017 21:03:22
  2. # 6
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
I'm also seeing Comodo WAF no longer functioning on all servers with Imunify360 installed :(
  1. 14.03.2017 14:03:23
  2. # 7
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
I did upgrade to version 1.1.4 today and hits from Comodo WAF is still not listed in WHM!
  1. 14.03.2017 15:03:45
  2. # 8
Oleksiy S Accepted Answer
Posts: 0
Joined: 21.11.2019
0
Votes
Undo
> I did upgrade to version 1.1.4 today and hits from Comodo WAF is still not listed in WHM!

Hi Morten,

This is a bug, jira id is DEF-1128. Please expect this jira bugfix will appear in one of subsequent bugfix releases: 1.0.5 or 1.0.6
  1. 14.03.2017 15:03:31
  2. # 9
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
In addition to entries not being logged in WHM, I'm not seeing anything new in /usr/local/apache/logs/modsec_audit.log either. Does this mean that ModSecurity is not functioning at all now?
  1. 14.03.2017 15:03:25
  2. # 10
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
In addition to entries not being logged in WHM, I'm not seeing anything new in /usr/local/apache/logs/modsec_audit.log either. Does this mean that ModSecurity is not functioning at all now?


Pretty sure CWAF is not working for you then. In my testing server it's logging both from Imunify and CWAF in that file.
  1. 14.03.2017 15:03:47
  2. # 11
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
> I did upgrade to version 1.1.4 today and hits from Comodo WAF is still not listed in WHM!

Hi Morten,

This is a bug, jira id is DEF-1128. Please expect this jira bugfix will appear in one of subsequent bugfix releases: 1.0.5 or 1.0.6


Thanks! Looking forward for a fix :-)
  1. 14.03.2017 15:03:09
  2. # 12
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
In addition to entries not being logged in WHM, I'm not seeing anything new in /usr/local/apache/logs/modsec_audit.log either. Does this mean that ModSecurity is not functioning at all now?


Pretty sure CWAF is not working for you then. In my testing server it's logging both from Imunify and CWAF in that file.


I'm not getting anything new logged in /usr/local/apache/logs/modsec_audit.log or in Imunify. Comodo WAF was working perfectly before installing Imunify.

Any idea how to fix? I should note I am using Litespeed and not Apache.
  1. 14.03.2017 15:03:08
  2. # 13
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
Actually, it's not logging on either of my test servers, one running Litespeed, the other Apache.
  1. 14.03.2017 15:03:21
  2. # 14
Morten Accepted Answer
Posts: 103
Joined: 16.04.2014
0
Votes
Undo
Ok, I have only tested this on a Apache server with mod_lsapi. Do not dare to test on LiteSpeed yet :p
Did you upgrade to latest version that came today?
  1. 14.03.2017 15:03:45
  2. # 15
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
Both my Apache + mod_lsapi and LiteSpeed servers are not logging anything new to /usr/local/apache/logs/modsec_audit.log.
  1. 14.03.2017 15:03:29
  2. # 16
Oleksiy S Accepted Answer
Posts: 0
Joined: 21.11.2019
0
Votes
Undo
> I'm also seeing Comodo WAF no longer functioning on all servers with Imunify360 installed :(

Hi Ryan,

That appears to be another Imunify bug jira id DEF-1169.

Imunify current version 1.0.4 tweaks ModSecurity SecRuleEngine setting from "Process the rules" to "Process the rules in verbose mode, but do not execute disruptive actions" which results Comodo WAF ModSecurity rules do not block.

Could you please change this setting ("Security Center" -> ModSecurity Configuration > SecRuleEngine) back to "Process the rules"?

The captcha will not work for CWAF blocks but Imunify will not be taking over block ability from CWAF, at least.

Please expect for general fix (jira id DEF-1169) to appear in changelog for one of our next bugfix releases.

Could you please attach output of
# imunify360-agent doctor
command so we can follow up if our guess regarding this bug is correct.

Thank you,
Imunify Developer
  1. 14.03.2017 16:03:56
  2. # 17
Oleksiy S Accepted Answer
Posts: 0
Joined: 21.11.2019
0
Votes
Undo
> I'm not getting anything new logged in /usr/local/apache/logs/modsec_audit.log or in Imunify.
> Comodo WAF was working perfectly before installing Imunify.

> Any idea how to fix? I should note I am using Litespeed and not Apache.

Hi Ryan,

Could you please open helpdesk ticket via -
https://helpdesk.cloudlinux.com/

We need more info to help you with figuring out what can go wrong with your Litespeed configuration.

Thank you,
Imunify developer
  1. 14.03.2017 16:03:03
  2. # 18
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
Actually I dug into it and on my Apache & mod_lsapi (EasyApache 4) server, nothing is being logged to /usr/local/apache/logs/modsec_audit.log, however I am seeing files generated in /var/log/apache2/modsec_audit/ with those entries being recorded in Imunify dashboard.

However, on my Litespeed (EasyApache 3) server, the /var/log/apache2/modsec_audit/ doesn't exist since this server isn't on EasyApache 4 yet. Should I try creating this directory or update the MODSEC_AUDIT_LOG_DIR variable in /opt/alt/python35/share/imunify360/scripts/modsec_log_collector?
  1. 14.03.2017 16:03:15
  2. # 19
Oleksiy S Accepted Answer
Posts: 0
Joined: 21.11.2019
0
Votes
Undo
> Should I try creating this directory

Ryan,

That will be the most straightforward way to fix audit logs. Please do.

> However, on my Litespeed (EasyApache 3) server, the /var/log/apache2/modsec_audit/ doesn't exist since this server isn't on EasyApache 4 yet

I logged a jira to make sure the dir will be created automatically if does not exist in next releases of Imunify.

Kind regards,
Imunify developer
  1. 14.03.2017 17:03:46
  2. # 20
Ryan Smith Accepted Answer
Posts: 32
Joined: 27.04.2016
0
Votes
Undo
Okay I've created the /var/log/apache2/modsec_audit/nobody/ directory and set it to match the permissions/ownership from my other server. Is there anything else needed to kickstart this to start working? I've restarted Imunify and Litespeed but haven't seen anything logged yet (usually I will see some hits every few minutes).

Another question - Is your Imunify ModSecurity rules compatible with Litespeed? Should there be no issues running it in conjunction with Comodo WAF ruleset?
  • Page :
  • 1
  • 2


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.