Poglavlje Firewall Technology Bezbednost Racunarskih Mreza

Poglavlje 4.
Implementacija
Firewall tehnologija
Bezbednost raunarskih mrea
ITE PC v4.1
Chapter 1 2007 2010, Cisco Systems, Inc. All rights reserved. Cisco Public 1
Chapter 4: Cilj predmeta
In this chapter you will:
Configure standard and extended IPv4 ACLs using CLI.
Verify the functionality of a configured ACL in relation to the network topology.
Configure TCP established and reflexive ACLs.
Configure dynamic ACLs.
Configure time-based ACLs.
Troubleshoot complex ACL implementations.
Use ACLs to mitigate common network attacks.
Configure object groups for use within an access control entry.
Explain how firewalls are used to help secure networks.
Describe the various types of firewalls.
Configure a classic firewall.
Explain design considerations for implementing firewall technologies.
Explain how Zone-Based Policy Firewalls are used to help secure a network.
Explain the operation of a Zone-Based Policy Firewall.
Configure Zone-Based Policy Firewall with CLI.

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 2
Chapter
4.0 Introduction
4.1 Access Control Lists
4.2 Firewall Technologies
4.3 Zone-Based Policy Firewalls
4.4 Summary

Data plane
Understanding the Data Plane
This section covers the
methods available for
implementing policy related to
traffic allowed through (transit
traffic) network devices.
For the data plane, this

discussion concerns traffic that
is going through your network
device rather than to a network
device.
This is traffic from a user

going to a server, and the
router is just acting as a
forwarding device. This is the
data plane. Table 10-4
describes some of the
prevalent ways to control the
data plane (which may be
implemented on an IOS
router).

4.1 Access Control Lists
Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential 5
Configuring Standard and Extended IPv4 ACLs with CLI
Introduction to Access Control Lists
Pristupne liste, Access Control
Lists (ACLs), predstavljaju jedan vid
filtriranja paketa (paketi se
proputaju ili odbojaju na osnovu
zadatih uslova u kreiranoj pristupnoj
listi)
ACL se moe konfigurisati na

ruteru ili na ASA ureaju
ACLs se mogu koristiti u

spreavanju napada u raunarskoj
mrei i kontroli saobraaj
Parametri koji se koriste prilikom

konfigurisanja security-related ACLs
ukljuuju IPv4, IPv6 izvorne i
odredine adrese, i brojeveTCP i
UDP portova.

Kada se konfiguriu, ACLs
izvravaju sledee:
Limitiraju saobraaj u mrei i time poveavaju
performanse same mree. Na primer, u
poslovnoj mrei je zabranjen video saobraaj, to
se postie konfigurisanjem odgovarajue ACL.
Time e se smanjiti optereenje u mrei i
poveati performanse mree
Obezbeuju kotrolu protoka saobraaja. ACLs
moe spreiti isporuku update poruka rutiranja,
ukoliko one nisu neophodne i na taj nain zatiti
propusni opseg.
Obezbeuju osnovni nivo sigurnosti za pristup
mrei. ACLs mogu dozvoliti samo odreenim
hostovima (autorizovanim korisnicima) pristup
ureajima i odgovarajuim resursima
Filtriraju saobraaj na osnovu tipa saobraaja.
Na primer, ACL dozvoljava email saobraaj, a
blokira Telnet saobraaj
Screen hosts to permit or deny access to network
services. ACLs can permit or deny a user to
Presentation_ID
access file types, such as FTP or HTTP. 2008 Cisco Systems, Inc. All rights reserved. 7
There are many types of ACLs and
many ways to apply them for filtering.
Note that an ACL can be used as a

classification mechanism used in
other features:
such as an IOS firewall, identifying
traffic for control plane protection,
identifying who is allowed to connect
to a vty line
where SNMP is allowed
NAT
such as crypto-maps in the case of
IPsec tunnels
In the discussion of protecting the

data plane, we focus primarily on
ACLs applied directly to interfaces for
the purpose of filtering.
Standard and Extended Numbered IP ACLs Cont.
ACLs numbered199 or 13001999 are standard IPv4 ACLs.
Standard ACLs match packets by examining the source IP address

field in the IP header of that packet.
Standard ACLs are used to filter packets based solely on Layer 3

source information.

Standard and Extended Numbered IP ACLs Cont.
ACLs numbered 100199 or 20002699 are extended ACLs.
Extended ACLs filter IP packets based on Layer3 and Layer4

informations:
Source and destination IP addresses
Source and destination TCP and UDP Ports
Protocol Type
TCP synchronization information
Standard and Extended ACLs are:

Applied an inbound or outbound on any Layer 3 interface on the router
using the ip access-group command.
Applied on a VTY port using the access-class command.

Configuring Numbered and Named ACLs
Standard Numbered ACL Syntax
Extended Numbered ACL Syntax
Named ACL Syntax
Standard ACE Syntax
Extended ACE Syntax

Applying an ACL
Syntax - Apply an ACL
to an interface
Syntax - Apply an ACL

to the VTY lines
Example - Named Standard ACL
Example - Named Extended ACL

Applying an ACL (Cont.)
Syntax - Apply an ACL to the VTY lines
Example - Named ACL on VTY lines with logging
Access control list

(ACL) logging: ACL
logging traffic consists of
any packets that are
generated due to a
match (permit or deny)
of an access control
entry (ACE) on which the
log keyword is used.

Standard and Extended Named IP ACLs
Router(config)# ip access list [standard | extended] name_of_ACL
Standard Named IP ACL example:
Extended Named IP ACL example:

Logging ACL Matches
The Log parameter can be used to log matches to ACLs. The
following information is included:
Action - Permit or deny
Protocol - TCP, UDP, or ICMP
Source and destination - IPv4 or IPv6 addresses
TCP and UDP - Source and destination port numbers
For ICMP - Message types
Log messages are generated on the first packet match and then at
five-minute intervals after that first packet match.

Access Control Entry (ACE) Rules
An ACL is made up of one or more access control entries (ACEs). The
caveats below should be considered when working with ACLs.
Implicit deny all - All Cisco ACLs end with an implicit deny all statement.
Standard ACL packet filtering
Standard ACLs are limited to packet filtering based on source addresses
only.
Extended ACLs might need to be created to fully implement a security
policy.
Order of statements
ACLs have a policy of first match; when a statement is matched, the list is
no longer examined.
Ensure that statements at the top of the ACL do not negate any
statements found lower.
Place specific ACL statements higher in the ACL and more general
statements near the end.
Access Control Entry Rules (Cont.)
Directional filtering
ACLs can be applied to inbound packets (toward the interface) or
outbound packets (away from the interface).
Double-check the direction of data that an ACL is filtering.
Special packets
Router-generated packets, such as routing table updates, are not subject
to outbound ACL statements on the source router.
If the security policy requires filtering these types of packets, inbound
ACLs on adjacent routers or other router filter mechanisms must be used.

Standard ACL Example
All traffic from subnet 172.16.4.0 must be denied access to another
subnet, but all other traffic should be permitted
R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255
R1(config)# access-list 1 permit any
R1(config)# interface FastEthernet 0/0
R1(config-if)# ip access-group 1 out

Extended ACL Example
FTP traffic from one subnet must be denied on another subnet.
R1(config)# access-list 101 deny tcp 172.16.4.0
0.0.0.255 172.16.3.0 0.0.0.255 eq 21
R1(config)# access-list 101 deny tcp 172.16.4.0

0.0.0.255 172.16.3.0 0.0.0.255 eq 20
R1(config)# access-list 101 permit ip any any

Editing Extended ACLs
The existing access list has three entries:
The access list is edited, adding a new ACE and replacing ACE line 20:
The updated access list has four entries:

Topology and Flow for ACLs
How Cisco Routers Handle ACL Matches
The direction of traffic through a networking device is defined by
the ingress (inbound) and egress (outbound) interfaces for the
traffic.
Inbound traffic refers to traffic as it enters into the router, prior to

the routing table being accessed.
Outbound traffic refers to traffic that entered the router and has
been processed by the router to determine where to forward that
data.
Depending on the type of device and ACL configured, the return

traffic can be dynamically tracked.

How Cisco Routers Handle ACL Matches Cont.
Inbound ACL Operation Flow

How Cisco Routers Handle ACL Matches Cont.
Outbound ACL Operation Flow
Because packet filtering uses a simple rule set (a

packet that comes in or out of an interface where
there is an ACL applied for filtering), there is a
check against the packet with the entries in the
ACL from top to bottom.
As soon as a match occurs, the ACL stops
processing the rest of the list and implements the
action against the packet, which is either a permit or
deny.
ACL Placement
Standard ACL Placement
Standard ACLs are placed as close to the destination as

