Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
For traffic logs, I usually recommend to "log at session end" for all of the security policies, and then filter out what you don't want to see. This can be accomplished in the ACC as well as the raw logs. One way is to do it by rule name:
This shows you traffic and threats, except for those you specifically filter out in the list. Once you find a view that you like, you can create your own custom ACC tab and have those filters pre-populated.
You can do similar things in the traffic, threat, and unified logs with a query like:
(rule neq 'allow to services') and (rule neq 'allow untrust to untrust')
One benefit to this approach is that you still have logs for all of the events, but you're only shown the ones you're interested in.
You're aware of the "log at session start" and "log at session end" options. That governs how traffic is logged for each individual security policy. If, for example, you have an internal application that generates way too many logs and you need to reduce the # of logs being written to disk (to increase log retention time for other traffic logs), then your next option is to not log any traffic through this particular security policy rule.
Afaik, this only affects "traffic logs" (aka traditional firewall logs). You'll still have URL logs, Threat logs, Data Filtering logs, etc. if applicable.
If your goal is to reduce logging for certain threat signatures, that can be done on a case-by-case basis by using security profile "exceptions". Let's say you had a network monitoring server that initatiates SSH sessions to network equipment all throughout your environment and it was generating too many "SSH2 Login Attempt" information alerts in your threat logs. You could add an exception to that profile by a.) enabling the exception, and b.) adding the IP address (source or destination). This action will disable that signature for traffic inspected by this specific profile and to/from the listed IP address.
Hopefully that gives you enough information to accomplish your goals. If not, let us know in more detail what you're trying to accomplish, what you see and what you'd like to see, and we'll figure it out.
Hello,
You should be able to accomplish this with a Vulnerability Protection Profile. Objects->Security Profiles-> Vulnerability Protection.
Here I have the polciies to block the offending IP for 1 hour.
Once this is completed you need to add the profile to a Security Polcies to it will take affect. What I usually do is Set all the security Profiles I need and then Bundle ithem into a Security Profile Group, then just apply the group to the security Policy.
Hope that helps!
Cheers.
For traffic logs, I usually recommend to "log at session end" for all of the security policies, and then filter out what you don't want to see. This can be accomplished in the ACC as well as the raw logs. One way is to do it by rule name:
This shows you traffic and threats, except for those you specifically filter out in the list. Once you find a view that you like, you can create your own custom ACC tab and have those filters pre-populated.
You can do similar things in the traffic, threat, and unified logs with a query like:
(rule neq 'allow to services') and (rule neq 'allow untrust to untrust')
One benefit to this approach is that you still have logs for all of the events, but you're only shown the ones you're interested in.
You're aware of the "log at session start" and "log at session end" options. That governs how traffic is logged for each individual security policy. If, for example, you have an internal application that generates way too many logs and you need to reduce the # of logs being written to disk (to increase log retention time for other traffic logs), then your next option is to not log any traffic through this particular security policy rule.
Afaik, this only affects "traffic logs" (aka traditional firewall logs). You'll still have URL logs, Threat logs, Data Filtering logs, etc. if applicable.
If your goal is to reduce logging for certain threat signatures, that can be done on a case-by-case basis by using security profile "exceptions". Let's say you had a network monitoring server that initatiates SSH sessions to network equipment all throughout your environment and it was generating too many "SSH2 Login Attempt" information alerts in your threat logs. You could add an exception to that profile by a.) enabling the exception, and b.) adding the IP address (source or destination). This action will disable that signature for traffic inspected by this specific profile and to/from the listed IP address.
Hopefully that gives you enough information to accomplish your goals. If not, let us know in more detail what you're trying to accomplish, what you see and what you'd like to see, and we'll figure it out.
