Đề tài Nghiên cứu về mạng riêng ảo và xây dựng giải pháp mạng riêng ảo sử dụng tường lửa Checkpoint

n thân AH Header: Next Header, Payload, Length, Reserved, SPI, SN, Authentication Data (được đặt bằng 0), và explicit padding (nếu có). + Dữ liệu của các giao thức lớp trên. + Các trường có giá trị thay đổi sẽ được coi bằng 0 trong phép tính ICV các trường có giá trị thay đổi nhưng có thể dự đoán được thì sẽ giữ nguyên giá trị. - Padding: Có hai loại chèn padding là Authenticaiton Data và Implicit Packet Padding (chèn dữ liệu ngầm định). + Authenticaiton Data Padding: Nếu đầu ra của thuật toán xác thực là 96 bit thì không cần chèn thêm dữ liệu. Nhưng nếu ICV có kích thước khác thì phải chèn thêm, nội dung của phần chèn thêm là tuỳ chọn và được đặt sau Authentication Data. + Implicit Packet Padding: Đối với một số thuật toán xác thực, chuỗi byte để tính ICV phải là một số nguyên lần của khối n byte. Nếu độ dài gói IP không thoả mãn điều kiện đó thì Implicit Packet Padding sẽ được thêm vào phía cuối của gói. Các byte này bằng 0 và không được truyền đi cùng gói. - Phân mảnh: Khi cần thiết, phân mảnh sẽ được thực hiện + Giao thức đóng gói tải bảo mật(ESP) Mục đích chính của ESP là cung cấp sự tin cậy ,xác thực người gửi và xác minh tính toàn vẹn của dữ liệu trong khi truyền. ESP mã hoá nội dung của gói dữ liệu bằng cách dùng các thuật toán mã hoá, như đã xác định bởi SA. Một số thuật toán được sử dụng bởi ESP bao gồm: DES-CBG, NULL, CAST-128, IDEA và 3DES. Các thuật toán xác thực thường được dùng tương tự như trong AH là HMAC-MD5 và HMAC-SHA. 1. Khuôn dạng gói dữ liệu dựa trên ESP Bits 8 8 0-255 32 32 Hình 34. Khuôn dạng ESP Các trường trong ESP đều là bắt buộc: - SPI: Là một số 32 bit bất kỳ, cùng với địa chỉ IP đích và giao thức an ninh, ESP cho phép nhận dạng duy nhất SA cho gói dữ liệu này. Các giá trị SPI từ 1 đến 255 được dành riêng để sử dụng trong tương lai. Giá trị SPI = 0 để chỉ ra chưa có SA nào tồn tại. - SN: Giống như AH, trường SN chứa một giá trị đếm tăng dần để chống lặp lại. Mỗi SA được lựa chọn thì giá trị của trường này bắt đầu là 0. - Payload Data: Trường có độ dài biến đổi chứa dữ liệu mô tả trong Next Header. Payload Data là trường bắt buộc, được mã hoá bởi các thuật toán mã hoá, các thuật toán mã hoá này được lựa chọn ngay khi thiết lập SA. Trường này có độ dài bằng một số nguyên lần 1 byte. - Padding: Trường này được thêm vào để đoạn được mã hoá là một số nguyên lần của một khối các byte. Ngoài ra trường còn dùng để che dấu độ dài thực của Payload. - Pad Length: Trường này xác định số byte padding đã thêm vào (0 đến 225) - Next Header: Là trường 8 bit bắt buộc, nó chỉ ra kiểu dữ liệu trong Payload Data. Ví dụ một giao thức bậc cao hơn như TCP. Giá trị của trường được chọn trong chuẩn IP Protocol Number được đưa ra bởi IANA. - Authentication Data: Trường có độ dài biến đổi chứa giá trị ICV được tính cho gói ESP từ SPI đến Next Header. Authentication là trường không bắt buộc, được thêm vào nếu dịch vụ Authentication được lựa chọn cho SA đang xét. Các thuật toán để tính ICV là các thuật toán hàm băm một chiều MD5 hoặc SHA giống với AH. 2. Chế độ hoạt động Hình 35. Gói ESP trong chế độ Transport ESP cũng được sử dụng ở hai chế độ: Transport và Tunnel - Chế độ Transport: Chế độ Transport cho phép bảo vệ các giao thức lớp trên nhưng không bảo vệ IP Header. Các gói tin IP cũ được cắt phần tiêu đề ra, sau đó tiêu đề ESP được đưa vào giữa. ESP trailer sẽ được đưa vào cuối gói tin, cuối cùng là Authentication Data được đưa thêm vào. Chế độ Transport không mã hoá cũng không xác thực IP Header, tuy nhiên nó có chi phí xử lý thấp, chỉ được dùng cho các Host. Hình 36. Gói ESP trong chế độ Tunnel - Chế độ Tunnel: Trong chế độ này, gói IP mới được xây dựng cùng với một IP Header mới. Các IP Header bên trong mang địa chỉ nguồn và đích cuối cùng, còn IP Header bên ngoài mang địa chỉ định tuyến qua Internet. Ở chế độ này, ESP sẽ bảo vệ cả gói tin IP ban đầu bao gồm: Payload và IP header. Đối với gói IP bên ngoài thì vị trí của ESP giống như trong chế độ Transport. 3. Các thuật toán sử dụng trong ESP Các thuật toán bắt buộc bao gồm: - Các thuật toán mật mã: DES ở chế độ CBC, AES, NULL. Thuật toán mã hoá được xác định bởi SA. ESP làm việc với các thuật toán mã hoá đối xứng. Với sự có mặt của trường Padding, các thuật toán mã hoá có thể có đặc tính khối hoặc luồng. - Các thuật toán xác thực: Mã xác thực bản tin MAC sử dụng MD5, mã xác thực bản tin MAC sử dụng SHA, NULL (Không sử dụng mã xác thực) 4. Xử lý gói tin đầu ra Quá trình xử lý gói đầu ra bao gồm các bước sau: - Tìm kiếm SA: Giống như AH, ESP được thực hiện trên một gói tin chỉ khi nào bộ điều khiển IPSec đã xác định gói tin đó được liên kết với một SA. - Mã hoá gói tin: Tuỳ thuộc vào chế độ Tunnel hay Transport mà ESP thực hiện đóng gói toàn bộ gói tin hay chỉ đóng gói phần Payload. Thêm Padding nếu cần thiết, mã hoá các trường Payload Data, Padding, PadLength, Next Header theo các thuật toán đã được chỉ ra bởi SA. Nếu dịch vụ xác thực được lựa chọn thì việc mã hoá được thực hiện trước, quá trình mã hoá không bao gồm trường Authentication Data. Và quá trình xác thực được thực hiện sau. Thứ tự xử lý này cho phép nhanh chóng xác định và loại bỏ các gói lỗi hoặc lặp lại mà không cần phải giải mã gói tin, đồng thời cho phép phía thu xử lý song song cả hai việc: giải mã và xác thực. - Tạo SN: Quá trình này được thực hiện giống với AH. - Tính ICV: Nếu dịch vụ xác thực được lựa chọn thì phía phát sẽ tính các giá trị ICV trên gói dữ liệu ESP gồm các trường sau: SPI, SequenceNumber, Payload Data, Padding, PadLength và Next Header. Trong đó 4 trường cuối ở dạng đã mã hoá. ICV được tính dựa vào các thuật toán xác thực dùng hàm băm một chiều như MD5 và SHA-1. - Phân mảnh: Nếu cần thiết thì phân mảnh sẽ được thực hiện sau khi đã xử lý ESP. 5. Xử lý gói tin đầu vào Quá trình xử lý gói đầu vào gồm các bước ngược với quá trình xử lý gói tin đầu ra. - Ghép mảnh: Ghép mảnh được thực hiện trước khi xử lý ESP. Nếu một gói tin cần xử lý ESP ở dạng phân mảnh thì phía thu phải loại bỏ gói tin đó. - Tìm kiếm SA: Khi nhận được một gói tin chứa ESP Header, phía thu sẽ xác định một SA phù hợp dựa trên địa chỉ đích, giao thức bảo mật và SPI. Nếu không thể tìm thấy một SA nào phù hợp cho phiên truyền dẫn này thì phía thu sẽ loại bỏ gói tin. - Kiểm tra SN: Giống với kiểm tra SN trong AH. - Kiểm tra ICV: Nếu dịch vụ xác thực được lựa chọn phía thu sẽ tính ICV của gói ESP ngoại trừ trường Authentication Data rồi so sánh với ICV của gói tin nhận được. Nếu hai giá trị ICV này trùng nhau thì gói tin là hợp lệ, nếu không gói tin sẽ bị loại bỏ. Việc kiểm tra được tiến hành như sau: Trước tiên trường Authentication Data được tách ra khỏi ESP và lưu lại, sau đó kiểm tra độ dài gói ESP còn lại, nếu Padding đã được ngầm định thì các byte 0 được thêm vào sau trường Next Header sau đó sẽ tính ICV và so sánh với giá trị ICV được lưu trong trường Authentication Data. - Giải mã gói tin: Đầu tiên là giải mã ESP bao gồm các trường Payload Data, Padding, Padlength, NextHeader sử dụng khoá, thuật toán mật mã đã xác định bởi SA. Sau đó xử lý phần Padding theo đặc điểm của thuật toán, loại bỏ nó trước khi đưa lên các lớp trên. Cuối cùng là xây dựng lại gói tin IP ban đầu tuỳ thuộc vào chế độ Transport hay Tunnel. Nếu là Transport, xây dựng lại gói tin ban đầu từ IP Header và thông tin giao thức lớp trên trong Payload của ESP. Nếu là Tunnel, xây dựng lại gói tin ban đầu từ IP Header của gói bên ngoài và toàn bộ gói IP bên trong. 1.4.5. Giao thức SSL. SSL VPN là một giải cho phép người dùng thiết lập kết nối VPN thông qua Web. SSL đầu tiên được biết đến như một giao thức bảo vệ web (HTTP) giữa người sử dụng và web server.Thông thường nó giúp việc bảo vệ các thông tin nhạy cảm giữa người dùng và các server.Tuy nhiên có nhiều hãng đã sử dụng SSL để thực thi các giải pháp VPN. Một tiện ích chính mà SSL VPNs là không cần sử dụng software bên phía người dùng , chỉ yêu cầu người dùng có sử dụng trình duyệt web. SSL VPN là chỉ hỗ trợ mô hình remote access không dành cho site-to-site SSL VPNs hoạt động ở tầng session của mô hình OSI . Bởi vì client là 1 Web Browser nên các ứng dụng mà hỗ trợ WebBrowser mới làm việc với VPN. Chính vì vậy các ứng dụng như Telnet , FTP , SMTP, POP3 , multimedia , IP Telephony, Remote desktop và các cái khác không hỗ trợ … Tuy nhiên các hãng đã sử dụng Java hoặc Active X để giúp SSL VPN có thể hỗ trợ các ứng dựng không phải web. . Cần xem kỹ sản phầm các hãng hỗ trợ thế nào để phù hợp với nhu cầu của chúng ta. Thực thi SSL VPN . - Lý do chính các nhà quản trị sử dụng SSL VPN đó là không yêu cầu đặc biệt về phần mềm VPN client được cài sẵn lên phía user chính vì vậy người dùng cần SSL-enabled webserver thôi, thông thường kèm theo Java hoặc ActiveX được bật. Có 3 kiểu thực thi SSL client đó là : - Clientless : chỉ yêu cầu trình duyệt chính vì thế còn gọi là Web VPNs khi chỉ được sử dựng cho SSL VPN . Mục đích chính chỉ cung cấp web-based traffic - Thin client : thin client thông thường là Java hoặc ActiveX được tải về cài đặt trên desktop user. Tuy nhiều quá trình này tự động và nó hỗ trợ client sử dụng các dịch vụ non-web qua SSL VPN - Network client : network-based access , một phần mềm SSL client được đòi hỏi cần được cài đặt trên user desktop , toàn bộ traffic được bảo vệ bởi SSL .Nhưng cần đòi hỏi quyền Administrator trên máy cá nhân. 1.4.6. Giao thức MPLS Mạng MPLS VPN không sử dụng hoạt động đóng gói và mã hóa gói tin để đạt được mức độ bảo mật cao. MPLS VPN sử dụng bảng chuyển tiếp và các nhãn “tags” để tạo nên tính bảo mật cho mạng VPN. Kiến trúc mạng loại này sử dụng các tuyến mạng xác định để phân phối các dịch vụ VPN, và các cơ chế xử lý thông minh của MPLS VPN lúc này nằm hoàn toàn trong phần lõi của mạng. Trước tiên, ta hãy xem xét một số thuật ngữ được dùng trong mạng MPLS VPN. Thiết bị CPE trong MPLS-VPN chính là các CE (Customer Edge) router và các CE router này được nối với mạng của nhà cung cấp dịch vụ thông qua các PE (Provider Edge) router. Một mạng VPN sẽ bao gồm một nhóm các CE router kết nối với các PE router của nhà cung cấp dịch vụ. Tuy nhiên, chỉ những PE router mới có khái niệm về VPN, còn các CE router thì không “nhận thấy” những gì đang diễn ra bên trong mạng của nhà cung cấp dịch vụ và sẽ coi như chúng đang được kết nối với nhau thông qua một mạng riêng. Mỗi VPN được kết hợp với một bảng định tuyến - chuyển tiếp VPN (VRF) riêng biệt. VRF cung cấp các thông tin về mối quan hệ trong VPN của một site khách hàng khi được nối với PE router. Bảng VRF bao gồm thông tin bảng định tuyến IP (IP routing table), bảng CEF (Cisco Express Forwarding), các giao diện của bảng định tuyến; các quy tắc, các tham số của giao thức định tuyến... Mỗi site chỉ có thể kết hợp với một và chỉ một VRF. Các VRF của site khách hàng mang toàn bộ thông tin về các “tuyến” có sẵn từ site tới VPN mà nó là thành viên. Đối với mỗi VRF, thông tin sử dụng để chuyển tiếp các gói tin được lưu trong các bảng định tuyến IP và bảng CEF. Các bảng này được duy trì riêng rẽ cho từng VRF nên nó ngăn chặn được hiện tượng thông tin bị chuyển tiếp ra ngoài mạng VPN cũng như ngăn chặn các gói tin bên ngoài mạng VPN chuyển tiếp vào các router bên trong mạng VPN. đây chính là cơ chế bảo mật của MPLS VPN. Bên trong mỗi một MPLS VPN, có thể kết nối bất kỳ hai điểm nào với nhau và các site có thể gửi thông tin trực tiếp cho nhau mà không cần thông qua site trung tâm. Tham số phân biệt tuyến RD (Route Distinguisher) giúp nhận biết các địa chỉ IP thuộc VPN riêng biệt nào. Xét mô hình mạng như hình 2, có 3 VPN khác nhau và được xác định bởi các RD: 10, 20 và 30. Một mạng MPLS có thể hỗ trợ hàng trăm đến hàng nghìn VPN. Phần bên trong của kiến trúc mạng MPLS VPN được kết cấu bởi các thiết bị của nhà cung cấp. Những thiết bị này hình thành mạng lõi (core) MPLS và không được nối trực tiếp đến các CE router. Các chức năng VPN của một mạng MPLS-VPN sẽ được thực hiện bởi các PE router bao quanh mạng lõi này. Cả P router và PE router đều là các bộ định tuyến chuyển mạch nhãn LSR (Label Switch Router) trong mạng MPLS. Các site khách hàng có thể được kết nối với các PE router bằng nhiều cách khác nhau như T1, Frame Relay, DSL, ATM, v.v... Hình 37. Mô hình mạng MPLS Trong một mạng MPLS VPN, site phía khách hàng sẽ sử dụng IP thông thường mà không cần biết đến MPLS, IPSec hay bất cứ một chức năng VPN đặc biệt nào. Tại các PE router, một cặp VRF và RD sẽ tương ứng với mỗi liên kết đến site của khách hàng (customer site). Liên kết này có thể là một liên kết vật lý T1, Frame Relay hay ATM VC, DSL... Giá trị RD sẽ hoàn toàn “ẩn” và sẽ không được cấu hình tại các thiết bị của khách hàng. Sau đây chúng ta sẽ xem xét một ví dụ cụ thể đường đi của một gói tin trong mạng VPN của khách hàng từ PC A thuộc site A tới PC B thuộc site B thông qua mạng MPLS. - Gói tin đến từ site A của PE router R1 như một gói IP thông thường với địa chỉ đích 10.2.1.100. Site này thuộc mạng VPN với RD:10. - R1 sẽ tra cứu bảng chuyển tiếp VPN của nó và dựa vào bảng này để gán nhãn cho gói tin, trong trường hợp này là nhãn 56. Nhãn này mang thông tin về đích đến của gói tin trong mạng VPN với RD:10 RD Prefix Destination PE Label 10 10.1.0.0/16 216.70.128.216 318 10 10.2.0.0/16 216.70.128.192 56 10 10.3.0.0/16 216.70.128.133 32 10 10.4.0.0/16 216.70.128.60 210 10 10.5.0.0/16 216.70.128.84 109 - R1 chuyển tiếp gói tin dựa vào địa chỉ PE đích trong bảng FIB (Label Forwarding Information Base). Khi gói tin này được chuyển đi, nó sẽ được gán một nhãn MPLS trong bảng LIB. Nhãn này (188) tương ứng với nhãn được yêu cầu để chuyển tiếp gói tin đến R2, có địa chỉ IP là 216.70.128.192. - LSR1 tiếp nhận gói tin và thưc hiện hoạt động chuyển mạch nhãn thông thường. Trong ví dụ này, LSR1 tráo đổi nhãn 188 với nhãn 62, sau đó chuyển tiếp gói tin đến LSR2. - LSR2 tiếp nhận gói tin và thực hiện chức năng Penultimate Hop Popping bởi vì đây là chặng cuối cùng trước khi gói tin đến PE đích, LSR2 sẽ loại bỏ nhãn (62) và gửi gói tin tới R2 với nhãn 56. - Sau khi R2 tiếp nhận gói tin, nó sẽ tra nhãn 56 trong bảng chuyển tiếp VPN, trong trường hợp này, nhãn sẽ tương ứng với RD:10. Sau đó, R2 tham chiếu địa chỉ IP trong gói tin để xác định ra đích đến là RD:10 với địa chỉ IP 10.2.1.100. R2 xác định RD:10 và địa chỉ IP:10.2.1.100 là thuộc site được liên kết trực tiếp với R2 bởi một liên kết IP thông thường nên nó sẽ loại bỏ nhãn và chuyển tiếp gói IP tới site đó. RD Prefix Destination PE Label 10 10.1.0.0/16 216.70.128.216 318 10 10.2.0.0/16 216.70.128.192 56 10 10.3.0.0/16 216.70.128.133 32 10 10.4.0.0/16 216.70.128.60 210 10 10.5.0.0/16 216.70.128.84 109 Chú ý rằng địa chỉ IP 10.2.1.100 và 216.70.128.192 khác nhau về phạm vi, địa chỉ IP 10.2.1.100 thuộc mạng VPN với RD:10 và chỉ những gói tin bên trong VPN này mới có thể đến được địa chỉ này. Có thể có một địa chỉ IP 10.2.1.100 khác ở các VPN khác, nhưng chúng được đặc trưng bởi những RD khác nhau. địa chỉ 216.70.128.192 thuộc mạng đường trục và nó không thuộc một VPN nào. Một trong những ưu điểm lớn nhất của các MPLS VPN là không đòi hỏi các thiết bị CPE thông minh bởi vì toàn bộ các chức năng VPN được thực hiện ở phía trong mạng lõi của nhà cung cấp dịch vụ và hoàn toàn “trong suốt” đối với các CPE. Các CPE không đòi hỏi chức năng VPN và hỗ trợ IPSec. điều này có nghĩa là khách hàng không phải chi phí quá cao cho các thiết bị CPE. Trễ trong mạng được giữ ở mức thấp nhất vì các gói tin lưu chuyển trong mạng không phải thông qua các hoạt động như đóng gói và mã hóa. Sở dĩ không cần chức năng mã hóa là vì MPLS VPN tạo nên một mạng riêng. Phương pháp bảo mật này gần giống như bảo mật trong mạng Frame Relay. Thậm chí trễ trong MPLS VPN còn thấp hơn là trong mạng MPLS IP sử dụng chuyển mạch nhãn Việc tạo một mạng đầy đủ (full mesh) VPN là hoàn toàn đơn giản vì các MPLS VPN không sử dụng cơ chế tạo đường hầm. Vì vậy, cấu hình mặc định cho các mạng MPLS VPN là full mesh, trong đó các site được nối trực tiếp với PE vì vậy các site bất kỳ có thể trao đổi thông tin với nhau trong VPN. Và thậm chí, nếu site trung tâm gặp trục trặc, các spoke site vẫn có thể liên lạc với nhau. Hoạt động khai thác và bảo dưỡng cũng đơn giản hơn trong mạng MPLS-VPN. Hoạt động này chỉ cần thực hiện tại các thiết bị bên trong mạng core mà không cần phải tiếp xúc đến các CPE. Một khi một site đã được cấu hình xong, ta không cần đụng chạm đến nó nữa cho dù nếu muốn thêm một site mới vào mạng vì những thay đổi về cấu hình lúc này chỉ cần thực hiện tại PE mà nó nối tới. Vấn đề bảo mật thậm chí còn đơn giản hơn nhiều khi triển khai trong các mạng MPLS VPN vì một VPN khép kín bản thân nó đã đạt được sự an toàn thông tin do không có kết nối với mạng Internet công cộng. Nếu có nhu cầu truy nhập Internet, một tuyến sẽ được thiết lập để cung cấp khả năng truy nhập. Lúc này, một firewall sẽ được sử dụng trên tuyến này để đảm bảo một kết nối bảo mật cho toàn bộ mạng VPN. Cơ chế hoạt động này rõ ràng dễ dàng hơn nhiều cho hoạt động quản lý mạng vì chỉ cần duy trì các chính sách bảo mật cho một firewall duy nhất mà vẫn đảm bảo an toàn cho toàn bộ VPN Một ưu điểm nữa của các mạng MPLS VPN là chỉ cần một kết nối duy nhất cho mỗi remote site. So sánh với mạng Frame Relay truyền thống có 1 nút trung tâm và 10 remote site (mỗi một remote site sẽ cần một Frame Relay PVC) thì tại nút trung tâm (hub) sẽ cần 10 PVCs. Trong khi bên trong một mạng MPLS VPN chỉ cần duy nhất một PVC tại vị trí hub trung tâm nên chi phí mạng sẽ giảm đáng kể. Chương 2: Giải pháp mạng riêng ảo của Check Point. Tường lửa Check Point là một trong những sản phẩm nổi tiếng hiện nay, sử dụng công nghệ Stateful Inspection. Tường lửa có vai trò quan trọng trong việc xây dựng hệ thống VPN. Trong hầu hết các trường hợp VPN được sử dụng để bảo mật thông tin khi truyền qua môi trường không tin cậy. Thiết bị VPN được tích hợp với tường lửa là lựa chọn tốt nhất, nếu để thiết bị VPN trước tường lửa thì nó sẽ không được bảo vệ trước các tấn công từ mạng Internet, nếu để thiết bị VPN sau tường lửa thì vô hình chung đã tạo ra một kết nối không bảo mật( không được ghi log, không được xác thực, không được lọc gói…) đi từ Internet vào mạng trong vì tường lửa không thể kiểm soát bên trong các gói tin đã bị mã hóa bởi VPN. Vì thế mà hầu hết các tường lửa của Check Point đều hỗ trợ tính năng VPN. Phiên bản Check Point NGX R70 hỗ trợ tính năng VPN rất tốt. 2.1. Giới thiệu về tường lửa Check Point 2.1.1. Kiến trúc tường lửa Check Point. Tường lửa Check Point gồm 3 thành phần chính: Smart Console, SmartCenter (Management), Security Gateway (Enforcement) Hình 38: Kiến trúc tường lửa Check Point Smart Console: cung cấp các giao diện để quản trị, được cài trên máy của nhà quản trị. Các thành phần của Smart Console bao gồm: - Smart DashBoad: cung cấp các giao diện để soạn thảo các các chính sách về Firewall, NAT, IPS, VPN … cho tường lửa. Hình 39: Smart DashBoard - SmartView Tracker: dùng để quản lý và xem các log Hình 40: SmartView Tracker - SmartView Monitor: để giám sát hoạt động của firewall như các kết nối VPN hiện thời, hiệu suất hoạt động của firewall, lượng gói tin vào ra firewall…. Hình 41: SmartView Monitor - SmartUpdate: để quản lý các gói và các licenses Hình 42: SmartUpdate SmartCenter (Management): để lưu trữ các chính sách được định nghĩa bởi SmartDashboard trong cơ sở dữ liệu. Bao gồm các đối tượng mạng được định nghĩa bởi quản trị, người dùng, chính sách bảo mật, các log files Security Gateway: là thành phần bắt buộc của filewall. Để thực thi các chính sách đã được soạn thảo ở SmartConsole, lưu trữ ở SmartCenter. 2.1.2. Các mô hình triển khai Mô hình Stand- alone Hình 43: Mô hình triển khai Stand-alone Theo mô hình này: - Thành phần SmartCenter Server và Security Gateway được cài đặt trên cùng một máy. - Thành phần SmartConsole được cài đặt trên máy người quản trị. Mô hình phân Distributed Hình 44. Mô hình triển khai Distributed Theo mô hình này thì: - Thành phần Smart Console cài trên máy nhà quản trị - Thành phần SmartCenter Server: cài trên một máy. - Thành phần Security Gateway cài trên một máy khác với máy cài SmartCenter Server. Truyền thông giữa các thành phần Các thành phần SmartConsole, SmartCenter Server, Security Gateway trao đổi, truyền thông với nhau thông qua SIC( Security Internal Communication). SIC làm nhiệm vụ: - Xác thực SmartConsole khi kết nối tới SmartCenter. - Kiểm tra chính sách bảo mật load trên Security Gateway đúng là lấy từ SmartCenter - Đảm bảo tính bí mật và toàn vẹn cho dữ liệu truyền giữa các thành phần sử dụng chứng chỉ số. Hệ điều hành SECUREPLATFORM của Check Point Chúng ta có thể cài đặt phần mềm tường lửa lên các hệ điều hành của hãng thứ 3 như Window, Solaris, tuy nhiên để tối ưu hoạt động nên cài đặt trên SecurePlatform – Hệ điều hành riêng cho tường lửa Check Point. Về cơ bản SecurPlatform là hệ điều hành dựa trên linux( linux based, kên 2.4 và 2.6), có thể cài đặt trên máy chủ , thiết bị của Check Point hay thiết bị của third-party. Việc cài đặt có thể boot từ ổ CD hoặc cổng USB. Cấu hình có thể qua giao diện dòng lệnh hoặc qua giao diện web sau khi cài đặt 2.2. Chức năng VPN của tường lửa Check Point 2.2.1. Cơ bản về chức năng VPN. Giải pháp VPN của Check Point chủ yếu dựa trên các chuẩn của IPSec. Thực thi VPN đảm bảo các liên kết an toàn giữa các gateway hoặc giữa gateway và một client . Security Gateway của Check Point là giải pháp phần mềm tích hợp cung cấp liên kết an toàn hợp nhất các mạng, người dùng di động, và người dùng từ xa, các cơ quan, chi nhánh và đối tác kinh doanh trong một dải rộng các nền mở( open platform ) và các công cụ an toàn ( security appliances). Các Security Gateway của Check Point tích hợp kiểm soát truy nhập, xác thực, và mã hóa để đảm bảo an toàn cho các kết nối qua mạng công cộng Internet. Một triển khai điển hình là một Security Gateway kết nối với mạng công ty, và phần mềm truy cập từ xa cài đặt trên máy xách tay của người dùng di động. Những site khác được bảo vệ bằng những Security Gateway khác và truyền thông giữa tất cả các thành phần được kiểm soát và điều chỉnh bởi một chính sách an toàn chặt chẽ. 2.2.1.1. Các thành phần VPN VPN Endpoints( các điểm đầu cuối) , được biết như các gateway, nhóm các gateway, hoặc phần mềm client từ xa, là các thành phần tạo nên kết nối VPN VPN trust entities( các thực thể tin cậy): như các ICA( Internal Certificate Authority). ICA là một thành phần của Check Point được sử dụng để thiết lập sự tin cậy cho cho các kết nối giữa các gateway , xác thực các quản trị, và máy chủ thứ 3 tin cậy. ICA cung cấp chứng chỉ cho các gateway bên trong và client truy cập từ xa – các thành phần của kết nối VPN. VPN Management tool( các công cụ quản trị): máy chủ Security Management và SmartDashboard. SmartDashboard là SmartConsole được sử dụng để truy cập tới máy chủ Security Management. VPN Manager là một phần của SmartDashboard. SmartDashboard cho phép tổ chức định nghĩa và triển khai mạng nội bộ Intranet, và các VPN truy cập từ xa. 2.2.1.2. Các thuật ngữ, khái niệm đặc trưng. - VPN: một mạng riêng được cấu hình trong một mạng công cộng như Internet. - VPN tunnel: một kênh dành riêng hoặc liên kết được mã hóa giữa các gateway. - VPN Topology: yếu tố cơ bản của VPN là liên kết hoặc kênh được mã hóa. Các liên kết được tạo giữa các gateway. Tập hợp các kết nối này tạo thành topology . Topology thể hiện sơ đồ của VPN. Có 2 topology cơ bản trong VPN là Mesh và Star. - VPN gateway: điểm đầu cuối của kết nối được mã hóa, nơi mà có thể là bất kỳ thành phần nào hỗ trợ nền giao thức IPSec, các gateway có thể là các module độc lập, đơn lẻ được sắp xếp trong một tập hợp của “ tính sẵn sàng cao và sự phân chia tải” - VPN Domain: là một nhóm trong đó chỉ rõ các host hoặc mạng cho việc mã hóa các gói IP được thực thi. Một VPN gateway cung cấp một lối vào VPN domain. - Site to site VPN: là một đường hầm VPN giữa các gateway - Remote Access VPn: nói đến những người dùng từ xa truy cập mạng sử dụng phần mềm SecuRemote/SecureClient hoặc các client IPSec của bên thứ 3. Security Gateway cung cập dịch vụ truy cập từ xa cho người dùng từ xa. - Encryption Algorithm(giải thuật mã hóa): một tập hợp các quy trình biểu diễn toán học cho việc biểu diễn thông tin thành một dạng vô nghĩa, sự biến đổi và chuyển hóa toán học được điểu khiển bởi một khóa đặc biệt. Trong VPN, các thuật toán mã hóa bao gồm 3DES, AES đảm bảo chỉ các bên tham gia truyền thông mới có khả năng hiểu được bản tin. - Integrity(tính toàn vẹn): sự kiểm tra tính toàn vẹn đảm bảo thông báo không bị chặn bắt và thay đổi trong suốt quá trình truyền. - Trust( tính tin cậy): PKI , chứng chỉ và thẩm quyền chứng chỉ được tận dụng để thiết lập tính tin cậy giữa các gateway. - IKE và IPSec: các giao thức VPN an toàn sử dụng để quản lý các khóa mã hóa, và trao đổi các gói mã hóa. IPSec là một nền công nghệ mã hóa hỗ trợ các chuẩn khác nhau cung cấp các dịch vụ xác thực và mã hóa cho dữ liệu. IKE là giao thức chuẩn cho việc quản lý khóa. IKE nâng cao IPSec bằng việc cung cấp các thành phần phụ, tính mềm dẻo và dễ cấu hình. 2.2.1.3. Site to site VPN Trung tâm của VPN là một đường hầm được mã hóa, được tạo sử dụng giao thức IKE/IPSec. Hai bên là các Security Gateway hoặc các client truy cập từ xa. Mỗi bên trước tiên thương lượng một liên kết tạo sự tin cậy giữa chung. Tin cậy này được thiết lập sử dụng CA, PKI hoặc pre-sharekey. Các phương thức được trao đổi và các khóa được tạo. Đường hầm mã hóa được thiết lập và sau đó được duy trì cho nhiều kết nối, việc trao đổi khóa cần thiết cho việc mới các khóa khi cần. Một gateway đơn lẻ duy trì nhiều đường hầm đồng thời với các thành phần VPN của nó. Luồng dữ liệu trong mỗi đường hầm được mã hóa, xác thực, đảm bảo tính toàn ven, bí mật. Dữ liệu được truyền với lưu lượng lớn thông qua các kết nối vật lý ảo. 2.2.1.4. VPN Communities( cộng đồng VPN ) Có 2 kiểu cộng đồng cơ bản: Mạng lưới ( Mesh) và hình sao ( star). Một topology là tập hợp các liên kết VPn có thể trong một hệ thống các gateway, các VPN domian của chúng, host đặt sau mỗi gateway và các client từ xa bên ngoài tới chúng. Trong cộng đồng Mesh, mỗi gateway có một liên kết tới gateway khác. Trong cộng đồng Star chỉ cac gateway được định nghĩa như các vệ tinh( Satellites hay Spoke) được phép truyền thông với gateway trung tâm( Hub ) nhưng không được truyền thông với gateway khác. Hình 45 Hai kiểu cộng đồng VPN 2.2.1.5. Remote Access VPN Mỗi khi người dùng truy cập tới tổ chức từ các khu vực từ xa, các yêu cầu về kết nối an toàn là cần thiết. SecuRemote/SecureClient mở rộng tính năng VPN tới người dùng từ xa, cho phép họ truyền thông tin nhạy cảm một cách an toàn qua đường hầm VPN. Người dùng được quản lý trong CSDL bên trong của Security Gateway hoặc qua một LDAP server bên ngoài. Hình 46. Client từ xa tới host đằng sau gateway. 2.2.2. Giao thức trao đổi khóa Internet – IKE(Internet Key Exchange). Bản thân giao thức IPSec không có khả năng thiết lập SA. Do đó quá trình được chia làm 2 phần: IPSec cung cấp xử lý ở mức gói và giao thức quản lý trao đổi khoá Internet thoả thuận các SA, IKE được chọn làm giao thức chuẩn để thiết lập các SA cho IPSec. IKE tạo ra một đường hầm được xác thực và mã hoá, sau đó là thoả thuận SA cho IPSec. Quá trình này yêu cầu hai hệ thống xác thực lẫn nhau và thiết lập các khoá sử dụng chung. IKE trợ giúp các nhóm liên lạc thương lượng các tham số bảo mật và các khoá xác thực trước khi một phiên IPSec an toàn được thực thi. Các tham số bảo mật được thương lượng này sẽ được định nghĩa một lần trong SA. Ngoài việc thương lượng và thiết lập các tham số bảo mật và các khoá mật mã, IKE cũng thay đổi các tham số và khoá khi được yêu cầu trong một phiên làm việc, IKE cũng chịu trách nhiệm xoá các khoá và các SA này sau khi một phiên truyền tin được hoàn tất. Những ưu điểm chính của IKE bao gồm: - IKE không phục thuộc vào công nghệ. Vì vậy nó có thể được dùng với bất kỳ cơ chế bảo mật nào. - IKE mặc dù không nhanh, nhưng hiệu quả cao vì một số lượng lớn các SA được thương lượng với một số thông điệp vừa phải. Theo cấu trúc làm việc của ISAKMP. IKE làm việc qua hai pha. Hai pha trao đổi khoá sẽ tạo ra IKE SA và một đường hầm an toàn giữa hai hệ thống. Một phía sẽ đưa ra một trong các thuật toán, phía kia sẽ chấp nhận hoặc loại bỏ kết nối. Khi hai bên đã thống nhất được các thuật toán sẽ sử dụng thì chúng sẽ tạo khoá cho IPSec. IPSec sử dụng một khoá dùng chung khác với khoá của IKE, khoá này có được nhờ sử dụng thuật toán Diffie-Hellman một lần nữa hoặc sử dụng lại khoá dùng chung có được từ trao đổi Diffie-Hellman ban đầu. Sau khi quá trình được hoàn tất thì IPSec SA được thiết lập. Quá trình thực hiện IKE gồm 2 pha, đó là : IKE Phase I và IKE Phasse II 2.2.2.1. IKE Phase1 Trong suốt pha IKE I -Các bên xác thực sử dụng chứng chỉ hoặc khoá bí mật đuợc chia sẻ. -Một khoá Diffie-Hellman được tạo ra.Với giao thức Diffie-Hellman các bên tạo ra khoá bí mật đuợc chia sẻ một cách độc lập và chỉ có các bên biết. -Yêú tố khoá (các bit ngẫu nhiên và dữ liệu toán học khác) cũng như thoả thuận cách thức cho pha IKE II được trao đổi giữa các bên.Về mặt hiệu suất, sự sinh khoá Diffie-Hellman chậm và nặng.Kết quả của pha này là IKE SA,là sự thoả thuận khoá và cách thức cho pha IKE II. Hình 47. IKE Phase1 a.Thống nhất thuật toán mã hóa, xác thực Packet 1 : A gửi cho B thông điệp UDP port 500 chứa các giao thức, thuật toán để B chọn, Chứa một giá trị ngẫu nhiên CookieA(Initiator) trong ISAKMP header Hình 48. Gói tin đề xuất các thuật toán Transform 1 Packet 2 : B lựa chọn thuật toán và khởi tạo cookieB. Hình 49. Gói tin lựa chọn thuật toán b. Trao đổi khóa : tạo khóa mật chung sử dụng Diffie Hellman IKE sẽ sử dụng thuật toán Diffie- Hellman (DH) để tạo một khoá bí mật dùng chung giữa bên A và bên B. - Bên A gửi: + Số nguyên tố lớn N. + Số g là một phần tử nguyên thuỷ của Z*N . + Hàm f(x)= gX mod N với X là số ngẫu nhiên thuộc Z*N do A chọn và gửi f(x) cho B. - Bên B chọn ngẫu nhiên y thuộc Z*N và tính f(y) = gY mod N rồi gửi cho A. Sau khi nhận được giá trị f(x), bên B tính SB = f(x)Y mod N. Còn A, sau khi nhận được giá trị f(y) của B, A tính: SA = f(y)X mod N. Khóa chung bí mật là SB = SA = S -> Khóa bí mật dùng chung được tạo từ khóa riêng của bên này và khóa công khai của bên kia. c. xác thực đối tác Trong trao đổi này hai bên trao đổi các thông tin nhận dạng của nhau thông qua chữ ký số. Messeage 3 được gửi để nhận dạng. IP Header UDP Header ISAKMP Header Identity Certificate Signature Các thông tin nhận dạng là các trường sau: Identity, Certificate, Signature đã được mã hóa bằng các giao thức, thuật toán được xác định tại bước trao đổi thức nhất và các khoá chung bí mật đã được thiết lập ở bước trao đổi khoá bí mật. 2.2.2.2. IKE Phase 2 IKE Phase hai có tác dụng: - Thoả thuận các tham số bảo mật IPSec, các tập chuyển đổi IPSec (IPsec Transform Sets) để bảo vệ đường hầm IPSec. - Thiết lập các thoả thuận bảo mật IPSec SA. - Định kỳ thoả thuận lại IPSec SA để đảm bảo tính an toàn của đường hầm. - Thực hiện trao đổi Diffie-Hellman bổ sung (tạo ra các khoá mới). Hình 50. IKE Phase2a Khóa IPSec được tạo thì dữ liệu được mã hóa và chuyển đi. Hình 51 Đường hầm VPN 2.2.2.3. Các phương pháp mã hóa và đảm bảo tính toàn vẹn - Hai tham số quyết định trong suốt quá trình đàm phán: + thuật toán mã hóa + thuật toán băm. Hình 52. Các thuật toán mã hóa, toàn vẹn của IKE NULL: chỉ kiểm tra tính toàn vẹn,gói tin không được mã hoá. Diffie Hellman Groups Sự tính toán khoá Diffie-Hellman dựa trên nhóm toán học Diffie-Hellman. Các nhóm DH được hỗ trợ bởi một gateway an toàn trong suốt quá trình thực hiện hai pha IKE: Một nhóm với nhiều bit hơn đảm bảo khoá khó bị bẻ gãy nhưng thực hiện với chi phí cho hiệu suất cao thực hiện bởi vậy việc tính toán đòi hỏi số vòng quay CPU nhiền hơn. 2.2.2.4. Các chế độ trong Phase 1 Gồm main mode và agressive mode. Gateway mặc định sử dụng main mode( 6 gói tin được trao đổi) vì : trong chế độ này chỉ mã hóa các gói tin sau khi khóa DH được phân phối giữa 2 bên (khóa dùng chung). Ít bị tấn công DoS vì khóa dùng chung được tính sau khi xác thức. Còn trong chế độ Agressive mode thì tính khóa dùng chung và xác thực thực hiện song song. Bên chưa được xác thực có thể tính khóa DH nhanh hơn bên kia.. Khi làm việc với remote access, IKE thêm vào 2 chế độ : Hybrid mode : thêm vào IKE phase 1, gateway cho phép xác thực sử dụng certificate và SecurID. Office mode : mở rộng cảu IKE protocol. Sử dụng để giải quyết vấn đề định tuyến giữa remote access client và VPN domain. Trong quá trình thương lượng K+IKE, chế độ config mode xen vào giữa IKE phase 1 và phase 2. Trong quá trình Config Mode  client yêu cầu IP từ gateway, -> gateway gán IP-> client tạo card ảo trong HĐH. Renegotiating IKE & IPSec Lifetimes IKE SA chỉ có giá trị trong khoảng thời gian nhất định. IPSec SA có thời gian sống( lifetime ) ngắn hơn IKE SA. -> có thể thay đổi lifetime sử dụng Dbedit để sửa file object_5_0.c. ike_p2_use_rekey_kbytes. Change from false (default) to true. ike_p2_rekey_kbytes. Modify to include the required rekeying value (default 50000). IP Compression: để giảm kích thước gói dữ liệu -> cải thiện tốc độ. IPSec hỗ trợ giải thuật nén- giải nén Flate/Deflate. IKE Phase 2 quyết định nén hay ko . mặc định IP comrpress disalbe. Với các client SecuRemote/SecureClient sử dụng kết nối chậm -> IP Compress là quan trọng. Với kết nối dialup -> nén để tăng tốc độ liên kết. Nếu gateway mã hóa gói tin ở chế độ Mixed up -> dữ liệu ko thể nén. Gói tin được nén trước khi mã hóa. 2.2.2.5. Bảo vệ lại tấn công DoS IKE Từ chối dịch vụ (DoS) là việc cố ý làm giảm khả năng thi hành của những người sử dụng hợp pháp tới các dịch vụ trên mạng, hoặc thậm chí đánh sập một dịch vụ . Họ không trực tiếp đe doạ an ninh theo nghĩa những thông tin bí mật bị tiết lộ, và không thể sử dụng đặc quyền của người dùng trái phép. Tuy nhiên, họ tiêu tốn tài nguyên máy tính như là bộ nhớ hay CPU. Nói chung, có 2 phương pháp tấn công DoS chính. Loại thứ nhất bao gồm gửi đi những gói tin kỳ dị tới dịch vụ với hi vọng khai thác được một lỗi nào đó và đánh sập dịch vụ. Loại thứ 2, kẻ tấn công cố gắng khai thác điểm yếu của dịch vụ hoặc giao thức bằng việc gửi đi số lượng lớn những gói tin. IKE DoS attack Protection giải quyết phương thức tấn công thứ 2. IKE DoS attack IKE yêu cầu gateway sắp xếp tài nguyên cho các gói của IKE ở pha 1. Gateway trả lời lại và nhận gói khác sau khi nó xử lý toàn bộ thông tin từ gói đầu tiên. Attacker có thể gửi nhiều gói IKE thứ nhất với các IP source khác nhau -> gateway nhận được -> reply lại từng gói -> cấp phát tài nguyên cho mỗi gói. Các gói tin của kẻ tấn công chiếm toàn bộ tài nguyên CPU của gateway. Nên người dùng hợp pháp không thể kết nối gateway không thể đáp ứng các yêu cầu kết nối của người dùng hợp pháp. Attacker gửi các gói IKE giả mả mạo các máy hợp pháp (được khép khởi tạo quá trình bắt tay IKE) -> giả mạo IP source. Attacker có thể giả mạo IP của gateway để nhận các gói của client. -> unidentifed source. Bảo vệ Defense Against IKE DoS Attacks: khi số kết nối thương lượng IKE đồng thời quá ngưỡng ( threshold) -> cho là tấn công DoS. Gateway có thể lọc các trường hợp của tấn công DoS. Có 2 cách: - stateless : Gateway ko cấp phát tài nguyên cho tới khi client chứng minh là hợp pháp với gateway. Tiến trình xử lý : 1. Nếu gateway kết luận rằng nó là liên quan đến tấn công DoS , nó nhận yêu cầu IKE, nó reply lại với gói tin chứa số mà chỉ gateway có thể sinh ra. Gateway sau đó “forgets” yêu cầu IKE đó. Thực tế nó ko cần lưu trữ yêu cầu IKE đó trong bộ nhớ (gọi là stateless) 2. nếu máy client nhận gói tin reply của gateway câpnf khởi tạo lại IKE requets bằng cách gửi IKE request khác chứa định số mà gateway sinh ra. 3. nếu gateway nhận được gói IKE requets chứ number của mình -> tiếp tục quá trình thương lượng IKE - Puzzeles(thách đố) : Gateway yêu cầu client phân giải một lượng lớn Puzzele. Các máy client thông thường chỉ có thể solve một vài Puzzele trong một giây. Nếu kẻ tấn công gửi nhiều gói tin IKE cùng lúc thì hạn chế được tấn công DoS. Enable chức năng trên gateway Hình 53. Cấu hình các tùy chọn chống IKE DoS Attack Một số cấu hình, mở rộng các trên gateway . Sử dụng Dbedit Thayđổi các giá trị : ike_dos_threshold, ike_dos_puzzle_level_identified_initiator, 2.2.3. Cơ sở hạ tầng khóa công khai PKI Bằng cách sử dụng chứng chỉ số các thực thể tham gia truyền thông có thể thiết lập mối quan hệ tin cậy với nhau, có thể xác thực lẫn nhau. Chứng chỉ số do một cơ quan có thẩm quyền cấp gọi là CA(Certificate Authority)- một thành phần cơ bản của cơ sở hạ tầng khóa công khai. CA phát hành các chứng chỉ số - chứng chỉ khóa công khai cho mỗi thực thể. Để kiểm tra, xác thực đối tượng tham gia truyền thông , kiểm tra chứng chỉ của thực thể đó -> kiểm tra chữ ký của CA trên chứng chỉ cấp cho đối tượng đó. Các chuẩn IKE khuyến cáo sử dụng PKI trong môi trường VPN nếu yêu cầu xác thực mạnh Các gateway – một đầu cuối của VPN tunnel có cặp khóa RSA và chứng chỉ được sinh bởi một CA tin cậy. Khi 2 thực thể thiết lập VPN tunnel (giữa 2 gateway với nhau, hoặc giữa gateway và remote user), để xác thực lẫn nhau, chúng có thể kiểm tra chứng chỉ số của nhau. Mỗi khi cài đặt một máy chủ Check Point Security Management, một thành phần ICA(Internal Certificate Authority) – chịu trách nhiệm phát hành chứng chỉ sử dụng cho VPN được cài đặt theo. Khi bật chức năng IPSec VPN trên sản phẩm checkpoint -> ICA được khởi tạo Check Point Security Gateway cũng hỗ trợ nhiều hệ thống PKI ở ngoài cho môi trường VPN. Bao gồm: Nhiều CA trên cùng một VPN tunnel: 2 gateway thiết lập tunnel với nhau, nhưng có thể sử dụng các chứng chỉ số được cấp bởi các CA khác nhau để xác thực lẫn nhau. Hỗ trợ Non-ICA: như External ICA- ICA của một server quản lý an toàn khác. - CA phân cấp: Phương pháp xác thực sử dụng chứng chỉ số, là phương pháp mạnh, nhưng đòi hỏi pải có một cơ sở hạ tầng khóa công khai chịu trách nhiệm quản lý các vấn đề liên quan đến chứng chỉ. Vì vậy tùy thuộc vào mục đích, quy mô, yêu cầu của tổ chức mà có thể lựa chọn các hệ thống PKI phù hợp( triển khai một hệ thống PKI, hay sử dụng một hệ thống tin cậy bên ngoài) Chương 3: Triển khai VPN trên Check Point. 3.1 Mô hình VPN Remote Access. 3.1.1. Mô hình Mô hình bao gồm: - Remote User ở địa chỉ 10.0.0.5/24 - Tường lửa Check Point- R70: 2 card mạng. IP External: 10.0.0.1/24 IP Internal: 172.16.1.1/24 - LDAP Server – Active Directory của Window.: 172.16.1.2/24 - Máy chủ ứng dụng: web server, file server, mail server: 172.16.1.3 Hình 54. Mô hình VPN Remote Access Các bước cấu hình Khi chưa cấu hình gì , mặc định Remote User không được phép truy cập tài nguyên bên trong mạng 172.16.1.0/24 Các bước cấu hình cơ bản Phía gateway: 1. định nghĩa gateway 2. quản lý các user 3. cấu hình VPN community và participant(các bên tham gia) 4. thiết lập các rule điều khiển truy nhập thích hợp trong Security Policy Rule base 5.Cài đặt Policy trên gateway Phía remote client 1. định nghĩa site 2. Đăng tý với Internal CA để nhận chứng chỉ(nếu cần thiết) 3 kết nối tới site. Hình 55. Các bước cấu hình VPN Remote Access 3.1.2.1 Cấu hình VPN Remote Access sử dụng xác thực Pre-share key. Phía gateway: Bước 1: Enable chức năng VPN trên tường lửa Checkpoint Hình 56: Bật chức năng VPN trên tường lửa Check Point Khi enable chức năng IPSec VPN thì tự động có một lớp mạng sinh ra –sử dụng cho office mode -> có thể sử dụng dải IP này để cấp cho các máy client khi thiết lập vpn tới gateway. Hình 57. Dải địa chỉ tự do hệ thống sinh ra khi bật chức năng VPN Cấu hình cấp IP cho các máy client (office mode) Hình 58. Cấu hình Office Mode Bước 2: Tạo người dùng trên gateway. Sử dụng phương pháp xác thực pre-sharekey. (pre-share key ở đây chính là password của người dùng.) Tạo user: vpn Password: abc@123 Hình 59. Tạo User trên gateway Bước 3: tạo group vpns, add người dùng vpn vào nhóm vpns Bước 4: Định nghĩa VPN Community và Participants. Hình 60. Định nghĩa VPN Community và Participants Bước 5: Tạo luật kết nối VPN client- to –site Hình 61. Tạo luật kết nối VPN client- to –site Bảng luật như sau Hình 62. Bảng luật cho remote Access Phía Client: máy remote user có địa chỉ 10.0.0.5/24 Hình 63. Địa chỉ IP của Remote User B1: cài đặt SecureClient. Cài đặt gói Check Point VPN-1 SecuRemoteSecureClient NGX R60 HFA2.msi ở chế độ SecureClient. Hình 64. Cài đặt SecureClient B2: tạo site kết nối tới gateway - Khai báo tên hoặc địa chỉ của gateway Hình 65. Tạo Site trên máy Remote User - Chọn phương pháp xác thực - Khai báo user/password- presharekey(nếu chọn phương pháp xác thực user/password) - lựa chọn kiểu cài đặt kết nối - gửi các tham số tới gateway - Server trả về -> thiết lập ban đầu thành công. Kiểm tra kết quả: từ máy client-> thực hiện kết nối tới gateway – sử dụng xác thực preshare-key(password của người dùng.) -> truy cập tài nguyên trong máy ở địa chỉ 172.16.1.2. Hình 66: Thực hiện kết nối từ máy client - Kết nối thành công - Xem địa chỉ máy remote user nhận được khi thiết lập kết nối vpn với gateway Truy cập tài nguyên trong mạng private - truy cập website trong mạng private ở địa chỉ 172.16.1.3 Hình 67. Test kết quả sau khi kết nối VPN remote access - truy cập tài nguyên chia sẻ ở địa chỉ 172.16.1.3 3.1.2.2. Cấu hình xác thực sử dụng certificate Phía gateway - sinh chứng chỉ cho user – vpn. Hình 68. Khởi tạo chứng chỉ cho user Tạo và lưu ra file -> chuyển cho người dùng bằng con đường nào đó - Nhập password bảo vệ chứng chỉ. - lưu chứng chỉ ra định dang *.p12 - Chuyển chứng chỉ cho người dùng. Phía máy client. Thay đổi phương pháp xác thực sử dụng certificate. - Thực hiện kết nối -> khai báo password bảo vệ chứng chỉ Hình 69. Kết nối VPN Remote Access sử dụng chứng chỉ - Kết nối thành công 3.1.2.3 Cấu hình sử dụng tài khoản domain (ldap user ) để thực hiện kết với VPN tới gateway 1. Cấu hình phía gateway - Tạo Ldap server: sử dụng máy chủ domain controler của window. - trên gateway: tạo tài khoản ldap. Hình 70. Tạo tài khoản ldap trên gateway - Load các tài khoản từ ldapserver về 2. Phía client quay số bằng toài khoản trên ldap server. Trên ldapserver có tài khoản user2. Thực hiện quay số bằng toài khoản user2. (sử dụng xác thực preshare key hoặc certificate) Kết nối bằng tài khoản user2 thành công Hình 71. Kết nối bằng tài khoản của ldap server - Nếu trên máy client không cài đặt SecureClient/SecureDesktop thì có thể sử dụng trình duyệt web để truy cập SSL- VPN tới gateway. 3.1.2.4. Cấu hình cho phép sử dụng SSL để thiết lập kết nối VPN Phía gateway: cấu hình để cho phép SSL VPN - cấu hình SSL Clients Hình 72. Cấu hình SSL clients - cấu hình SSL clients - Cấu hình Visitor mode Phía remote user chỉ cần trình duyệt web là có thể thiết lập vpn với gateway - Từ trình duyệt truy cập vào gateway qua https Hình 73. Kết nối SSL VPN - Nếu là kết nối lần đầu tiên thì máy client tự động cài đặt SSL Network Extender - Gateway cấp IP cho client. Kết nối SSL-VPN thành công. Remote user truyền thông với VPN domain qua kênh vừa được thiết lập. 3.2. Mô hình VPN Site- to- Site( Extranet VPN) 3.2.1. Mô hình Site 1 bao gồm - GW1: tường lửa Check Point có 2 card mạng. IP External:10.0.0.1/24 IP Internal: 172.16.1.1/24 - LDAP Server1: chạy dịch vụ Active Diretory của Window. IP: 172.16.1.2/24 - Application Server: Làm web server, mail server, File server. IP: 172.16.1.3/24 - Host1- máy client IP: 172.16.1.4/24 Site 2 bao gồm - GW2: tường lửa Check Point có 2 card mạng IP External: 10.0.0.2/24 IP Internal: 172.16.10.1/24 - LDAP Server2: chạy dịch vụ Active Diretory của Window. IP: 172.16.10.2/24 - Application Server 2: Làm web server, mail server, File server. IP: 172.16.10.3/24 - Host2- máy client IP: 172.16.10.4/24 Hình 74. Mô hình VPN Site-to-Site 3.2.2. Các bước cấu hình Khi chưa cấu hình thì mặc định giữa 2 site không thể liên lạc hay truy cập vào tài nguyên của nhau được. Các bước cấu hình VPN site – to site PreShare Key : làm tại site 1 , site 2 tương tự. Trước hết phải enable chức năng IPSec- VPN trên cả GW1, GW2 Bước 1: Thiết lập miền VPN. Hình 75. Thiết lập VPN domain Theo hình trên thì các kết nối của VPN site to site được phép truy nhập đến tài nguyên trong mạng LAN1(172.16.1.0/24) Bước 2: Đưa tường lửa vào VPN Community Hình 76. Đưa tường lửa vào VPN Community Bước 3: Tạo đối tượng mạng, tường lửa đối tác - Tạo đối tượng mạng đối tác LAN10– 172.16.10.0/24 Hình 77. Tạo mạng đối tác - tạo tường lửa đối tác Hình 78. Tạo tường lửa đối tác - Nhập các thông tin cho tường lửa đối tác: topology, VPN domain. - Đưa tường lửa đối tác vào cộng đồng VPN. Bước 4: Cấu hình cộng đồng VPN MyIntranet. Hình 79. Cấu hình cộng đồng VPN MyIntranet - Kiểm tra chỉ có GW1(win2k3) và GW2(gateway2) trong Participant Gateway - cấu hình khóa bí mật chi sẻ với GW2. trên GW2 cũng phải cấu hình giá trị này mới có thể thiết lập tunnel với GW1. Hình 80. Cấu hình Presharekey giữa 2 gateway Bước 5: Tạo luật cho kết nối VPN. Tạo luật site- to- site Hình 81. Tạo luật cho VPN site-to-site Làm tương tự 5 bước bên GW2 Kiểm tra kết quả sau khi cấu hình VPN site to site. - Kiểm tra tunnel được tiết lập giữa 2 site: sử dụng SmardView Monitor Hình 82. Kiểm tra tunnle được tạo bằng SmartViewMonitor - từ host trên site 1 truy cập webserver trên site 2: từ máy 172.16.1.4 truy cập webserver trên máy 172.16.10.3. Hình 83. Test kết quả VPN site-to-site Như vậy kết nối VPN site to site thiết lập giữa GW1 và GW2 thành công. Chương 4: Một số vấn đề an toàn của Check Point 4.1. Xung đột địa chỉ IP trong cấu hình VPN-Tunnel Lỗi sảy ra với các phiên bản NGX R60, NGX R61, NGX R62, NGX R65, NG AI R55. Xung đột về địa chỉ IP sảy ra giữa các Remote Client và IP của một miền mã hóa có thể từ chối các kết nối mới. Đây chính là một dạng tấn công DoS. Các kết nối VPN Remote Access sẽ phá các kết nối VPN site-to-site. 4.1.1. Mô hình. Hình 84. Mô hình tấn công DoS Bao gồm Site1 - GW1: có 2 card mạng IP ex: 10.0.0.11/24 IP In: 172.16.1.1/24 Host1: 172.16.1.3/24 Site2 - GW2: có 2 card mạng IP Ex: 10.0.0.2/24 IP In: 172.16.10.1/24 Host2: 172.16.10.3/24 - Phía remote user: đứng sau một thiết bị NAT như moderm ADSL. Chúng ta có thể lấy một máy ảo linux là thiết bị NAT. Ở đây chúng em sử dụng máy ảo centos có 2 card mạng IP Ex: 10.0.0.3/24 IP In: 172.16.10.1/24 Remote User ở địa chỉ: 172.16.10.3/24 trùng với Host2. Trên máy của Remote User cài đặt gói SecureRemote- không hỗ trợ chế độ office mode. 4.1.2. Các bước thực hiện tấn công DoS như sau. Thực hiện trên phiên bản NGX R65. - Thiết lập từng kết nối VPN bình thường. - Kiểm tra từng kết nối VPN Remote Access thành công. Ngắt kết nối Remote Access - Kiểm tra kết nối VPN site-to-site thành công. - Host 1 và Host 2 đang trao đổi dữ liệu với nhau. - Máy Remote User thực hiện kết nối VPN đến GW1 thì quá trình trao đổi dữ liệu giữa Host1 và Host2 sẽ bị lỗi. Do tunnel giữa GW1 và GW2 bị kết nối của Remote User chiếm đoạt. 4.1.3. Giải pháp. Việc xung đột địa chỉ IP sảy ra trong quá trình tạo các SAs của Phase2 cho các tunnel site-site và client-site. Quá trình thượng lượng Phase2 của tunnel Client-site sẽ đè lên hoặc chiếm quyền ưu tiên quá trình thương lượng Phase2 site-site . Để khắc phục kiểu tấn công trên: sử dụng một trong 2 cách sau cấu hình Office Mode trên GW1. Giải mạng của Office mode không được trùng với miền mã hóa của bất kỳ Gateway nào có thiết lập tunnel site-site với nó. Nếu không sử dụng Office Mode thì có thể download các HotFix được CheckPoint cung cấp Kết luận Cùng với sự phát triển không ngừng của khoa học kỹ thuật và kinh tế thế giới, nhu cầu truyền thông an toàn của con người và các tổ chức ngày càng cấp thiết. Công nghệ Mạng riêng ảo đã ra đời và ngày càng khẳng định vai trò quan trọng và thiết thực của nó trong việc đảm bảo an ninh thông tin, cũng như hoạt động mạng của con người Qua đề tài mạng riêng ảo và giải pháp mạng riêng ảo của Check Point nhóm em đã phần nào hiểu được Công nghệ VPN vài triển khai được VPN trên tường lửa Check Point. Chúng em hoàn thành với các nội dung cơ bản sau : Tìm hiểu về công nghệ mạng riêng ảo : chúng em nhận biết được VPN là gì, các mô hình VPN thông dụng, các giao thức thường sử dụng trong VPN. Tìm hiểu về giải pháp mạng riêng ảo của Check Point  thông qua sản phầm NGX R70. Xây dựng thành công 2 mô hình mạng riêng ảo Remote Access, Site-to-Site. Một số vấn đề an toàn (trên phiên bản NGX R65) : thử nghiệm tấn công DoS giữa các kết nối VPN Remote Access và Site-to-site. Trên đây là kết quả còn rất mà chúng em đạt được trong đề tài của mình . Nhóm rất mong được sự đóng góp và hướng dẫn của thầy cô và các bạn để nhóm em có thể nắm bắt được sâu hơn về VPN và Giải pháp VPN của CheckPoint. Nhóm em xin chân thành cảm ơn ! Nhóm nghiên cứu khoa học. Tài liệu tham khảo Giáo trình An toàn mạng riêng ảo- Học Viện Kỹ thuật Mật Mã Đồ an tốt nghiệp đại học " Nghiên cứu về mạng riêng ảo và xây dựng giải pháp mạng riêng ảo đảm bảo an toàn cho các hoạt động mạng sử dụng tường lửa Check Point " Cán bộ hướng dẫn : ThS.Hoàng Sỹ Tương hướng dẫn. Sinh viên thực hiện : Lê Thị Hồng Vân Giáo trình thực hành an toàn mạng – Học viện Kỹ Thuật Mật Mã IPSec VPN Design By Vijay Bollapragada, Mohamed Khalid, Scott Wainner MPLS VPN Security By Michael H. Behringer, Monique J. Morrow Layer 2 VPN Architectures By Wei Luo, - CCIE No. 13,291, Carlos Pignataro, - CCIE No. 4619, Dmitry Bokotey, - CCIE No. 4460, Anthony Chan, - CCIE No. 10,266 Comparing, Designing, and Deploying VPNs By Mark Lewis, - CCIE No. 6280 Tài liệu đi kèm ISO NGX- R70 của CheckPoint website https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk34579. Internet.