Palo Alto/QRadar Netflow Integration

IBM has been saying since around 2012 that they integrate with Palo Alto for Layer 2 Netflow informatiion. Well an old QRadar I tested it on, did no such things; it actually stripped the Palo Alto-specific fields out of the payload. I read a lot of forums online saying the same thing. Luckily I had access to a brand new 7.2.6 demo VM and it works...sort of. The important thing is that it displays the full payload of the Netflow packet.

IBM provides a Security Content Pack for Palo Alto which as far as I can tell is useless. To get the data into QRadar properly we'll need to make custom fields (note that the "Application" field that QRadar uses port-based look ups will still be present in the log information).

Firstly, we'll need to set up a Netflow profile on the Palo Alto to point to the QRadar; make sure you check PAN-OS Field Types as this allows for User-ID and App-ID information to be sent. Also be sure to include a policy if they’re in different zones to permit the traffic.

Apply the profile to interfaces. Make sure these are inside interfaces and not web facing unless you’ll end up getting a lot of noise.

 

In the QRadar, add the Palo Alto device as a Flow Source, use the same port you specified in your Netflow profile on the Palo Alto

Once added you should see a bunch of flow traffic coming into the “Network Activity” tab in QRadar.

If you go into one of them, you’ll notice that QRadar doesn’t map Palo Alto’s Layer 7 information (App-ID and User-ID) correctly or at all for that matter. The current application being indexed for each flow is a port-based lookup that the QRadar performs.

To get around this we can create two Custom Flow Properties. Navigate to Admin> Flows> Custom Flow Properties and click Add at the top and fill out the little wizard-esque window with the appropriate fields, mine is below.

The regex I wrote for this should catch all alphanumeric character as well as generally used special characters as well as periods, hyphens, underscores, and backslashes (to accommodate the domain name being included in the username). I can’t imagine any other characters showing up in this field.

The Regex for User-ID fields: (?:PALOALTO_USER_NAME=)([\w\.\-\_\\\!\@\#\$\%\^\&\*]*)

You can go ahead and do the same for the application ID; luckily only alpha and hyphens will show up here because that’s all Palo Alto uses for its naming. I included underscores as well because application signatures can be user-created and they may end up using them.

The Regex for App-ID fields: (?:PALOALTO_APP_ID=)([A-Za-z\-\_]*)

  

Once that’s completed, you can go back to your Network Activity and see the applications and users being mapped correctly.

Now that we’re indexing App-ID and User-ID, we can use them for reporting and graphs. Some example of use cases would be:

• Top-Talkers by App or User
• Reference set of Users for use with rules
• Behavior analysis of application use (thresholds)
• Offenses based on unpermitted applications (if app is in not allowed reference set and from user x then fire offense)

Palo Alto Hardening

People tend to forget that the Palo Alto isn't just a stateful firewall, but because they've had experience with deploying them (Netscreen, ASA, Checkpoint, etc) that's how they set them up.
Yes, people will attach inspection profiles to their policies and think they get all the protection they paid for - but there's a lot more to hardening a firewall than just flipping a switch.

I'm going to go over a few hardening techniques for Palo Alto that should help you secure your network.

Everything is an application
If your users are using custom ports for services (8080 for example), don't create a service for it, create a custom application. Provided you set up the signature correctly, this will prevent other applications from hijacking this port.

Organize your network
The Palo Alto should be the default gateway for everything in your network. It should be your router on a stick. This way you'll have full visibility on East/West as well as North/South traffic. Most people will be hesitant to do this because you'll lose bandwidth (Nexus switches push an excess of 900Mbps whereas the Palo Alto are well under 300Mbps). This is something you'll have to speak to your clients about, is the faster accessing of a server in the DMZ worth the risk?

The DMZ is the DMZ
Continuing with the last topic, your DMZ is exactly that, it's demilitarized. Keep the DMZ out of your trust network, don't put your publicly accessible web server and your DC in the same zone. Even with the Palo Alto in the middle of your network, if you have a web server and your DC on the same segment and your server gets compromised - you'll be switching packets over without your noticing. That's where a VM-series Palo Alto comes into play (something I'm not going to get into here). If you have to, create a second DMZ; the point is to keep things out of your trusted zone.

Be paranoid
Palo Alto endorses a concept of a "zero trust network" and so should you. You can't trust anyone in your network so you have to lock things down as tight as you can to prevent anything that'll come up. If you can afford the decryption hit to your throughput (usually 50%), turn it on. Enable file blocking to and drop any file you can't inspect; unless you have TRAPS, you as a firewall admin can't rely on McAffee to do its job.

Another good practice is to use the 'continue' option in file blocking. This will prompt the user when a download occurs for them to confirm it's legitimacy - this will help stop drive-by-downloads.

There can be only one DNS
Have your DNS server be the only host on the network (yes you can have more than one, but the point is it's something YOU control) sending egress queries. There's no reason for Joe Blow in marketing to be contacting a public DNS server.

Sink it
Setting up a single DNS server makes it difficult to identify who on the network sent the original request. Palo Alto has a feature which enables it to passively intercept DNS queries if a bad host is attempting to be resolved it will respond with a bogus IP; this is your sinkhole address. Once that happens the host will attempt to establish a session with it and you'll have a policy to pick it up and your logs will show the original sender.

Authorize everyone
Speaking of identifying users, you should be using User-ID everywhere possible. This will let you deploy policies specifying specific groups and users as a source as well as identify users who are doing things they shouldn't be.

Keep up your policies
I'm going to outline a small list of policies you should keep at the top of your policy list to help secure your network

Rule	Purpose/Description	Caveats
Dynamic Blocklist	Uses Spamhaus’ DROP (don’t route or peer) list to block ingress and egress traffic. This list consists of known bad addresses.
Block by Country	Blocks ingress traffic from countries which the client does not conduct business with. Particularly useful if NATs are in place.	Mobile users may have issues connecting remotely. Ingress GlobalProtect permit-any policy may be required above this.
DNS Sinkhole	Uses Passive DNS inspection to perform dynamic DNS resolution on bad FQDNs. This policy allows logs to be generated for these requests.
Drop High-Risk	Denies traffic for high risk (risk level 5) traffic.	Applications which are common-use may fall into this category, specifically SMTP and HTTP-Video; these will need to be overridden to a risk of 4 or lower.
DNS from Server/DNS from Any	Only allows DNS traffic from a dedicated DNS server.	DNS server use will need to be enforced. May only be applicable to corporate zone (guests will be allowed to Google or Level3 DNS).
53 from Any	Prevents traffic being tunneled out port 53.
Block by Category	Specifying the URL categories in its own policy prevents the Palo Alto from passing this traffic through the rest of the Content-ID engine, which saves CPU cycles. Useful on larger devices.

Don't risk it
One thing I didn't include above was any inspection policies. You'll want to apply a block to any application with a risk rating of 5. Yes, SMTP and some others have a risk of 5, well override these ones. It's easier to override 3 or 4 applications (if you legitimately need them) than it is to risk your network.

They're there to be used
A lot of Palo Alto firewalls I've seen don't user Zone Protection or DoS Protection - they're there for a reason, turn them on.