ĐỒ ÁN HỆ THỐNG MẠNG BẢO MẬT TRONG WLAN chương 3_2 pptx

Trong chế độ quản lý, nó sẽ làm việc với các AS và sẽ yêu cầu sự hỗ trợ của 802.1x và EAP.802.1x và EAP cho phép một bộ thích ứng mạng khách đàm phán qua một AP với một back – end AS sử

Trang 1

ĐỒ ÁN HỆ THỐNG MẠNG

Đề tài:

BẢO MẬT TRONG WLAN

CHƯƠNG III

BẢO MẬT TRONG WLAN

Bảng3-2 :Dải các tùy chọn bảo mật cho mạng vô tuyến

Không có

gì

Các dịch vụ ứng dụng không được bảo mật thông tin Tuy nhiên nhiều người

Thư viện, cửa hàng cafe, khách sạn, sân bay…

Trang 2

2

Bảo mật

giới hạn

40- or 128-bit WEP,

MAC access control

list (ACL), và không

quảng bá

Một số mạng truy nhập và bảo mật

802.11i)

Truy nhập mạng và bảo mật

dữ liệu

Nhà, SOHO, và các hệ thống nhỏ linh động

4

Bảo mật

cấp cao

802.1x/EAP-X và RADIUS

(PPTP), PPTPv2,

Layer 2 Tunneling Protocol (L2TP), Kerberos, và IP Security (IPSec)

dữ liệu

Các ứng dụng đặ biệt, trao đổi thường mại, liên lạc…

Trang 3

3.5.1 Truy nhập công cộng

Truy nhập công cộng giống như việc để các khoá cho mọi người đều biết và

sử dụng NoCat Auth, Sputnik, và Wayport hạn chế truy nhập tới người sử dụng công cộng bằng cách nhận thực họ Tiến trình nhận thực họ bảo vệ mạng bởi các

sự khác nhau của uỷ nhiệm truy nhập Trong một số trường hợp, quảng cáo được trao đổi để giành quyền truy nhập hệ thống Trong các trường hợp NoCat Auth, truy nhập có thể bị loại bỏ để tránh việc người ta lạm dụng hệ thống Nhiều giải pháp loại này không cung cấp một cơ chế (tunnel) bảo mật cho những người sử dụng của chúng Dữ liệu gửi trên không khí là trong điều kiện rõ ràng Những người sử dụng phải được cung cấp sự bảo vệ của riêng mình chống lại những lỗ

hổng của độ tin cậy như là sử dụng một VPN để tạo tunnel quay lại công trình

mạng của họ

3.5.2 Điều khiển truy nhập cơ bản

Hiện nay, truy nhập cơ bản cũng giống như việc giấu một khoá dưới một tấm thảm Khoá được dấu ngoài để cho những người thông minh có thể tìm thấy, nhưng mạng truy nhập và dữ liệu được truy nhập sẽ không có giá trị do sự cố ngắt mạng

Tối thiểu, người sử dụng nên kích hoạt WEP, các mật khẩu bảo vệ các thiết

bị dùng chung và các tài nguyên, thay đổi tên mạng từ SSID mặc định, sử dụng lọc địa chỉ MAC, và tắt quảng bá nếu có thể Viện công nghệ điện và điện tử (IEEE) đang làm việc để loại bỏ khoá tránh tình trạng “khóa dưới thảm” bằng hai giải pháp - cải tiến WEP tạm thời và thay thế WEP lâu dài

3.5.3 Các phương thức bảo mật 802.11 ngoài WEP

Truy nhập bảo vệ Wi-Fi (WPA): tháng 11 năm 2002, liên minh Wi – Fi thông báo tiêu chuẩn bảo mật WPA Nó sẽ thay thế tiêu chuẩn WEP hiện tại trên

Trang 4

thiết bị Wi – Fi Có thể thấy trước rằng nhiều nhà cung cấp sẽ đưa ra phần sụn và phần mềm nâng cấp cho các sản phẩm Wi – Fi sẵn có để chúng làm việc với WPA

WPA sử dụng giao thức toàn vẹn khoá tạm thời (TKIP), một kỹ thuật mật

