Dùng chứng chỉ Client

Chia sẻ: Rer Erer | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

52
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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: 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 Nhập cụm...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Dùng chứng chỉ Client

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: SSLRequire %{SSL_CLIENT_S_DN_O} eq "Seccure" 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.
Tấn 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ữ liệu đã được mã hoá của SSL/TLS. Nếu như khoá được tìm ra, đoạn tin nhắn đó có thể được dùng để giải mã toàn bộ phần văn bản trong phiên giao dịch đó. Tin tốt là số lượng khoá lớn nhất phải được kiểm tra là 2^128 khi mã hoá đối xứng 128-bit được dùng. Ngày nay, chúng ta tin tưởng nó đủ sức bảo vệ các session nhiều lần trong năm. Tuy nhiên, từ khi CPUs ngày càng tăng kích thước chúng ta không thể dự đoán được các khoá đồng bộ 12-bit có thể xem như là an toàn được hay không nữa. Cụ thể các hacker có thể truy cập vào một số lượng lớn các siêu máy tính. Trong trường hợp bộ mã hoá theo lớp xuất khẩu (40 bit, và một số bộ mở
rộng là 56 bits) chẳng hạn như tấn công brute force có thể thành công trong một lượng thời gian, đôi khi thậm chí là vài ngày, phụ thuộc vào con số của CPU. Nếu có thể dùng bộ mã hoá mạnh thì bạn nên dùng một cách dứt khoát thay. Ngoài 2 kiểu trên, còn có một số kiểu khá nguy hiểm khác như thuật toán rollback attacks, timing attacks, phân tích lưu lượng, Bleinchenbacher's attacks… Thật thú vị khi hiểu chúng. Bạn có thể tìm thêm thông tin trong các tài liệu của Bruce Schneier và David Wagner cũng như nhiều tài liệu khác trên internet. Các lỗi thực thi SSL/TLS điển hình Web browser không nhận ra 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 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 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 điểm rất quan trọng là bạn phải luôn chạy những phiên bản mới nhất của OpenSSL và Apache. Lập trình viên viết các đoạn mã lớn hơn mà không có sai sót là đ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 xếp đột ngột thấp hơn mức an toàn của 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ỗ trợ kiêu 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 gửi vào trong văn bản, chẳng hạn như giữa SSL Reverse Proxy và phần của web server). Nếu không thì chúng ta không thể dò ra bất kỳ cuộc tấn công nào, ngoại trừ các kiểu tấn công từ chối dịch vụ. Cho phép 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 phạm Khi chúng ta tập trung vào an toàn ở các web browser, chúng ta có thể dễ dàng quên đi an 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 domain thì chúng ta cần chăm sóc an toàn cho nó cẩn thận. Sử dụng tường lửa cá nhân, các phần mềm diệt virút, phần mềm chống gián điệp và bật chế độ cập nhật tự động . Quan trọng nhất là web 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 Apache chấp nhận cả HTTP và HTTPS với cùng yêu cầu dịch vụ. Chẳng hạn như thông tin website cùng truy cập qua HTTP, và một phần giao dịch có thể truy cập qua HTTPS. Trong trường hợp này chúng ta phải rất cẩn thận với các ứng dụng web, không dùng cùng một session IDs/cookies cho cả hai giao thức. Nếu không thì kẻ phá hoại có thẻ đánh hơi ra giao dịch của HTTP giữa web server và nạn nhân. Và cũng có thể cố gắng để dùng IDs truy cập các phần đã kiểm định của ứng dụng web qua SSL. Kết luận Bài này kết thúc loạt ba bài về cấu hình Apache 2.0 hỗ trợ SSL/TLS. Nó
hướng dẫn làm cách cài đặt giao thức SSL/TLS để có được mức an toàn cao nhất và độ thực thi tối ưu. Nó cũng hướng dẫn làm cách nào để tạo và thu hồi chứng chỉ, và thực hành chúng như thế nào.