Сигурност при PPP връзки

1. Сигурност при PPP връзки
   1.1. PPP - Point-to-Point protocol
        1.1.1. наследник на SLIP (Serial Line IP)
        1.1.2. съвкупност от протоколи

   1.2. Използване
        1.2.1. серийна линия (телефон, модем)
        1.2.2. PPP-over-anything (Ethernet, TCP, PPTP, DNS, ...)

   1.3. Атаки


2. PPP - Point-to-Point protocol
   2.1. Цели
        2.1.1. предаване на данни през директна връзка между станциите
        2.1.2. различни начини за автентикация
        2.1.3. договаряне на IP адреси
        2.1.4. договаряне на протоколи, корекция за грешки, контрол на шума и т.н.
        2.1.5. "вграждане" (encapsulation) на протоколи
        2.1.6. компресия, кодиране, ...

   2.2. Единствено изискване - предаване на байтове
        2.2.1. серийна линия и RS-232-C, V.35 и т.н.
        2.2.2. TCP връзка
        2.2.3. UDP с малко допълнителен код за reliability
        2.2.4. Ethernet, ADSL, ATM, пощенски гълъби, ...


3. Начин на работа - слоеве
   3.1. Link layer - пакетите на PPP (frames)
        3.1.1. [ Flag | Address | Control | Protocol | Data | FCS ]
        3.1.2. [ 6E | FF | 03 | pp pp | dd dd dd ... | cc cc ]
        3.1.3. различни протоколи "по едно и също време"

   3.2. Link control protocol

   3.3. Authentication (optional)

   3.4. Network control protocols


4. Link control protocol - основа на PPP
   4.1. Установяване и договаряне на параметри на връзката
        4.1.1. непозволени стойности
        4.1.2. MTU, MRU, изобщо максимални размери на пакети
        4.1.3. callback

   4.2. Качество на линията (LQM - Link Quality Monitoring), RFC 1989
        4.2.1. не е задължително
        4.2.2. LQR - Link Quality Report - брои изпратени пакети, байтове, LQR-и

   4.3. Договаряне на мрежовите протоколи
        4.3.1. всъщност договаряне на какво ли не
        4.3.2. CONFREQuest, CONFACKnowledge, CONFREJect
        4.3.3. протоколи за автентикация
        4.3.4. протоколи за предаване на данни, компресия, криптиране, ...


5. Автентикация - най-интересната част :)
   5.1. Незадължителна, но се налага

   5.2. Двупосочна, или еднопосочна в която и да е посока

   5.3. Протоколи
        5.3.1. крипто-слаби: PAP, ShivaPAP, MSCHAPv1
        5.3.2. крипто-силни: CHAP, MSCHAPv2, EAP-MD5
        5.3.3. особени: EAP-OTP, EAP-GenTokenCard, EAP-TLS


6. Крипто-слаби протоколи
   6.1. PAP - Password Authentication Protocol
        6.1.1. паролата в чист вид
        6.1.2. позволява пазене на паролата в криптиран вид при доставчика
        6.1.3. тривиален за заобикаляне при възможност за подслушване

   6.2. Shiva PAP - Shiva Access Manager
        6.2.1. изпраща паролата криптирана, но недостатъчно добре
        6.2.2. proprietary, патентован алгоритъм, никой не го използва

   6.3. MSCHAP(v1) - версия на CHAP от Microsoft
        6.3.1. "разширение" на CHAP (embrace and extend)
        6.3.2. LANMAN хешове, стандартният начин за auth между Windows станции
        6.3.3. Windows NT хешове, малко по-силен начин за криптиране
        6.3.4. проблем: изпращат *и* двата хеша, LANMAN се "чупи" тривиално


7. Крипто-силни протоколи
   7.1. CHAP - Challenge Authentication Protocol
        7.1.1. едната страна изпраща challenge
        7.1.2. другата страна криптира паролата с този challenge
        7.1.3. първата криптира запазената при себе си парола и сравнява
        7.1.4. изисква пазене на паролата в чист вид и от двете страни

   7.2. MSCHAPv2 - подобрена версия на MSCHAP
        7.2.1. излишно усложнени методи за криптиране
        7.2.2. ключът за междинното криптиране се изпраща съвсем малко по-късно


