Đồ án thiết lập hệ thống IPSECVPN sử dụng giao thức IPSEC trên Windows Server
MỤC LỤC
Giao thức ESP
Nested header thường được sử dụng thường xuyên hơn.Trong trường hợp hai(đã trình bày ở phần về AH) ,nếu 2 gateway SG1 và SG2 yêu cầu tất cả các truyền thông gateway to gateway đều được xác thực và mã hóa.Điều này có thể thực hiện bằng hai cách như sau: Thông qua một ESP SA cung cấp cả xác thực và mã hóa ,hoặc thông qua một adjacent AH và ESP SA.Đối với những gateway bảo vệ truyền thông giữa các host H1 và H2 ,SA nên là tunnel mode SA.Tuy nhiên điều này dẫn tới truyền thông giữa H1 và SG1 chưa được bảo vệ.Nếu H1 không tưởng security gateway của nó để vận chuyển truyền thông ,hoặc có một user trong mạng cục bộ của H1 không đáng tin cậy,lúc này H1 cũng cần xác thực truyền thông trong mạng cục bộ.Để đạt. -10:Tính toán dữ liệu xác thực nếu việc xác thực được yêu cầu bởi SA.Các dữ liệu được xác thực gồm có initial ESP header cũng như các dữ liệu đã được mã hóa.Thuật toán xác thực được dùng trong quá trình xử lí IPSEC đối với ESP là HMAC-MD5 ,HMAC-SHA1 và null authentication algorithm.Thuật toán cuối cùng không cung cấp sự xác thực.Bởi vì ESP header cần phải cung cấp tính toàn vẹn ,tính xác thực hoặc cả hai ,nên khi null authentication algorithm được sử dụng để xác thực thì null encycript algorithm không được sử dụng để mã hóa. Giả sử H1 và H2 thiết lập hai SA bảo vệ đầu cuối (end to end):SA1 và SA2 là các ESP encycrypt only SA (Các ESP SA chỉ cung cấp việc mã hóa) và SA3,SA4 là các AH SA xác thực các thông điệp đã được mã hóa và ip header của chúng.Điều gì xảy ra nếu H1 chỉ sừ dụng SA1 để gửi các FTP request đến H2.Các thông số của gói tin inboud như SPI,protocol,địa chỉ đích đều chỉ đến SA1.Gói tin sẽ được mã hóa thành công vì nó chỉ đến một SA hợp lệ trong SAD.Tuy nhiên khi chuyển sang quá trình kiểm tra các policy áp dụng cho gói tin trên có phù hợp không thì gói tin.
Mặc dù việc mã hóa các tiêu đề của lớp trên nhằm mục đích bảo mật,nó mã hóa luôn một số trường ở transport header bao gồm transport protocol và port.Nó cũng mã hóa luôn một số trường mà các trường này thường được sử dụng để phân tích truyền thông trên internet.Một số trường trong transport header có thể sử dụng cho một số mục đich khác như network traffic analyst ( phân tích truyền thông trên mạng):sự quản lí ,cách cải tiến hiệu suất, kiểm tra sự xâm nhập bất hợp pháp và cách xử lí cho một số loại truyền thông nhất định (được phân loại thành một số loại chất lượng dịch vụ (QOS) khác nhau. Để đạt được sự đơn giản theo Bruce Schneier và Neil Ferguson nên loại bỏ giao AH và transport mode .Rất nhiều nhà phát triển IPSEC cho rằng giao thức AH nên bị bỏ đi và điều này có thể xảy ra trong phiên bản tiếp theo của IPSEC.Tuy nhiên có một số ý kiến đối lập cho rằng có một số giao thức đòi hỏi sử dụng AH và điều này chống lại ý kiến phải loại bỏ giao thức này.Tiếp theo khi giới hạn tất cả các SA về tunnel mode, hai ông đề xuất nên sử dụng một header phức hợp nào đó để giúp tiết kiệm kích thước gói thêm vào khi sử dụng tunnel mode nếu chúng không thật sự cần thiết.Các tác giả thú nhận rằng họ không phải là các chuyên gia về mạng máy tính.Những chuyên gia làm việc trong lĩnh vực này kiên quyết bảo vệ rằng việc bao gồm cả transport mode và tunnel mode là do sự tất yếu của kiến mạng máy tính. Bruce Schneier và Neil Ferguson không hài lòng với trình tự xử lí của giao thức ESP.Hai ông cho rằng gói tin đi ra ngoài cần được xác thực trước khi mã hóa.Trình tự này được lựa chọn một cách có chủ ý giúp gói tin inbound nếu không xác thực đúng sẽ không cần phải trải qua việc giải mã tốn thời gian,chi phí.Các tác giả dẫn ra một tình huống khi các quá tình xác thực và mã hóa khóa chưa hoàn thành,do đó một gói tin sau khi đã được xác thực đúng chưa chắc đảm bảo sẽ được giả mã đúng.Để giải quyết vấn đề này mà không làm thay đổi trình tự của việc xử lí ESP,hai ông cho rằng nên xác thực cả khóa giải mã và các dữ liệu cần dùng trong mã hóa cùng với dữ liệu của gói tin.Về phía đối lập ,các chuyên gia mật mã (những người đã tham gia và quá trình xây dựng IPSEC) hài lòng với trình tự này và cho rằng không cần thiết phải xác thực thêm một số dữ liệu như trên.Ngoài ra ,khi IKE thỏa thuận về khóa việc xác thực và mã hóa khóa của ESP là một thành phần của cả quá trình tổng thể.
Câu trả lời cho câu hỏi này liên quan đến lịch sử và chính trị.Một số quốc gia cấm xuất khẩu các phần mềm thực hiện hoặc hỗ trợ việc mã hóa.Phiên bản đầu của RFC tách biệt phần có thể xuất khẩu được là AH với phần liên quan đến vấn đề về vũ khí chiến tranh (ESP header)( vì một số quốc gia cho rằng các phần mềm mã hóa là một vũ khí chiến tranh).Trong dạng nguyên thủy của nó,ESP header chỉ cung cấp việc mã hóa nếu việc xác thực được yêu cầu thì cả hai tiêu đề được sử dụng.Bởi vì một gói tin đã được mã hóa mà chưa được xác thực tạo lỗ hổng cho một số loại tấn công sửa đổi dữ liệu ( modification attack).Mỗi gói tin đã được mã hóa cần phải xác thực,việc này yêu cầu hai SA riêng biệt và phân chia công bằng các xử lí không cần thiết cho mỗi gói tin đã bảo vệ.Do đó trong bản thứ hai của RFC(RFC 2402 và RFC 2406),tính xác thực.
Quản lý khóa với IKE
Có thể khẳng định rằng AH bảo vệ các tiêu đề không được cung cấp bởi ESP,cụ thể là địa chỉ nguồn và địa chỉ đích.Tuy nhiên việc xác thực của quá trình trao đổi khóa gắn địa chỉ của các bên tham gia với khóa ,điều này là đủ để cung cấp sự bảo vệ địa chỉ nguồn và địa chỉ đích.Ngòai ra quá trình xử lí với AH phải đối mặt với nhiều vấn đề phức tạp như là việc phân biệt giữa các loại dữ liệu immutable và mutable …để đưa vào hàm băm,điều này phức tạp hơn so với. Trong hình thức chung nhất, PF_Key là một giao diện trình ứng dụng (API: Application. Programming Interface) giữa 1 ứng dụng trao đổi SA, chẳng hạn như là IKE, và mức độ hệ thống thường hay tạo và truy cập vào Cơ sở dữ liệu SA. 2.SADB_Acquire: Khi 1 trình ứng dụng truyền ra ngoài với sự đòi hỏi bảo vệ của IPSec, nhưng SA thì không có SA thích hợp, lúc đó IPSec gởi 1 SADB_Acquire tới tất cả trình ứng dụng đã đăng ký, bao gồm luôn cả IKE.
6.SADB_Get: Ta có 1 ví dụ như sau, một nhà quản trị mạng muốn kiểm tra định kỳ toàn bộ SAD hoặc một số SA đặc biệt nào đó trong SAD, lúc đó, một SADB_Get có thể được gởi từ 1 trình ứng dụng đặc quyền đến IPSec nhằm yêu cầu thông tin về 1 SA cụ thể nào đó. -Nếu như liên kết bảo mật được thiết lập giữa hai máy IPSEC Driver sẽ quan sát tất cả IP traffic , so sánh các traffic đã được định nghĩa trong các Filter, nếu có hướng đi tiếp các traffic này sẽ được mã hóa hoặc xác nhận số. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 44 - Tiếp theo hộp thoại Active Directory Installation Wizard xuất hiện bạn ấn Next > hộp thoại Operating System Compatibility ấn Next.
Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 47 - Kích hoạt VPN Server bằng cách nhấp phải chuột lên tên server và chọn Configure and Enable Routing and Remote Access. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 53 - Hộp thoại Request for Secure Communication > bỏ check ở mục Activate the default response rule. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 54 - Cửa sổ Wellcome ấn Next > cửa sổ Tunnel Endpoint chọn This rule does not specify a tunnel > Next.