mã cứng rắn hơn được sử dụng trong WEP TKIP sử dụng khoá băm (KeyMix) và kiểm tra tính toàn vẹn bản tin phi tuyến (MIC) TKIP cũng sử dụng một giao thức

rapid – rekeying (ReKey) thay đổi khoá mật mã cho khoảng 10.000 gói tin Tuy

nhiên, TKIP không loại trừ những điểm yếu cơ bản trong bảo mật Wi – Fi Nếu

một attacker tấn công TKIP, anh ta hoặc cô ta không chỉ bẻ gãy độ tin cậy, mà còn

điều khiển truy nhập và nhận thực

WPA sẽ làm việc trong hai phương pháp khác nhau, tuỳ thuộc vào loại mạng Trong nhà và các văn phòng nhỏ, công nghệ sẽ làm việc trong chế độ khoá

“tiền chia sẻ” Những người sử dụng nhập khoá mạng để giành quyền truy nhập

Trong chế độ quản lý, nó sẽ làm việc với các AS và sẽ yêu cầu sự hỗ trợ của 802.1x và EAP.802.1x và EAP cho phép một bộ thích ứng mạng khách đàm phán qua một AP với một back – end AS sử dụng các giao dịch mật mã an toàn để trao đổi các khoá phiên

WPA bao gồm nhiều phần của 802.11 Tuy nhiên, một số các phần tử khoá không được bao gồm trong đó như là sự hỗ trợ cho một thuật toán mật mã mới gọi

là tiêu chuẩn mật mã hoá cấp cao (AES), tiêu chuẩn này sẽ thay thế thuật toán mật

mã RC4 cơ sở khi 802.11i trở nên phổ biến

3.5.4 802.11 Phương pháp bảo mật ngoài WPA

WPA khi trở nên phổ biến, sẽ là một bước chuyển tiếp tốt bảo mật một nhà hoặc một SOHO WLAN Tuy nhiên, cho một hệ thống lớn, 802.1x/EAP và VPN là vẫn có thể phát triển và tồn tại được

Trang 5

3.5.5 802.1x và EAP—bảo mật cấp cao

802.11x cung cấp một Framework nhận thực cho các WLAN, cho phép một người sử dụng được nhận thực bởi một trung tâm nhận thực Thuật toán thực tế được sử dụng để xác định một người sử dụng là đúng hoặc sai và có thể ghép nhiều thuật toán với nhau

802.11x sử dụng EAP, một giao thực sẵn có làm việc trên Ethernet, Token Ring, hoặc các WLAN cho việc trao đổi bản tin trong thời gian tiến trình nhận thực

3.5.6 Nhận thực cổng mạng 802.1x :

Nhận thực 802.1 x cho các WLAN có ba thành phần chính : Supplicant (thường là các phần mềm máy khách), bộ nhận thực (AP), và AS (thông thường là một server RADIUS) Các bộ nhận thực kết nối tới mạng LA Hình 3-14 minh họa tiến trình này

Hình 3-14 : Nhận thực 802.1xDạng thông thường cho một nhân thực 802.11x như sau : Supplicant (trong máy khách ) thử kết nối tới AP bằng cách gửi một bản tin bắt đầu AP tìm ra

Trang 6

Supplicant và làm cho các cổng supplicant trong trạng thái không được phép, vì vậy chỉ các bản tin 802.1x/EAP được chuyển tiếp Tất cả các lưu lượng khác bị chặn

Supplicant sau đó gửi một bản tin EAP khởi động AP tin tưởng vào một bản tin toàn vẹn EAP - Yêu cầu để giành được nhận dạng Supplicant Gói tin EAP – Trả lời của máy khách bao gồm nhận dạng Supplicant để chuyển tiếp tới AS

AS nhận thực Supplicant và các trả lời khác bằng cách chấp nhận hoặc loại

Mặc định rằng, nhận thực là khôngbắt buộc Nếu nhận thực của liên kết được mong muốn, một thực thi phải chỉ rõ tùy chọn cấu hình giao thức nhận thực trong thời gian Phase thiết lập liên kết

Các giao thức nhận thực này được chỉ định cho sử dụng đầu tiên bởi các Host và các router kết nối tới một server mạng PPP qua các chuyển mạch hoặc các đường dial – up, nhưng có thể được chấp nhận để xác định các kết nối Server có thể sử dụng sự nhận dạng của kết nối host hoặc router trong sự lựa chọn các tùy chọn cho tầng mạng

