ccsp asa transparent
TRANSCRIPT
-
8/13/2019 CCSP ASA Transparent
1/12
LAYER 2 PROCESSING OF TRAFFIC
In version 6.0 and earlier, the appliances would not process traffic on an interface unless we
assigned an IP address to them. So basically the appliance was acting as a routing device: traffic
would come in an interface, the appliance would compare the destination IP address to its routing
table, find the corresponding destination network and the interface to eit from, apply the policies to
the packet, and the appliance would forward the packet out the eit interface.
!ithout IP addressing on the appliance, traffic wouldn"t flow through it.
Routed vs. Transparent Mode
Starting in version # of the $S, the appliances support two modes of operation: routed
and transparent. In routed mode, the appliance acts as a layer % device and forwards packets based
on destination IP addresses. In transparent mode, the appliance acts as a layer & device, like a bridge
or switch, and forwards 'thernet frames based on destination ()* addresses.
In the routed mode the interfaces, whether they"re physical or logical +trunked with
-)s/, must be in separate -)s +broadcast domains/. Since routed mode is used and the
appliance must see these as two distinct networks, two subnets are used for the layer % addressing.
he appliance then forwards frames based on the IP addresses it sees inside the IP packet headers.
In the transparent mode the interfaces involved in the layer & process are in separate
-)s +broadcast domains/, but they are in the same layer % subnet +10.0.1.0/. !hen intransparent mode, the appliance behaves more like a layer & switch or bridge, where it switches
frames between interfaces based on the ()* addresses in the 'thernet frame headers.he
appliances still have the capability of filtering traffic based on information in the layer % and layer 2
headers as well as the application layer +layer #/ payload.
Brides vs. Transparent Mode
$ne thing to keep in mind about transparent mode is that even though an appliance is
operating at layer &, it does not behave eactly the same way as layer & switches or bridges. 3es,
they are both operating at layer &, but there are 4uite a few differences between how a switch and an
appliance will handle traffic.
-
8/13/2019 CCSP ASA Transparent
2/12
Switches perform three primary functions:
5 -earn what ()* addresses are associated with which interfaces, and store them in a local ()*
address table +sometimes called a *)( table/.
5 Intelligently forward traffic using the ()* address table, but flood unknown destination unicast
addresses, multicast addresses, and broadcast addresses.
5 se the Spanning ree Protocol +SP/ to break up layer & loops to ensure that only one active
path eists between a source and destination.
-ike switches, appliances when configured for transparent mode will perform the learning
function , also the appliance will also use then ()* address table to intelligently forward frames
based on the destination ()* addresses in the frame headers7 however, the app!ian"e #i!! not
$!ood destination uni"ast addresses t%at are not $ound in t%e MAC address ta&!e.
he appliance will flood broadcasts and multicasts. he appliance assumes that if the
devices are using *P8IP, they"ll go through the )9P process to discover destination ()*
addresses that are associated with layer % IP addresses7 through this discovery process the appliance
will learn the respective source ()* addresses and the interfaces they are associated with.
herefore, if a device breaks away from this epectation and uses a hardcoded ()* address that
the appliance hasn"t learned +either dynamically or statically/, the appliance will drop the unknowndestination ()* address.
he second deviation from layer & devices is that the appliances do not participate in SP.
hus it is very important toensure we don"t inadvertently create any layer & loops when setting up
transparent mode. If you create a loop, we can 4uickly figure this out when the *P utili;ation on
the appliance and switches
-
8/13/2019 CCSP ASA Transparent
3/12
and (P-S +(ultiprotocol -abel Switching/. his traffic can be configured to go through
the appliance by using an 'therype )*-.
) third advantage of transparent mode is that many, many features that work in routed
mode also are supported in transparent mode, like address translation +in version C/, stateful
filtering, standard and etended )*-s, *P, web content filtering, (P>, and many,
many others.
Tra$$i" F!o# and ACLs
*isco still uses security levels to control traffic between interfaces when an appliance is running in
transparent mode, where the same rules apply:
5 $utbound connections are allowed by default unless restricted.
5 Inbound connections are denied by default unless allowed.
he eception to these rules is )9P packets, which are always allowed by default since )9P
is used as a discovery process to learn the ()* addresses of devices. !e can restrict )9P packets,
however, but this is optional.
CONFIG'RING TRANSPARENT MO(E
!hen an appliance boots up, *isco assumes we"re running it in routed mode. $f course,
when we run the setup script , that"s the first 4uestion the script asks, where the answer defaults to
routed mode. *hanging it to transparent mode is a very simple process,
!hen setting up transparent mode, only two interfaces, physical and8or -), can be used.
he devices on the two sides must be in different broadcast domains, like -)s, but they must be
in the same subnet. !e can get around the twointerface limit with transparent mode: set up
contets, ) contet is basically a virtual firewall. !e can have some contets in transparent mode
and some in routed mode, where the contets in transparent mode support two interfaces each.
S#it"%in to Transparent ModeIf appliance is currently running in routed mode, we can very easily switch it to transparent
mode with the following command:
myappliance+config/G $ire#a!! transparent
ciscoasa+config/G
@ecause many features in routed mode are unsupported in transparent mode, the configuration on
the appliance is cleared. o revert back to routed mode, use the no $ire#a!! transparent command.
!hen switching from routed to transparent mode, we are not prompted to continue the processEthe
appliance immediately eecutes the command, and configuration is erased, and we go in
transparent mode. So if we want to try transparent mode on an appliance with a routed mode
configuration, first back up the configuration before trying it= !e can verify the mode with the
s%o# $ire#a!! command, like this:
-
8/13/2019 CCSP ASA Transparent
4/12
ciscoasa+config/G s%o# $ire#a!!
>irewall mode: ransparent
Manae)ent IP Address
!hen assigning a management IP address to the appliance, the address must be from the
subnet connected to the two interfaces on the appliance.
ciscoasa+config/G ip addressIP_address Hsubnet_mask Hstand&*IP_addresshe ip address command is a global commandEwe are not in an interface when
configuring it. he stand&*parameter assigns a management IP address to the standby unit in a
failover configuration .se the s%o# ip address command to verify management IP address
configuration.
he assignment of a management address is optional. )lso the management address is
or devices in the subnet, do not point them to this address as a
default gateway. 9emember that the appliance is in transparent mode, acting as a layer & device: it
is not acting as a router.
MAC Address Ta&!e and Learnin
he appliances will build a ()* address table of source ()* addresses associated with aninterface. !e can view the ()* address table with the s%o# )a"+address+ta&!e command:
ciscoasaG s%o# )a"+address+ta&!e Hlogical_if_name J "ount J stati"
!ithout any parameters, all the ()* addresses in the table are shown. !e can limit the
display to ()* addresses associated with a particular interface, to a count of the total addresses in
the table, or to listing
-
8/13/2019 CCSP ASA Transparent
5/12
must create an 'therype )*- +or )*-s/ and apply it to each interface we want to allow the non
IP traffic on.
he synta for creating an 'therype )*- is as follows:
ciscoasa+config/G accesslist )*-MIB ethertype Ndeny J permitO Nip J bpdu J mplsunicast J
mplsmulticast Jany J heMGMofMprotocolO Hlog
he ethertype parameter specifies that this is not an IP )*-. >ollowing the permit or deny
parameter, we specify the protocol that will be matched on. $ptionally we can specify aheadecimal number greater than or e4ual to 0600 for the protocol. >or eample, *P8IP uses a
protocol number of 00C00 and )pplealk uses 0C0b. $nce created 'therype )*-, we need to
apply it to an interface with the accessgroup command.
ciscoasa+config/G accessgroup )*-MIB in interface logicalMifMname
ARP Inspe"tion
@y default all )9P packets are allowed through the appliance. he source generates a
broadcast )9P 4uery to learn the IPto()* address association of the destination. )nd since the
appliance is learning the source ()* address of the re4uester, when the destination replies with an
)9P unicast response, this is allowed +the source ()* address is in the )9P table/, given that the
destination ()* address is found in the ()* address table and the packet is an )9P reply.he problem with the )9P protocol, however, is that it is very easy for an attacker to spoof
responses or to generate a gratuitous )9P announcement with incorrect IPto ()* address
information or by matching the attacker"s ()* address with someone else"s IP address.
o somewhat limit the effectiveness of )9P spoofing, *isco supports an )9P inspection
feature on the appliances when they are running in transparent mode. he )9P inspection feature
looks for mismatches between the IP address, ()* address, and the associated interface for )9P
replies. If the appliance sees the wrong combination of IPto()* address matching in an )9P
reply, or sees an )9P reply with a source of an incorrect interface, the appliance will drop the
packet.
ARP Inspe"tion Con$iuration
@y default the )9P inspection feature is disabled, which means that when the appliance sees
an )9P 4uery, it is flooded out the opposite interface. 'nabling )9P inspection is done with the
arpinspection command:
ciscoasa+config/G arpinspection logicalMifMname enable Hflood J noflood
)9P inspection is enabled on an interfacebyinterface basis. he flood parameter, which is
the default if omitted, will flood all )9Ps received on the interface. he noflood parameter will not
forward an )9P reply if it doesn"t match a specific static )9P entry on the appliance. herefore,
when using the noflood parameter,we need to create static entries for the associated interface with
the arp command:
ciscoasa+config/G arp logicalMifMname IPMaddress ()*MaddressIf we don"t configure this command and )9P flooding is disabled, devices will be unable
to communicate with each other via IP across the associated interface.
ARP Inspe"tion ,eri$i"ation
o see the status of )9P inspection and your configuration, use the show arpinspection
command. ?ere"s an eample:
ciscoasaG show arpinspection
If having issues with the )9P inspection feature, or feel that the appliance might be
dropping )9P re4uests and replies that it shouldn"t, we can use the de&u
arp+inspe"tioncommand to troubleshoot the problem.
he problem with )9P inspection on the appliance is that it will not stop )9P spoofingattacks occurring off the same interface, like a hacker impersonating a user"s ()* address, where
both devices are connected to the same switch, which is then connected to an interface on the
-
8/13/2019 CCSP ASA Transparent
6/12
appliance. )9P inspection will prevent )9P spoofing attacks between interfaces on the appliance.
TRANSPARENT FIRE-ALL EAMPLE CONFIG'RATION
?ere"s the )S) KK10 configuration:
myasaG s%o# $ire#a!!
>irewall mode: 9outer
myasa+config/G $ire#a!! transparentciscoasa+config/G s%o# $ire#a!!
>irewall mode: ransparent
ciscoasa+config/G inter$a"e e/0/
ciscoasa+configif/G no s%utdo#n
ciscoasa+configif/G e1it
ciscoasa+config/G inter$a"e e/0/./
ciscoasa+configsubif/G v!an /
"is"oasa3"on$i+su&i$45 na)ei$ outside
ciscoasa+configsubif/G se"urit*+!eve! /
ciscoasa+configsubif/G e1it
ciscoasa+config/G inter$a"e e/0/.2/ciscoasa+configsubif/G v!an 2/
ciscoasa+configsubif/G na)ei$ inside
ciscoasa+configsubif/G se"urit*+!eve! //
ciscoasa+configsubif/G e1it
ciscoasa+config/G ip address /./..267 266.266.266./
ciscoasa+config/G a""ess+!ist ACLoutside per)it i")p an* an*
ciscoasa+config/G a""ess+!ist ACLoutside per)it t"p an* an* e8 9/
ciscoasa+config/G a""ess+!ist ACLoutside per)it t"p an* an* e8 2
ciscoasa+config/G a""ess+!ist ACLoutside per)it t"p an* an* e8 26
ciscoasa+config/G a""ess+!ist ACLoutside per)it udp an* an* e8 67
ciscoasa+config/G a""ess+!ist ACLoutside den* ip an* an*
ciscoasa+config/G a""ess+roup ACLoutside in inter$a"e outside
In real life, I would be as specific as possible about what is and isn"t allowed from the users
to the campus network. In a campus situation is to primarily rely on *P with downloadable )*-s
to restrict users" access versus static )*- entries on the appliance: this gives us more fleibility and
scalability when implementing policies.
T:REAT (ETECTION
Basi" T%reat (ete"tion
he basic threat detection feature of the appliance was introduced in version C. !ith this featureenabled, the appliance monitors the dropped packet rate and security events and, if it sees a threat,
the appliance generates a log message with a log identifier number of #%0100. he kinds of security
events or dropped packet rates that the appliance monitors include
5 (atches on deny statements in )*-s.
5 (alformed packets +for eample, invalid IP header values or an incorrect header length/.
5 Packets that fail application layer inspection policies defined by the (odular Policy >ramework
+(P>/ or that inherit in the application inspection process itself. +>or eample, if a specified 9-
in a policy was seen, causing an ?P connection to be reset, or if a #i; command was eecuted on
an S(P8'S(P connection respectively./
5 Befined connection limits that have been eceeded, which includes global system values as well
as limits defined with (P> or the stati"8nat commands.5 Seeing unusual I*(P packets or connections.
5 'amining the combined rate of all securityrelated packet drops here in the list.
-
8/13/2019 CCSP ASA Transparent
7/12
5 )n interface became overloaded, causing packet drops.
5 ) scanning attack was detected.
5 )n incomplete connection was detected.
Basi" T%reat (ete"tion Con$iuration
Setting up basic threat detection is a simple process that involves one re4uired step: enabling
it. o enable basic threat detection, use the following command:ciscoasa+config/G t%reat+dete"tion &asi"+t%reat
@asic threat detection only affects the performance of the appliance when the appliance
detects dropped packets or a potential threat. he impact of basic threat detection in the appliance
is very minimal. $nce enabled, the appliance uses the default event thresholds given below
If a threat eists7 these can be seen on the appliance with the s%o# runnin+"on$i
a!! t%reat+dete"tion command. hese rates are used by the appliance to determine when a device is
considered a victim or attacker.
T%e averae event rateover a time interval, as well as a &urst event rateover as%orter
ti)e interva!. he &urst rate is 0
-
8/13/2019 CCSP ASA Transparent
8/12
ciscoasaG s%o# t%reat+dete"tion rate H)in+disp!a*+rate min_display_rate Ha"!+drop J &ad+
pa"=et+drop J "onn+!i)it+drop J dos+drop J $#+drop J i")p+drop J inspe"t+drop J
inter$a"e+drop J s"annin+t%reat J s*n+atta"=
he )in+disp!a*+rateparameter limits the displayed statistics to those that eceed
the one specified by this parameter +in events per second/. his value can range from
0 to &,12#,2C%,62# seconds.
?ere is an eample of the use of this command:ciscoasaG s%o# t%reat+dete"tion rate
)verage+eps/ *urrent+eps/ rigger otal events
10min )*- drop: 0 0 0 %%
1hour )*- drop: 0 0 0 1&&
1hour S3 attck: 6 0 % &2%1C
10min Scanning: 0 0 %1 &2%
1hour Scanning: 11K 0 1K %2C66#
1hour @ad pkts: C2 0 % &2#60
10min >irewall: 0 0 2 %2
1hour >irewall: C2 0 % &6211
10min BoS attck: 0 0 0 C1hour BoS attck: 0 0 0 22
10min Interface: 0 0 0 12
1hour Interface: & 0 0 %&1%%%
o clear the basic threat statistics, use the Privilege mode "!ear t%reat+dete"tion rate
command.
S"annin T%reat (ete"tion
Scanning threat detection was added in version C.0 of the appliances. his feature a!!o#s
t%e app!ian"e to dete"t s"annin atta"=s?wherean atta"=er is s"annin IP addresses o$ devi"es
or s"annin ports on a devi"e or )u!tip!e devi"es in a su&net. !e typical IPS or I(S "an easi!*
dete"t $ast s"an atta"=s &* "o)parin tra$$i"with its signature database.
Scanning signatures are basically templates that define the kinds of traffic and the thresholds
that have to be reached to indicate a scanning attack. (ore intelligent IPS8IBS solutions will use
heuristic analysis to better determine if a scanning attack is taking place, even those that are spread
out over a period.
he scanning threat detection feature of the appliances falls into the latter camp in its
approach to detecting scanning attacks. he appliance maintains a database in memory of host
statistics and the connections and devices sources are accessing to determine if a scan attack is
taking place. @asically the appliance is looking for connection anomalies that would indicate
scanning, like traffic from a source, without responding traffic from a destination+s/, or a source
accessing a port that is closed on a destination, using the same IPIB numbers in fragments that arepart of the same packet +the IPIB is the fragment identifier number/, and many other anomalies.
!hen a scan is detected, the appliance automaticallyenerates a !o )essae a&out
t%e s"an #it% a !o )essae I( o$ @7//7 !e can have the appliance block traffic from the
offender, which *isco "a!!s shunning. 'nabling scanning threat dete"tion on t%e app!ian"e will
a$$e"t its CP' and )e)or* usae? asthe app!ian"e )ust &ui!d a data&ase o$ devi"es and their
connection characteristics, and then compare connections with the database
o ensure that the scanning threat detection feature doesn"t overwhelm the appliance and
cause the appliance to inadvertently drop legitimate packets.
S"annin T%reat (ete"tion Con$iuration
Scanning threat detection is disa&!ed &* de$au!t on t%e se"urit* app!ian"es. o enable it, use thefollowing command:
-
8/13/2019 CCSP ASA Transparent
9/12
ciscoasa+config/G t%reat+dete"tion s"annin+t%reat Hs%un He1"ept Nip+addressIP_address
subnet_mask J o&e"t+roup network_object_group_IDO
he s%un keyword will automatically drop traffic$ro) t%e s"annin atta"=er. he e1"ept
parameter a!!o#s to )a=e e1"eptions to t%e s%unnin pro"ess, where we can make eceptions
for an address or range of addresses or a group of addresses defined in a network obor host statistics, the statistics are accumulated
for as long as the device is active and currently in the scanning threat database. If the device is
inactive for more than 10 minutes, it is removed from the database and its statistics are cleared. If
port statistics are enabled, statistics are gathered on *P and BP protocols. $ther IP protocol
statistics can be gathered by enabling the proto"o!parameter.
If we enable threat statistics, the performance of the appliance can suffer. Port statisticshave the least impact on the appliance, and host statistics the most impact.
-
8/13/2019 CCSP ASA Transparent
10/12
T%reat Statisti"s ,eri$i"ation
$nce threat statistics are enabled, we can view them with the s%o# t%reat+dete"tion
statisti"s command.
IP A'(IT
he appliances have supported IPS capabilities for a long time. he original IPS
implementation on the appliances was software based, which was originally designed for S$?$networks. It supports over K0 signatures to detect attacks. he software implementation doesn"t
even begin to compare to the capabilities of the )S) )IPSS( IPS module, which can detect over
1,K00 attacks. ?owever, if you don"t have this card, we can supplement the security of your
appliance with the IPS software feature, commonly calledIP audit!
IP Audit Con$iuration
@y default IP audit is disabled on the appliances. o enable it, use the following
configuration:
ciscoasa+config/G ip audit na)e >audit_policy_name >in$o Ha"tion Ha!ar) Hdrop Hreset
ciscoasa+config/G ip audit na)e >audit_policy_name >atta"= Ha"tion Ha!ar) Hdrop Hresetciscoasa+config/G ip audit inter$a"e >logical_if_name>"audit_policy_name>
he ip audit na)e command specifies which of the two signature categories we will be
enabling. he policy that we have created must then be enabled on a logical interface. If we want to
enable both informational and attack signatures for an interface, we use the same policy name when
enabling them. !e can have the appliance generate an alarm, drop the offending packet, and8or reset
the connection +if it is using *P/. If we don"t specify an action when there is a match on the
signature, it defaults to a!ar). he ip audit inter$a"e command enables the named policy on an
interface in the inbounddirection.
3ou can disable a signature with the following command:
ciscoasa+config/G ip audit sinaturesignature_number disa&!e
3ou might want to disable a signature when legitimate traffic matches the signature in most
situations, creating false alarms7 however, disabling the signature is performed at a global level,
meaning that no traffic will trigger the signature +even bad traffic/ when it is disabled.
IP Audit Sinatures
IP audit signatures fall under two categories: informational and attack. Informational
signatures look for connections, which could be normal traffic7 attack signatures look for network
attacks.
-
8/13/2019 CCSP ASA Transparent
11/12
-
8/13/2019 CCSP ASA Transparent
12/12