07-17-2012 10:31 AM - edited 03-11-2019 04:31 PM
Hi guys,
What is the best practices when deploying the IOS Firewall feature on routers, especially on the 800 series routers?
I know that a router will never be a true firewall but those features are there to make them simulate...
Usually what I do is the following:
ip inspect name IOS_Firewall tcp
ip inspect name IOS_Firewall udp
And then I apply this on the Outside firewall:
interface FastEthernet4
ip inspect IOS_Firewall out
.
.
So far I've no problems but I was wondering if there is even a better way, which Im sure there is. Like for example, those 2 "inspect" statements will grab all tcp and udp packets, but what about for the other packets that have other protocols?
thank you in advanced
07-17-2012 11:06 AM
Hi Bro
The word "best" is very subjective but here's my 2 cents, when deploying IOS Firewall feature on a typical Cisco IOS Routers. This is provided you've the correct IOS FEATURE SET, as well.
Besides using the Cisco document as a guide in performing IOS security hardening on your IOS equipment regardless of the Router model as stated in http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml there are other Cisco technologies that you could adopt (with caution, of course!!!) as well as listed below;
a) Flexible Packet Matching (FPM) or Modular Policy Framework (MPF)
b) Zone-Based Firewall (ZFW)
c) IOS IPS
I hope I have answered your questions.
07-17-2012 12:26 PM
If you have a quite simple Firewall-setup (like only two interfaces) it's fine to stay with CBAC (ip inspect). This system probably doesn't have a real future, as all effort on IOS-firewalling is going into ZBF. So don't expect any new fancy features there. But CBAC is still fine in situations where ZBF is just overkill.
For CBAC (as for any Firewall) you must make sure that all your protocols are inspected the right way.
If you only have TCP and UDP, your two staements above are fine. If you use any other protocol it could be needed to add an inspection. The inspections are divided into two classes:
1) Inspections that make your protocol work
2) Inspections that make a protocol more secure
The first class would be the inspection for FTP. Without the inspection FTP wont work in every situation because of the dynamic data-channels. In the same class are voip-inspections as SIP, H.323 and so on.
Then there are inspections that make your network more secure: I.E. esmtp-inspection. SMTP will work without the inspection, but with the inspection you can limit what a client (or attacker) can talk to your mailserver. Other inspections of this class are IMAP, POP3 and a couple more.
A best practice is the following:
- From the first class, only activate the inspections that are really needed for your traffic.
- From the second class, only activate the inspections where you need more control over an application and really understand what the inspection does. Just google for "pix mailguard" and read how many problems an inspection can make if it's used in the wrong way.
This is what I typically activate on a simple CBAC-setup:
ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
ip inspect name FW dns
ip inspect name FW ftp
ip inspect name FW tftp
The parameter "router-traffic" inspects the traffic that is initiated by the router. So you can do http or dns, ntp etc. from your router to the internet whitout having to allow the return-traffic in your outside-ACL. For this parameter to work it's needed to activate the inspection outgoing on the outside interface the same way you have in your example.
07-17-2012 08:56 PM
Thank you for the simple approach to these types of questions. And also good to know that Cisco has already ended the CBAC and is only implementing the ZBF. I think I had read something about this before and again very good you brought that up.
As you said, my current setup is pretty simple. 2 interfaces, LAN and WAN, and I just need to make sure that I can make this Cisco 881W that I am currently working with look to be like a firewall as close as possible. I've had too many customers where their IT people had no clue how to deal with these things, specially for applications that have an strange "return" behavior. But again I know that there are more protocols and those questions will come up one day.
Question though for the syntaxt you have in the "ip inspect" statements. The word "router-traffic" at the end, is that really necessary? You said that this is needed to allow return traffic to the router when the router initiates the connection, but isnt this already allowed by the statements themselves without the "router-traffic" word?
07-19-2012 10:02 AM
Unless Cisco changed it lately what I don't think, then the parameter is needed. Without the parameter, only traffic going through the router was inspected, but not the traffic that was originated by the router. So it is handled pretty much the same as ACLs where outgoing ACLs also don't catch the router-initiated traffic.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide