Bảo mật trong PPTP Giao thức PPTP trong ứng dụng VPN

Giao thức PPTP trong ứng dụng VPN PPTP là một giao thức mạng dùng để tạo đường hầm điểm nối điểm cho phép chuyển giao dữ liệu từ một PPTP client đến một PPTP server bằng cách tạo ra một mạng riêng ảo (VPN) trên mạng IP. PPTP hỗ trợ theo yêu cầu, đa giao thức, mạng riêng ảo.

Bảo mật trong PPTP

Giao thức PPTP trong ứng dụng VPN

Giới thi u ệ

 PPTP là một giao thức mạng dùng để tạo đường hầm điểm nối điểm cho phép chuyển giao dữ liệu từ một PPTP client đến một PPTP server bằng cách tạo ra một mạng riêng ảo (VPN) trên mạng IP.

 PPTP hỗ trợ theo yêu cầu, đa giao thức, mạng riêng ảo.

• Control Message Type: 8 – Thông đi p ệOutgoing-Call-Reply

• Call ID: Giá tr đị ược gán b i PAC đ xác đ nh ở ể ị

Set-Link-Info là thông đi p c p nh t thông tin ệ ậ ậ

c a cu c g i nh m cho bi t các thay đ i trong ủ ộ ọ ằ ế ổ

PPP đ PAC có th k p th i đi u ch nh.ể ể ị ờ ề ỉ

Enhanced GRE header

(Generic Routing Encapsulation)

Tr ườ ng C: checksum bit b ng 0 cho th y r ng GRE trong ằ ấ ằ

PPTP không ki m tra tính toàn v n c a d li u mà nó bao ể ẹ ủ ữ ệ

đóng

GRE là giao th c đóng ứ

Đóng gói d li u khi truy n ữ ệ ề qua đ ườ ng h m PPTP ầ

Point-to-Point Protocol (PPP)

PPP cung c p nh ng ch c năng chính sau ấ ữ ứ

• Đóng gói (encapsulate) nh ng gói d li u đa giao th c ữ ữ ệ ứ

• Giao th c Đi u khi n Đ ứ ề ể ườ ng d n ( ẫ Link Control

Protocol - LCP ) đ thi t l p, ch nh c u hình và ki m ể ế ậ ỉ ấ ể tra đ ườ ng truy n d li u ề ữ ệ

• Giao th c Đi u khi n K t n i ( ứ ề ể ế ố Network Control

Protocols - NCP ) đ thi t l p và c u hình nh ng giao ể ế ậ ấ ữ

th c t ng m ng ứ ầ ạ

PPP – V n hành ậ

LCP - Configure-Request

Một thiết lập muốn mở một kết nối phải truyền

một Configure-Request Trường Options được

điền với những cấu hình mong muốn và phải

khác với những cấu hình mặc định của link.

• Code: 1

• Identifier: Trường Identifier phải thay đổi bất cứ khi nào mà nội dung của trường Option thay đổi, và bất cứ khi nào một reply hợp lệ được nhận từ yêu cầu ( request) trước đó

• Options: Trường Option có thể khác nhau về độ dài và chứa danh sách từ 0 tới nhiều cấu hình tùy chọn mà người gửi muốn thương lượng

LCP - Configure-Ack

Nếu mỗi Cấu hình Option nhận được trong Configure-Request

có thể nhận ra được và mọi giá trị đều chấp nhận được, thì thiết lập phải gửi Configure-Ack Khi nhận Configure-Ack, trường Identifier phải phù hợp với Configure-Request được truyền trước

đó Thêm nữa, những Cấu hình Option trong Configure-Ack nhất định phải hoàn toàn trùng khớp với những gì trong Configure- Request Code: 2 đã truyền Những gói không phù hợp sẽ bị bỏ

Identifier: Được gán bằng trường identifier của Request tạo Configure-Ack này

Configure-Options: Trường Options khác nhau về độ dài ( length), và chứa 0 hay nhiều cấu hình tùy chọn mà người nhận đã nhận biết và đồng ý

