Office VPN security

[paradoXical]

Dag Tweakers! Mijn laatste topic is al even geleden, maar ik zit met een vraag, en ik ben erg benieuwd naar de mening van mede tweakers.

Momenteel is het mogelijk een vpn tunnel naar ons kantoor op ter zetten met OpenVPN. Alle thuis ip's van medewerkers staan whitelisted in onze firewall, dus zonder betreffende whitelist is inloggen niet mogelijk.

Nu draaien we binnen ons kantoor verschillende diensten (denk aan SVN, fileserver, password server en dat soort zaken). Nu het probleem dat een aantal externe medewerkers graag een VPN tunnel naar ons kantoor willen opzetten, maar dit lukt in veel gevallen niet i.v.m. een dynamisch IP. Ik moet dan weer het IP adres updaten en het werkt weer. Nu is er het idee ontstaan om VPN wereldwijd open te zetten, zodat iedereen van waar ook ter wereld in kan bellen.

Ik heb aangegeven dit een erg slecht idee te vinden, aangezien ik zelf erg voorstander ben van access restricties. Natuurlijk is een IP adres gemakkelijk te spoofen, maar alleen al het stoppen van ip/port scans vind ik de moeite waard. Als argument krijg ik te horen dan een wereldwijd benaderbare VPN common practice is bij veel grote bedrijven, en dat de standaard die wij hanteren erg overdreven is. Maar is dit wel zo? Wat zijn jullie ervaringen?

[Rolfie]

Gewoon zorgen dat de VPN server altijd up to date is.
Goede authenticatie gebruiken op de VPN.

Daarna totaal geen probleem meer. Ik zou het zelfs niet eens zo willen zoals jij je hem nu geconfigureerd hebt. Niet te beheren.

Gewoon openzetten en zorgen voor juiste authenticatie in je VPN.

Persoonlijk vind ik je huidige configuratie een slecht idee.

[MAX3400]

DirectAccess inzetten? MFA (soft- of hardtoken)? Radius?

Er zijn meerdere wegen die naar Rome leiden; ik lees vooralsnog geen requirement voor je huidige oplossing.

[True]

Iedereen z'n eigen VPN login geven?
2FA implementeren op VPN?
IDS/IPS/Firewall voor verkeerd pogingen tot inloggen?
Publieke blacklists gebruiken?

Het idee van VPN is dat iedereen met toegang(authentication) in mag en kan loggen. Want dan heb je je Virtual Private Network, immers als je inlogt vanaf een vertrouwde locatie is er ook geen echte reden voor een VPN

Je wilt eigenlijk VPN inperken om redenen dat het er juist is.

[The Realone]

Met Rolfie eens, dit is totaal niet praktisch en dat merk je nu zelf ook. Ik ken zelf geen klanten bij ons die een dergelijke opzet hebben.

Zorg voor een fatsoenlijke remote access VPN oplossing met MFA en je hoeft je niet druk te maken.

[eric.1]

IP restrictie is opzich niet nodig indien er voldoende andere maatregelen zijn genomen.

- 2FA (bijv een token) is (nagenoeg) een vereiste.
- sterke wachtwoorden gebruiken
- (poging tot) misbruik detecteren en actie op ondernemen; bijv 3x onjuist wachtwoord = blocked account (en token als je wilt )
- software up to date houden en uiteraard goed configureren
- gebruik persoonlijke accounts
- logging

Wat ik ook nog wel eens ben tegen gekomen zijn Stepping Stone servers, de enige server die vanaf de vpn-verbinding te bereiken is. Vanuit die server kan je dan verder je netwerk in. Dit kan een extra beveiligingslaag zijn indien goed ingesteld en gecontroleerd.

Maarja...uiteindelijk ligt het aan wat je als bedrijf wilt / wat voor eisen gesteld worden.

[FreakNL]

IPs whitelisten? Lijkt mij een brakke oplossing. Wat als ik in een hotel wil werken. Of bij mij ouders.

Je doet nu iets wat niet eens veilig is. Zorg ervoor dat je andere lagen op orde zijn en dit soort rare dingen kun je mee stoppen.

[johnkeates]

Zorg dat er altijd certificaten per use + credentials per user nodig zijn (al dan niet met OTP / 2FA), dan zit je goed.

Op het moment hoeft iemand alleen maar op de juiste verbinding te zitten en dan kan je verbinden, het is net wat moeilijker als je ook TLS certificaten nodig hebt om uberhaupt packets te kunnen decoderen, en certificaten + credentials nodig hebt om je identiteit te bewijzen. Dit kan allemaal vrij makkelijk in een package aan een legitieme gebruiker gegeven worden, doe hoeft dan alleen nog z'n username+password (of token) in te voeren bij verbinden. Dit geeft je ook controle om verbindingen per gebruiker te screenen zonder iets met het account te hoeven doen wat je AAA iets flexibeler maakt.

