SIEM posting Botnets , but Firewall do not

[F.Pinar]

We are currently experiencing a situation in which we are receiving requests to our public segment pool. According to a syslog that Palo Alto sends to our SIEM, many of these IP addresses are part of a botnet. However, when we checked Palo Alto, we did not see this information in the traffic log.

• The SIEM/Sentinel is enriching logs received from Palo Alto using Microsoft threat intelligence, allowing it to classify IPs as malicious or part of a botnet even if Palo Alto does not directly identify them as threats.
• On the firewall, several observed events matched default rules such as Intrazone Default / Interzone Default or policies where not all required security profiles were applied.
• When a policy does not include profiles such as Anti-Spyware, Vulnerability Protection, and URL Filtering, the firewall may only log normal traffic without generating Threat-type events.
• Traffic with incomplete or expired sessions was identified, which may indicate that sessions were not fully established, preventing signature-based detection from being triggered.
• It was confirmed that the Threat Prevention license is active, therefore the analysis should focus on policy configuration, profiles, and lists.
• It was observed that logging at session start is not recommended as a general practice, as it can generate unnecessary log volume and additional resource consumption. Logging at session end is recommended instead.

However, the cliente cannot apply 24 ip address because they do not have an internal server to feed the firewall. My recommendation was to get GITHUB and its raw. Then, we applied as a source , but they firewall did not show up the IPS in question.

By any chance that you have any recommendations about it.

Any kind of help would be highly cherished.

Best Regards,

[PavelK]

Hello @F.Pinar

thank you for post!

It is common to see IP addresses associated with known scanners, attackers, malicious actors in the logs hitting resources that are publicly available. When it comes to security detection you should be looking into Threat logs instead of Traffic logs. In the Threat logs refer to columns: Type, Threat ID/Name, Threat Category. As a basic layer of protection I would recommend to configure a policy with Palo Alto's  built-in EDL lists: Built-in External Dynamic Lists  as a source and destination your public subnet and action deny. With this policy in place you can block know IP addresses based on Palo Alto's threat intelligence before it even gets to signature based inspection.

Additionally, Firewall can only block traffic that can inspect, therefore if you have publicly available services serving HTTPS you should consider to implement Inbound SSL Decryption. Here is a reference: How to Configure SSL Decryption. With Inbound SSL Decryption in place Firewall has a certificate that server has and is able to block traffic based on threat type before it reaches server.

Regarding points you highlighted below are my comments:

• Based on your description I can't rule out any potential misconfiguration in your Firewall. In nutshell known attacker IP addresses might be already included either in this EDL: " Palo Alto Networks Known Malicious IP Addresses" or in this EDL: "Palo Alto Networks High-Risk IP Addresses". Beyond this you will have to make sure that all policies have logging enabled and security profile attached. If Firewall has visibility into traffic with decryption enabled, it can detect threat based in Anti-spyware, Antivirus or Vulnerability protection. None of this gives you however guarantee that Firewall will treat this detection as a part of botnet. Firewall has built-in botnet detection: Monitor > Botnet which detects botnet traffic from inside your organization, not other way around. Also, this feature is available directly in Firewall. You will not find this option in Panorama.
• This looks expected. Unless there is a specific policy to match traffic, the traffic is going to hit default intrazone-default and interzone-default policies. These rules are effectively catch all polices.
• That is correct. To make use if all security features make sure to attach security profiles to all policies.
• Here is the KB with further explanation: Not-Applicable, Incomplete, Insufficient Data in the Application Field. What incomplete means TCP 3 way handshake was either not completed or after 3 way handshake was completed there were no data sent. This is common pattern in scanning / reconnaissance where scanner is probing open ports.
• That is correct. With Advanced Threat Prevention license you have most of the features to build solid security policy. Advanced URL Filtering, Advanced WildFire and Advanced DNS Security are complementary subscription that can take your security to next level.
• That is correct. You should avoid to use logging at session start unless you perform troubleshooting. In this case enable it temporarily

Regarding your last comment with GitHub, could you provide more information? Palo Alto has hosted EDL with all GitHub IPs: EDL Hosting Service GitHub. 

Thank you and Regards

Pavel