EBL Issues

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
Cyber Elite

EBL Issues

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
IPs:
184.24.76.74
104.66.34.213
23.197.186.129
173.241.244.220
104.95.37.162

 

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?


Accepted Solutions
Highlighted
L3 Networker

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.24.76.74 & dst: 10.191.44.21 then my guess traffic is inititated from 10.191.44.21 to 184.24.76.74, 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?

 

 

View solution in original post


All Replies
Highlighted
L5 Sessionator

Are you able to see the list of IP address in the cli when you run the command:

 

request system external-list show type ip name <Name of ELB>

Highlighted
Cyber Elite

Yes, that's actually where I pulled it for the original post.

Highlighted
L5 Sessionator

could you share the screenshot of the policy that you have configured? and you are blocking traffic going to EBL ip or coming to EBL ip?

Highlighted
Cyber Elite

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.

EBL.PNG

Highlighted
L5 Sessionator

Could you show the logs that should hit this rule but is not hitting. 

Please attached the detailed log view.

Highlighted
Cyber Elite

Hopefully this is what you were looking for.

domain: 1
receive_time: 2016/06/16 14:39:46
serial: 001801005401
seqno: 34507671
actionflags: 0x0
type: THREAT
subtype: vulnerability
config_ver: 1
time_generated: 2016/06/16 14:39:46
src: 184.24.76.74
dst: 10.191.44.21
natsrc: 184.24.76.74
natdst:
rule: Rule 644
srcuser:
dstuser: \jallison
srcloc: US
dstloc: 10.0.0.0-10.255.255.255
app: soap
vsys: vsys1
from: outside
to: inside
inbound_if: ethernet1/2
outbound_if: ethernet1/1
logset: Solarwinds-Email
time_received: 2016/06/16 14:39:46
sessionid: 51703
repeatcnt: 10
sport: 80
dport: 63177
natsport: 80
natdport: 13041
flags: 0x400000
proto: tcp
action: reset-both
cpadding: 0
dg_hier_level_1: 0
dg_hier_level_2: 0
dg_hier_level_3: 0
dg_hier_level_4: 0
vsys_name:
device_name: LegFPA1
vsys_id: 1
threatid: HTTP Request Brute Force Attack(40059)
reportid: 0
category: computer-and-internet-info
contenttype:
severity: high
direction: server-to-client
url_idx: 1
padding: 0
pcap_id: 0
filedigest:
user_agent:
filetype:
misc:
cloud:
xff:
referer:
sender:
subject:
recipient:
file_url:

 

Highlighted
L5 Sessionator

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

Highlighted
Cyber Elite

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. 

Highlighted
L5 Sessionator

May be the text file have some issue or it may be the issue with the firewall. Try creating a new txt file and check if not then please open a case with support.

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 Live Community as a whole!

The Live Community thanks you for your participation!