Hoe onveilig is pptp

[Gilles]

Hoi,

Ik heb intussen al bij twee kleine bedrijfjes een poptop configuratie draaien. Deze draait wel achter een dusdanige firewall configuratie dat alleen "trusted people" via ip blocking de poptop server kunnen benaderen.

Ik hoor echter constant enge verhalen over hoe gigantisch onveilig het pptp protocol is en vraag me af hoe gevaarlijk dat is in mijn geval. Ik draai het met 128 bits mppe encryptie en chap v2 voor authentication.

[Arno]

poptop

[blackd]

Traag schreef op 06 September 2003 @ 20:51:
poptop

http://www.poptop.org/

[PtrO]

PPTP ansich is veilig genoeg wanneer eenmaal de verbinding actief is.
PPTP biedt overigens geen beveiliging tegen data-manipulatie van MIM (Man In the Middle).
Hiervoor zul je IPsec moeten overwegen met liefst AH encryptie (wat meeste NAT routers niet leuk vinden). Hieraan voeg je de nodige source/target firewall settings en gebruik je evt. smartcard danwel SecurId om de VPN/IKE challenge keys uit te geven.

Het probleem met PPTP zit 'm in de (on)veiligheid van de wachtwoorden uitwisseling.
Afhankelijk van besturingssysteem & methode zal het wachtwoord zelfs leesbaar zijn of middels een simpele Hash-CRC waarde worden doorgegeven.
Deze hashwaarde kan je evt. gebruiken om via dictionaries terug te rekenen naar het oorspronkelijke wachtwoord. Deze data kan je natuurlijk aftappen (Etherpeek oid) en vandaar uit verder werken.

[ Voor 3% gewijzigd door PtrO op 06-09-2003 21:28 ]

[Gilles]

Die password check wordt alleen gedaan via Chap v2, ik kan me niet voorstellen dat dat plaintext is.

[PtrO]

Passwords op zich worden met CHAP niet in plain text uitgewisseld. Er worden zgn. password-hashes gebruikt om te authenticeren en vanuit de password hashes worden de veranderlijke sessies-keys berekend. Als zodanig het het niveau van beveiliging (in)direct afhankelijk van het gebruikte password (en de lengte daarvan).

De gebruikte challenge keys voor de sessie-pakketjes zijn voor een MIM met enige moeite voorspelbaar en naar mijn weten zelfs te achterhalen vanuit de de pakketten nodig voor de PPTP besturing (wat dus niet encrypted is en gewoon plaintext leesbaar !!).

Technisch gezien is er een andere 'zwakheid' zoals Microsoft PPTP Chap 2.0 heeft geïmplementeerd. MS hanteert voor zowel de client als voor de server data channels de zelfde (RC4) sleutels.

Al met al is PPTP (ook subprotocol mppe) onveilig voor risico gebruik maar echt ruim voldoende als beveiliging voor het kleinbedrijf laat staan particulieren. Voor gevoeliger is er dus L2TP of IPSec danwel een eigen mechaniek.

Echter onthoudt wel dat je ook de dingen kunt overdrijven. IPSec gebruiken voor het Kazaa verbindinkje met een maatje omdat het zo stoer is, is natuurlijk waanzin. Net als je geen 1024-bit PGP zult gebruiken voor je inhoudsloze mailtjes.

Bedenk wel, beveiliging kost wat en naar mate de beveiliging ingewikkelder is, zal het ( en zeker voor jou) lastiger zijn te boordelen of die beveiliging werkelijk goed is.

Heb zelf een aantal voorbeelden meegemaakt dat m'n dacht dat er dus zware encryptie gebruikt werd en zich dus voldoende veilig waande wat beslist niet het geval was. Immers beveiliging staat niet op zichzelf maar houdt verband met de cultuur, procedures, classificatie etc.etc.

[sniper20]

Ik las een tijdje terug in C'T dat PPTP nog veilig genoeg is mits je ingewikkelde lange wachtwoorden gebruikt. Wel is het zo dat Windows 2000 PPTP beter is dan die van NT4.
Als je dan ook op de firewall ook nog filtert op Ip-adressen moet het veilig genoeg zijn.

[blackd]

sniper20 schreef op 07 September 2003 @ 12:37:
Ik las een tijdje terug in C'T dat PPTP nog veilig genoeg is mits je ingewikkelde lange wachtwoorden gebruikt.

En de sterkte van je wachtwoorden kun je meestal wel afdwingen met een password policy, dus dat is het probleem niet zo lijkt me.

[Verwijderd]

PtrO schreef op 07 September 2003 @ 00:53:
Al met al is PPTP (ook subprotocol mppe) onveilig voor risico gebruik maar echt ruim voldoende als beveiliging voor het kleinbedrijf laat staan particulieren. Voor gevoeliger is er dus L2TP ofEN IPSec danwel een eigen mechaniek.

L2TP is unencrypted...

[ Voor 5% gewijzigd door Verwijderd op 08-09-2003 10:04 ]

[PtrO]

Verwijderd schreef op 08 September 2003 @ 10:04:
[...]
L2TP is unencrypted...

U heeft geheel gelijk. L2TP en IPsec gaan hand in hand.

[Verwijderd]

PtrO schreef op 08 September 2003 @ 14:16:
[...]


U heeft geheel gelijk. L2TP en IPsec gaan hand in hand.

