cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3239
Views
6
Helpful
8
Replies

Object-group entry in ACL breaks IOS firewall

s1rm
Level 1
Level 1

My goal is to be able to edit firewall exceptions "on the fly" and without having to hack an ACL. I have created a service object-group that contains exceptions to the firewall, however when I apply this object-group to the firewall ACL, it opens up the ACL entirely!

What am I doing wrong with this configuration? Thanks very much for any insight you can provide!

Cisco 871 running c870-advsecurityk9-mz.124-22.T.bin. Here are the configs:

ip access-list extended FIREWALL
permit object-group FIREWALL-EXCEPTIONS any any log
permit udp any eq bootps any eq bootpc
deny   ip any any

object-group service FIREWALL-EXCEPTIONS

description <<< specific ports allowed through the firewall >>>
tcp eq 443
tcp eq 25

tcp eq 80

interface FastEthernet4
ip dhcp client client-id FastEthernet4
ip address dhcp
ip access-group FIREWALL in
ip access-group WAN-EGRESS-FILTER out
no ip redirects
no ip unreachables
no ip proxy-arp
ip accounting output-packets
ip accounting access-violations
ip nat outside
ip inspect INSPECT-FIREWALL out
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
arp timeout 600

8 Replies 8

Jon Marshall
Hall of Fame
Hall of Fame

ip access-list extended FIREWALL
permit object-group FIREWALL-EXCEPTIONS any any log
permit udp any eq bootps any eq bootpc
deny   ip any any

object-group service FIREWALL-EXCEPTIONS

description <<< specific ports allowed through the firewall >>>
tcp eq 443
tcp eq 25

tcp eq 80

I have only used object-groups on firewalls so i may be wrong but assuming these ports are ports you want to allow inbound from the outside of your router your acl doesn't look right. Shouldn't it be

permit tcp any any object-group FIREWALL EXCEPTIONS log

Jon

You're right Jon. The ACL should actually read "permit tcp any any object-group FIREWALL-EXCEPTIONS" but the device won't take the command when it's structured like that! It's really throwing me off!

Maybe I've encountered a bug in the IOS?

Here's the output when I attempt to issue that ACL:

871-Firewall(config-ext-nacl)#5 permit tcp any any ?
  ack          Match on the ACK bit
  eq           Match only packets on a given port number
  established  Match established connections
  fin          Match on the FIN bit
  fragments    Check non-initial fragments
  gt           Match only packets with a greater port number
  log          Log matches against this entry
  log-input    Log matches against this entry, including input interface
  lt           Match only packets with a lower port number
  match-all    Match if all specified flags are present
  match-any    Match if any specified flag is present
  neq          Match only packets not on a given port number
  option       Match packets with given IP Options value
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  range        Match only packets in the range of port numbers
  reflect      Create reflexive access list entry
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time-range   Specify a time-range
  tos          Match packets with given TOS value
  ttl          Match packets with given TTL value
  urg          Match on the URG bit
 

Actually i've just found a doc which shows how to use them and surprisingly your original syntax was correct. Why it can't be standard like other acl usage i don't know

So is that acl allowing everything in ? What does the acl look like when you do a "sh ip access-list FIREWALL_EXCEPTIONS" ?

Jon

Extended IP access list FIREWALL
    5 permit object-group FIREWALL-EXCEPTIONS any any log (62 matches)
    500 deny ip any any (3457 matches)

Service object group FIREWALL-EXCEPTIONS
  tcp eq 61259
  tcp eq 25222

The object-group shows up in the FIREWALL ACL, but I think the ios is reading the entry as "permit ip any any" and disregarding the object-group TCP information altogether.

The only external tool that I currently have access to is the "Shields Up" scanner at grc.com (not the most ideal test, but it works for my purposes!)

When I have the firewall ACL in place with NO object-group entry then the firewall blocks everything as it should (GRC returns "Stealth" for every port).

When I place the object-group entry into the ACL (as shown above) GRC returns that all scanned ports are "Closed" and it also sees the ASA 5505 that I have in testing behind the router is running Web VPN (port 443 shows "Open"). In addition to all that, the ACL that blocks input into the VTY lines reports that it has blocked an attempt from the GRC scanning IP.

This is driving me up the wall!    The ACL syntax is correct. The only two explanations I can think of are 1) IOS bug or 2) The device was reporting "

%ALIGN-3-SPURIOUS: Spurious memory access made at..." errors earlier in the week. 

Maybe I need to reload and/or upgrade the IOS?

We are seeing the same behavior in c2821 routers.  Did you receive a reolution tothis problem?

permit TCP object group * works

permit UDP object-group * works

permit IP object group * does not work

permit object-group * any any does not work

No. I have not yet found a way to make this work. If you find a resolution please let us know!

I hust ran into a similar situation, not involving a group of ports, but a

range of networks-

object-group network A

host 10.10.10.1

object-group network B

range 192.168.0.0 192.168.4.255

ip access-list extended firewall

permit tcp object-group B object-group A eq smtp

deny any any

Testing reveled that any IP could now connect to my mail server.

Pulling the permit line blocked traffic, so I thought maybe the

range was not proper/working and replaced it with-

object-group network B

192.168.0.0 /24

192.168.1.0 /24

192.168.2.0 /24

192.168.3.0 /24

I re-added the rule to the access-list and found that once again any IP

could connect to my email server.  So now I do not use object-groups

to define the source.  Rules with object-groups as the target all worked,

This is on a ISR 2851 running 12.4.(24)T4

BrianSekleckiGE
Level 1
Level 1

10-years later, on Traditional IOS, on Cisco IE4000/Rockwell Stratix 5400, I observe the same problem.

 

  If an access list references a group-object / object-group of any class: source address, destination address, or service

 

  It doesn’t seem to matter if the reference object group is nested or not-nested.

 

   An IP ACL, with any single line, referencing any single object-group, immediately causes the rule processing to stop and all traffic is then permitted (completely ignoring the explicit default deny at end of rule)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: