1. Read the threat log correctly
In the firewall’s Monitor section, open the threat logs and filter for the event, for example by source, destination or threat name. Note the severity, the threat name or CVE, and above all the action column.
An action of alert means the firewall noted the event and let the traffic through. Actions such as drop, reset or block mean it was stopped. The same signature can be alert-only in one rule and blocking in another, so read the action on the line you are looking at.
2. Separate scans from exploits
A burst of probes against many ports is a scan. It tells you the Internet is knocking, and it is noise to track, not a case to open. An exploit attempt names a specific vulnerability against a specific service. Only that second kind, and only when it was allowed, needs the steps below.
3. Check the target
- Identify the destination host and the service behind the NAT rule.
- Check whether that service is vulnerable to the CVE, using your scanner or agent data.
- Look at the host for signs of compromise around the time of the event: new processes, new accounts, outbound connections, changed files.
- If there are signs of compromise, treat it as an incident: contain first, then investigate.
4. Fix the cause: patch the target
The firewall profile is a safety net, not the fix. Apply the vendor update to the vulnerable service, or, if there is no fix, apply a mitigation such as disabling the feature or restricting who can reach it. Confirm the fix from fresh scanner or agent data.
5. Tighten the vulnerability protection profile
- Go to Objects, Security Profiles, Vulnerability Protection and open the profile used by the rule that allowed the traffic.
- Check the rules inside the profile. They match in order and the first match wins, so a broad alert rule placed above a stricter one overrides it.
- For critical and high severity, set the action to block or reset so the connection is ended, not just logged.
- Check that the profile is actually attached to the security rule (directly or through a profile group). An unattached profile does nothing.
- Commit, then watch the threat log to confirm the same event is now blocked.
Test changes to profile actions on a limited scope first if you can. Blocking can break a legitimate application that sends traffic matching a signature.
6. Verify and keep watching
After the patch and the profile change, check that the same exploit attempt, if repeated, now shows a blocking action and that the target no longer reports the vulnerability. Keep the case open until both are true, and reopen it if the attempts return.
Where Cronzy Watch fits
Cronzy Watch reads the firewall’s threat and traffic logs, picks out the exploit attempts that were not blocked, ties each to the vulnerable asset behind the firewall, and opens a case with a deadline. The case shows the how-to-fix steps, including the firewall CLI with verification and rollback, and keeps watching until the attacks stop. See Palo Alto firewall security. If you need to block an address now, a second person can approve a response action.