possible.
Standard ACLs filter packets are based on the source address

only.
Placing standard ACLs that are too close to the source can deny
valid traffic.
Extended ACL Placement
Extended ACLs are placed on routers as close as possible to

the source that is being filtered.
Placing extended ACLs too far from the source is inefficient use
of network resources.

ACL Configuration Guidelines

Editing Existing ACLs
Modifying ACLs
New entries are added to an ACL, and are always added to the bottom.
Starting with Cisco IOS 12.3, sequence numbers can be used to edit an
ACL.
The ACL is processed top-down based on the sequence numbers of the

statements (lowest to highest).

Editing Existing ACLs
Existing access list has three entries
Access list has been edited, which adds a new ACE and replaces ACE line
20.
Updated access list has four entries

Sequence Numbers and Standard ACLs
Existing access list has four entries
Access list has been edited, which adds a new ACE that permits a specific IP
address.
Updated access list places the new ACE before line 20

Verifying ACL Functionality
show running-config command
show ip access-lists command

2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 30
Antispoofing with ACLs

Permitting Necessary Traffic through a
Firewall

Mitigating ICMP Abuse

Mitigating SNMP Exploits

Advantage and Disadvantages of Packet
Filters

Firewall Type Descriptions
Packet Filtering Firewall Application Gateway Firewall
Stateful Firewall NAT Firewall

Packet Filtering Firewall Benefits &
Limitations

Configuring TCP Established and Reflexive ACLs
First-Generation Approach to Stateful Firewall
The first-generation IOS traffic filtering solution to support the two-
way nature of TCP virtual circuits was the TCP
established keyword for extended IP ACLs.
Block all traffic coming from the Internet except for the TCP reply
traffic associated with established TCP traffic initiated from inside
network.
The second generation IOS solution for session filtering was

reflexive ACLs.
Filter traffic based on source and destination addresses, and

port numbers, and track sessions.
The TCP established option and reflexive ACLs are examples of
complex ACLs.

Monitoring TCP Flag Settings
In 1995, the first-generation IOS traffic filtering solution based on
the TCP established keyword for extended IP ACLs.
The TCP established keyword blocks all traffic coming from

the Internet, except for the TCP reply traffic associated with
established TCP traffic initiated from the inside of the network.
The established keyword forces the router to check
whether the TCP ACK or RST control flag is set.
If the ACK flag is set, the TCP traffic is allowed in.
Set ACK or RST bits indicate that the packet is not the first
in the session, and therefore, that the packet belongs to an
established session.
If not, it is assumed that the traffic is associated with a new

connection initiated from the outside.
TCP Established in Action
R1(config)# access-list 100 permit tcp any eq 443 192.168.1.0 0.0.0.255 established
R1(config)# access-list 100 deny ip any any
R1(config)# interface s0/0/0
R1(config-if)# ip access-group 100 in

Stateful Firewalls
Stateful Firewalls State Tables
Stateful Firewall Operation

Reflexive ACLs (refleksivne pristupne liste)
In 1996, the second-generation IOS solution for session filtering was
Reflexive ACLs.
Unlike the TCP Established feature, which just used ACK and RST bits,
reflexive ACLS filter traffic were based on source, destination addresses,
and port numbers.
Reflexive access lists omoguavaju da IP paketi budu filtrirani na

osnovu informacija sloja sesije (upper-layer session information).
Primer: Mogue je kreiranje refleksivne access liste koja e dozvoliiti IP

saobraaj iz sesija koje su uspostavljene od strane lokalne mree, a da sa
druge strane odbije IP saobraaj u okviru sesija koje su uspostavljene od
strane spoljne mree.
Filtriranje refleksivnim pristupnim listama je neka vrsta filtriranja

sesija.
Reflexive access lists mogu biti definisane samo uz pomo

imenovanih proirenih IP access listi. You cannot define reflexive
access lists with numbered or standard named IP access lists or with other
protocol access lists.
Reflexive ACLs (cont.)
Ruter proverava izlazni saobraaj i kada primeti uspostavljanje nove
konekcije (sesije), on kreira entry za privremenu access listu ime se
omoguava povratni saobraaj iz spooljne mree unutar pomenute
kreirane sesije
These entries are automatically created when a new IP session

begins, for example, with an outbound packet, and the entries are
automatically removed when the session ends.
Reflexive access lists contain only temporary (privremene) entries.

These entries are automatically created when a new IP session begins
and the entries are removed when the session ends.
Reflexive access lists are not themselves applied directly to an

interface, but are nested within an extended named IP access list that
is applied to the interface.
Also, reflexive access lists do not have the usual implicit deny all
traffic statement at the end of the list, because of the nesting.
Reflexive ACLs (cont.)
Reflexive access lists do not work
with some applications that use port
numbers that change during a
session.
For example, if the port numbers for a
return packet are different from the
originating packet, the return packet will be
denied, even if the packet is actually part of
the same session.
The TCP application of FTP is an example
of an application with changing port numbers.
With reflexive access lists, if you start an FTP
request from within your network, the request
will not complete.
Instead, you must use Passive FTP when
originating requests from within your network.

Temporary Access List Entry Characteristics
If an outbound TCP packet is forwarded to outside of your network, and
this packet is the first packet of a TCP session, then a new, temporary
reflexive access list entry will be created.
This entry is added to the reflexive access list, which applies to inbound
traffic. The temporary entry has characteristics as described next:
The entry is always a permit entry.
The entry specifies the same protocol (TCP) as the original outbound TCP packet.
The entry specifies the same source and destination addresses as the original
outbound TCP packet, except the addresses are swapped (zamenile mesta, jer u
dolaznom saobraaju izvorna adresa je odredina i obrnuto).
The entry specifies the same source and destination port numbers as the original
outbound TCP packet, except the port numbers are swapped.
This entry characteristic applies only for TCP and UDP packets.
Other protocols, such as ICMP and IGMP, do not have port numbers, and
other criteria are specified. For example, for ICMP, type numbers are
used instead.)
Presentation_ID 45
2008 Cisco Systems, Inc. All rights reserved.
Temporary Access List Entry Characteristics
Dolazni TCP saobraaj se ispituje
na osnovu kreirane privremene
refleksivne access liste i njenog
sadraja (entry) sve dok entry u
pomenutoj listi postoji
If an inbound TCP packet matches

the entry, the inbound packet will be
forwarded into your network.
Nakon prolaska poslednjeg paketa

unutar neke sesije kroz interfejs rutera,
sadraj (entry) iz privremeno kreirane
refleksivne access liste se uklanja
If no packets belonging to the

session are detected for a configurable
length of time (the timeout period), the
entry will expire.

Using Reflexive ACLs
Step 1. Kreirati internu ACL koja
nadgleda da li je formirana
neka nova outbound
sesija (sesija se
uspostavlja sa hostom iz
udaljene mree, pri emu
je inicira host unutar LAN
mree) i nakon toga ruter
kreira privremenu reflexive
ACEs.
Step 2. Kreirati eksternu (external)

ACL koja koristi
prethodno konfigurisanu i
aktiviranu the reflexive
ACLs za proveru
povratnog saobraaja
Step 3. Aktivirati imenovane ACLs

na odgovarajuim
Presentation_ID
interfejsima 2008 Cisco Systems, Inc. All rights reserved. 47
Gde postaviti reffexive pristupnu listu?
The first topology is shown in
the figure below. In this simple
topology, reflexive access lists
are configured for the external
interface Serial 0/0/0.
This prevents IP traffic from

entering the router and the
internal network, unless the traffic
is part of a session already
established from within the
internal network.

Gde postaviti reffexive pristupnu listu?
The second topology is
shown in the figure below.
In this topology, reflexive
access lists are configured Eth1
for the internal interface
Ethernet 0. Eth0
This allows external

traffic to access the
services in the
Demilitarized Zone (DMZ),
such as DNS services, but
prevents IP traffic from
entering your internal
network--unless the traffic
is part of a session already
established from within the
internal network.
Defining the Reflexive Access List(s)
To define a reflexive access list, you use an entry in an
extended named IP access list.
This entry must use the reflect keyword.

Router(config)# ip access-list extended name
Router(config-ext-nacl)# permit protocol any any reflect name
[timeout seconds]
Router(config-ext-nacl)# exit
Router(config)# interface type number
Do one of the following:

Router(config-if)# ip access-group name out

Router(config-if)# ip access-group name in