Jaja je hebt er altijd betweters tussen he

[Verwijderd]

redelijk essentieel is dat wel... ik ging er ook wel van uit dat ptro dat wist maar misschien anderen niet...

[mutsje]

Verwijderd schreef op 08 September 2003 @ 14:21:
[...]


Jaja je hebt er altijd betweters tussen he

De meeste in GOT zullen denken dat L2TP encrypted is.. maar helaas gaat dit niet zonder IPSec.
Lastige is met IPSec dat het niet graag wil Natten(schijnt mogelijk te zijn maar heb nog nooit een werkende situatie gezien).

Zoals Potr al aangeeft is PPTP meestal al afdoende en heeft het hoofdzakelijk met de cultuur te maken.

[Taigu]

IPsec en NAT is tegenwoordig geen probleem meer. Drayteks, Speedtouches (oudere) e.d. ondersteunen dir prima!

[PtrO]

IPsec kan op verschillende wijze geimplementeerd worden bijv als AH of ESP in zowel Tunnel of Transport mode. Elke heeft z'n erites waarin ik niet te veel on in zal gaan.

Ben het op zich niet helemaal eens, dat IPSec geen probleem meer is noor NAT routers.

Beetje droge kost maar lees verder wanneer je wat meer wilt weten. Ik heb het wat practisch gehouden.

De moeilijkste voor NAT is wanneer IPSec bedreven wordt met AH (Authenticatie-Header). In dit geval zal een 'domme' NAT-router de adres-headers (proberen te ?) manipuleren waardoor de checksum van het pakket wordt veranderd, de integriteit van de data is aangetast en ongeldig wordt. Effectief kan een ordinaire NAT router dus geen (flat) IPsec-AH doen.

De vorm die hedentendage door veel routers wel kan worden verwerkt is IPSec-ESP waarbij dus de adres-headers buiten de authenticatie & encryptie vallen en dus kunnen worden ge-NAT.
Strict genomen kan dit de herkomst-integriteit van de (payload)data geweld aandoen. Immers de Address-Headers worden (bewust) gemanipuleerd waarbij een (kleine) onzekerheid ontstaat of dit wel met goede bedoelingen is.

Een volgende vorm, die je meer en meer ziet, is dat de IPsec-data (evt. met AH) opnieuw wordt ingepakt en wordt getransporteerd over TCP (of UDP). Het TCP/UDP protocol () kan dan normaal worden ge-NAT'ted. Dit soort implementaties zie je meer en meer en wordt verzorgd door specifieke programmatuur/hardware.

De meeste NAT-routers kunnen vaak maar 1 data-stream van IPSec-ESP aan en kunnen (helaas) ook niet specifiek worden ingesteld op NAT voor/van bepaalde protocolllen zoals bijv. protocol 47, 50, 51 etc.
Vaak suggeren merken dat ze IPSec ondersteunen terwijl ze feitelijk niets anders zeggen dat ze het kunnen doorgeven aan/naar een default machine op je LAN. Het is een beetje als dat de router geen flauw idee heeft wat ie moet doen met de ongesupporte data pakketjes en het maar neerkwakt bij een IP-adres die het maar moet uitzoeken. Dit wordt vaak (onterecht) als 'DMZ' capable verkocht.

Een ander probleem is de uitwisseling van de IKE (Internet Key Exchange) data. Vaak is dit gebonden aan vast ingestelde (source/target) poorten (standaard UDP/500) waardoor een router met een zwakke IPsec implementatie niet in staat is deze poort goed te routeren wanneer op de NAT-router meerder clients IPsec willen doen. Deze routers doen dan wel NAT maar baseren hun logica eik op source/target PORT (NAPT) vertaling.

Ook kan met IPsec via NAT een probleem ontstaan wanneer pakketjes gefragmenteerd worden. Practisch geen enkele (bij mijn geen enkele) el cheapo router is in staat om dit te overbruggen. Oplossing hiervan is om de IPsec data ruim binnen de maximale pakketgrootte van het transport medium te houden (MTU bij Ethernet is < 1500 minus nog wat, advies is 1376 of kleiner).

Daarnaast zie je soms een probleem ontstaan met providers. Sommigen beschouwen IPsec als zakelijk verkeer en blokkeren (bewust/incidenteel ?) dit verkeer zodat je van frustratie tzt vanzelf een commercieëel (duur !!) abbo moet of gaat afsluiten.

De oplossing is voor een aantal server/client implementaties om de IPsec-data (en evt. zelfs ook de IKE) opnieuw in te pakken en via het UDP(of TCP) protocol te versturen. Dit vereist specifieke implementatie afhankelijke programmatuur (en zelfs soms apparatuur) aan zowel de client als server zijde die de boel weer moet uitpakken. Theoretisch is deze werkwijze dan weer gevoelig voor IP-spoofing.

[igmar]

mutsje schreef op 09 September 2003 @ 14:27:
De meeste in GOT zullen denken dat L2TP encrypted is.. maar helaas gaat dit niet zonder IPSec.
Lastige is met IPSec dat het niet graag wil Natten(schijnt mogelijk te zijn maar heb nog nooit een werkende situatie gezien).

Wij doen niet anders. Zolang je client en server maar NAT-T ondersteunen is d'r niks aan de hand. Client software met NAT-T is helaas vrij zeldzaam.