Hoi allemaal,
Niet echt een netwerkbeheerder, maar ik heb gemerkt dat er veel brute force SSL VPN login pogingen zijn met generieke gebruikersnamen zoals support, admin, HR, enz…
De bron-IP’s verschillen allemaal, dus ik kan niets effectief blokkeren.
Wat is de beste aanpak hiervoor?
We hadden ditzelfde probleem een paar weken geleden, maar ze probeerden het tegen onze clientless VPN. Gelukkig heeft alles op onze CVPN nu zijn eigen webinterface, dus we hadden er geen behoefte meer aan en hebben het gewoon uitgeschakeld. Onze cliënt vereist een e-mailadres, dus je kunt niet eens een poging doen met alleen een gebruikersnaam.
Ik heb een supportticket geopend en kreeg te horen dat ze niet konden vertellen hoe ze de logins probeerden te genereren, maar dat de firewall ze blokkeerde zoals ontworpen omdat ze niet in de toegestane lijst stonden.
Ik weet niet of jouw VPN wereldwijd toegankelijk hoeft te zijn. Als dat niet zo is, zou je de regio-optie kunnen overwegen om in ieder geval het gebied waar de pogingen vandaan komen te beperken.
Mijn werk heeft deze aanval ook gezien op meer dan 500 client-firewalls. Het is irritant dat Palo dit niet detecteert en de IP’s toevoegt aan hun IP-bloklijst, aangezien voor onze FWs dezelfde bron-IP’s worden gebruikt.
Het standaard Threat Prevention-profiel werkt alleen voor brute force-aanvallen met GP als een IP 10 mislukte inlogpogingen binnen 60 seconden.
Probeer MFA te gebruiken als je Azure AD hebt, dat is gratis met Microsoft Authenticator.
Welk probleem probeer je op te lossen? Wil je brute force-aanvallen voorkomen, voorkomen dat logs vollopen met deze gebeurtenissen, of iets anders?
Zonder te weten welk probleem je probeert op te lossen, hier enkele opties om te overwegen:
Laten we gokken… Dit zijn de generieke gebruikersnamen die in de aanval worden gebruikt:
‘helpdesk’
‘admin’
‘gebruiker’
‘gebruiker3’
‘mail’
‘ssl’
‘vpn’
‘gast’
‘testgebruiker’
‘administrator’
‘privé’
‘scan’
‘named’
‘us2010’
‘video’
‘us2003’
‘emerson’
‘us2009’
‘us2011’
‘us2004’
‘vpntianyan’
‘scan’
‘mysqladmin’
‘maec staff’
‘station’
‘mediaro’
‘receptie’
‘water’
‘ST2’
‘paklets’
‘Brenden’
‘ST3’
‘informatie’
‘dienst’
‘xerox’
‘metaadmin’
‘backups’
‘dienst’
‘sT4’
‘gebruiker1’
‘informatie’
‘personeel’
‘eigenaar’
‘op afstand’
‘Michael’
‘postgreSQL’
‘design3’
‘xerox’
‘test1’
‘gpvpn’
Dat is wat ik in ieder geval heb gezien.
Er is een mogelijkheid om een dynamisch object te maken dat wordt gevuld door een interne service die de gebruikersnaam/IP observeert en als het overeenkomt met een van deze vermeldingen, het IP-adres invoegt, waardoor de toegang tot je gehele netwerk wordt geblokkeerd.
Geo-gebaseerde en ASN-filtering helpen enorm als je AWS, AZURE, GCP, AliYun enzovoort ASN-nummers kunt identificeren.
In een Palo Alto zouden er twee plekken moeten zijn met blokkades. Je zou onderaan een blokkade moeten hebben en een paar regels bovenin. De strengste blokkades moeten aan de bovenkant staan. Als je me een privébericht stuurt, kan ik je een generieke screenshot sturen. Dit zal de meeste aanvallen verwijderen. Een andere goede tip is het implementeren van AIOps (gratis) en dat te gebruiken om compliant te blijven.
Schakel de webportal uit als je dat kunt, ik deed dat en het probleem verdween. Wij installeren de client toch al vooraf, dus we hoeven het niet open te laten staan.
Elke login prompt krijgt dit soort automatische aanvallen. Sommige mensen noemen het internet-radiatie - het hoort erbij om een service open te stellen voor de wereld op internet.
Ik heb dit gezien op GlobalProtect dat geen client-certificaat vereist.
Ik heb altijd GP geconfigureerd met gebruikersnaam/wachtwoord en certificaat, en soms met OTP als derde factor.
Het client-certificaat opvragen voorkomt deze brute force-authenticatie, omdat het eerste wat de portal doet, het vragen om een client-certificaat is. Scripts die brute force proberen, kunnen dat niet bieden en bereiken daardoor niet de loginpagina.
Je kunt machinecertificaat gebruiken als bedrijfsapparaat, of gebruikerscertificaat zoals Windows Hello for Business. Zorg er gewoon voor dat de sub-CA die het ondertekent uit je eigen PKI komt.
Je zult nog steeds enkele authenticatiefouten zien in GP-logs bij de pre-login op certificaat, maar je geeft er niet om, je hebt geen hoge poging-rate voor gebruikersnamen en wachtwoorden. Mijn eigen Palo@home is zo ingesteld. Bijna geen authenticatiepogingen, aangezien de scanner niet weet wat deze pagina is omdat er om een certificaat wordt gevraagd in het eerste contact, en gaat daarom niet verder. Mijn grootste klant heeft dezelfde configuratie en wij krijgen meldingen bij dergelijke pogingen, maar in 2 jaar was de enige poging die een alert veroorzaakte… ik, tijdens het testen. Let wel, deze certificaatfout gebeurt alleen als de aanvaller een GP-client gebruikt of als je de clientloze portal hebt ingeschakeld. Wanneer het een webscanner is, helpt het als je de landingspagina/welkomstpagina uitschakelt.
Bovendien is het hebben van deze controle een best practice, je weet zeker dat het een bedrijfsapparaat is, dat het een bekende gebruiker is. Je kunt een apparaat intrekken door het certificaat daarvan in je PKI in te trekken bijvoorbeeld, of een gebruiker uitschakelen in AD. Het maakt je configuratie twee-factorauthenticatie.
Om deze lijst van blokkades nog verder te versterken, voeg je er een jerk-lijst aan toe. Ban hun /24 en ga door.
Ja, precies. Ik wou dat ik die gebruikersnamen op een of andere manier kon blokkeren.
Scriptkids hard aan het werk.
Onze cyberbeveiligingsverzekering vereiste dat we de loginprompt op de webportal op WAN uitschakelden. Ik zei OK. Ik heb een andere portal gemaakt die op een interne interface staat zodat ik de nieuwe GlobalProtect-clients kan testen en upgraden. Geen probleem.