Nesting the Reflexive Access List(s)
After you define a reflexive access list in one IP extended
access list, you must nest the reflexive access list
This entry must use the evaluate keyword.

Router(config)# ip access-list extended name
Router(config-ext-nacl)# evaluate name of previously defined
reflexive access-list
Router(config-ext-nacl)# exit
Router(config)# interface type number
Do one of the following:

Router(config-if)# ip access-group name in

Router(config-if)# ip access-group name out

Using Reflexive ACLs Cont.
Create a reflexive ACL that matches
internal users surfing the Internet with a
web browser and relying on DNS with a
10-second timeout period.
R1(config)# ip access-list extended INTERNAL_ACL

R1(config-ext-nacl)# permit tcp any any eq 80 reflect WEB-ONLY-REFLEXIVE-ACL
R1(config-ext-nacl)# permit udp any any eq 53 reflect DNS-ONLY-REFLEXIVE-ACL timeout 10
R1(config-ext-nacl)# exit
R1(config)# ip access-list extended EXTERNAL_ACL
R1(config-ext-nacl)# evaluate WEB-ONLY-REFLEXIVE-ACL
R1(config-ext-nacl)# evaluate DNS-ONLY-REFLEXIVE-ACL
R1(config-ext-nacl)# deny ip any any
R1(config-ext-nacl)# exit
R1(config)# interface s0/0/0
R1(config-if)# ip access-group INTERNAL_ACL out
R1(config-if)# ip access-group EXTERNAL_ACL in
Setting a Global Timeout Value
Reflexive access list entries expire after no packets in the session have
been detected for a certain length of time (the timeout period).
You can specify the timeout for a particular reflexive access list when you
define the reflexive access list.
But if you do not specify the timeout for a given reflexive access list, the list will
use the global timeout value instead.
The global timeout value is 300 seconds by default. But, you can change the
global timeout to a different value at any time.
To change the global timeout value, use the following command in global
configuration mode:
Router(config)# ip reflexive-list timeout

seconds

Primer
Internet
Konfigurisati reflektovanu pristupnu listu koja dozvoljava dolazni
TCP saobraaj sa Interneta, samo ukoliko je iniciran od korisnika iz
LAN mree 172.16.1.0/24. Dozvoliti takoe i EIGRP i ICMP na
interfejsu S0/1
S0/1
Prvi korak:
R3
R3(config)#ip access-list extended Outboundfilters
F0/0 .1
2
R3(config-ext-nacl)#permit tcp 172.16.1.0 3
0.0.0.255 any reflected tcptrafic 172.16.1.10
172.16.1.50
R3(config-ext-nacl)#exit
172.16.1.0 / 24
R3(config)#
1
Komentar: Define the reflexive access list tcptraffic. This entry
permits all outbound TCP traffic and creates a new access list named 172.16.1.254
tcptraffic. Also, when an outbound TCP packet is the first in a new
session, a corresponding temporary entry will be automatically created
in the reflexive access list tcptraffic.

Primer
Internet
LAN mree 172.16.1.0/24. Takoe, dozvoliti dolazni saobraaj EIGRP
update poruka, ali i zabraniti dolazni ICMP saobraaj
S0/1
Drugi korak:
R3
R3(config)#ip access-list extended Inboundfilters
F0/0 .1
2
R3(config-ext-nacl)#permit eigrp any 172.16.1.0 3
0.0.0.255 172.16.1.10
172.16.1.50
R3(config-ext-nacl)#deny icmp any 172.16.1.0
0.0.0.255 172.16.1.0 / 24
R3(config-ext-nacl)#evaluate tcptraffic 1
R3(config-ext-nacl)#exit
172.16.1.254
Komentar: Define the inbound access list entries. This example

shows Enhanced IGRP permitted on the interface. Also, no ICMP traffic
is permitted. The last entry points to the reflexive access list. If a packet
does not match the first two entries, the packet will be evaluated
against all the entries in the reflexive access list
Presentation_ID
tcptraffic.
2008 Cisco Systems, Inc. All rights reserved. 55
Primer
Internet
LAN mree 172.16.1.0/24. Takoe, dozvoliti dolazni saobraaj EIGRP
update poruka, ali i zabraniti dolazni ICMP saobraaj
S0/1
Trei korak:
R3
R3(config)#interface serial 0/1
F0/0 .1
2
R3(config-if)# description Access to the Internet 3
via this interface 172.16.1.10
172.16.1.50
R3(config-if)# ip access-group inboundfilters in
172.16.1.0 / 24
R3(config-if)# ip access-group outboundfilters out
1
Komentar: Define the inbound access list entries. This example
shows Enhanced IGRP permitted on the interface. Also, no ICMP traffic 172.16.1.254
is permitted. The last entry points to the reflexive access list. If a packet
does not match the first two entries, the packet will be evaluated
against all the entries in the reflexive access list tcptraffic.

Primer
Internet
Provera: Ukoliko nije bilo iniciranja TCP saobraaja od strane
ureaja iz LAN mree ka odreditu koji se nalazi u udaljenoj mrei,
rezultat komande show access-lists je sledei:
R3# show access-lists

S0/1
Extended IP access list inboundfilters
R3
permit eigrp any any
F0/0 .1
deny icmp any any 2
3
evaluate tcptraffic
172.16.1.10
Extended IP access list outboundfilters 172.16.1.50
permit tcp any any reflect tcptraffic

172.16.1.0 / 24
Komentar: Notice that the reflexive access list does not appear in
this output. This is because before any TCP sessions have been 1
initiated, no traffic has triggered the reflexive access list, and the list is
empty (has no entries). When empty, reflexive access lists do not show 172.16.1.254
up in show access-list output.

Primer
Internet
Provera: Nakon iniciranja Telnet konekcije od strane nekog ureaja
iz LAN mree ka odreditu koji se nalazi u nekoj udaljenoj mrei,
rezultat komande show access-lists je sledei:
R3# show access-lists

S0/1
Extended IP access list inboundfilters
R3
permit eigrp any any
F0/0 .1
deny icmp any any 2
3
evaluate tcptraffic
172.16.1.10
Extended IP access list outboundfilters 172.16.1.50
permit tcp any any reflect tcptraffic

172.16.1.0 / 24
Reflexive IP access list tcptraffic
permit tcp host 172.19.99.67 eq telnet host 172.16.1.10 eq 1

11005 (5 matches) (time left 115 seconds)
172.16.1.254
Komentar: Notice that the reflexive access list tcptraffic now
appears and displays the temporary entry generated when the Telnet
session initiated with an outbound packet.

Benefits of the reflexive access lists
Reflexive access lists are an
important part of securing your
network against network hackers,
and can be included in a firewall
defense.
Reflexive access lists provide a

level of security against spoofing
and certain denial-of-service
attacks.
Reflexive access lists are

simple to use, and, compared to
basic access lists, provide greater
control over which packets enter
your network.

Configuring Dynamic ACLs
Dynamic ACLs (Lock-and-Key Security)
Dynamic ACLs are available for IP traffic only.
Dynamic ACLs are dependent on Telnet
connectivity, authentication (either local or
remote), and extended ACLs.
Dynamic ACLs offer these security benefits over
standard and static extended ACLs:
Challenge mechanism to authenticate individual users
Simplified management in large internetworks
Reduced router processing for ACLs
Less opportunity for network break-ins by network hackers
Creation of dynamic user access through a firewall, without
compromising other configured security restrictions.
Dynamic ACLs (Lock-and-Key Security)
When lock-and-key is configured, designated users whose IP traffic is
normally blocked at a router can gain temporary access through the
router.
When triggered, lock-and-key reconfigures the interfaces existing IP

access list to permit designated users to reach their designated host(s).
Afterwards, lock-and-key reconfigures the interface back to its original

state.
For a user to gain access to a host through a router with lock-and-key

configured, the user must first open a Telnet session to the router.
When a user initiates a standard Telnet session to the router, lock-and-

key automatically attempts to authenticate the user. If the user is
authenticated, they will then gain temporary access through the router
and be able to reach their destination host.

Dynamic ACL Operation
An extended ACL is applied to block all traffic
through the router, except Telnet. Users who want to
traverse the router are blocked by the ACL until they
use Telnet to connect to the router and are
authenticated.
Users authenticate using Telnet, and then dropped.
However, a single-entry dynamic ACL is added to the
extended ACL that exists.
This permits traffic for a particular period; idle and absolute
timeouts are possible.