LCP - Configure-Nak

 Nếu mọi trường của cấu hình tùy chọn

nhận được đều có thể nhận ra, nhưng vài giá trị trong đó lại không thể chấp nhận được, thì thiết lập phải gửi một Configure- Nak

 Nhận được Configure-Nak phù hợp thì một Configure-Request mới sẽ được gửi lại với cấu hình tùy chọn được chỉnh lại như đã xác định trong Configure-Nak

LCP - Configure-Reject

Nếu vài cấu hình tùy chọn trong Configure-Request

không thể nhận ra hoặc không được chấp nhận (như

là đã được tinh chỉnh bởi quản trị mạng), thì phải gửi một gói Configure-Reject

Configure Option – Authentication

Người ta muốn một số đường link sẽ yêu cầu peer

tự xác thực trước khi cho phép những gói giao thức tầng mạng trao đổi Cấu hình Option này là phương pháp để đàm phán việc dùng 1 giao thức chuyên biệt để xác nhận

Một thiết lập không được có nhiều cấu hình tùy chọn dạng Authentication-Protocol trong những gói

Configure-Request

• Type: 3

• Authentication-Protocol: chỉ ra giao thức xác thực cần thiết Một

số giá trị:

• c023 - Password Authentication Protocol (PAP)

• c223 - Challenge Handshake Authentication Protocol (CHAP)

• Data: Trường Data là một hay nhiều octet, và chứa thêm dữ liệu tùy vào giao thức cụ thể

PAP - Password

Authentication Protocol

 PAP(Password Authentication Protocol) là ph ươ ng pháp xác th c t ự ươ ng t nh ph ự ư ươ ng pháp login thông th ườ ng.

 Xác th c b ng cách ki m tra username và ự ằ ể password c a ng ủ ườ i đăng nh p ậ

 Các giá tr xác th c là m t giá tr tĩnh (không thay ị ự ộ ị

đ i) ổ

• R t d b t n công d ấ ễ ị ấ ướ ạ i d ng dò mã hay th mã ử

• Do ph ươ ng th c này không có c ch ki m ch ng ứ ơ ế ể ứ

ng ườ i dùng này có th t hay không nên r t d ậ ấ ễ dàng gi m o ng ả ạ ườ i dùng.

CHAP - Challenge – Handshake

CHAP – Cách ho t đ ng ạ ộ

CHAP – Đánh giá

 Ư u Đi m ể

• Có tính b o m t cao h n nhi u so v i PAP ả ậ ơ ề ớ

• Ch ng v i các lo i t n công Replay Attack hay nghe tr m ố ớ ạ ấ ộ

• Có c ch ki m tra ng ơ ế ể ườ i dùng có th t s hay không ậ ự

 Nh ượ c Đi m ể

• Đòi hỏi tính bảo mật ở database lưa thông tin password cao Vì password phải lưu dưới dạng bản rõ hay dưới dạng mã hoá 2 chiều thì ta mới có dùng password để kiểm chứng.

• Dễ dàng bị tấn công từ điển nếu mật khẩu người dùng ngắn hoặc dễ đoán

MS-CHAPv2 - Microsoft Challenge

Handshake Authentication vesion 2

Một phương thức xác thực lẫn nhau (2 chiều) dựa trên mật khẩu chung

tự thi tổng độ phức tạp của nó là 9621 trường hợp.

 Vét cạn trị tóm lược MD4(Password)

 Nhưng hàm băm MD4 cho bản tóm lược có độ dài 128 bit, với năng lực tính toán hiện nay, vét cạn 2128 trường hợp là không thể Vậy làm thế nào?

Bản tóm lược MD4 của mật khẩu được sử dụng để sinh ra 3 khóa DES, mỗi khóa 7 byte, và các khóa này được sử dụng hoàn toàn độc lập với nhau

Như vậy, thay vì dò tìm giá trị tóm lược, ta có thể dò 3 khóa DES này với tổng số trường hợp là:

