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:
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?
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.
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?
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.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...