When to Use Lock-and-Key
When you want a specific remote user (or group of remote users) to be
able to access a host within your network, connecting from their remote
hosts via the Internet. Lock-and-key authenticates the user, then permits
limited access through your firewall router for the individuals host or
subnet, for a finite period of time.
When you want a subset of hosts on a local network to access a host

on a remote network protected by a firewall. With lock-and-key, you can
enable access to the remote host only for the desired set of local users
hosts. Lock-and-key require the users to authenticate through a
TACACS+ server, or other security server, before allowing their hosts to
access the remote hosts.

How Lock-and-Key Works
The following process describes the lock-and-key access
operation:
A user opens a Telnet session to a border (firewall) router configured for lock-
and-key. The user connects via the virtual terminal port on the router.
The Cisco IOS software receives the Telnet packet, opens a Telnet session,
prompts for a password, and performs a user authentication process. The user
must pass authentication before access through the router is allowed. The authentication
process can be done by the router or by a central access security server such as a
TACACS+ or RADIUS server.
When the user passes authentication, they are logged out of the Telnet session,
and the software creates a temporary entry in the dynamic access list. (Per your
configuration, this temporary entry can limit the range of networks to which the user is
given temporary access.)
The user exchanges data through the firewall.
The software deletes the temporary access list entry when a configured timeout
is reached, or when the system administrator manually clears it. The
configured timeout can either be an idle timeout or an absolute timeout.
Dynamic ACL Operation Cont.

Configuring a Dynamic ACL

Dynamic ACL Timeouts
Two timeouts are associated with dynamic ACL
entries: absolute and idle.
The absolute timer is specified in the dynamic ACL
entry.
The idle timeout value is specified in the
autocommand command, which enables lock-and-key
authentication on the vty lines.
If timeouts are not specified, the default is to never
time out the entry; therefore, it is recommended to
configure a timeout.

Configuring Time-Based ACLs
Time-Based ACLs
Time-based ACLs allow for access control based on
time.
Timed-based ACLs enable traffic to be restricted
based on the time of day, the day of the week, or the
day of the month.


Time-Based ACL Scenario
Users are not allowed to access the
Internet during business hours,
except during lunch and after hours
between 5:00 p.m. and 7:00 p.m.
R1(config)# time-range EMPLOYEE-TIME

R1(config-time-range)# periodic weekdays 12:00 to 13:00
R1(config-time-range)# periodic weekdays 17:00 to 19:00
R1(config-time-range)# exit
R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any time-range EMPLOYEE-TIME
R1(config)# access-list 100 deny ip any any
R1(config)# interface FastEthernet 0/1
R1(config-if)# ip access-group 100 in
R1(config-if)# exit

Troubleshooting Complex ACL Implementations
Verify and Troubleshoot ACLs
Two commands are very useful for troubleshooting ACLs:
show access-lists
debug ip packet (detail)

Troubleshooting Complex ACL Implementations
Debugging ACLs

Mitigating Attacks with ACLs
Mitigating Spoofing and DoS Attacks
ACLs can be used to mitigate many network threats
IP address spoofing, inbound and outbound
DoS TCP SYN attacks
DoS smurf attacks
ACLs can also filter the following traffic

ICMP messages (inbound and outbound)
traceroute

Antispoofing with ACLs
Deny all IP packets containing the
following IP addresses in their
source field:
Any local host addresses
(127.0.0.0/8)
Any reserved private addresses
(RFC 1918)
Any addresses in the IP
multicast address range
(224.0.0.0/4)
R1(config)# access-list 150 deny ip 0.0.0.0 0.255.255.255 any

R1(config)# access-list 150 deny ip host 255.255.255.255 any

Permitting Necessary Traffic Through a Firewall
DNS, SMTP, and FTP are common services that often
must be allowed through a firewall.

Mitigating ICMP Abuse
Hackers use ICMP packets for pings sweeps and DoS flood
attacks, and use ICMP redirect messages to alter host routing
tables.
Both ICMP echo and redirect messages should be blocked

inbound by the router.

Mitigating SNMP Exploits
Management protocols, such as SNMP, while useful for remote
monitoring and management of networked devices, can be
exploited.
Apply interface ACLs to filter SNMP packets from non-authorized

systems.

Using Object Groups in ACEs
Object Groups
When creating access lists, you can run into problems. Suppose, for
instance, that you have 15 different servers and that they are not all on the
same subnet.
So, you cannot create a nice summary range for them. You also need to
permit both web and email traffic to these 15 servers.
It is possible to create object groups that identify those 15 servers, and

then use those object groups embedded into entries in your access list.
To allow 2 protocols to 15 different servers, it could be created an object

group for the 15 servers and implemented your access list with 2 lines, one
for web traffic and one for email traffic to the object group.
In reality, this is just a timesaver for the administrator, because behind

the scenes the router is still logically checking an access list, which would
be 30 lines long, about 2 specific services to each of the 15 different
devices.
Object groups are convenient for the configuration of policy and a

benefit to the administrator for that reason.
Object Groups
Object groups are used to classify users, devices, or
protocols into groups.
These groups can then be used to create access control policies

for groups of objects in easy to read statements.
This feature lets the administrator use object groups instead

of individual IP addresses, protocols, and ports, which are used
in conventional ACLs.
This results in fewer, more manageable Access Control Entries

(ACEs).
Both IPv4 and IPv6 ACLs can use object groups.

Object Groups
There are two main
categories for object
groups.
There are network object
groups
Identify devices based on
IP address, and could be a
network, host, or a range of
hosts.
The other type of object

group is called a service
object group
Help to specify TCP, UDP,
and a collection of ports that
represent common services
such as TCP port 22 for
Secure Shell (SSH) , TCP port
443 for Secure Sockets Layer
Presentation_ID
(SSL) , and so on. 2008 Cisco Systems, Inc. All rights reserved. 80
Network and Service Object Groups
Object groups must have unique names.

Additional objects can be appended to existing object groups.
Objects such as hosts, protocols, or services can be grouped.
Cannot delete an object group or make an object group empty if it is
being used in an ACE.

Configuring Network and Service Object Groups

Creating an Object Group-Based ACL
In this ACL, all IP addresses and networks specified within the
eng_network_group are permitted all services specified in the
eng_srv_group.
In the example, the protocol argument (tcp, udp, icmp) is not
necessary, because the protocol is specified within the services
group.

4.2 Firewall Technologies
Defining Firewalls
Uopteno govorei, uloga firewall-a je da razdvoji dva
entiteta, kontroliui na specifian nain pristup izmeu tih
entiteta, tj. mrea.
U najveem broju sluaja komercijalni firewall-ovi mogu
da filtriraju pakete, vre pregledanje sadraja na
aplikativnom sloju, vre stateful packet filtriranje, NAT,
obezbeuju funkcije AAA i VPN (virtual private network)
servise.
Dobar primer ovakvog ureaja jeste Cisco Adaptive
Security Appliance (ASA), koji predstavlja namenski
kompleksan firewall ureaj
Mnoge gore navedene karakteristike mogu biti
implementirane softverski u IOS rutera ije licence, memorija
i CPU mogu to podrati.
Namenski firewall ureaj se smatra ureajem koji moe
obezbediti bolju bezbednost u raunarskoj mrei zbog ega
je poeljniji u odnosu na realizaciju firewall-a softverski na
ruteru.
Defense-in-depth pristup predlae implementaciju gore
navedenih bezbedonosnih karakteristika na vie ureaja u
mrei. 85
Presentation_ID 2008 Cisco Systems, Inc. All rights reserved.
Securing Networks with Firewalls
Defining Firewalls
Cisco has implemented some form of
firewall protection in their IOS for many years.
You can implement packet filtering with

access lists applied to interfaces
The older firewall feature set named

context-based access control (CBAC)
provided stateful filtering.
More recently, that CBAC has been

replaced by a newer method for stateful
filtering and application inspection called the
Zone-Based Firewall (ZBF).

Defining Firewalls
Firewall spreava pristup
neeljenog saobraaja nekoj
predefinisanoj oblasti unutar
raunarske mree. Drugim reima,
spreava potencijalne napade.
Firewall sprovodi polise kontrole

saobraaja izmeu mrea. Na
primer:
A packet filtering router
A switch with two VLANs
Multiple hosts with firewall
software
In 1989, AT&T Bell Laboratories

developed the first stateful firewall. A
stateful firewall is able to
determine if a packet belongs to
an existing flow of data.
Defining Firewalls Cont.

Benefits and Limitations of Firewalls
Benefits
Spreava izlaganje hostova od znaaja (poput servera) i aplikacija
neeljenim korisnicima
Saobraaj update poruka unutar protokola moe biti preien i na taj

