According to https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html Meraki MX (w/ Advanced Security, I'm sure) can detect and block Log4J exploits (https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java).
I'm curious how this is possible if the the traffic is TLS encrypted. As far as I know, Meraki MX is not doing SSL inspection/decryption which means that Log4j compromises couldn't be detected, right?
Hi community, we have this issue currently investigated (not with Cisco, but internally as we are a Cisco partner)
Meraki MX uses the same kind of security intelligence sources as lets say an FTD (Cisco Thalos, Snort,etc,..) , and after discussed this with our senior engineers we believe Meraki firewalls should have the latest updates installed and so the latest Snort-definitions.
See this for reference
It doesn't seem SSL inspection is necessary, but layer 7 application-based policy should do for IPS.
Also, I would personally recommend to restrict LDAP, DNS traffic to a bare minimum so it's tightened to what you really need (ex: DNS-server can reach outside, but rest of the network is more limited)
General security advisory..
Hope this helps
@DangerNoodle that is VERY cool. Thank you for sharing that. I would still like to know more details on *how* it works, but I guess it is just looking at source IP's. Do you know if this connection was inbound to a TLS encrypted port?
It was a http request made to the login page of the DVR.
It triggered this SNORT rule: https://snort.org/rule_docs/1-58737
Looking at the inspect packet, they tried to inject this:
To confirm, if Meraki is showing this as being blocked, that does not mean the downstream device is vulnerable, correct? It just means someone was hitting the downstream device with a string which the MX is blocking?
Correct. You should make an inventory to assess what is running vulnerable versions of software. I use Metasploit vulnerability scanner for this. Stay safe !
@lpopejoy for IPS/IDS, you don't necessarily need SSL decryption; otherwise, it would be useless a long time ago.
Primarily, it's based on the signatures (traffic flow behaviour/pattern/fingerprinting) that exploit uses.
Once it's detected/identified, a signature is created and pushed to the device IPS/IDS database.