Ik ben belast met het voorkomen dat interne gebruikers de Anyconnect-client activeren en gebruiken terwijl ze op ons interne netwerk zijn.
Wat is de beste aanpak hiervoor?
ACL toegepast op de inside-interface inbound?
Een ACL toewijzen aan een split tunnel-configuratie?
Iets anders?
Alvast bedankt voor alle hulp.
Allereerst wil ik jullie allemaal bedanken voor jullie reacties.
Een beetje meer informatie:
Ik heb net toegang gekregen tot de ASA
Er is geen NAT betrokken. Dit agentschap gebruikt openbare IP’s.
Op de ASA is de inside-interface uitgeschakeld.
Het Anyconnect-verkeer is betrouwbaar.
Het netwerk dat intern geweigerd moet worden, is een /16
Dit gebruikt split tunneling. Ik dacht dat ik de tunnelexclude-beleid kon gebruiken om te weigeren, maar dat werkt niet. Andere ideeën? De Anyconnect werkt prima; het enige wat dit agentschap wil, is voorkomen dat interne gebruikers dat /16 gebruiken.
– In je eigen netwerk inbellen vanuit de LAN
– Inbellen op het VPN van een ander bedrijf
Als we het hebben over de eerste, kun je dit niet doen met een ACL.
Een ACL filtert alleen door de firewall, niet het verkeer naar de firewall.
Ik zou denken aan een lokale DNS-pointer die de VPN-URL naar een blackhole resolveert vanaf de LAN.
Hoe doe je de authenticatie? Wij regelen dit op onze RADIUS-server (Clearpass) voor bepaalde connectieconfiguraties. RADIUS krijgt alle benodigde info om het te doen (naam connectieprofiel, IP van de gebruiker), maar je RADIUS-server moet goed en flexibel genoeg zijn om het te doen.
Je kunt ook een ACL op de inbound-interface toepassen, maar dat zou gelden voor alle verbindingen/groepen/gebruikers/etc…
Voor ons is de beveiligingsfirewall het hart van het netwerk. Om toegang te krijgen tot de enige VPN-geschakelde interface op de ASA, moet je erdoorheen gaan en wij blokkeren dat verkeer.
Als de interne gebruikers via dezelfde ASA internet opgaan als ze op jou VPN inbellen, zou je Anyconnect op de inside-interface moeten uitschakelen. Het is gewoon een eenvoudige instelling.
Is dit ‘nieuw’ op je gelinkte document, het wordt vermeld onder 9.18.3.
Ik was begin 2023 met Cisco aan het controleren op zoiets om VPN’s uit verschillende landen te blokkeren en werd gezegd ‘sorry, geen manier om dat te doen’.
Het is niet nieuw, je kon al enige tijd ACLs toepassen op het controlevlak. Maar je krijgt alleen uitgebreide ACLs, je kunt het niet via de Firepower-engine laten gaan voor geolocatie. Dus er is nog steeds geen manier om verschillende landen te blokkeren zoals je zei. Je zou het via IP moeten doen, wat nogal raar is.
aan elk van mijn deployments.