nain se spreava zloupotreba eventualnih mana samog protokola
Maliciozni podaci se mogu detektovati i blokirati. To je esto uloga IPS-a
Firewall moe kontrolisati saobraaj na osnovu primene AAA
Realizacija polisa bezbednosti u mrei primenom firewall ureaja je

jednostavnija, bolja i skalabilna

Benefits and Limitations of Firewalls
Limitations
Ukoliko je firewall loe podeen,
konsekvence mogu biti krajnje ozbiljne,
mogua pojava single point of failure.
Podaci mnogih aplikacija se ne mogu

bezbedno propustiti firewall-om
Korisnici mogu traiti naina na

firewall-u da ipak prime blokiran materijal,
inei time mreu slabom na potencijalne
napade.
Korienje firewall-a moe dovesti do

usporavanja rada mree i degradiranja
njenih performansi.
Mogue je tunelovanje i sakrivanje

neautorizovanog saobraaja iza
legitimnog saobraaja, ime se
omoguava njegovo proputanje kroz
firewall.
Objectives of a Good Firewall (Ciljevi)
Firewall mora biti otporan na napade:
Ukoliko se firewall moe oboriti ili
kompromitovati u takama gde se nakon toga
omoguava neeljen saobraaj, onda je
nemogue adekvatno implementirati eljene
bezbedonosne polise u mrei. Problem je i ako
je firewall rtva DoS napada na mestu gde se
nakon toga ne moe omoguiti normalan
pristup regularnim korisnicima. Postojanje
slabosti napada moe maksimalno da
zloupotrebi i iskoristi u svoju korist u pristupu, a
potom i u modifikaciji konfiguracije na firewall-u

Objectives of a Good Firewall (Ciljevi)
Saobraaj izmeu mrea je neophodno
omoguiti iskljuivo preko firewall-a: Ukoliko
postoje nekoliko razliitih putanja izmeu dve
mree (primer mree A i mree B), neophodno
je da firewall kontrolie sve konekcije. Ako neka
alternativna putanja izmeu tih mrea zaobilazi
firewall, mogue preko te nekontrolisane
putanje realizovati neki vid malicioznog
saobraaja koji potom naruava bezbednost u
mrei. Neophodno je da u sluaju postojanja
vie putanja izmeu dva entiteta postoji ista
firewall polisa i da se u svim takama primeni
ista firewall metodologija.
Neophodno je da firewall dosledno izvrava

the access control policy kompanije: Jako
esto se prvo implementiraju rules na firewall-u
na osnovu koji se dokumentuju polise
kompanije, to je pogreno. Preporuka je da se
prvo definiu polise kompanije na osnovu
njihovih zahteva i potreba, a tek onda na
osnovu definisanih polisa implementirati
odgovarajue rules na firewall-u.
Firewall Design Considerations
Lista najboljih preporuka za realizaciju
i raspored firewall-a u mrei:
Firewall-e treba postaviti na graninim takama
entiteta koje su bitne za sigurnost u mrei. To su
take razdvajanja mrea sa razliitim nivoima
poverenja (gledano iz ugla firme, kompanije). Primer
bi bio privatna unutranja mrea firme kao jedan
entitet i Internet kao drugi entitet.
Firewall-ovi treba da budu primarni sugurnosni
ureaji, ali ne i jedini sigurnosni ureaji kao jedina
mera zatite bezbednosti u mrei.
Polisa koja poinje sa stanovitem odbaci sve, a
potom se po potrebi dozvoljava pojedinaan eljeni
saobraaj je bolji koncept od polise koja
podrazumevano dozvoljava sve, a onda se
zabranjuje pojedinaan neeljeni saobraaj.

Maksimalno iskoristiti karakteristike (feature)
firewall-a koje najbolje odgovaraju potrebama same
kompanije. Primer, ukoliko kompanija ima na hiljade
zaposlenih koji e imati potrebu za Internetom,
preporuka je da se u tom sluaju implementira
dinamiki NAT/PAT tim korisnicima, omogui stateful
filtriranje saobraaja i zabrani inicijalni dolazni
saobraaj sa Interneta. Time se zabranjuje
korisnicima sa Interneta da iniciraju sesije sa
zaposlenima u kompaniji zbog deny statusa na
izlaznom interfejsu firewall-a kompanije. S druge
strane, dozvoljen je pristup Internetu zaposlenima
implementacijom dinamikog NAT-a. Povratni
saobraaj sa Interneta (odgovor na iniciran saobraaj
iz mree kompanije) je dozvoljen kroz firewall jer je
realizovano stateful filtriranje i firewall moe
dinamiki da omogui povratni saobraaj. Ukoliko se
eli samo pojedinanim korisnicima omoguiti pristup
Internetu, mogue je dodatno ukljuiti AAA funkcije
na firewall-u.

Obezbediti fiziku sigurnost i bezbednost u
kontroli i upravljanju pristupom firewall ureajima i
infrastrukturi koja te ureaje podrava, kao to su
kablovi i svievi.
Redovno vriti prikaz i uvid u logove koji su
zabeleili prethodne aktivnosti na firewall-u. Mnogi
softverski alati mogu obezbediti pregled i analizu
syslog poruka i detekciju anomalija i poruka koje
ukazuju na potrebu daljeg nadzora.
Praktikovati promenu menadmenta pri svakoj
izmeni u konfiguraciji na firewall-u. AAA i
odgovarajua dokumentacija je vana za uvanje
izvetaja o tome koji administrator je menjao
konfiguraciju na firewall-u i kada je vrio te promene.
Snimljeni izvetaj ili njegova kopija se prebacuje
barem na jedan server koji je van administratorske
kontrole admin grupe. Time se kompanija na neki
nain titi od administratora koji sluajno ili namerno
naprave promene u konfiguraciji na firewall-u,
naprave problem u mrei, a potom pokuaju da
obriu accounting logs o problematinim promenama
Presentation_IDkonfiguracije koje su prethodno nainili. 2008 Cisco Systems, Inc. All rights reserved. 98
Types of Firewalls
Firewall Types
Packet Filtering Firewall
1. Packet filtering firewall - Tipino
ruter koji ima sposobnost da filtrira
neki sadraj paketa, Layer 3 i
ponekad Layer 4 informacije.
Stateful Firewall
2. Stateful firewall - vri monitoring,

tj. nadgledanje stanja (moda)
konekcija, da li je konekcija u modu
iniciranja veze, transfera podataka
ili raskidanja veze.

Types of Firewalls
Firewall Types
Application Gateway Firewall
3. Application gateway firewall

(proxy firewall) - firewall koji filtrira
informacije na Layers 3, 4, 5, i 7
OSI referentnog modela. Kontrola i
filtriranje saobraaja se uglavnom
izvrava softverski.
NAT Firewall
4. Network address translation

(NAT) firewall - firewall koji ini
dostupnim odreeni broj javnih IP
adresa, dok sa druge strane krije
privatni adresni prostor lokalnih
mrea.
Types of Firewalls
1. Packet Filtering Firewall
Packet-filtering firewall obino predstavlja deo Cisco IOS Software
firewall-a na ruteru koji prvenstveno koristi ACLs. Ovaj tip firewall-a
ispituje paket na osnovu informacija dobijenih iz zaglavlja paketa.
Packet-filtering firewalls koristi jednostavne policy table lookup na

osnovu kojih dozvoljava, odnosno zabranjuje saobraaj na osnovu
svecifinih kriterijuma:
Izvorne IP adrese
Odredine IP adrese
Protokola
Broja izvornog porta Transportnog sloja
Broja odredinog porta Transportnog sloja
Synchronize/start (SYN) packet receipt

Types of Firewalls
2. Stateful Firewalls
Stateful firewalls su najraznovrsniji i najei tipovi firewall
tehnologija koji se koriste danas
Stateful filtering snima svaku konekciju skenirajui sve interfejse

firewall-a uz potvrdu da li konekcije validne ili ne.
Ovaj tip firewall-a analizira informacije iz zaglavlja paketa (layer3) i

segmenta (layer4)
Naziva se drugaije i stateful packet filters i application-aware

packet filters.
Stateful firewalls su unapreeni dvema novim funkcijama vezano za

filtriranje paketa
Maintain a session table (state table) where they track all
connections.
Recognize dynamic applications and know which additional
connections will be initiated between the endpoints.
Types of Firewalls
Stateful Firewalls Cont.
Stateful firewalls inspect every packet, compare the packet against
the state table, and may examine the packet for any special
protocol negotiations.
Stateful firewalls operate mainly at the transport (TCP and UDP)

