cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
371
Views
0
Helpful
4
Replies

Considering FWSM over PIX515/525....

tkropp
Level 1
Level 1

I'm having our CE come in to present the FWSM for 6500. I'm hoping to get some feedback from this forum a bit in advance. Does anyone have any pro's/con's regarding the FWSM, Routing (OSPF), Policies, MSFC2/SUp720 integration, Vlans? Or even design limitations using the FWSM.

Thanks in advance,

Tim

4 Replies 4

ehirsel
Level 6
Level 6

The pix 6.3 code can run ospf as well as understanding and processing IEEE 802.1q tagged vlan frames using logical interfaces, and you can have up to 10 logical interfaces and 8 physical interfaces on a pix 515. To my knowledge, the pix has more IDS signatures than firewall functions on a router, and will probably continue to do so as its main function is firewalling.

It is my opinion that the FWSM is a good place to start firewalling functions (using it as an internal firewall, for example) and I believe that it can compliment a pix, instead of replacing it entirely. Having a pix can distribute your security policy a bit more, and the benefit of that is that a compromise of one device, say the 6500, does not affect the integrity of the other. Similarly if there were security holes in IOS and/or CATOS they usually would not affect pix code and vice versa.

Regardless of using the FWSM only, a PIX only or a combo of both use private or edge vlans where possible to prevent two devices connect to the same switch from talk direct to each other. The later version of the CAT code can extend that concept to trunk links as well. Using edge vlans forces the traffic to flow through a layer 3 device which can be the msfc or the pix. I also recommend using routing protocol authentication using md5 keys to validate routing updates. The later version of the pix code (6.3, maybe 6.2 as well) and the ios 12.0 and higher version have ways of authenticating ospf, eigrp, and rip v2 updates. The Cisco online resources can provide some good examples of how to do this.

If you want to use the pix and have the routing protocols updates flow through it, but not to it (that is, it does not process the updates, it just forwards them) you will need to tunnel the traffic using GRE.

Another good security technique that may be of value is unicast verify reverse path check (VRPF). The pix 6.3 code is capable of doing this as well as some 12.0 or higher ios codes and you should not need FWSM to implement that. This will help mitigate attacks using spoofed ip addresses, or at least give you an idea of where they originate from in the case where it cannot be prevented. However in IOS you need to implement CEF to get the benefits of VRPF. VRPF is helpful on the PIX when running dynamic routing protocols such as OSPF.

If I come across anyone I know that uses FWSM, I'll find out what they think of it and pass it on.

Thanks for the insight. I'm currently using MD5 for OSPF, the VRPF is something I'll look into, as I do have CEF implemented.

It sounds as if everyone stresses the importance of separating the FW functions out of the 6500 for sake of not having all "eggs in one basket".

I'll see what the CE has to say today, and read up a little more on the FWSM and post some info.

- Tim

On the FWSM, the 'debug packet' command only shows information destined for the FWSM IP address and it does not show any information on traffic flowing across the FWSM.

From a troublehsooting standpoint, ensuring the packet traverses the device as expected, or an understanding of where it is failing, is crucial.

For example, running the 'debug packet inside src 10.10.10.x dst 10.20.20.x proto tcp dport

3389' generates no output.

Thank you. The advice has helped