Cisco ASA to Palo Migration for ACLs

[Stevenjwilliams83]

It seems to me that the "migration" from Cisco ASA to Palo is not apples to apples. Working in ASA for quite some time I am able to control traffic as what I allow in to the interface....So if I have 14 security zones I can control what comes into interface 5 without having to go to 13 security zones and denying the access to interface 5 from all zones. Palo uses zones, which i guess you can map to "interface security Zones" But the ability to combine rules and make them bi-directional within the same rule makes the policy less lines per say. The issue I am finding is you can use a zone for source and build a "block" of rules for all subnets within that zone and allow them to all the destinations. Then at the end of that block you can put a deny rule in there for those source subnets to any, but this doesn't stop other things and zones from accessing them since they are just denied from talking out. So this is where the Deny rule at the end of the policy comes in, but what about another "Block" of rules that needs to be locked down? I feel like you can't really deploy rules in a stepped phase. What did people do in a migration situation? 

[ddelcourt]

It certainly is not always apples to apples as both platforms can secure traffic but do it a little bit differently... in PANOS there is an implicit deny, so if you don't permit something it will be denied by default... if you want to see (log) what is being denied then you would want to create an explicit rule so you can attach logging to it.

In PANOS, similar to Cisco, it is all about the direction of the expected traffic flow... the return traffic is automatically allowed, the essence of statefulness. There are ways to create more inclusive rules with multiple source/destination zones and/or IPs/subnets.

Do you have a specific example to help illustrate what you are trying to do?

[S.Cantwell]

Hi Steve!

Been working with PANW firewalls, doing migrations from Cisco ASA to PANW, using a nearly apple to apple migration strategy.

I sort of understand your question, but I also think I would like to see a few screen captures to show us what it is you are attempting to do.  The GUI of the FW is pretty powerful and so if we can see a rule that you are have a challenge with, we can visually determine what is the best way.

There is a lot of confusion between bi-directional (which I think is a term used for static NAT using bidirectional) and bi-directional between the zones (trust to dmz, and then dmz to trust... if combined into a single rule, I guess is also considered bidirectional).

Anyways, each interface on the FW should have been in its own zone. 

So, if your Cisco ASA had 14 interfaces, and you controlled traffic through the ACLs, then when the policy is configured to PANW, each of your 14 interfaces (although technically inside or trusted part of your network), should have had different zones.

Then traffic from Zone1 can/cannot talk to Zone2, based on how the traffic is ingressing from the interface.

Again, this is where screen captures would help us, to help you!

Thanks

[Stevenjwilliams83]

So I have business units within my organization. So in the ASA world I would have an ACL called BU01_access_in. This would dictate what traffic behind the interface named "BU1" can talk to. Nothing else on any other interface can talk into the interface unless allowed within the ACL.

So if I want to build groups of rules based on TAGs like BU01 I would need to make sure all traffic it needs to access and all traffic that needs to access it is defined because then I would want to build a deny rule from the sources of BU1 to any and Any to BU1. So that deny would only affect that group of rules for the BU01. Palo gives you flexibility to build rules many different ways, so its hard to decide on a "best way".

examples:

rule 1 - Allow BU1 server network to Domain controllers (in different networks)

rule 2 - Allow BU1 server network to NTP Servers (in different networks)

rule 3 - Deny BU1 server network to RFC1918

rule 4 - Allow BU1 server network to Internet

rule 5 - Deny BU1 server network to ANY

rule 6 - Deny ANY to BU1 server network

so this means that domain controllers in any other subnet beside BU1 servers wont be able to communication inbound to the server network because of the last rule. 

I need to deny to rfc1918 because I do not want the server subnet to talk to any subnet it shouldnt unless allowed. 

I need to allow an any after the rfc1918 for servers to get to internet for things like DUO MFA, Cloud based apps, etc, etc. 

Maybe that last rule isn't needed? 

[S.Cantwell]

Hello Again..

When you said you were making rules based on tags, I am confused.

As a zone based FW, you are making rules based on the SZ and DZ (src and dest zones)

You are right that there are different ways to accomplish it.

And it looks like you have a great understanding.

Are you familiar with concepts of of the Intrazone and Interzone rules?

Intrazone (traffic within same zone is allowed by default)

Interzone (traffic between 2 different zone is denied by default)

Your policies could look like this

rule 1 - Allow BU1 server network to Domain controllers (in different networks)

rule 2 - Allow BU1 server network to NTP Servers (in different networks)

rule 4 - Allow BU1 server network to Internet

These rule would not necessarily needed (presuming the RFC traffic is on different zones (when you mentioned different subnets).

And if this traffic is indeed, in different zone, then the interzone.

rule 3 - Deny BU1 server network to RFC1918

RFC traffic would NOT be going out to the Internet, so why does this need to go above the Internet rule?

Internet and RFC traffic should be in different zones (not possible to route private IPs to Internet), 

rule 5 - Deny BU1 server network to ANY

rule 6 - Deny ANY to BU1 server network

The best way, is to put all of more specific traffic at the top of the FW, and general aftewards.

So I would focus on all of your ALLOW rules in your policies.

Whatever is not allowed will hit the clean up rule (if you create one) or be denied with the default Interzone rule.

I would be glad to do a screen share session (if comfortable) and help you have a better conversation.

You could also talk with your PANW SE or even your reseller (presuming they have engineers who work on PANW)

[rmfalconer]

Another difference in the ASA vs PA is the security levels applied to interfaces. The PA doesn't have the concept of permitting higher to lower unless specifically denied. Everything is denied unless specifically allowed.

As @S.Cantwell said, if interfaces are in different zones, traffic is not permitted between them unless a policy is in place.

[jeremy.larsen]

There are 2 things I see ASA people getting hung up on when converting... well I guess more like 3.

1. PAN does not operate like an ASA (this is a good thing).  If you try and operate it like an ASA you will have a lot of pain.  Embrace the difference before tackling any conversion.

2. ASA Security Levels do NOT translate directly over to PAN Security Zones.  The implicit ALLOW when moving from a higher security level to a lower security level on an ASA does NOT translate over to a PAN.  Every Zone-to-Zone (interzone) communication has an IMPLICIT Deny.  This "may" change your rule set quite a bit.

3. I've seen too many ASA guys (and others) get hung up on strictly defining src/dst subnets and ports in their rules.  I'm not saying to never do this.  BUT, embrace the way zones work and don't get so hung up on IP/Ports all the time.  Also, embrace DNS/Users/Apps.  Think of your rules as allowing Users/Apps from zoneA to zoneB instead of IP/Port from interfaceA to interfaceB.

There is a learning curve but if you can learn to embrace the change you will be much happier.  You will find this makes your life easier in the long run as a PAN administrator.

Good Luck!

[Stevenjwilliams83]

I get the port/services thing, Layer 7 vs Layer 3. 

I do not think specific source and destinations is a bad thing. 

[Stevenjwilliams83]

I think some of the issues I am running into is we have business units within our organizations, and now that I think of it I should have ran multi vsys for each one which would have kept their rules "segregated" But now I am trying to slam all these rules into one vsys and one large policy. 

[jeremy.larsen]

Just be careful you don't jump on multi vSYS too quickly.  Realize that routing between vSYS will have to be piped out to a router and back in.  There is a shared gateway feature but it has severe limits on both what you can use it for and inter-vSYS throughput (don't expect anything over 1.5Gb/s on a 5200 series).  vSYS for something like a guest network that should never traverse your internal network is a good use case example.  I would try a rule organization that does something along the lines of sections broken out by source zone.  Using colored tags here really helps.