Dùng chứng chỉ Client doc

Dùng chứng chỉ Client Trong phần này, chúng ta sẽ cố gắng truy cập đường dẫn URL của website một lần nữa. Nếu phần trên đã hoàn thành một cách thành công, mỗi lần được yêu cầu, chúng ta có thể xem và chọn chứng chỉ đã được thiết lập từ danh sách, như hình 6 bên dưới: Hình 6. Chọn chứng chỉ client khi đã làm xong nền. Chọn chứng chỉ client khi đã làm xong nền. Sau khi chọn xong chứng chỉ, người dùng phải nhập mật khẩu yêu cầu để giải mã khoá private tương ứng, như trong hình 7: Hình 7. Nhập cụm mật khẩu cho chứng chỉ. Nhập cụm mật khẩu cho chứng chỉ. Bây giờ, chúng ta truy cập vào website an toàn, như minh hoạ trong hình 8: Hình 8. Truy cập an toàn, dùng chứng chỉ đã được chấp nhận. Truy cập an toàn, dùng chứng chỉ đã được chấp nhận. Điều khiển truy cập tuỳ biến Với các thư mục thêm server-side, chúng ta có thể điều khiển các phần website của cá nhân hoặc một nhóm người dùng được thông qua hay bị từ chối. Ví dụ khi một tổ chức phải giao dịch một cách an toàn với nhiều công ty khác nhau, chúng ta có thể giới hạn quyền truy cập website chỉ trong một công ty cụ thể (O-secure) bằng cách thêm vào httpd.conf các chỉ dẫn sau: <Location /> SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" </Location> Ví dụ khác minh hoạ cho việc làm cách nào chỉ cho phép truy cập một văn phòng nào đó (OU= “Secure Labs”) bên trong một công ty (O= “Seccure”). SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ %{SSL_CLIENT_S_DN_OU } eq "Seccure Labs" Hoặc chỉ cung cấp quyền truy cập một vài phòng ban (OU=”Seccure Labs hoặc OU=”development””) trong cùng công ty (O = “Seccure”). SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ %{SSL_CLIENT_S_DN_OU } in {"Seccure Labs", "Development"} Cuối cùng, thậm chí có thể cấp quyền truy cập cho một người dùng cụ thể (CN = “Frodo Baggins”) từ một công ty cụ thể (O=”Seccure”): SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" and \ %{SSL_CLIENT_S_DN_CN} in {"Frodo Baggins"} Chú ý rằng có thể cung cấp các biến môi trường trên cho tập lệnh CGI (bao gồm PHP và những ngôn ngữ khác) bằng cách thêm vào tham số "+StdEnvVars" trong chỉ dẫn SSLOptions. Thành phần này cho phép chúng ta dùng tên DN bên trong các ứng dụng web (như PHP và một số ngôn ngữ khác) để cung cấp các quyền thẩm định chi tiết hơn hoặc các điều khiển truy cập. SSLOptions +StdEnvVars Thu hồi một chứng chỉ client Nếu một chứng chỉ trở nên gây hại hoặc bị mất, bạn sẽ làm gì? Trong trường hợp này, chúng ta cần thu hồi lại chứng chỉ đó như đã nói trong các phần trước. Tiếp theo chúng ta phải sao chép lại một file CRL vào thư mục Apache như sau: install -m 644 -o root -g sys crl.pem /usr/local/apache2/conf/ssl.crl/ Chúng ta cũng cần chắc chắn rằng "SSLCARevocationFile" trong httpd.conf trỏ vào file trên: SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/crl.pem Sau đó chúng ta cần khởi động lại Apache để có được hiệu quả của sự thay đổi. Chứng chỉ được thu hồi sẽ không cho phép truy cập website, như đuợc chỉ trong hình 9: Hình 9. Cố gắng truy cập với chứng chỉ bị thu hồi. Cố gắng truy cập với chứng chỉ bị thu hồi. Chrooting server Để nâng cao độ an toàn web server của bạn và làm cho Apache có ít lỗ hổng bị tấn công tràn bộ nhớ đêm hơn, bạn nên chạy Apache trong môi trường chrooted. Chrooting web server cách ly tiến trình tạo thư mục gốc mới để chúng không thấy được các file còn lại của server. Tiến trình chooting Apache đươc mô tả trong "Securing Apache 2.0: Step-by- Step". Vì thế các bạn nên theo các bước đã nói trên. Cùng với việc thêm phần hỗ trợ cho SSL/TLS, chúng ta cần cài đặt thêm một số thư viện và tạo một vài thư mục con. Trong trường hợp FreeBSD 5.1, danh sách các thư viện và thư mục như sau: cp /usr/lib/libssl.so.3 /chroot/httpd/usr/lib/ cp /usr/lib/libcrypto.so.3 /chroot/httpd/usr/lib/ cp -R /usr/local/apache2/conf/ssl.key /chroot/httpd/usr/local/apache2/conf/ cp -R /usr/local/apache2/conf/ssl.crt /chroot/httpd/usr/local/apache2/conf/ cp -R /usr/local/apache2/conf/ssl.crl /chroot/httpd/usr/local/apache2/conf/ Chúng ta cũng cần thêm ổ ngẫu nhiên như sau. Ví dụ bên dưới được lấy ra từ FreeBSD 5.1: ls -al /dev/*random crw-rw-rw- 1 root wheel 2, 3 Jan 4 12:10 /dev/random lrwxr-xr-x 1 root wheel 7 Jan 4 12:10 /dev/urandom -> random cd /chroot/httpd/dev mknod ./random c 2 3 ln -s ./random ./urandom chown root:sys ./random chmod 666 ./random Trong trường hợp các hệ điều hành khác, người đọc có thể tạo ra danh sách các file cần thiết bằng cách dùng các câu lệnh như truss, strace, ktrace v.v…như đã được mô tả chi tiết trong phần: “Chrooting the server ” ở bài báo Security focus: “Secirity Apache: Step-by-step” Mỗi lần các bước này hoàn thành, bạn có thể chạy Apache trong môi trường enviroment như sau: chroot /chroot/httpd /usr/local/apache2/bin/httpd Các kiểu tấn công SSL/TLS được biết đến Mặc dù giao thức SSL/TLS về mặt lý thuyết thì có mức an toàn cao, nhưng trong thực tế nó có thể nó có thể bị tấn công bằng một vài cách sau. Có nhiều phương hướng tấn công, trong đó có hai cách đáng quan tâm nhất: Kiểu Man in the middle (MITM) Trong kiểu tấn công này, kẻ phá hoại ngăn chặn lưu lượng trao đổi qua lại giữa client và server, chẳng hạn như giả mạo DNS trả lời hay như đổi hướng của ARP, sau đó đóng vai client đối với server và ngược lại. Trong suốt cuộc tấn công này web browser của người dùng không kết nối trực tiếp với server đích. Nhưng thay vì phá hoại host,nó đóng vai web browser và hành động về cơ bản giống như là một proxy. Có hai tin dành cho nhà quản trị muốn bảo vệ hệ thống chống lại các cuộc tấn công: Tin tốt là web browser cảnh báo người dùng khi nhận dạng của web server không thể được kiểm chứng, và có thể chỉ ra cuộc tấn công man-in- middle bằng cách hiện một hộp tin nhắn cảnh báo. Tin xấu là, trong thực tế, người dùng thường bỏ qua các tin nhắn. Do đó nếu web browser của người dùng chấp nhận kết nối tới các website SSL mà nhân dạng không thể kiểm tra được, chúng ta chỉ có thể tin tưởng vào ý thức của người dùng, và tin rằng họ sẽ nhấn nút “proceed” nếu cảnh báo hiện ra. [...]... trọng là bạn phải chắc chứng chỉ được ký (thường là một CA tin cậy) được cài đặt trên web browser Nếu một chứng chỉ CA cục bộ được dùng, chúng ta phải chắc chắn tất cả các client muốn truy cập đều đã được cài chứng chỉ CA cục bộ đó Nguyên tắc giống như thế cũng được áp dụng cho chứng chỉ tự ký Chứng chỉ hết hạn Chứng chỉ của web browser nên được làm mới lại trước khi chứng chỉ trước hết hạn Nếu không... browser phải luôn được cập nhật Tóm lại bạn nên làm như sau: - kiểm tra sự thu hồi chứng chỉ của nhà sản xuất - kiểm tra sự thu hồi chứng chỉ server - không nên dùng SSLv2.0 mà chỉ là TLSv1.0 hoặc SSL v3.0 - thể hiện các cảnh báo về các chứng chỉ web server không phù hợp - dùng Session IDs/cookies giống nhau cho cả SSL và HTTP Dùng các session IDs/cookies giống nhau cho SSL và HTTP Có thể có một cấu hình... các chứng chỉ ký bởi một CA Lỗi lớn nhất trong khi thực thi SSL/TLS là các web browser không tin chứng chỉ của web server do một CA ký Hay nói cách khác là chứng chỉ của CA không được cài đặt trên web browser Điều này làm cho các cuộc tấn công Man in the middle rất dễ dàng Bởi vì người dùng không có cách nào kiểm chứng được nhân dạng của web server Để tránh vấn đề này, quan trọng là bạn phải chắc chứng. .. toàn của các máy client Nếu chúng bị phá hoại thì an toàn của SSL/TLS cũng bị phá họại Trong trường hợp này kẻ tấn công có thể thực hiện với các máy trạm, chẳng hạn như thay thế chứng chỉ của web browser, cài đặt keylogger, thay đổi hướng host để đỏi hướng yêu cẩu web, làm giả web server, hay thậm chí lấy cắp chứng chỉ client nếu chúng được đánh dấu là có thể xuất khẩu Do đó, nếu cơ cấu client dưới Administrative... chứng chỉ trước hết hạn Nếu không thì nó có kết quả như trên do các web client không thể thẩm định được web server và lại một lần nữa làm cho các kết nối SSL/TLS bị xâm phạm bởi kiểu tấn công Man-In-The-Middle Trong trường hợp này, người dùng có thể quen xem một tin cảnh báo nói rằng chứng chỉ đã hết hạn mà không chú ý rằng đó là chứng chỉ giả mạo Các phiên bản có nhiều lỗ hổng của OpenSSL và Apache Một... kết nối Vì vậy, chúng ta không nên dùng giao thức SSL v2.0 mà nên thay thế bằng TSL v1.0 hay SSL v3.0 Dùng phương pháp mã hoá yếu Thời kỳ đầu của SSL chỉ có thể dùng các khoá 40 bít với kiểu mã hoá đối xứng do bị chính phủ Mĩ hạn chế Thật không may, dữ liệu được mã hoá cách này giờ có thể bị giải mã trong một thời gian ngắn Do đó khoá 40 bít hay 56 bít không nên dùng Hầu hết web browser hiện đại hỗ... mã hoá đồng bộ 128 bit Và bây giờ, nó là khoá ngắn nhất bạn có thể dùng với SSL/TLS Dùng không phù hợp NIDS (Network Intruder Detection System) Ngoài NIDS có thể giải mã được SSL (như qua cách dùng khoá private của web browser) thì không dễ để dò ra được các cuộc tấn công trên ứng dụng web Để dò ra kết quả cuối cùng, hoặc là chúng ta dùng HIDS, hoặc là đặt NIDS trong phân đoạn lưu lượng SSL/TLS được... truy cập không chỉ qua SSL mà còn qua các giao thức không được mã hoá (như HTTP) Cài đặt SSL/TLS và mở tự mở cổng 443/TCP cho web server cũng chẳng có nghĩa là gì nếu người dùng vẫn có thể truy cập qua giao thức không mã hoá HTTP, cổng 80/TCP Do đó, một giao thức phải được kiểm tra đúp để bảo vệ nội dung không thể truy cập qua HTTP hay các giao thức khác (như FPT, Samba, NFS, …) Cơ chế client dễ bị xâm... công Brute-force trên các khoá session: Kiểu tấn công này được dùng khi kẻ phá hoại biết hoặc nắm được một phần đoạn văn bản gửi trong session SSL/TLS, chẳng hạn như “GET/HTTP/1.0” Và kẻ tấn công có thể nghe lén cuộc nói chuyện trong phiên này (như dùng tcpdump, Ethereal hoặc các chức năng khác) Sau đó hắn giải mã đoạn bắt được bằng việc dùng các khoá có thể, cố gắng tìm các biến thể của nó trong dữ... điều không thể Vì vậy chúng ta phải luôn dùng những phiên bản mới nhất (vì nó thường ít lỗi bảo mật hơn các phiên bản trước) Sự chấp nhận của SSL v2.0, kiểm định không đồng bộ (aNULL), và mã hoá đồng bộ (NULL) tại Web server Như chúng ta đã thảo luận, việc dùng bộ mã hoá hỗ trợ định dạng không đồng bộ hay không đòi hỏi mã hoá nên dừng lại Mặt khác, nguy hiểm là client có thể bị lừa bởi các tham số dàn . chọn chứng chỉ đã được thiết lập từ danh sách, như hình 6 bên dưới: Hình 6. Chọn chứng chỉ client khi đã làm xong nền. Chọn chứng chỉ client khi đã làm xong nền. Sau khi chọn xong chứng chỉ, . một chứng chỉ CA cục bộ được dùng, chúng ta phải chắc chắn tất cả các client muốn truy cập đều đã được cài chứng chỉ CA cục bộ đó. Nguyên tắc giống như thế cũng được áp dụng cho chứng chỉ. tra sự thu hồi chứng chỉ của nhà sản xuất - kiểm tra sự thu hồi chứng chỉ server - không nên dùng SSLv2.0 mà chỉ là TLSv1.0 hoặc SSL v3.0 - thể hiện các cảnh báo về các chứng chỉ web server