04-13-2018 08:51 AM
Assumning you're logging all of your traffic, the Unified Log Viewer might be able to address this particular request.
Monitor / Logs / Unified
Use this query:
(addr in x.x.x.x) and (action neq alert) and (action neq allow)
The result of this query will show blocked traffic to/from that specific IP address, and whether it was blocked because of URL Filtering, File Blocking, Security Policy, Application Control, IPS, Anti-Virus, etc.
This would only show you things that have actually been blocked in the past. It will not show you things that might be blocked in the future.
If you're looking to "test" your security policy for some potential future event, take a look at the "test" commands available via the CLI. For example, "test security-policy-match"
admin@pa0-black_knight(active)> test security-policy-match
+ application Application name
+ category Category name
+ destination destination IP address
+ destination-port Destination port
+ from from
+ protocol IP protocol value
+ show-all show all potential match rules until first allow rule
+ source source IP address
+ source-user Source User
+ to to
| Pipe through a command
<Enter> Finish input
admin@pa0-black_knight(active)> test security-policy-match source 10.1.1.100 destination 4.2.2.1 protocol 17 destination-port 53 application dns
"deny outbound dns; index: 9" {
from any;
source any;
source-region none;
to untrust;
destination any;
destination-region none;
user any;
category any;
application/service 0:dns/any/any/any;
action deny;
icmp-unreachable: no
terminal no;
}
admin@pa0-black_knight(active)>
04-13-2018 08:54 AM
I should have qualified the question, find a rule that is going to block a certain IP
04-13-2018 09:48 AM
I would recommend using the "test security-policy-match" CLI command then.
04-13-2018 09:58 AM
I know the source but it looks like i have to enter a destination as well and that would give what rule is blocking it.
04-13-2018 12:44 PM
Isn't that what you are looking for? Unless the source address is blocked on a 'Blacklist' of sorts that sits above all the rest of your security policies, the source itself doesn't really matter.
Say for example I wanted to see if a source address of 1.5.5.5 would be blocked by my current policies, on my network it would be due to it existing in an IP block in a research range and it being included on a 'Blacklist' which is the very first security policy I have. Now if I wanted to check 206.185.243.187, which isn't in my blacklist, then I would need to go through my entire rulebase and see if that address would be allowed. It might be denied from my SMTP servers, but be allowed to hit my webserver, but then be denied from hitting an SSH jumphost. There is noway to go through and say is 206.185.243.187 going to be allowed across my entire rulebase automatically.
If you feel like an address is getting blocked for some reason, then using the unified logs as mentioned by @jvalentine is your best bet to see what exactly happened to the traffic.
04-13-2018 01:42 PM
I guess I would say I am trying to answer someones question - can you find the rule on the firewall that will block an IP address? Before you even try doing anything to or from that IP address
04-13-2018 01:50 PM - edited 04-13-2018 02:09 PM
"test security-policy-match" will find the rule on the firewall that will block a flow.
Of course, the firewall never sees "just" an IP address out of context.... it will also see source/destination IPs, source/destination ports, protocols, etc. The "test security-policy-match" requires that information in order to determine whether or not it would block that flow.
Changing any one of those variables (src/dst address/port, protocol, app) will affect the firewall's decision to allow/deny. For example, let's say you have only two firewall rules:
rule1: permit from x.x.x.x to "any ip" on udp/53
rule2: deny all traffic
Your question is will "x.x.x.x" be blocked? If it meets the additional conditions to match rule #1, then no, it won't be blocked. If it doesn't meet the conditions to match rule #1, then it matches rule #2 and will be blocked.
Now ask the question, with this same policy, will "y.y.y.y" be blocked?
If x.x.x.x initiates a connection to y.y.y.y on udp/53, then it will match rule #1 and will not be blocked.
If x.x.x.x initiates a connection to y.y.y.y on tcp/80, then it does not match rule #1 and will be blocked.
04-16-2018 06:09 AM
Again this question is based on a situation with coworkers where they think that the PA should be able to tell you if any of the rules you have will block a specific IP address/server
So can you remove a server from a rule that allows the traffic from the internet in to the server (external to internal) and stil be able to go to an ubuntu update site and download updates to the server that has been removed from and internet incoming rule.
04-16-2018 10:15 AM
That would depend on why you were allowing traffic from the internet in to the server; if it was configured this way because the external host was initiating the traffic to the server then you would likely still need it.
If the server in question is the one initiating the traffic and the external server is simply replying, it'll match the session already allowed and the traffic will be allowed to pass.
04-16-2018 12:45 PM
We are allowing it because it is a wordpress server hosting blogs. But as we all know wordpress servers are dirt magnets
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
