Imunfy360 uses tags for different ModSecurity rules. The purpose of the tagging mechanism - to allow easy automated categorization of events. Based on that, an Imunify360 agent can act differently for the different kinds of attacks. In this article, we are going to talk about further two types of rules in Imunify ModSecurity and related tags.
1. Blocking rules
These rules are developed to prevent someone from getting into the website or attacking and affecting the website’s performance. You can refer to an example of the test rule triggered below:
curl -v
http://mycoolwebsite.net/?i360test=88ff0adf94a190b9d1311c8b50fe2891c85af732
More details on how to check that ModSecurity works, you can find here.
Results:
INFO [2020-03-16 08:11:35,462] defence360agent.internals.the_sink:
SensorAlert({'modsec_version': '2.9.1', 'access_denied': True, 'tag':
['i360custom'], 'timestamp': 1584360695.4032168, 'domain':
'imunify-test.info', 'advanced': {'http_method': 'GET', 'uri':
'/wordpress/', 'headers': [['Host', 'imunify-test.info'],
['X-Forwarded-For', '10.102.1.24'], ['X-Accel-Internal',
'/internal-nginx-static-location'], ['Connection', 'close'], ['accept',
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'],
['user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3)
AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15'],
['accept-language', 'ru'], ['accept-encoding', 'gzip, deflate, br'],
['cookie', 'wordpress_test_cookie=WP+Cookie+check']]}, 'method': 'ALERT',
'name': 'IM360 WAF: Testing the work of the i360 ModSecurity rules',
'message': 'IM360 WAF: Testing the work of the i360 ModSecurity
rules||MVN:ARGS:i360test||MV:88ff0adf94a190b9d1311c8b50fe2891c85af732|
|T:APACHE||PC:1392', 'rule': '33312', 'vendor': ['CWAF_Apache'],
'properties': {'ttl': 300, 'expiration': 1584360995, 'deep': 0}, 'user_id':
'09c431aefdfe6481cf417f2e523af7d19ae82eb8', 'attackers_ip':
IPv4Network('10.102.1.24/32'), 'plugin_id': 'modsec', 'severity': 2})
You will see the corresponding entry in the Incidents tab of your Imunify360 Dashboard:
If we will look at the rule itself:
SecRule ARGS:i360test "@streq 88ff0adf94a190b9d1311c8b50fe2891c85af732" \
"id:33312, \
msg:'IM360 WAF: Testing the work of the i360 ModSecurity rules||MVN:%{MATCHED_VAR_NAME}||MV:%{MATCHED_VAR}||T:APACHE||PC:%{PERF_COMBINED}', \
phase:2, \
deny, \
status:406, \
t:none,t:lowercase, \
rev:1, \
severity:2, \
tag:'i360custom'"
We will see the “deny” action is in use in this rule. The “deny” action stops rule processing and intercepts transactions. And based on “status:406” we will get the HTTP 406 error as a response.
2. Non-blocking rules
The non-blocking rules (working in a pass mode) are typically used to track "suspicious activity". These rules check requests as well and generate entries in the logs as soon as those get triggered, but they will not prevent a visitor from getting to the site. We collect the information about these rules triggered and process them further.
Comparing with the blocking rules, you will also see the corresponding ‘noshow’ tag entry. It does not carry information load or benefit, our Imunify360 agent does not reflect them in the Imunify360 UI >> Incidents tab. But, unfortunately, triggering of these rules is displayed in the control panels and is present in the logs. You should not focus on them and worry about that when you see such records in your logs.
These rules do not create problems and delays, but only help to improve protection.
When we are talking about rules with the “noshow” flag - they are used for data collection, taking part in the agent’s logic as well as most “noshow” rules are involved in heuristic rules. An agent sends logs from "noshow" rules to the server where logs will be processed with heuristic rules and filled with the results. Some local heuristic rules available as well and an agent can make a decision to ban immediate and independently of a remote Imunify360 server. So it’s not recommended to disable “noshow” rules, as it can weaken server protection.
As an example we performed several failed attempts to access the CMSMadeSimple admin area – the ModSecurity rule 33334 was used for tracking CMSMadeSimple sign-in attempts from the captured IP as well as no IP blocking took place:
INFO [2020-03-16 08:03:01,473] defence360agent.internals.the_sink:
SensorIncident({'rule': '33334', 'modsec_version': '2.9.1', 'user_id':
'09c431aefdfe6481cf417f2e523af7d19ae82eb8', 'tag': ['bruteforce', 'i360',
'noshow'], 'attackers_ip': '10.102.1.24', 'plugin_id': 'modsec',
'timestamp': 1584360181.095125, 'domain': 'imunify-test.info', 'advanced':
{'http_method': 'POST', 'uri': '/admin/login.php', 'headers': [['Host',
'imunify-test.info'], ['X-Forwarded-For', '10.102.1.24'],
['X-Accel-Internal', '/internal-nginx-static-location'], ['Connection',
'close'], ['Content-Length', '111'], ['accept',
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'],
['content-type', 'application/x-www-form-urlencoded'], ['origin',
'https://imunify-test.info'], ['accept-language', 'ru'], ['user-agent',
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15
(KHTML, like Gecko) Version/13.0.5 Safari/605.1.15'], ['referer',
'https://imunify-test.info/admin/login.php'], ['accept-encoding', 'gzip,
deflate, br'], ['cookie', 'cmsmdsimpls_test_cookie=CM+Cookie+check']]},
'method': 'INCIDENT', 'name': 'CMSMadeSimple login attempt', 'severity': 4,
'message': 'CMSMadeSimple login
attempt||imunify-test.info||MTD:58e6b3a414||LOG:e', 'vendor':
['CWAF_Apache']})
The rule itself:
SecRule REQUEST_FILENAME "@endsWith admin/login.php" \
"id:33334,\
chain,\
msg:'CMSMadeSimple login attempt||%{REQUEST_HEADERS.Host}',\
pass,\
log,\
t:none,t:urlDecode,t:normalizePath,t:lowercase,\
phase:2,\
rev:'1',\
maturity:'1',\
severity:'WARNING',\
tag:'bruteforce',\
tag:'i360',\
tag:'noshow'"
...
As you can see, an action is “pass” and one of the applied tags is “noshow”.
This helps us to monitor and capture suspicious activity, to block attackers IP that are using some attacks we know nothing about, as well as to detect new attacks and develop specific blocking rules.
Comments
0 comments
Please sign in to leave a comment.