Trang 7

3.5.7.2 Giao thức nhận thực có thể mở rộng điểm tới điểm (EAP)

Giao thức nhận thực có thể mở rộng (EAP) là một giao thức bảo mật tầng giao vận của mô hình OSI, nói chung là một giao thức cho nhận thực PPP hỗ trợ nhiều kĩ thuật nhận thực EAP không lựa chọn một cơ chế nhận thực cụ thể tại Giai đoạn điều khiển liên kết (Link Control Phase), đúng hơn là nó trì hoãn điều này cho đến giai đoạn nhận thực Điều này cho phép bộ nhận thực yêu cầu thêm thông tin trước khi xác định cơ chế nhận thực rõ ràng Điều này cũng chấp nhận sự sử dụng một server “back - end” thi hành nhiều cơ chế khác nhau trong khi server PPP chỉ đơn thuần đi qua tổng đài nhận thực

1 Sau khi giai đoạn thiết lập kết nối được hoàn thành, bộ nhận thực gửi một

hoặc nhiều Request để nhận thực điểm Request có một trường Type để xác định những gì đang được yêu cầu Ví dụ về các loại Request bao gồm Identity, MD5-challenge, One-Time Passwords, Generic Thẻ bài Card…Thông thường, bộ nhận thực sẽ gửi một Indentity Request theo sau bởi một hoặc nhiều Request cho thông tin nhận thực Tuy nhiên, một Indentity Request không được yêu cầu, và có thể bỏ qua trong các trường hợp Indentity là đoán được

2 Điểm (Peer) gửi một gói tin Response trong trường Reply cho mỗi Request Cũng như gói tin Request, gói tin Respone bao gồm một trường Type tương ứng với trường Type của Request

3 Bộ nhận thực chấm dứt giai đoạn nhận thực với một gói tin thành công hoặc thất bại (Succes or Failure packet)

Ưu điểm

Giao thức EAP có thể hỗ trợ nhiều cơ chế nhận thực không phải thực hiện giai đoạn tiền đàm phán một cách riêng biệt trong giai đoạn LCP

Trang 8

Các thiết bị không cần thiết phải hiểu mỗi loại Request và cũng có thể đơn giản các hoạt động như một tác nhân passthrough cho một server “back - end” trên một host Thiết bị chỉ cần xem mã thành công/ thất bại để kết thúc giai đoạn nhận thực

3.5.7.3 Cấu hình khuôn dạng tùy chọn

Cấu hình khuôn dạng tổng quát tùy chọn như sau:

Hình 3-15 : Khuông dạng tổng quát gói tin

Type 3

Length 4

3.5.7.4 Khuôn dạng gói tin

Chính xác một gói tin PP EAP được đóng gói trong trường thông tin của một khung PPP tầng liên kết dữ liệu ở đây trường giao thức chỉ rõ loại Hex C227 (PPP EAP) Dạng tổng quát của khuôn dạng gói tin EAP được biểu diễn như sau Các trường được phát từ trái qua phải

Code Indentifier Length Data

Trang 9

Hình 3-15 : Khuôn dạng gói tin

Identifier :Trường Identifier gồm một octet

Length : Trường Length gồm hai octet và chỉ rõ chiều dài của các gói tin

EAP bao gồm Code, identifier, Length và Data Các octet bên ngoài phạm vi của trường Length có thể coi là đệm tầng liên kết dữ liệu và không cần để ý khi tiếp

nhận

Data : Trường Data gồm 0 hoặc nhiều octet Khuôn dạng trường dữ liệu

được quyết định bởi trường Code

Request and Response : Gói tin Request được gửi bởi bộ nhận thực tới

Peer Mỗi Request có một loại trường phục vụ việc xác định những gì đang được yêu cầu Bộ nhận thực phải phát một gói tin EAP với tập trường mã tới 1 ( Request) Các gói tin Request bổ sung được gửi cho đến khi một gói tin Response hợp lệ được nhận Các Request phát lại phải được gửi với cùng giá trị nhận dạng

để mà phân biệt được chúng với các Request mới Các nội dung của trường dữ liệu

là phụ thuộc loại Request Peer phải gửi một gói tin Request trả lời gói tin