8. EAP - Extensible Authentication Protocol
   8.1. Стандартизирана дефиниция на протоколи с гарантирано качество

   8.2. EAP-MD5 - challenge/response

   8.3. EAP-OTP - one-time passwords
        8.3.1. поредица от пароли, всеки път се изпраща пореден номер

   8.4. Generic Token Card - подобно на OTP

   8.5. EAP-TLS - използване на PKI/X.509


9. NCP - Network Control Protocol
   9.1. Договорихме връзката, а сега какво?

   9.2. Протокол за предаване на данните
        9.2.1. TCP/IP
        9.2.2. NETBEUI
        9.2.3. AppleTalk, IPX, ...

   9.3. Договаряне на адреси

   9.4. Представяне на данните
        9.4.1. компресия
        9.4.2. криптиране
        9.4.3. multilink PPP


10. NCP - избор на протокол
   10.1. IPCP - IP Control Protocol
        10.1.1. адреси, gateway
        10.1.2. DNS сървъри

   10.2. IPXCP - IPX Control Protocol

   10.3. NBFCP - NetBIOS Frame Control Protocol
        10.3.1. всичко, което се случва в една Windows Workgroup или Domain
        10.3.2. NetBIOS Name Projection - уникални имена на станциите

   10.4. AppleTalk, Banyan, DECnet, XNS, ...

   10.5. ИЗКЛЮЧВАЙТЕ ТЕЗИ, КОИТО НЕ ВИ ТРЯБВАТ!


11. Представяне на данните
   11.1. Компресия
        11.1.1. Deflate (PKZIP) - класическият алгоритъм на Lempel-Ziv
        11.1.2. MPPC - Microsoft Point-to-Point Compression
        11.1.3. други - LZS (Stac), BSD, FZA (няколко пакета), Magnalink (самонастройващ се)

   11.2. Криптиране: ECP - Encryption Control Protocol
        11.2.1. DESE, 3DESE - ключовете се обменят в началото

   11.3. Криптиране: MPPE - Microsoft Point-to-Point Encryption
        11.3.1. честа промяна на ключовете (може и след всеки пакет!)
        11.3.2. coherency count - защита от нестабилна връзка
        11.3.3. първоначалният ключ се получава от автентикацията на другата страна!


12. Атаки върху PPP
   12.1. Защо?
        12.1.1. крадене на акаунти (пароли)
        12.1.2. крадене на трафик (използване на чужд акаунт)
        12.1.3. крадене на самоличност (представяне за друг при статични адреси)

   12.2. Кой?
        12.2.1. при серийна линия - някой, който се закачи за кабела
        12.2.2. при PPP-over-каквото-и-да-е - някой, който подслушва преносната среда


13. Атаки върху крипто-слабите протоколи
   13.1. Подслушване на паролата при PAP

   13.2. Атака върху LANMAN при MSCHAPv1 (Rainbow)

   13.3. Hash playback при ShivaPAP

   13.4. НЕ ГИ ИЗПОЛЗВАЙТЕ!


14. Атаки върху крипто-силните протоколи
   14.1. Hash playback при двупосочна автентикация
        14.1.1. еднакви пароли
        14.1.2. защита: еднакви хешове - трябва да бъдат отхвърлени!

   14.2. Улеснено претърсване за хешовете при MSCHAPv2
        14.2.1. защита: не го използвайте

   14.3. Man-in-the-middle атака
        14.3.1. седи по средата, предава auth информацията, после подслушва връзката
        14.3.2. решение 1: криптиране след автентикация - не е достатъчно
        14.3.3. решение 2: използване на EAP-TLS (PKI, X.509)


15. Повече информация
   15.1. IETF RFC's - търсене за PPP, EAP ще покаже повечето

   15.2. От преподавателите
        15.2.1. секцията "материали"
        15.2.2. Боян Кроснов - http://boyan.ludost.net/papers/security/

   15.3. Други:
        15.3.1. http://www.networksorcery.com/enp/topic/pppsuite.htm



$Ringlet: perl/text/present/xsl/txt.xsl,v 1.1 2004/10/26 12:24:06 roam Exp $
$Ringlet: perl/text/present/pres/ppp.pod,v 1.1 2004/10/26 12:25:10 roam Exp $