layer.

Stateful Firewall Benefits and Limitations
Next Generation Firewalls

Granular identification, visibility, and control of behaviors within applications
Restricting web and web application use based on the reputation of the site
Proactive protection against Internet threats
Enforcement of policies based on the user, device, role, application type, and threat profile
Performance of NAT, VPN, and SPI
Use of an IPS

Types of Firewalls
Cisco Firewall Solutions
Cisco Systems provides several options for network security
professionals to implement a firewall solution.

Classic Firewall
Classic Firewall
Classic Firewall, formerly known as
context-based access control (CBAC)
Classic Firewall provides four main

functions that include traffic filtering, traffic
inspection, intrusion detection, and
generation of audits and alerts
(upozorenja)
Classic Firewall is a dramatic

improvement over the TCP established
and reflexive ACL firewalls in several
ways:
Monitors TCP connection setup
Tracks TCP sequence numbers
Monitors UDP session information
Inspects DNS queries and replies
Inspects common ICMP message types
Supports applications that rely on

multiple connections
Inspects embedded addresses
Inspects application layer information

Classic Firewall
Classic Firewall Configuration
To configure Classic Firewall:
Step 1. Select an interface, either
internal or external.
Step 2. Configure IP ACLs at the

interface.
Step 3. Define inspection rules.
Step 4. Apply an inspection rule

to an interface.

Classic Firewall
Classic Firewall Operation

Classic Firewall
Classic Firewall Operation Cont.
With Classic Firewall, the protocols to inspect are specified in an inspection rule.
An inspection rule is applied to an interface in a direction, either in or out, where the

inspection applies.

2013 Cisco and/or its affiliates. All rights reserved. Cisco Public 110
Inside and Outside Networks

Demilitarized Zones
Demilitarized Zones (DMZs) define the portions of a network
that are trusted and untrusted.

Demilitarized Zones
Demilitarized Zones (DMZs) define the portions of a network
that are trusted and untrusted.

Zone-Based Policy Firewalls

Layered Defense
Considerations for network defense:
Network core security
Perimeter security
Endpoint security
Communications security
Firewall best practices include:

Position firewalls at security boundaries.
It is unwise to rely exclusively on a firewall for security.
Deny all traffic by default. Permit only services that are needed.
Ensure that physical access to the firewall is controlled.
Monitor firewall logs.
Practice change management for firewall configuration changes.
Remember that firewalls primarily protect from technical attacks originating from the outside.

Firewalls In Network Design
Firewalls and the Security Policy
Firewall Best Practices

4.3 Zone-Based Policy
Firewalls
Zone-Based Policy Firewall Characteristics
Zone-Based Policy Firewalls concept
podrazumeva kreiranje zona od strane
administratora, logikih oblasti u kojima svi
ureaji imaju isti nivo poverenja. Na primer,
kreiranje DMZ zone, u kojoj su smeteni
svi DMZ ureaji jedne organizacije.
Sa ZBFs konceptom, interfejsi se

smetaju unutar konfigurisanih zona.
Kreiranjem zona od strane

administratora, zonama se dodeljuju
odgovarajua imena koja imaju smisla
(imena zona poput inside, outside i DMZ
su veoma esta)
Unutar zone se specificiraju polise

kojima se definie kom tranzitnom
(korisnikom) saobraaju e biti dozvoljeno
da bude iniciran
Na primer, za saobraaj od korisnika
unutar inside zone ka resursima koji su u
outside zoni, mogue je definisati koje
aktivnosti e firewall preduzeti, poput
pregledanja (ispection), odnosno stateful
inspection of the traffic)
Nakon to je saobraaj proveren i

pregledan (inspected) i doputen, replay
saobraaj (odgovor na prethodni inicijalni)
je dozvoljen nazad kroz firewall zbog
karakteristika stateful filtriranja

Polise se implementiraju u jednom smeru
(primer: smer inside outside)
Ukoliko se eli dopustiti inicijalni saobraaj u

oba smera, u tom sluaju se kreiraju dve
unidirectional polise koje e dozvoliti i pregledati
saobraaj u oba smera, tj. jedna polisa za jedan
smer (inside-outside), druga polisa za drugi
smer (outside-inside)
Implementiraju se dve odvojene polise jer su

polise same po sebi unidirectional
Prednost ovakvom modularnom pristupu

jeste u tome to nakon implementiranih polisa,
ukoliko se konfiguriu naknadno interfejsi, i eli
da ti novi interfejsi budu dodati odgovarajuim
zonama, potrebno je da se ti interfejsi samo
dodele eljenim zonama. Nakon toga, polise
koje vae za izabrane zone se novo-dodatim
interfejsima dodeljuju automatski.

A Zone-Based Policy Firewall
configuration model (ZPF or ZBF or ZFW)
was introduced in 2006 with Cisco IOS
Release 12.4(6)T.
Primenom ZPF-a realizuju se polise

nadgledanja (inspection policy) saobraaja
izmeu razliitih zona
Podrazumevana polisa je zabraniti sav
saobraaj sve dok se eksplicitno ne
dozvoli (kod CBAC-a je obrnuto,
podrazumevano je dozvoliti sav
saobraaj)

Osnovne karakteristike i mogunosti
Zone-Based Policy Firewall-a:
Stateful inspection.
Application inspection.
Packet filtering.
URL filtering.
Transparent firewall (implementation method).
Support for virtual routing and forwarding (VRF).
Access control lists (ACL) are not required as a

filtering method to implement the policy.
URL filtering: ability to control what traffic is permitted or denied (mostly denied) based on the URL
that is trying to be accessed by the client.
A transparent firewall is implemented at Layer 2 but can still perform analysis of traffic at Layer 3 and
higher.
VRFs are virtual routing tables on a Cisco router that can be used to compartmentalize (divide into
discrete sections or categories) the routing tables on the router instead of keeping all the routes in the
global (primary) routing tables 122
Presentation_ID 2008 Cisco Systems, Inc. All rights reserved.
Zone-Based Policy Firewalls Cont.
Zone-Based Policy Firewall-ovi ne zavise od access listi.
Polise kod ZPF-a nalau ruteru da podrazumevano blokiraju sav

saobraaj sve dok se eksplicitno ne dozvoli
Lako je vriti reading and troubleshooting polisa sa C3PL (Cisco

Common Classification Policy Language).
Jedna polisa deluje na bilo koji dat saobraaj, za razliku od potrebe

za viestruke ACLs i akcije nadgledanja (provere, pregleda saobraaja
inspection)

Zone-Based Policy Firewall Design
Prvo se kreira zona od strane administratora, a potom se interfejsi
pridruuju nekoj od kreiranih zona
Jedna zona moe imati vie pridruenih interfejsa. Svaki interfejs

moe pripadati samo jednoj zoni
Postoji podrazumevana zona, koja se naziva self zona i koja je

logika zona.
Svi paketi koji su usmereni direktno ka ruteru (destinaciona IP

adresa paketa je IP adresa rutera), pripadaju saobraaju koji ruter
prima unutar self zone. Svaki saobraaj iniciran od strane rutera,
smatra se saobraajem koji naputa self zonu.
Podrazumevano, svaki saobraaj ka i od self zone je

podrazumevano dozvoljen. Ta polisa se moe po elji promeniti.

Za ostale zone koje su kreirane od strane administratora, saobraaj
izmeu interfejsa koji ne pripadaju istoj zoni nije dozvoljen.
Za sve interfejse koji su pridrueni istoj kreiranoj zoni, saobraaj izmeu tih
interfejsa je podrazumevano dozvoljen.
Ukoliko se eli dozvoliti saobraaj izmeu dve zone (na primer izmeu
inside zone, tj. interfejsa koji je pridruen inside zoni, i outside zone, tj.
interfejsa preko koga se ostvaruje veza sa Internetom), neophodno je kreirati
polisu za saobraaj izmeu te dve zone. Drugim reima, formira se a zone
pair za eljenu polisu.
A zone pair predstavlja konfiguraciju na ruteru pomou koje se identifikuje

saobraaj iniciran od strane ureaja u jednoj zoni, a namenjen ureaju u
drugoj zoni.
Administrator potom povezuje set definisanih pravila (polisu) sa

kreiranim unidirectional zone pair, kao to je inspekcija saobraa itd.

Zone-Based Policy Firewall Design - rezime
Determine the Zones - The internetworking infrastructure under
consideration must be split into separate zones with various security
levels focusing on the separation of the infrastructure into zones.
Establish policies between zones - For each pair of "source-