[paradoXical]

Bedankt voor jullie commentaar. Om nu in te loggen is een certificaat + een uniek user/password al noodzakelijk. Logging is ook aanwezig, maar logging is wat mij betreft mosterd na de maaltijd. Ik zie zelf 2fa wel zitten, ik ga naar de mogelijkheden kijken.

Wij hebben overigens ~10 accounts, en 2 externe accounts. We praten hier niet over honderden users.

Ik werk zelf altijd met ip whitelisting. Alle linux machines welke ik beheer zijn enkel benaderbaar vanuit mijn huis (IP). Ik ben wellicht wat panish hierin, maar na het zien van alle scans op vps's ben ik hier jaren geleden op over gegaan.

[johnkeates]

paradoXical schreef op vrijdag 21 april 2017 @ 21:11:
Bedankt voor jullie commentaar. Om nu in te loggen is een certificaat + een uniek user/password al noodzakelijk. Logging is ook aanwezig, maar logging is wat mij betreft mosterd na de maaltijd. Ik zie zelf 2fa wel zitten, ik ga naar de mogelijkheden kijken.

Wij hebben overigens ~10 accounts, en 2 externe accounts. We praten hier niet over honderden users.

Ik werk zelf altijd met ip whitelisting. Alle linux machines welke ik beheer zijn enkel benaderbaar vanuit mijn huis (IP). Ik ben wellicht wat panish hierin, maar na het zien van alle scans op vps's ben ik hier jaren geleden op over gegaan.

Whitelisting is een wassen neus, en in de praktijk werkt het vooral tegen. Zet gewoon een goede firewall neer, en doe desnoods origin blocking als je bijvoorbeeld geen verkeer uit rusland, china, vietnam, oekraine enz. verwacht. Daarnaast kan je ook beter een IDS/IPS in je netwerk opnemen, Suricata, Bro en SNORT hebben prima standaard profielen om scans en bruteforces te filteren.

Stel dat jouw ISP besluit je IP te veranderen, hoe ga je dat dan rechtbreien terwijl een klant ondertussen iets nodig heeft wat je dan niet kan regelen om dat er niet bij je systemen kan? Wat als je overreden wordt? Wat als je op vakantie bent en 'eventjes op afstand' wat moet doen.

Port knocking en jumpboxen zijn ook geen oplossing, net als een proxyserver niet helpt. VPN en SSH zijn de juiste paden om te bewandelen, en goede gelaagde beveiliging is the manier om het spul te beschermen.

[Blommie01]

Voeg gewoon Google Authenticator toe aan je vpn server. Aangezien je maar een paar accounts hoeft te beheren lijkt me dit de simpelste oplossing. Binnen 5 minuten geregeld

Ik vind ook dat het whitelisten van IP adressen het hele idee van vpn onderuit haalt..

Zorg er voor dat je server up to date is en gebruik desnoods de NL versie van OpenVPN.

[Verwijderd]

De moderne trend is om security te verplaatsen naar de hogere lagen van het OSI model. Een voorbeeld daarvan is sterkte authenticatie. Zeker in een mobiele en dynamische wereld is het whitelisten van ip adressen ouderwets en niet praktisch.

[Thralas]

paradoXical schreef op vrijdag 21 april 2017 @ 21:11:
Ik werk zelf altijd met ip whitelisting. Alle linux machines welke ik beheer zijn enkel benaderbaar vanuit mijn huis (IP). Ik ben wellicht wat panish hierin, maar na het zien van alle scans op vps's ben ik hier jaren geleden op over gegaan.

Opzich geen verkeerde gedachtengang, maar (zoals reeds benoemd) enigzins tegenstrijdig bij een VPN-server.

Realiseer je bovendien dat OpenVPN by design al (praktisch) niet vatbaar is voor brute force attacks, dus zolang de software correct functioneert maakt het weinig uit of de hele wereld erbij mag.

Als OpenSSL weer eens grandioos stuk blijkt (Heartbleed!) dan heb je wel een probleem, maar daar is ook een handige oplossing voor die je zou moeten gebruiken: tls-auth.

[CyBeR]

paradoXical schreef op vrijdag 21 april 2017 @ 18:57:
Natuurlijk is een IP adres gemakkelijk te spoofen

Dat is alvast niet zo, maar dat staat hier los van.

