Firewall deployment and implementation

[icecream-guy]

can anyone describe firewall deployment and implement from an architectural point of view?
specifically with ASA firewalls

I'm hard press to come up with more than:
1. identify targets that need to be protected
2. develop policies to protect identified targets.
3. place firewall in front of identified targets

The implementation part is pretty straight forward

console in to the device,
apply basic configuration
setup a basic policy for SSH access
connect the device to the network
SSH to device and finish configuration details.

is there more to is than this?

[deanwebb]

If one has to be able to SSH to devices behind the firewall from a jump box in front of the firewall that also manages the firewall, then the management of the firewall cannot be via the management interface, because of routing issues.

"Develop policies" should specify guidelines on why a requested access might be refused, IE permits telnet from office to protected network, allows RDP direct from Internet to office, allows any internet connection from protected network, things like that.

"In front of" - should be defined, as well. Is this logical or physical segmentation? If logical, then the L3 device where the hairpin to the firewall originates is a potential weak point if the routing there is changed to allow traffic to bypass the firewall. I prefer physical segmentation, where the path must physically pass through the firewall.

[mlan]

I would add "analyze traffic inspection parameters for current services":

One thing I see missed with ASA/firewall deployments is that the device will be doing stateful TCP inspection out of the box, and some custom inspection tuning (ICMP, FTP, SIP, H323, etc.) might be needed to keep services running.  Also, I'm not sure about the latest code revs, but it was previously required to increase the DNS packet size inspection in the global service policy to 4096 to prevent drops due to large responses.

[Otanx]

Develop procedure to update rules after deployment. You don't just want the firewall admin opening stuff because the server guy said to do it. Also you want to get rid of old rules that are not getting used anymore.
Develop procedure to identify, validate, and deploy patches. Security vulnerabilities in security devices are bad, and need to be addressed quickly.
Centralized management? Depending on how many you are deploying, and how standardized the rule sets are you don't want to be doing this by hand. If you go with FTD over vanilla ASA you can use FPM to manage multiple firewalls. I have not played with FTD or FPM yet, but they have to be better than ASDM.
Mlan mentioned this as well; are you just doing layer 4 stateful filtering, or is there interest in using the other inspection engines? I found the SMTP, SIP, and RPC inspection engines on the ASA work pretty well. DNS does need inspection updated to a higher number if you support eDNS.

-Otanx

[LynK]

@ristau,

You want to consider where you are placing the firewall, because east/west traffic can be a real pain in the butt if you don't properly account for it. Make sure you get the model you want, and the speed you want with ALL of the bells/whistles turned on.

Do you have the option to consider any other firewall vendors? I have worked with Sonic Wall, Barracuda, ASA, and Palo Alto. I would really consider PAN.

[icecream-guy]

Thanks all, and Juniper too,

I found this doc and it helped clarify firewall deployment

Step 1. Identify Security Requirements for Your Organization
Step 2. Define an Overall Security Policy
Step 3. Define a Firewall Philosophy
Step 4. Identify Permitted Communications
Step 5. Identify the Firewall Enforcement Points

for more details:
http://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000591-en.pdf

[Dieselboy]

Great post!

Can someone explain what they mean by step 3? Is it with regards to the manufacturer / appliance choices or just a general understanding that everyone has with regards to what the firewall is supposed to be doing?




[ristau5741 note, oops i hit modify instead of quote]

[icecream-guy]

Great post!

Can someone explain what they mean by step 3? Is it with regards to the manufacturer / appliance choices or just a general understanding that everyone has with regards to what the firewall is supposed to be doing?

I believe the firewall philosophy has to do with the overall corporate security policy and making sure that the firewall implementation takes that into consideration.

[deanwebb]

Great post!

Can someone explain what they mean by step 3? Is it with regards to the manufacturer / appliance choices or just a general understanding that everyone has with regards to what the firewall is supposed to be doing?

I believe the firewall philosophy has to do with the overall corporate security policy and making sure that the firewall implementation takes that into consideration.

Right, this would be something like, "Put a firewall and an IPS inline on every connection to the datacenter, except on the MPLS links directly to other datacenters" and things of that nature.

This would also get into the area of physical vs. logical segmentation for separating sensitive environments.

[SimonV]

Here's my take:

- Split up your firewall into virtual firewalls (naming varies per vendor). For example: one virtual FW for Edge, one for Internal, One for server farm, etc...
- Configure VRFs on your switches and use them as default gateway.
- Use a transit VLAN/network between your switches and the firewall to get deterministic routing and keep the ARP tables small and predictable.
- Incorporate as much physical redundancy as possible. Use LACP and redundant cluster links.
- Group networks with similar security requirements into zones or use sub-interfaces and determine general firewall/NAT policies. 

You can build huge topologies with just a few physical boxes. Don't install a multi-slot chassis FW and just use two physical interfaces for inside/outside

[Dieselboy]

Simon, that's basically how we built a multi-tenanted env. out of a couple of 5510's and 3750's. We just had the one customer to begin with but quickly grew. As it grew, more expensive network trickery was purchased. The downside to the virtual firewalls is that you cant do VPN in context mode so additional firewalls were added. What I liked about the design is that quite big changes could be done at the datacentre without physically going to the datacentre. You could logically move connections and provision without requiring to physically patch and re-patch.
I'm going a bit off topic though.