ASA

Threat detection, remote access
För att skydda från botar och intrångsförsök kan man använda sig av threat protection. Threat protection placerar IP-adresser i en shun-lista vid för många inloggningsförsök och/eller för många initationer av klient-tunnel. 

 Det kräver att man är på rätt ASA-kod: 

 9.16 version train -> supported from 9.16(4)67 and newer versions within this specific train.

 9.18 version train -> supported from 9.18(4)40 and newer versions within this specific train.

 9.20 version train -> supported from 9.20(3) and newer versions within this specific train.

 9.22 version train -> supported from 9.22(1.1) and any newer versions. 

 Konf: 

 threat-detection service invalid-vpn-access

threat-detection service remote-access-authentication hold-down 10 threshold 20

threat-detection service remote-access-client-initiations hold-down 10 threshold 30 

 Validering: 

 show threat-detection service

show threat-detection service entries 

show threat-detection service remote-access-authentication entries

show shun x

no shun x = ta bort shun för viss IP

clear shun = ta bort shun för samtliga 

 Om man har PAT på vägen till en vpn-ASA kan det bli problem. Det går inte att rensa en specifik entry som är i recording, det går att rensa samtliga men inte specifik. Jag har ful-löst det här med ett EEM skript som rensar shun-listan var femte sekund: 

 event manager applet Clear_Shun_PATIP

 description Clear PAT IP every 5 seconds

 event timer watchdog time 5

 event none

 action 1 cli command "no shun 1.3.3.7"

 output none

 

 Man kan också vilja rensa hela shun-listan varje vecka, då den ej rensas automatiskt. 

 event manager applet Clear_Shun_Weekly

 description Clear shunned IPs every 7 days

 event none

 event timer watchdog time 604800

 action 1 cli command "clear shun"

 output none

Placering av ASA bakom annat brandväggskluster
Om man fortfarande kör ASA för exempelvis VPN S2S eller VPN RA så kan det vara bra att placera ASAn bakom ett mer modernt brandväggskluster för att nyttja säkerhetsfunktioner.  

 En sak man ska ta med sig är att för S2S bör brandväggen fortsatt ha de publika IPv4 adresserna på interfacet, ej använda NAT för att komma åt Internet. Detta då brandväggen injicerar information i IKE-meddelandena gällande vilken IP som finns på utgående interface. Om andra sidan matchar på publika IPn kommer då uppsättningen att misslyckas. Se debug-loggar  från en Cisco 4k ISR nedan där den förväntade sig en publik IPv4 adress: 

   

 Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Process auth response notify

Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Searching policy based on peer's identity '172.31.52.4' of type 'IPv4 address'

Aug 15 08:39:08: IKEv2-ERROR:(SESSION ID = 1,SA ID = 1):: Failed to locate an item in the database

Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Verification of peer's authentication data FAILED

Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Auth exchange failed

Aug 15 08:39:08: IKEv2-ERROR:(SESSION ID = 1,SA ID = 1):: Auth exchange failed

Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Abort exchange

Aug 15 08:39:08: IKEv2:(SESSION ID = 1,SA ID = 1):Deleting SA

Aug 15 08:39:11: IPSEC(crypto_ipsec_received_invalid_spi): SPI present in Transient Tree, not sending INVSPI KMI to IKE

Aug 15 08:39:19: IKEv2-ERROR:Address type 2147516258 not supported

 

  

vpn load-balancing, klient VPN
Har man flera ASA-brandväggar kan man använda sig av en teknik som heter vpn load-balancing. Det gör att man kan använda sig av samtliga burkar istället för att köra active/standby. Se exempelkonf nedan. 

 vpn load-balancing 

 redirect-fqdn enable

 priority 3

 interface lbpublic Outside

 interface lbprivate Inside

 cluster key password

 cluster ip address 1.1.1.1

 cluster encryption

 participate 

 Vill man ta ur en medlem ur klustret kan man slå no participate i läget ovan. 

 Verifiering sker med show vpn load-balancing .