Als argument krijg ik te horen dan een wereldwijd benaderbare VPN common practice is bij veel grote bedrijven, en dat de standaard die wij hanteren erg overdreven is. Maar is dit wel zo? Wat zijn jullie ervaringen?

Helemaal mee eens: je overdrijft sterk. Het hele idee van een VPN is een veilige manier geven om vanuit willekeurige plekken toegang te krijgen tot een ander netwerk. Jij beperkt nu juist je collega's in het veilig gebruik van netwerkdiensten door VPN's niet toe te staan op willekeurige plekken.

De zwakste plek in een VPN-dienst is, imo, de combinatie gebruikersnaam en wachtwoord. Dat is eigenlijk het enige wat, bij een goed opgezette VPN, in enige mate te kraken is. Dat heb jij al afgedekt zeg je, want je gebruikt certificaten en zolang jullie zorgen dat de private keys daarvan secure blijven is dat nagenoeg onkraakbaar.

Dus: open zetten die zooi.

[Wim-Bart]

Gewoon een goede oplossing neerzetten met 2Factor authentication. En je twee of zelfs 3 factoren goed bepalen. Daarnaast in je VPN policies gewoon aangeven dat virus scanner maximaal 2 weken oude definities mag hebben, dat tijdens een VPN sessie alleen Internet verkeer mogelijk is via de Interne bedrijfs proxy/firewall/wasstraat. Maar dan zit je wel aan een wat duurdere oplossing zoals een Citrix netscaler of iets dergelijks.

[Blommie01]

Thralas schreef op zaterdag 22 april 2017 @ 02:09:
[...]

Als OpenSSL weer eens grandioos stuk blijkt (Heartbleed!) dan heb je wel een probleem, maar daar is ook een handige oplossing voor die je zou moeten gebruiken: tls-auth.

Dat is te voorkomen door bijvoorbeeld gebruik te maken van mbed TLS. Als die stuk ook blijkt heb je natuurlijk wel hetzelfde probleem.

[_root]

Thralas schreef op zaterdag 22 april 2017 @ 02:09:
[...]
Als OpenSSL weer eens grandioos stuk blijkt (Heartbleed!) dan heb je wel een probleem, maar daar is ook een handige oplossing voor die je zou moeten gebruiken: tls-auth.

In NL versie van Openvpn is openssl vervangen door Polarssl en heeft dus geen last gehad van Heartbleed.

Maar het het gebruik van certificaten icm username en pwd en uiteraard up-to-date software en een CRL ben je redelijk veilig.

[Blommie01]

_root schreef op zaterdag 22 april 2017 @ 08:04:
[...]


In NL versie van Openvpn is openssl vervangen door Polarssl en heeft dus geen last gehad van Heartbleed.

Maar het het gebruik van certificaten icm username en pwd en uiteraard up-to-date software en een CRL ben je redelijk veilig.

Daar doelde ik ook op in mijn reactie.. PolarSSL heet tegenwoordig mbed TLS.

https://tls.mbed.org

[ Voor 3% gewijzigd door Blommie01 op 22-04-2017 08:25 ]

[mcDavid]

paradoXical schreef op vrijdag 21 april 2017 @ 21:11:
Bedankt voor jullie commentaar. Om nu in te loggen is een certificaat + een uniek user/password al noodzakelijk. Logging is ook aanwezig, maar logging is wat mij betreft mosterd na de maaltijd. Ik zie zelf 2fa wel zitten, ik ga naar de mogelijkheden kijken.

Certificaat (something you have) + password (something you know) ís al 2fa. Maar je kunt natuurlijk altijd overwegen meer factoren toe te voegen.

[Thralas]

_root schreef op zaterdag 22 april 2017 @ 08:04:
In NL versie van Openvpn is openssl vervangen door Polarssl en heeft dus geen last gehad van Heartbleed.

Het was slechts een voorbeeld om aan te tonen dat je absoluut tls-auth wilt gebruiken. PolarSSL/mbed TLS heeft z'n eigen lijst zorgelijke issues [1] [2], dus daarvoor geldt hetzelfde.

mcDavid schreef op zaterdag 22 april 2017 @ 09:02:
Certificaat (something you have) + password (something you know) ís al 2fa. Maar je kunt natuurlijk altijd overwegen meer factoren toe te voegen.

Een typisch OpenVPN-certificaat is een zeer zwakke 'something you have' omdat deze triviaal te dupliceren is als je 'm niet in een smartcard stopt. Daarnaast kan iemand die het certificaat weet te bemachtigen het wachtwoord ook relatief eenvouding buitmaken.

Een echt 2FA-middel voegt een (fysiek) device toe, met one time use tokens. Dus een Yubikey of OTP-app.