specific blocked IP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

specific blocked IP

L4 Transporter

Is there a way to search for one IP and all the places it might be blocked on the firewall?

10 REPLIES 10

L7 Applicator

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)>

@jvalentine

I should have qualified the question, find a rule that is going to block a certain IP

I would recommend using the "test security-policy-match" CLI command then.  

@jvalentine

 

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. 

 

@jdprovine,

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. 

@BPry

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

"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.

@jvalentine @BPry

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. 

@jdprovine,

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. 

 

 

@BPry

We are allowing it because it is a wordpress server hosting blogs. But as we all know wordpress servers are dirt magnets

  • 4376 Views
  • 10 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!