destination" zones (for example, from inside network to Internet),
define the sessions that clients in the source zones can request from
servers in destination zones.
Design the physical infrastructure - The administrator must

design the physical infrastructure, considering security and availability
requirements.
Identify subset within zones and merge traffic requirements -

For each firewall device in the design, the administrator must identify
zone subsets connected to its interfaces and merge the traffic
requirements for those zones.

Implementacija Zone-Based Policy Firewall Design u malim
kompanijama
A small company, with users on the inside network, with the only
other connection being the Internet, might want to create two zones,
one for the inside and one for the outside.
Then they would assign the inside interface to the inside zone, and
the outside interface to the outside zone.
Then, a policy could be created that specifies that traffic that is

initiated from the inside users and going out to the Internet should be
inspected and that information should be placed in the stateful
database.
A zone pair identifying traffic from the inside to the outside would
have the policy applied to it, letting it know that the stateful inspection
should be done.

Implementacija Zone-Based Policy Firewall Design u veim
kompanijama
A larger company that has a public-facing server may have three
interfaces and three zones.
The zones may be inside, outside, and DMZ. Compared to the

small company, this mediumsized company creates an additional
zone pair (from outside to DMZ) and then applies a policy to that zone
pair to allow outside users to access the servers on the DMZ.

Putting the Pieces Together
Cisco koristi jezik Cisco Common Classification Policy
Language (C3PL) za implementaciju polisa na firewall-u. Ovaj
proces sadri tri osnovne komponente:
Class maps:
Class maps se koristi za identifikaciju saobraaja koji je potrebno nadgledati i
proveriti inspected. Saobraaj koji se moe nadgledati i identifikovati je saobraaj
nivoa od 3 do 7 OSI modela (ukljuujui i 7. aplikativni sloj). Class maps moe da
obuhvata i pristupne liste - access control lists (ACL) radi identifikovanja saobraaja
ili ak pozivanja druge class maps.
Class map moe imati vie match statements (uslova za proveru i identifikaciju).
Class map moe specificirati da svi match statements moraju da se podudaraju, tj.
match (to predstavlja a match-all condition).
Pored toga, class map moe da specificira da poklapanje bilo kog uslova od svih
navedenih (statements) se smatra dovoljnim za identifikovanje saobraaja (or can
specify that matching any of the entries is considered a match - which is a match-
any condition).
A system-defined class map named class-default can be used that represents
all traffic not matched in a more specific (administratively configured) class map.
Policy maps:
Policy map definie akcije koje je potrebno preduzeti nad identifikovanim
saobraajem to je prethodno uinjeno uz pomo class maps.
Policy maps se pozivaju na class maps za klasifikaciju saobraaja.
Policy maps sa vie sections se procesiraju prethodno definisanim redom
Primarne akcije koje se mogu implementirati primenom policy map su: inspect
(which means that stateful inspection should happen), permit (which means that
traffic is permitted but not inspected), drop, or log.

Zone-Based Policy Firewall Operation
Zone-Based Policy Firewall Actions
Inspect
which means that stateful inspection should happen
It automatically allows for return traffic and potential ICMP messages.
For protocols requiring multiple parallel signaling and data sessions (for example,
FTP or H.323), the inspect action also handles the proper establishment of data
sessions.
Pass
Analogous to a permit statement in an ACL.
It does not track the state of connections or sessions within the traffic (traffic is
permitted but not inspected).
Pass allows the traffic only in one direction.
A corresponding policy must be applied to allow return traffic to pass in the opposite
direction.
Drop
Analogous to a deny statement in an ACL.
Presentation_ID
A log option is available to log the rejected packets.
2008 Cisco Systems, Inc. All rights reserved. 131
Policy map actions:

Service policies:
Service policies definiu gde se polise postavljaju, na kom zone pair (par dve
zone) se polise implementiraju, tj. na kom zone pair e polisa biti primenjena.
Polisa se preuzima iz prethodno definisanog policy map.
Ukoliko policy map sadri vie akcija, za vie tipova saobraaja to je definisano
razliitim class mapidentified traffic, akcije iz policy map se procesiraju od vrha ka
dnu, implementirajui akcije ukoliko je saobraaj prethodno identifikovan uz pomo
class map.
If a specific section of a policy map matches, the action is taken. If traffic does
not match, the packet is compared against the next section of the policy map.
If none of the sections match the traffic, the default behavior action is taken. The
default policy for traffic that is trying to be initiated between two zones (starting in
one zone and going to a device in another zone) is an implicit deny.
(The exception to this default deny is traffic to or from the built-in self zone,
which is allowed by default.)
Service policies:
A service policy is applied to a zone pair.
The zone pair represents a unidirectional flow of traffic between two zones.
A specific zone pair can have only a single service policy assigned to it.
Because the zone pair is unidirectional, the policy map applied to the zone pair
(using the service-policy command) applies to traffic initiated in one zone going to
the other zone in one direction.
If reply traffic is desired, the inspect action in the policy map should be applied,
which will allow stateful inspection, and the reply traffic from the servers will be
dynamically allowed (because of the stateful database being referenced).

Zone-Based Policy Firewall Rules for Routers
The ZBF rules for a zone-based policy firewall are different when the
router is the source or the destination of the traffic.
When an interface is configured to be a zone member, the hosts that are connected
to the interface are included in the zone.
However, traffic to the router is not subject to the zone policies.
By default, all router IP interfaces are part of the self zone.
A zone-pair that includes the self zone and associated policy, applies
to router generated or traffic destined to the router. It does not apply to
traffic traversing the router.
A policy can be defined using the self zone as either the source or the
destination zone.
The self zone is a system-defined zone.
It does not require any interfaces to be configured as members.

Kada ruter primi paket, ruter donosi odluku na osnovu sadraja tabele rutiranja na koji izlazni
interfejs e paket rutirati i usmeriti dalje ka odredinoj mrei. Ukoliko je ZBF konfigurisan na ruteru,
ruter e paket propustiti ili odbaciti na osnovu stateful tabele i implementiranih polisa
Tabela 15-3 opisuje tok saobraaja koji se rutira izmeu interfejsa iz razliitih zona u zavisnosti od
ZBF konfiguracije.
Ingress definie paket koji nadolazi na interfejs rutera, dok egress definie paket koji se alje sa
interfejsa rutera.

Saobraaj se proputa jer ZBF nije implementiran na ulaznom i izlaznom
interfejsu rutera, interfejsi nisu pridrueni zonama

Saobraaj se odbacuje jer je jedan interfejs dodeljen zoni, a drugi nije,
usput je implementirana i polisa izmeu dve zone gde jednoj od njih pripada
egress interfejs (to sada nema uticaja na odluku rutera)

Saobraaj se proputa jer su oba interfejsa ingress i egress pridruena
istoj zoni, usput je implementirana i polisa izmeu dve zone gde jednoj od njih
pripadaju oba ingress i egress interfejsi (to sada nema uticaja na odluku rutera)

Saobraaj se odbacuje jer je jedan interfejs dodeljen jednoj zoni, a drugi
interfejs drugoj zoni, pri emu nije implementirana polisa izmeu te dve zone

Jedan interfejs je dodeljen jednoj zoni, a drugi interfejs drugoj zoni, pri emu
je implementirana polisa izmeu te dve zone. Saobraaj se prosleuje ili
odbacuje na osnovu akcija koje su definisane postavljenom polisom

Configuring a Zone-Based Policy Firewall with CLI
Configuring Zone-Based Policy Firewalls with CLI
Before we go any further, I want to show you a configuration that

includes the following ZBF components:
Zones
Interfaces that are members of zones
Class maps that identify traffic
Policy maps that use class maps to identify traffic and then specify the
actions which should take place
Zone pairs, which identify a unidirectional traffic flow, beginning from
devices in one zone and being routed out an interface in a second zone
Service policy, which associates a policy map with a zone pair

The class map "classifies" or "identifies" the traffic
In this example, this class map will match on either TELNET traffic or
any type of ICMP traffic
R3(config)# class-map type inspect match-any MY-CLASS-MAP
R3(config-cmap)# match protocol telnet
R3(config-cmap)# match protocol icmp
R3(config-cmap)# exit

The class map "classifies" or "identifies" the traffic
In this example, this class map will match on either TELNET traffic or
any type of ICMP traffic Odreuje da je dovoljno samo jedan od vie tipova navedenih
saobraaja da bude detektovan i da se u tom sluaju aktivira
Komanda za kreiranje class map-a koji e definisati tip policy map, ovaj deo komande se primenjuje ako je navedeno
saobraaja koji e se potom nadgledati vie tipova saobraaja.
R3(config)# class-map type inspect match-any MY-CLASS-MAP
R3(config-cmap)# match protocol telnet