Request

Trang 10

Lưu ý : Bởi vì tiến trình nhận thực sẽ thường bao gồm đầu vào người sử

Trường Identifier gồm một octet Trường Identifier phải giống nhau nếu một

gói tin Request được phát lại trong thời gian timeout trong khi đang chờ một

Response Bất kỳ các Request mới nào cũng phải sửa đổi trường Identifier Nếu một Peer nhận một bản sao Request khi nó đã gửi một Response, nó phải gửi lại một Respone Nếu một Peer nhận một bản sao Request trước khi nó đã gửi một Response tới Request đầu tiên, nó sẽ lặng lẽ loại bỏ bản sao Request

Length

Trường Length gồm hai octet và chỉ rõ chiều dài của gói tin EAP bao gồm Code, Indentifier, Length, Type, và Type – Data Các octet ngoài phạm vi của

Trang 11

trường Length có thể coi là phần đệm tầng liên kết dữ liệu và không cần quan tâm tới khi nhận

Type

Trường Type gồm một octet Trường này chỉ rõ loại Request và Response Chỉ một Type phải được xác định rõ trên Request hoặc Respone EAP Thông thường, trường Type của Response giống trường Type của Request Tuy nhiên, cũng có một Nak Response Type cho việc xác định rằng một Request Type không được chấp nhận tới một điểm Khi gửi một Nak trong một Respone tới một Request, Peer có thể xác định rõ một Type nhận thực luân phiên

Dạng tổng quan của khuôn dạng gói tin Success và Failure được biểu diễn như sau Các trường được phát từ trái qua phải :

Trang 12

Hình 3-17 : Các trường gói tin Code

3.5.7.5 Các loại Request /Response EAP ban đầu

Trường Type gồm một Octet và các nhận dạng cấu trúc của gói tin Request hoặc Respone EAP 3 Type đầu tiên được dành cho các Type đặc biệt Các Type còn lại định nghĩa các trao đổi nhận thực Nak Type là hợp lệ chỉ đối với các gói tin Respone, nó không được gửi trong một Request Nak Type chỉ được gửi trong việc trả lời tới một Request sử dụng một mã Type nhận thực Tất cả các thực thi EAP phải hỗ trợ các Type 1 – 4 Các Type này, cũng như các Type 5 và 6

Trang 13

Trường Indentity được sử dụng để truy vấn nhận dạng điểm Nói chung, bộ nhận thực sẽ đưa ra điều này cũng như Request ban đầu Có thể bao gồm Một bản tin có thể hiển thị tùy chọn để nhắc Peer trong trường hợp mong muốn tương tác với người sử dụng Một Respone phải được gửi tới Request này với một Type1 (Nhận dạng)

Type : 1 octet

Type-Data : Trường này có thể bao gồm một bản tin có thể hiển thị Request

Respone sử dụng trường này để trả về Indetity Nếu Identity là không được biết, trường này sẽ nhận các byte toàn 0 Trường không được kết thúc bằng Null Chiều dài của trường xuất phát từ trường Length của gói tin Request/Response và vì thể một Null không được yêu cầu

Khai báo (Notification)

Notification Type được sử dụng tùy ý để truyển một bản tin có thể hiển thị

từ một bộ nhận thực tới Peer Peer nên hiển thị bản tin này tới người sử dụng hoặc bản ghi nó nếu nó không thể được hiển thị Nó được dự định để cung cấp một thông báo xác nhận của một số tình trạng khẩn cấp

Type : 2 octet

Type-Data : Trường Type-Data trong Request bao gồm một bản tin có thể

hiển thị Độ dài của bản tin được xác định bởi trường Length của gói tin Request Bản tin phải không được kết cuối bằng Null Một Respone phải được gửi trong sự trả lời tới Request với một trường Type của 2 (Notification) Response nên được gửi ngay lập tức

Nak

Trang 14

Type-Data là hợp lệ chỉ trong bản tin Response Nó được gửi trong trả lời tới một Request ở dây Type nhận thực là không thể được chấp nhận Các Type nhận thực được đánh số 4

Type : 3octet

Type-Data : Trường này phải bao gồm một octet đơn xác định loại

nhận thực mong muốn3.5.2 Điều khiển truy nhập cơ bản