I’m about to swap from an ASA to a Palo. On my ASA I have a bunch of contexts and ACLs. I want to consolidate into a single firewall. How does like a Trust zone work? What is best practice to put within the same zone? For example I would have ACLs: outside,management,app,database,dmz. Do people just put outside on a no trust zone and everything else in trust? Do you need to go through security policies if 2 networks are in the same zone? I’m only asking these questions because i’ve now seen 2 big companies work off pretty much only 2 zones, trust and untrust. Do they not care about security between an app network and database network?
How one use’s Zone’s would be up to the business needs. Our DC PA’s have over 20 zones, small stores have 2-4. How much intra-company different-privilege traffic do you want to police?
As far as you “seeing big companies with only 2 zones”, that be their external FW only, maybe they run internal FW for internal traffic.
Zones are just a logical grouping of hosts/subnets for policing purposes, the exact same functionality they have on ASA. If you want to be “host a can’t talk to host b” and they’re say two PCs in accounting that sit next to each other, then put them in the same zone, override the default intrazone permit rule to a deny, turn in private VLANS on the switch port level to enforce port isolation (basically disable local ARP to CAM switching which would otherwise bypass the firewall), and build any policies as required (from zone accounting to zone accounting, host a to host b). If you do this be very mindful of throughput and session table limitations of your PA. It’s usually complete overkill but I’ve seen it and deployed it, it has its place.
On ASA you can create ACLs that match an inbound interface. This can have scaling issues if you want to have one rule match multiple similar interfaces. Zones are a way of grouping interfaces to treat them the same in a rule.
For example, I have OOB management tunnels going out to various sites. Since every one of these tunnels serves the same purpose and carries the same traffic, I only have one rule for all the tunnels. I created a zone for all those interfaces and added them to the zone. Now I can create a rule that says “source zone of the OOB management tunnels” and match them all at once.
Hope that makes sense!
I make a zone for anything I want to regulate different. For example at our main plant I have a server zone, dmz, corporate lan zone, wireless lan zone, wireless guest zone, authenticated vpn zone, site-site vpn zone, storage replication zone, automation network zone, internet untrusted zone, etc.
Depends on business requirements. Trust, DMZ, Untrust, RemoteAccess, VPN, 3rdPartyVPN, Azure, CorporateWiFi GuestWiFi etc.
Smaller businesses may only require Trust and Untrust zones.
We have a zone for each interface/vlan, and only in specific cases do multiple interfaces exist in a zone (like for different VPN gateways, or if we have to carve out a new subnet/vlan for another test network). This ensures all traffic hits the firewall rules for interzone traffic. Interfaces in the same zone can pass for intrazone traffic unless you have rules that restrict by zone and by subnet.
It’s tedious to have a lot of zones because if you have a rule to allow certain users to nearly any zone, you have to enumerate them (might not want to choose any zone as a destination because you don’t want them to have access to certain zones). It is better security though because it means users can only go wherever your rules say, nothing is implied except intrazone/L2 traffic.
We zone for almost every vlan, VPN, and internet WAN link.
I pretty much dont want anything talking across network to each other. I would of just made a flat network. This is why i’m confused I guess.
Yea that makes sense. I’m going to assume there are lower firewalls on these examples I have seen and that’s why its not making any sense.