Definisanje imena za
kreiran class map
R3(config-cmap)# match protocol icmp
R3(config-cmap)# exit
Definisanje tipova
saobraaja koji treba da
budu detektovani kako bi
se aktivirao policy map
Specijalizovan mod kreiranog class
map-a u kome se dalje konfigurie

The policy map calls on a specific class map that it wants to use to
identify which traffic the policy applies to, and then specifies the policy
action. In this example, it is to inspect the traffic
R3(config)# policy-map type inspect MY-POLICY-MAP
R3(config-pmap)# class type inspect MY-CLASS-MAP
R3(config-pmap-c)# inspect
R3(config-pmap-c)# exit
R3(config-pmap)# exit

The policy map calls on a specific class map that it wants to use to
identify which traffic the policy applies to, and then specifies the policy
action. In this example, it is to inspect the traffic
Definisanje imena za
Komanda za kreiranje policy map-a koji e definisati set akcija koje e
kreiran policy map
se primenjivati nad detektovanim saobraajem iz class map-a
R3(config)# policy-map type inspect MY-POLICY-MAP
R3(config-pmap)# class type inspect MY-CLASS-MAP
R3(config-pmap-c)# inspect Navoenje imena

class map-a
R3(config-pmap-c)# exit Komanda za definisanje prethodno kreiranog

class map-a nad kojim e se izvravati akcije
R3(config-pmap)# exit iz upravo kreiranog policy map-a
Definisanje tipa akcije unutar

Specijalizovan mod kreiranog policy kreiranog policy map-a koja e se
map-a u kome se dalje konfigurie izvravati nad detektovanim
saobraajem unutar class map-a

Next we create the security zones, they can be named whatever you
want to name them. In this example, I named them inside and outside.
R3(config)# zone security inside
R3(config-sec-zone)# exit
R3(config)# zone security outside

Next we create the security zones, they can be named whatever you
want to name them. In this example, I named them inside and outside.
Komanda za kreiranje zone
Ime kreirane zone

R3(config)# zone security inside
R3(config)# zone security outside
Specijalizovan mod kreirane zone u

kome se moe dalje konfigurisati

Create the zone-pair, specifying the zones and the direction (from
where to where)
R3(config)# zone-pair security in-to-out source inside

destination outside
Use the service-policy command in zone-pair configuration mode to

apply the policy map you want to use for traffic that matches this zone-pair
R3(config-sec-zone-pair)# service-policy type inspect MY-

POLICY-MAP
R3(config-sec-zone-pair)# exit

Create the zone-pair, specifying the zones and the direction (from
where to where) Komanda za kreiranje jednog para zona i
definisanje smera nad kojim ce se Ime kreiranog para zona Definisanje koja zona
nadgledati saobraaj i izvravati je izvorna
odgovarajue akcije
R3(config)# zone-pair security in-to-out source inside

destination outside
Definisanje koja zona

je odredina
Use the service-policy command in zone-pair configuration mode to

apply the policy map you want to use for traffic that matches this zone-pair
Navoenje imena policy map-a koja e se primenjivati nad
kreiranim parom zona u definisanom smeru source-destination
R3(config-sec-zone-pair)# service-policy type inspect MY-

POLICY-MAP
R3(config-sec-zone-pair)# exit Komanda za vezivanje prethodno kreiranog

policy map-a za upravo kreiran par zona i
definisan smer source-destination
Specijalizovan mod kreiranog para
zona u kome se dalje konfigurie
Configure the interfaces, so they become members of the respective
zones
R3(config)# interface GigabitEthernet3/0
R3(config-if)# description Belongs to outside zone
R3(config-if)# zone-member security outside
R3(config-if)# exit
R3(config-if)# description Belongs to inside zone
R3(config-if)# zone-member security inside
R3(config-if)# exit
R3(config)#

Configure the interfaces, so they become members of the respective
zones
R3(config-if)# description Belongs to outside zone
R3(config-if)# zone-member security outside
R3(config-if)# exit Komanda kojom se interfejs pridruuje

prethodno konfigurisanoj zoni
R3(config)# interface GigabitEthernet1/0 Ime kreirane

zone
R3(config-if)# description Belongs to inside zone
R3(config-if)# zone-member security inside
R3(config-if)# exit
R3(config)#

Configuring Zone-Based Policy Firewalls with CLI - rezime
Create the zones for the firewall.
zone security
Define traffic classes. These are used to identify traffic, such as traffic
that should be inspected. Traffic can be matched based on Layer 3
through Layer 7 of the OSI model, including application-based
matching.
class-map type inspect
Specify firewall policies. These are the actions that should be taken
on the traffic. Policy maps call on the class maps for the classification of
traffic. Policy maps with multiple sections are processed in order.
policy-map type inspect

Configuring Zone-Based Policy Firewalls with CLI - rezime
Apply firewall policies to pairs of source destination zones.
zone-pair
Assign router interfaces to zones.

zone-member security

Creating Zones

Defining Traffic Classes

Specifying Firewall Policies

Applying Firewall Policies and Assigning Router Interfaces
The firewall policy is applied to traffic between a pair of zones using the
zone-pair security command.
To apply a policy, a zone pair must first be created.
Specify the source zone, the destination zone, and the policy for handling
the traffic between them.
A service policy is applied to a zone pair. The zone pair represents a
unidirectional flow of traffic between two zones.
A specific zone pair can have only a single service policy assigned to it.
Because the zone pair is unidirectional, the policy map applied to the zone
pair (using the service-policy command) applies to traffic initiated in one
zone going to the other zone in one direction.
If reply traffic is desired, the inspect action in the policy map should be
applied, which will allow stateful inspection, and the reply traffic from the
servers will be dynamically allowed (because of the stateful database
being referenced).
Finally the administrator must assign interfaces to the appropriate security

zones using the zone-member interface command.
Presentation_ID 159
2008 Cisco Systems, Inc. All rights reserved.
Applying Firewall Policies and Assigning Router Interfaces

Configuring a Zone-Based Policy Firewall with CCP Wizard
Viewing the Zone-Based Policy Firewall State Table
Use the show policy-map type inspect zone-pair
session command to examine the active connections in the ZPF state
table.

Poglavlje Firewall Technology Bezbednost Racunarskih Mreza

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Poglavlje Firewall Technology Bezbednost Racunarskih Mreza

Încărcat de

Drepturi de autor:

Formate disponibile

Poglavlje 4.

Bezbednost raunarskih mrea

Verify the functionality of a configured ACL in relation to the network topology.

Configure TCP established and reflexive ACLs.

Configure dynamic ACLs.

Configure time-based ACLs.

Troubleshoot complex ACL implementations.

Use ACLs to mitigate common network attacks.

Configure object groups for use within an access control entry.

Explain how firewalls are used to help secure networks.

Describe the various types of firewalls.

Configure a classic firewall.

Explain design considerations for implementing firewall technologies.

Explain the operation of a Zone-Based Policy Firewall.

Configure Zone-Based Policy Firewall with CLI.

4.1 Access Control Lists

4.2 Firewall Technologies

4.3 Zone-Based Policy Firewalls

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 3

For the data plane, this

This is traffic from a user

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 4

ACL se moe konfigurisati na

ACLs se mogu koristiti u

Parametri koji se koriste prilikom

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 6

Note that an ACL can be used as a

In the discussion of protecting the

Standard ACLs match packets by examining the source IP address

Standard ACLs are used to filter packets based solely on Layer 3

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 9

Extended ACLs filter IP packets based on Layer3 and Layer4

Source and destination TCP and UDP Ports

TCP synchronization information

Standard and Extended ACLs are:

Applied on a VTY port using the access-class command.

Extended Numbered ACL Syntax

Named ACL Syntax

Standard ACE Syntax

Extended ACE Syntax

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 11

Syntax - Apply an ACL

Example - Named Standard ACL

Example - Named Extended ACL

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 12

Syntax - Apply an ACL to the VTY lines

Example - Named ACL on VTY lines with logging

Access control list

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 13

Standard Named IP ACL example:

Extended Named IP ACL example:

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 14

Action - Permit or deny

Protocol - TCP, UDP, or ICMP

Source and destination - IPv4 or IPv6 addresses

TCP and UDP - Source and destination port numbers

For ICMP - Message types

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 15

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 17

R1(config)# access-list 1 permit any

R1(config)# interface FastEthernet 0/0

R1(config-if)# ip access-group 1 out

Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. 18