• Khóa 1, 2 đầu là có độ dài 7 byte

• Khóa thứ 3 chỉ có độ dài 2 byte (16 bit)

• Mà vi c dò ệ 216 trường h p khóa DES thì có th đợ ể ược

th c hi n trong vòng vài giâyự ệ

MPPE – Microsoft Point to

Point Encryption

 MPPE là giao thức đảm nhận chức năng mã hóa dữ

liệu trong giao thức PPP bằng việc sử dụng thuật toán RSA, RC4

 MPPE sẽ dùng khóa phiên để bắt đầu việc mã hóa.

Khả năng tạo khóa của MPPE

MPPE sinh khóa 128 bits t ừ

Tạo MasterSessionKey bằng cách băm PasswordHashHash,

NT-Response (từ MS-CHAPv2), Magic1 (hằng số) bằng SHA-1

 Tạo 2 khóa phiên:

 MasterSendKey (dùng để gửi)

 Master ReceiveKey (dùng để nhận)

 Để tạo MasterSendKey, MasterReceiveKey bằng cách băm

MasterSessionKey, SHSpad1, s, SHSpad2

 Khóa của server và dùng để gửi thì s = magic3

 Khóa của server và dùng để nhận thì s = magic2

 Khóa của client và dùng để nhận thì s = magic3

 Khóa của client và dùng để gửi thì s = magic2

 B ướ c 4: T o khóa phiên g i/nh n ạ ử ậ

MPPE – Đánh giá b o m t ả ậ

 Việc sinh khóa phiên từ 40 bits từ MS-CHAPv1 cho khóa giống nhau

 RC4 sử dụng khóa 40 bits bị xem là mã hóa yếu

MS-CHAPv2 nên rất dễ bị tấn công như đã mô tả ở

phần trước

MPPE, MPPC

Microsoft Point to Point Encryption

Microsoft Point to Point Compression

MPPE sinh khóa d a trên quá trình MS-CHAPv1, MS-CHAPv2, EAP-TLS, ự

s d ng RC4 đ mã hóa payload c a PPP.ử ụ ể ủ

 Gói tin GRE không đ ượ c mã hóa b o v ả ệ

 N u payload trong gói tin PPP không đ ế ượ c mã hóa

b o v thì d li u có th b nghe lén và thay đ i ả ệ ữ ệ ể ị ổ

Th c nghi m – Mô hình ự ệ

Khi ch a k t n i đ n vpn server ư ế ố ế

Sau t o đ ạ ườ ng h m PPTP và ch ng th c v i VPN SERVER b ng tài ầ ứ ự ớ ằ kho n m t kh u trên Domain Controller: ả ậ ẩ

PPP LCP th ươ ng l ượ ng c u ấ hình

Các gói tin giai đo n PPP LCP ạ

PPP LCP – Client yêu c u c u hình tùy ch n ầ ấ ọ

PPP LCP – Server yêu c u c u hình tùy ch n ầ ấ ọ

PPP LCP – Server đ ng ý m t s c u hình tùy ồ ộ ố ấ

PPP LCP – Client t ch i m t s giao th c ừ ố ộ ố ứ

PPP LCP – Server đi u ch nh l i ề ỉ ạ

PPP LCP – Client g i Configuration-Nak đ t ử ể ừ

PPP LCP – Server g i l i Configuration- ử ạ

PPP LCP – Client ch p nh n Configuration- ấ ậ

PAP

CHAP – Challenge packet

CHAP – Response packet

CHAP – Success packet

MS-CHAPv2 – Challenge packet

MS-CHAPv2 – Response packet

MS-CHAPv2 – Success packet

MPPE

Tài li u tham kh o ệ ả

 Hanks, S., Li, T., Farinacci, D and P Traina, "Generic Routing

Encapsulation (GRE)", RFC 1701, October 1994.

 K Hamzeh, G Pall, W Verthein, J Taarud, W Little, G Zorn, to-Point Tunneling Protocol (PPTP)”, RFC 2637, July 1999

“Point- Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC