ACL Logging

ACL Logging
The ACL logging feature lets you log the number of permits or denies of a flow during a
specific period of time. A flow is defined by protocol, source IP address, source port,
destination IP address, and destination port. When a flow is permitted or denied, the system
checks to see if the flow already exists in the system. If not, an initial syslog message with a
hit count of 1 for the flow is generated. The flow entry is then created and the hit count for
the flow is incremented every time the flow is permitted or denied. The command syntax to
enable logging of the number of permits or denies of a flow by an ACL entry is as follows:
access-list acl-id [log [level] [interval seconds] | [disable|default]]
For an existing flow, a syslog message is generated at the end of each configurable interval to
report the nonzero hit count for the flow in the current interval. After the syslog message is
generated, the hit count for the flow is reset to 0 for the next interval. If there is no hit
recorded during the interval, the flow is deleted and no syslog message is generated. Large
numbers of flows may concurrently exist at any point in time. To prevent unlimited
consumption of memory and central processing unit (CPU) resources, a limit is placed on the
number of concurrent deny flows. When the limit is reached, no new deny flow will be
created until the existing deny flows expire. To specify the maximum number of concurrent
deny flows that can be created, enter the following command:
access-list deny-flow-max num-of-flows
The deny-flow-max keyword specifies the maximum number of concurrent deny flows that
can be created. New values for this option go into effect immediately. The default is set for
4096 flows allowed.

When the maximum number of flows has been reached, a syslog message (106101) is
generated. By default, this message is repeated once every 300 seconds.
The syslog message generated for the ACL entry has the following format:
106101: access-list ->
hit-cnt (first hit|n-second interval)
Advanced Protocol Handling
Some applications require special handling by the Cisco Security Appliance application
inspection function. These types of applications typically embed IP addressing information
in the user data packet or open secondary channels on dynamically assigned ports. The
application inspection function works with NAT to help identify the location of embedded
addressing information.
In addition to identifying embedded addressing information, the application inspection
function monitors sessions to determine the port numbers for secondary channels. Many
protocols open secondary TCP or UDP ports to improve performance. The initial session on
a well-known port is used to negotiate dynamically assigned port numbers. The application
inspection function monitors these sessions, identifies the dynamic port assignments, and
permits data exchange on these ports for the duration of the specific session. Multimedia
applications and FTP applications exhibit this kind of behavior.
Table 7-4 syslog Format Description
Field Description
Displays whether the flow is permitted or denied.
Displays the protocol type: tcp, udp, icmp, or an IP protocol number.
Displays the interface name (as configured by the nameif command) for
the source or destination of the logged flow. This can include logical
(virtual LAN) interfaces.
Displays the source IP address of the logged flow.
Displays the destination IP address of the logged flow.
Displays the source port of the logged flow (TCP or UDP). For ICMP, this
field is 0.
Displays the destination port of the logged flow (TCP or UDP). For ICMP,
this field is icmp-type.
Displays the number of times this flow was permitted or denied by the
ACL entry in the configured time interval. The value is 1 when the first
syslog message is generated for the flow.
first hit Displays the first message generated for this flow.
n-second interval Displays the interval over which the hit count is accumulated

icmp-type Object Type

icmp-type Object Type
Internet Control Message Protocol (ICMP) object groups can be created to group certain
types of ICMP messages. For example, ICMP messages of ECHO-REQUEST, ECHOREPLY,
and DESTINATION-UNREACHABLE with numerical type values of 8, 0, and 3,
respectively, can be grouped as shown in Example 7-9.

Grouping ICMP Messages
pix(config)# object-group icmp-type icmp-test
pix(config-icmp-type)# icmp-object 0
pix(config-icmp-type)# icmp-object 3
pix(config-icmp-type)# icmp-object 8


Nesting Object Groups
You can add an object group within an object group. The object-group command allows
logical grouping of the same type of objects andicmp-type Object Type construction of hierarchical object groups
for structured configuration. To nest an object group within another object group, use the
group-object command. Example 7-10 illustrates the use of nested object groups.

Configuring Nested Object Groups
pixfirewall(config)# object-group network web-servers
pixfirewall(config-network)# description web servers
pixfirewall(config-network)# network-object host 192.168.1.12
pixfirewall(config-network)# network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)# object-group network Public-servers
pixfirewall(config-network)# description Public servers
pixfirewall(config-network)# network-object host 192.168.1.18
pixfirewall(config-network)# group-object web-servers
pixfirewall(config-network)# exit

service Object Type

Example 7-7 Creating a New Protocol Object Group
pixfw(config)#object-group protocol grp-citrix
pixfw(config-protocol)#protocol-object tcp
pixfw(config-protocol)#protocol-object 1494
pixfw(config-protocol)#exit

service Object Type
The service object type identifies port numbers that can be grouped. This is particularly
useful when you are managing an application. The syntax for service object-type is
[no] object-group service obj-grp-id tcp | udp | tcp-udp
As soon as you are in the service subcommand, the command port-object eq service adds a
single TCP or UDP port number to the service object group. The port-object range beginservice
end-service command adds a range of TCP or UDP port numbers to the service object
group. Example 7-8 shows how to use object-group service subcommand mode to create a
new port (service) object group.

network Object Type

network Object Type
The network object type is used to group hosts and subnets. Server and client hosts can be
grouped by functions. For example, mail servers, web servers, or a group of client hosts that
have special privileges on the network can be grouped accordingly.
Example 7-5 shows a web servers object group.

Configuring an Object Group
pixfirewall(config)#object-group network web-servers
pixfirewall(config-network)#description Public web servers
pixfirewall(config-network)#network-object host 192.168.1.12
pixfirewall(config-network)#network-object host 192.168.1.14
pixfirewall(config-network)# exit
pixfirewall(config)#access-list 102 permit tcp any object-group web-servers eq www
pixfirewall(config)#access-group 102 in interface outside

Notice that when you enter the object-group command, the system enters the appropriate
subcommand mode for the type of object you are configuring. In this case, you see the confignetwork
subcommand prompt. The network-object host subcommand adds the host to the
network object group. The description is optional, but it is helpful to include it.

NOTE It is also possible to use a name instead of an IP address when defining the
network host. For example:
pixfw(config)# object-group network mis-ftp-servers
pixfw(config-network)#network-object host 10.10.100.154
pixfw(config-network)#network-object host 10.10.100.155
pixfw(config-network)#network-object host 10.10.100.156
pixfw(config-network)#exit

To display the configured object group, use the show object-group command, as shown in
Example 7-6.

Displaying Configured Object Groups
pix(config)# show object-group
object-group network web-servers
description: Public web servers
network-object host 192.168.1.12
network-object host 192.168.1.14

Object Grouping

Object Grouping
Object grouping allows you to group objects such as hosts (servers and clients), services, and
networks and apply security policies and rules to the group. Object grouping lets you apply access
rules to logical groups of objects. When you apply an access list to an object group, the command
affects all objects defined in the group. Object grouping provides a way to reduce the number of
access rules required to describe complex security policies. This in turn reduces the time spent
configuring and troubleshooting access rules in large or complex networks.
The syntax for creating object groups is as follows:
[no] object-group object-type grp-id
Use the first parameter, object-type, to identify the type of object group you want to
configure. There are four options:
■ network
■ protocol
■ service
■ icmp-type
Replace grp-id with a descriptive name for the group.