Object-group entry in ACL breaks IOS firewall

s1rm · ‎08-06-2010

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

Jon Marshall · ‎08-06-2010

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

s1rm · ‎08-06-2010

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

Jon Marshall · ‎08-06-2010

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

s1rm · ‎08-06-2010

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?

bwilloughby · ‎11-02-2010

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

s1rm · ‎11-02-2010

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

mdeloach · ‎05-19-2011

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 · ‎08-14-2020

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)