ccsp asa transparent

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.


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


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:


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


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


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.


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/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:


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.


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.


11/12


12/12

ccsp asa transparent

Documents