I've just started to test working with an EBL to quickly update a block list without having to apply the URL Filter to all of the different groups that we have. I've verified that I have connection to the document and that the Palo Alto sees it but I can't actually get it to stop showing traffic, instead the HTTP Request Brute Force Attack reset picks it up instead of the rule that I have the EBL on.
Currently the output looks like the following:
Next update at: Thu Jun 16 15:00:31 2016
The Rule is near the top of the list, set to universal on the outside zone with the EBL list set as the source address to any destination, any service, any applicaiton, and the action is to block it and log at end. The issue is I'm seeing in the alerts is that it's identified as Rule 644 which is a catch all allowing traffic on HTTP and HTTPS instead of being blocked by the EBL. Is there something wrong with the way that I've inputed the IPs?
Solved! Go to Solution.
How are you testing this rule? From which side/IP the traffic is initiated?
If the Threat traffic log shows it as server-to-client flow and src: 184.108.40.206 & dst: 10.191.44.21 then my guess traffic is inititated from 10.191.44.21 to 220.127.116.11, that way this EBL policy will not match. If traffic/session would be initiated from the 184.x.x.x, that the source address would matter when traffic hits Palo Alto (unless something is different for Dynamic Lists as I have not used them). But when you said using simple IP without EBL worked fine, that made me question my assumptions, but still sharing them with you.
Anyway you can try testing if the policy matches through CLI #test security-policy-match ... and try taking a look at #show running security-policy if there are EBL addresses seen within the rule. Additionally check session information by #show session id for that particular session.
What PANOS version are you running on?
Here you go. I'm trying to block the traffic coming from the EBL IP list; I'm starting to question if I don't need to set the destination as the EBL IP. When I look at the alert however it shows the source as one of the EBL IPs coming into the inside (Trust) interface, so I'm fairly certain that this should function perfectly fine.
http://textuploader.com/5b84q/raw : This is the link to the test EBL that I made, from what I could see in Palo Alto guides to working with the EBL the fact that I left out the /32 shouldnt' be causing issues but I'm not 100% positive on that.
Hopefully this is what you were looking for.
receive_time: 2016/06/16 14:39:46
time_generated: 2016/06/16 14:39:46
rule: Rule 644
time_received: 2016/06/16 14:39:46
threatid: HTTP Request Brute Force Attack(40059)
This should work.
Try one more this clone the EBL policy put it on top or the EBL rule and instead of EBL address object put IP and test. So that we can confirm if it is the issue with EBL or something else
With the IP instead of the EBL object the rule functions as it should. I also tried creating a rule specifically saying that our inside network can't go to the EBL as the destination and that appears to function fine.
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 Live Community as a whole!
The Live Community thanks you for your participation!