IOS firewall inspection rules

joshgibson82joshgibson82 Member Posts: 80 ■■□□□□□□□□
Guys/Gals,

Can anyone help clarify the rules for which interface and which direction the inspection rules need to be applied? The CP book does NOT make it clear in my opinion. Several practice tests give answer in the exact opposite way that CP describes it.

Thanks!
Josh, CCNP CWNA

Comments

  • mikearamamikearama Member Posts: 749
    Not quite sure what you mean Josh... just a little vague.

    Do you mean which interface is the ingress int? If so, the "outside" interface, which is the "untrusted" side, gets the ACLs applied, in the inward direction. That's the most typical situation.
    So if you had an ACL (called, say, StayOut) preventing everything except one vendor from entering your network from the outside, an inspection rule (called InspectFTP) that inspected FTP from the vendor, and the outside link is a serial connection, your config would be something like:

    int s0/0
    ip inspect InspectFTP in
    ip access-group StayOut in
    end

    However, if you want to prevent traffic from getting to certain subnets, then the ACLs are applied outward, on those interfaces.

    Or were you thinking about zones and their configs?
    There are only 10 kinds of people... those who understand binary, and those that don't.

    CCIE Studies: Written passed: Jan 21/12 Lab Prep: Hours reading: 385. Hours labbing: 110

    Taking a time-out to add the CCVP. Capitalizing on a current IPT pilot project.
  • joshgibson82joshgibson82 Member Posts: 80 ■■□□□□□□□□
    Yes you're hitting on the subject I was struggling with. I understand the concepts of inbound/outbound, but the inspection direction is where I struggle. I suppose there isn't a certain way they must be implemented. It is possible to apply inspection inbound/outbound on secure and insecure interfaces.

    In other words, I suppose there is no certain way to do it. Is that true?
    Josh, CCNP CWNA
  • _maurice_maurice Member Posts: 142
    Excellent question. Take a look at this document. It is very helpful.

    http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a0080094e8b.shtml

    So, to answer your question, you apply the inspect rule to the inside trusted interface (LAN), not the outside untrusted WAN interface. The direction you would apply the inspect rule on the trusted LAN interface is inbound.

    This will allow for temporary permit rules to be placed on the untrusted WAN interface for the return traffic to come back in.

    Cheers
  • joshgibson82joshgibson82 Member Posts: 80 ■■□□□□□□□□
    Thanks for the doc. That's funny though because when I configure a firewall with the SDM, it puts the inspection rules outbound on the Untrusted interface. Which, as far as I can tell, will do the same thing as putting it inbound on the trusted interface. Your thoughts?
    Josh, CCNP CWNA
  • _maurice_maurice Member Posts: 142
    Josh,

    I was thinking about that earlier. I will lab it with dynamips in a couple hours. The only reason I can think of to put the inspect rule on the trusted interface is in case you have 2 WANs, and the traffic might be routed out of either one. I will let you know what happens with dynamips later in the day. All good questions.
  • mikearamamikearama Member Posts: 749
    Ah yes, CBAC. Good link, maurice. I always found CBAC a little confusing too.

    I guess you can look at it this way... if you have a router with an internal (trusted) and external (untrusted) connection, you would most likely have a strong ACL on the outside preventing just about everything from getting into your LAN. Shoot, it might block absolutely everything.

    On the internal side, you'd configure an ACL to identify traffic to be permitted, and therefore inspected, and apply the "inspect" rule, both inbound. Inbound on the internal interface equates to traffic leaving the network.

    Of interest is how CBAC pokes holes in the outside ACL, so that traffic that is normally blocked by your strong outer ACL is permitted back into the LAN, providing it's a response to traffic that originated internally.

    I think the new zone approach is so much of an improvement. And easier to understand.
    There are only 10 kinds of people... those who understand binary, and those that don't.

    CCIE Studies: Written passed: Jan 21/12 Lab Prep: Hours reading: 385. Hours labbing: 110

    Taking a time-out to add the CCVP. Capitalizing on a current IPT pilot project.
  • _maurice_maurice Member Posts: 142
    I made a dynamips lab. The inspect rule works the same, whether you have it inbound on the LAN, or outbound on the WAN.

    I had an access-list with "deny ip any any"
    I also had an inspect rule allowing tcp

    When running a "sh ip access-list 100" I only saw "deny ip any any"

    My question is, aren't you supposed to see the temporary permit rules added by CBAC when running a sh ip access-list command?
  • mikearamamikearama Member Posts: 749
    The temporary holes in the ACL are not recorded in the running config, so they won't show using the show access-list command.

    I believe they are stored in the state table... and I have no idea what command to use to view the state table, or if it's even possible.
    There are only 10 kinds of people... those who understand binary, and those that don't.

    CCIE Studies: Written passed: Jan 21/12 Lab Prep: Hours reading: 385. Hours labbing: 110

    Taking a time-out to add the CCVP. Capitalizing on a current IPT pilot project.
  • mgeorgemgeorge Member Posts: 774 ■■■□□□□□□□
    If you are doing this as a basic firewall to protect from the outside network then you would apply the ip inspection rule outbound on the outside interface.

    For example; if you have a routers FastEthernet0/1 interface connected to your cable modem and it has a public IP address 76.23.125.55; you apply the inspection rule outbound on the FastEthernet0/1 with the ACL inbound blocking all traffic inbound on that interface.

    In doing so; communications from the LAN to the router does not participate in the ios firewall process unless it is destined to a network out interface FastEthernet0/1

    I slapped together a config example for 12.3 below;

    ip inspect name FIREWALL tcp
    ip inspect name FIREWALL udp
    ip inspect name FIREWALL ftp
    ip inspect name FIREWALL http
    ip inspect name FIREWALL smtp
    ip inspect name FIREWALL icmp
    ip inspect name FIREWALL sip
    ip inspect name FIREWALL fragment maximum 256 timeout 1
    !
    interface FastEthernet0/0
    description ## INSIDE INTERFACE ##
    ip address 192.168.1.254 255.255.255.0
    ip nat inside
    !
    interface FastEthernet0/1
    description ## OUTSIDE INTERFACE ##
    ip address dhcp
    ip nat outside
    ip access-group OUTSIDE_IN in
    ip inspect FIREWALL out
    !
    ip nat inside source list NAT_TRAFFIC interface FastEthernet0/1 overload
    !
    ip route 0.0.0.0 0.0.0.0 dhcp
    !
    ip access-list extended NAT_TRAFFIC
    10 permit ip 192.168.1.0 0.0.0.255 any
    !
    ip access-list extended OUTSIDE_IN
    10 permit icmp any any echo (allow if you want your outside interface pingable)
    500 deny ip any any log (If you want to log denied traffic, give your deny statement a high number to allow for other entries)


    If you are using a Dialer interface for the PPPoE client then you would apply the ACL and inspection rule to the Dialer# interface. This is just your common IOS configuration firewall, hope this helps clear up the confusion.
    There is no place like 127.0.0.1
  • _maurice_maurice Member Posts: 142
    I love the input, but I believe that if you apply the inspection rule on the LAN interface, the traffic destined to/from the cisco will not be affected.

    R0(config)#ip inspect name test icmp ?
    alert Turn on/off alert
    audit-trail Turn on/off audit trail
    router-traffic Enable inspection of sessions to/from the router
    timeout Specify the inactivity timeout time
    <cr>


    Check out the router-traffic parameter.
Sign In or Register to comment.