Bình luận đề thi Registered Information Security Specialist, Thu 2023 (Reiwa 5), câu hỏi buổi chiều Q2 ── tệp bị mang ra từ Wi-Fi khách

Đã cấm kết nối USB. Đã cấm lưu tệp lên đĩa cục bộ. Giao tiếp tới webmail và kho lưu trữ đám mây công ty không cho phép đã bị chặn. Đính kèm tệp khi gửi email đã bị cấm. Máy chủ tệp nội bộ đã bị bãi.

Vậy mà tệp nghiệp vụ vẫn mang ra được.

Câu hỏi 2 buổi chiều kỳ thi Registered Information Security Specialist Thu 2023 (Reiwa 5) lấy công ty may mặc M — đã triển khai đủ các biện pháp trên — làm sân khấu, rồi hỏi các lỗ còn lại¹. Bài này là phần hai của loạt nối tiếp bình luận câu hỏi 1 (XSS lưu trữ), và phạm vi chuyển từ ứng dụng web sang mạng nội bộ và xác thực thiết bị.

Nếu câu 1 hỏi “biện pháp xếp trước ứng dụng web bị lọt ở đâu”, câu 2 hỏi “thiết kế biện pháp định bảo vệ phạm vi nào”. Không biện pháp nào của công ty M sai. Chỉ cần xác nhận từng chỉ định phạm vi bảo vệ, thì ngay phía ngoài đã trống.

Điều bài này mang lại, ngoài đáp án mẫu từng câu và căn cứ, là các góc kiểm dùng được nguyên trên thực tế cho ba vùng: WLAN, chứng chỉ máy chủ, hạn chế địa chỉ IP nguồn. Người đọc vì ôn thi có thể bắt đầu từ mục theo từng câu hỏi; người chỉ cần góc thực tế có thể đọc từ Chương 11 và 12 mà vẫn thông.

1. Kết luận trước

• Lối thoát là phòng họp. Công ty M đã cấm mang PC cá nhân vào, nhưng chỉ cấm phòng làm việc; phòng họp nằm ngoài đối tượng. Phòng họp có cả WLAN nhân viên lẫn WLAN khách
• Đường nhân viên mang ra có hai. Giả mạo địa chỉ MAC rồi nối WLAN nhân viên, và chỉ việc nối WLAN khách. Cách sau dễ hơn nhiều; cái cần chỉ là khóa chia sẻ trước đang phát cho khách
• Kho lưu trữ đám mây (dịch vụ B) đã hạn chế “chỉ đăng nhập được từ địa chỉ IP toàn cục của công ty M”. Tuy nhiên giao tiếp WLAN khách cũng được cùng NAT đổi thành cùng địa chỉ IP toàn cục, nên hạn chế này đi thẳng. Hạn chế theo địa chỉ IP nguồn là thiết lập cho phép không phải thiết bị mà mọi người đang chia sẻ lối ra
• AP giả + site giả của kẻ tấn công bên ngoài bị kiểm chứng chỉ máy chủ chặn. Cái có hiệu là hai điểm: “do CA được tin phát hành không” và “tên máy chủ trên chứng chỉ khớp đích không”. Theo bình luận chấm điểm IPA, tỷ lệ đúng của câu hỏi đòi hai điểm này thấp
• Dù gõ nhầm http://, HSTS thay thành HTTPS rồi mới kết nối nên vẫn thành lỗi chứng chỉ. Hơn nữa, trên host HSTS đang bật, không được đưa lựa chọn bỏ qua cảnh báo rồi đi tiếp cho người dùng
• Chức năng chia sẻ tệp hợp lệ cũng thành đường mang ra. Chỉ cần chỉ định địa chỉ email riêng của mình làm địa chỉ người chia sẻ bên ngoài. Có phê duyệt cấp trên, nhưng có cấp trên không kiểm đích
• Trụ đối phó có ba. Đưa WLAN nhân viên sang EAP-TLS, xác thực bằng chứng chỉ máy khách theo từng thiết bị, cất khóa riêng vào TPM để không lấy ra khỏi PC nghiệp vụ. Tách WLAN khách khỏi mạng công ty M (hoặc tách địa chỉ IP toàn cục lối ra). Và xóa VLAN, quy tắc lọc, SSID không còn dùng

Bản đồ tri thức của bài viết này

Bài viết này lấy câu hỏi 2 buổi chiều kỳ thi Registered Information Security Specialist Thu 2023 (Reiwa 5) làm đề tài, sắp xếp đánh giá thiết kế quanh WLAN và chứng chỉ máy chủ. WPA2-PSK — mọi người chia sẻ cùng khóa — có điểm yếu: ai biết khóa đều dựng được AP giả (evil twin) không phân biệt với thật, nhưng nếu có kiểm chứng chỉ máy chủ và HSTS thì đăng nhập site giả không thành. Với việc nhân viên mang ra, giả mạo địa chỉ MAC được đối phó bằng EAP-TLS dùng chứng chỉ máy khách và RADIUS; bài toán hạn chế địa chỉ IP nguồn bị lọt vì lối ra NAT dùng chung nhiều mạng được đối phó bằng tách mạng khách. Cất khóa riêng vào TPM để không lấy ra được là then chốt để xác thực bằng chứng chỉ thật sự có hiệu.

flowchart LR
    accTitle: Bản đồ tri thức câu 2 buổi chiều kỳ thi Registered Information Security Specialist Thu 2023 (WLAN và chứng chỉ máy chủ)
    accDescr: Sơ đồ cho thấy điểm yếu vì khóa dùng chung của WPA2-PSK dẫn tới giả mạo địa chỉ MAC và tấn công evil twin, trong khi kiểm chứng chỉ máy chủ và HSTS ngăn đăng nhập site giả, EAP-TLS cùng RADIUS và khóa riêng cất trong TPM hiện thực xác thực theo từng thiết bị, cùng giới hạn hạn chế địa chỉ IP nguồn dùng chung qua NAT và việc chỉnh sửa
    wpa2_psk["WPA2-PSK"]
    eap_tls["EAP-TLS"]
    evil_twin["Tấn công evil twin (sinh đôi ác)"]
    phishing["Lừa đảo (phishing)"]
    mac_address_filtering["Lọc địa chỉ MAC"]
    mac_address_spoofing["Giả mạo địa chỉ MAC"]
    server_certificate_validation["Kiểm chứng chỉ máy chủ"]
    certificate_chain["Chuỗi chứng chỉ"]
    root_ca["Chứng chỉ CA gốc"]
    certificate_revocation_check["Xác nhận thu hồi chứng chỉ"]
    trust_anchor_risk["Rủi ro lạm dụng điểm tin cậy"]
    hsts["HSTS (HTTP Strict Transport Security)"]
    hsts_preload_list["Danh sách preload HSTS"]
    client_certificate["Chứng chỉ máy khách"]
    radius["RADIUS"]
    ieee_802_1x["IEEE 802.1X (EAP over LAN)"]
    network_policy_server["Network Policy Server (NPS)"]
    private_key["Khóa riêng"]
    tpm["TPM"]
    key_exfiltration_risk["Rủi ro mang khóa riêng ra ngoài"]
    shared_egress_ip_bypass["Lọt hạn chế IP nguồn vì IP lối ra dùng chung"]
    nat["NAT (chuyển đổi địa chỉ mạng)"]
    guest_network_isolation["Tách mạng khách"]
    unused_config_cleanup["Xóa thiết lập không còn dùng"]
    source_ip_restriction["Hạn chế địa chỉ IP nguồn"]
    wpa2_psk -->|"có thể gây"| evil_twin
    evil_twin -.->|"có thể gây"| phishing
    mac_address_filtering -->|"không khuyến nghị"| mac_address_spoofing
    eap_tls -->|"khuyến nghị cho"| mac_address_spoofing
    server_certificate_validation -.->|"ngăn chặn"| phishing
    server_certificate_validation -->|"sử dụng"| certificate_chain
    server_certificate_validation -->|"sử dụng"| root_ca
    server_certificate_validation -.->|"sử dụng"| certificate_revocation_check
    root_ca -.->|"có thể gây"| trust_anchor_risk
    hsts -.->|"ngăn chặn"| phishing
    hsts -->|"yêu cầu"| server_certificate_validation
    hsts_preload_list -.->|"giảm thiểu"| evil_twin
    eap_tls -->|"sử dụng"| client_certificate
    eap_tls -.->|"sử dụng"| radius
    eap_tls -.->|"sử dụng"| ieee_802_1x
    network_policy_server -->|"triển khai"| radius
    client_certificate -->|"yêu cầu"| private_key
    private_key -.->|"lưu trong"| tpm
    tpm -.->|"ngăn chặn"| key_exfiltration_risk
    shared_egress_ip_bypass -.->|"yêu cầu"| wpa2_psk
    nat -->|"có thể gây"| shared_egress_ip_bypass
    guest_network_isolation -->|"ngăn chặn"| shared_egress_ip_bypass
    guest_network_isolation -->|"nên làm trước"| unused_config_cleanup
    source_ip_restriction -.->|"không tương thích"| nat

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 24, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

2. Về đề tài ── nguồn và cách bài này xử lý

Đề được nêu là như sau.

Nguồn: Kỳ thi Registered Information Security Specialist Thu 2023 (Reiwa 5), buổi chiều, câu hỏi 2

IPA nêu rằng với đề thi quá khứ đã công bố, trừ khi luật có quy định đặc biệt thì không cần xin phép hay trả phí sử dụng. Tuy nhiên không phải từ bỏ bản quyền; họ đòi ghi nguồn theo dạng “năm, kỳ, loại thi, khung giờ, số câu hỏi, v.v.”, và nếu sửa một phần đề thì cũng ghi rõ điều đó².

Bài này không sao nguyên hình bảng in trong tập đề. Trong phạm vi cần để giải thích cơ chế, chúng tôi thay bằng hình giản lược và tóm tắt do chúng tôi viết. Câu hỏi và đáp án mẫu cũng được tóm. Bản gốc tập đề, đáp án mẫu, bình luận chấm điểm tải miễn phí từ trang IPA, nên khuyến nghị mở sẵn khi đọc^{1 3 4}.

Tương ứng câu hỏi và bài viết

Bạn có thể bắt đầu đọc từ câu hỏi muốn giải.

Mô tả tập đề và cách bài này xử lý

Để đối chiếu với nguyên văn, gom chỗ nào được xử lý thế nào.

3. Sân khấu đề ── việc công ty M “đã làm rồi”

Công ty M là công ty con của công ty L, 100 nhân viên, ngành may mặc. Tòa nhà văn phòng mặt đại lộ đông người trong nội đô. Một câu này sẽ có hiệu sau.

Năm trước, nhân viên công ty M lưu tệp thiết kế sản phẩm mật trên máy chủ tệp nội bộ ra USB rồi mang sang đối thủ. Theo chỉ đạo của công ty mẹ L, việc xem lại biện pháp bảo mật đang tiến. Ba việc xem lại đã triển khai như sau.

• Đưa phần mềm chống rò rỉ thông tin vào notebook cấp cho nhân viên (sau đây, PC nghiệp vụ), đặt cấm kết nối phương tiện lưu trữ ngoài như USB, cấm lưu tệp lên đĩa cục bộ trừ cài phần mềm, chặn giao tiếp tới webmail và kho lưu trữ đám mây công ty không cho phép, cấm cài phần mềm công ty không cho phép, cấm đính kèm tệp khi gửi email
• Gom chỗ lưu tệp nghiệp vụ vào một nơi: kho lưu trữ đám mây đã dùng từ trước (sau đây, dịch vụ B), rồi xem lại thiết lập
• Bãi máy chủ tệp nội bộ

Vụ trước đi đường “máy chủ tệp nội bộ” → “USB”, nên đã dập cả hai đầu. Mạch đúng.

Cấu hình mạng

Tòa nhà có phòng làm việc và phòng họp. Phòng làm việc dùng được WLAN nhân viên; phòng họp dùng được cả nhân viên lẫn khách. Máy chiếu phòng họp dùng bằng cách nối thiết bị khách mang theo (PC, tablet, smartphone khách mang) hoặc PC nghiệp vụ vào WLAN khách.

Thu hẹp vào phạm vi cần giải thích thì hình như sau.

flowchart LR
    accTitle: Cấu hình mạng công ty M
    accDescr: WLAN khách, WLAN nhân viên và mạng máy chủ cùng bị FW NAT đổi thành một địa chỉ IP toàn cục rồi ra dịch vụ B
    subgraph M["Mạng nội bộ công ty M"]
        direction TB
        G["WLAN khách<br/>192.168.10.0/24<br/>(chỉ AP phòng họp)"]
        E["WLAN nhân viên<br/>192.168.20.0/24<br/>(phòng làm việc và phòng họp)"]
        S["Mạng máy chủ<br/>192.168.30.0/24<br/>DHCP, DNS, thư mục"]
        FW["FW<br/>NAT đổi nguồn thành<br/>một địa chỉ IP<br/>toàn cục"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Dịch vụ B<br/>(kho lưu trữ đám mây)"]
    FW --> I["Internet"]

Hình 1: WLAN khách, WLAN nhân viên và mạng máy chủ cùng ra internet qua một FW NAT thành một địa chỉ IP toàn cục.

Đặc tả cần nắm như sau.

Và ba quy tắc bảo mật. Cấm mang PC nghiệp vụ ra ngoài công ty, cấm mang PC, tablet, smartphone cá nhân vào phòng làm việc, cấm mang tệp nghiệp vụ ra ngoài công ty bằng cách khác ngoài chức năng chia sẻ tệp của dịch vụ B.

Bạn có nhận ra quy tắc thứ hai viết “vào phòng làm việc” không? Phòng họp không được viết.

Cách đề tiến

Y của bộ phận hệ thống thông tin, với sự hỗ trợ của ông S — Registered Information Security Specialist (chuyên viên bảo mật đã đăng ký) của công ty mẹ L — xác nhận biện pháp chống mang tệp ra từ dịch vụ B đã đủ chưa. Hai người tách mang ra do kẻ tấn công bên ngoài và mang ra do nhân viên. Câu 1 là cái trước, câu 2 cái sau, câu 3 là lập biện pháp.

4. Wi-Fi giả và site giả ── câu 1(1)(2)

Điều Y nêu trước là kịch bản khách từng dùng WLAN khách, với tư cách kẻ tấn công, từ gần công ty M nối WLAN khách rồi truy cập dịch vụ B.

Kịch bản này thành vì cách xác thực WLAN là WPA2-PSK. PSK (Pre-Shared Key, khóa chia sẻ trước) đúng như tên là cách mọi người chia sẻ cùng một khóa. Khóa chia sẻ trước của WLAN khách tồn tại để dạy khách. Một khi đã dạy, không có cách hủy trạng thái người đó vẫn biết (trừ đổi cả mọi người). Hơn nữa tòa nhà mặt đại lộ đông người nên sóng tới được cả từ ngoài nhà.

Câu trả lời của ông S rõ. Để đăng nhập dịch vụ B cần [a] ID người dùng và [b] mật khẩu. Đó là đáp án mẫu câu 1(1) (không kể thứ tự). Bản thân nối được WLAN không nghĩa là đăng nhập dịch vụ B.

AP giả và site giả

Y đi thêm một tầng. Chuẩn bị AP giả cùng thiết lập với AP WLAN khách, và site giả cùng URL với dịch vụ B, rồi chỉnh thiết lập DNS để đánh cắp ID người dùng và mật khẩu thì sao. Đặt AP giả gần công ty M, nhân viên công ty M có thể nối nhầm PC nghiệp vụ vào AP giả, định truy cập dịch vụ B thì vào site giả rồi đăng nhập.

Đó là cái gọi là evil twin (sinh đôi ác). Dựng AP cùng SSID, cùng khóa chia sẻ trước với WLAN khách thì nhìn từ thiết bị không phân biệt AP thật. Điều WPA2-PSK cho thiết bị xác nhận về AP chỉ là “cùng biết khóa chia sẻ trước”. AP không biết khóa không hoàn thành quy trình kết nối; nói ngược, ai biết khóa đều có thể thành “AP thật”. Đã là khóa phát cho khách thì nên nghĩ kẻ tấn công cũng được phát.

Câu trả lời ông S ở đây cũng rõ. Khi nhân viên định truy cập site giả bằng HTTPS, cùng thông điệp lỗi kết nối không an toàn, một hoặc nhiều trong bốn mục sau hiện trên trình duyệt web, tùy chứng chỉ máy chủ dùng cho site giả.

• Chứng chỉ máy chủ này không phải chứng chỉ máy chủ do CA được tin phát hành (ô trống c)
• Tên máy chủ ghi trên chứng chỉ máy chủ này khác tên máy chủ đích (ô trống d)
• Chứng chỉ máy chủ này đã thu hồi
• Chứng chỉ máy chủ này đã hết hạn

Hai mục dưới đã viết sẵn trong tập đề; trả lời hai mục trên (ô trống c, d, mỗi cái trong 40 chữ, không kể thứ tự) là câu 1(2).

sequenceDiagram
    accTitle: AP giả và site giả bị dừng bởi kiểm chứng chỉ
    accDescr: Nhân viên kết nối HTTPS qua AP giả thì lỗi vì không phải do CA được tin phát hành hoặc tên máy chủ không khớp, nên màn hình đăng nhập không hiện
    autonumber
    participant U as PC nghiệp vụ của nhân viên
    participant F as AP giả, site giả<br/>(kẻ tấn công)
    participant B as Dịch vụ B (thật)

    Note over F: Dựng AP cùng SSID,<br/>cùng khóa chia sẻ trước với WLAN khách
    U->>F: Nối nhầm vào AP giả
    Note over F: Chỉnh DNS, hướng tên miền<br/>dịch vụ B về site giả
    U->>F: Kết nối URL dịch vụ B bằng HTTPS
    F-->>U: Chứng chỉ máy chủ của site giả
    Note over U: Kiểm không đạt<br/>· không phải do CA được tin phát hành<br/>· tên máy chủ trên chứng chỉ khác đích
    Note over U: Hiện lỗi kết nối không an toàn<br/>màn hình đăng nhập không hiện
    Note over U,B: Bản thân không giao tiếp<br/>với dịch vụ B thật

Hình 2: Truy cập HTTPS qua AP giả thất bại ở kiểm chứng chỉ máy chủ; màn hình đăng nhập không hiện.

Kiểm chứng chỉ đang nhìn gì

Bình luận chấm điểm viết về câu này như sau.

Câu 1(2) có tỷ lệ đúng thấp. Dù kẻ tấn công chuẩn bị site giả, nếu truy cập bằng HTTPS thì kiểm chứng chỉ máy chủ thất bại. Kiểm chứng chỉ máy chủ là kiến thức cơ bản để bảo đảm an toàn giao tiếp, nên hãy hiểu cả cụ thể đang kiểm những mục nào.

Nghĩa là dù biết “sẽ ra lỗi chứng chỉ”, ít người tách được đang xác nhận gì mà không đạt thành bốn mục. Sắp xếp bốn mục hình 2 nêu theo góc “mỗi cái xác nhận để làm gì” thì như sau.

Nhìn từ kẻ tấn công, hai mục trên là tường không vượt. Tự làm chứng chỉ tự ký thì trượt mục 1; lấy chứng chỉ miễn phí hợp lệ cho miền mình (ví dụ b-service.example.net) thì đích là miền dịch vụ B nên trượt mục 2. Chứng chỉ cho tên miền dịch vụ B không lấy được nếu không quản miền dịch vụ B. Kết hợp hai điểm này có thể nói là thân của cơ chế chứng chỉ.

Quy trình kiểm đường chứng chỉ do RFC 5280⁵, quy trình đối chiếu tên trên chứng chỉ với tên đích do RFC 6125⁶ quy định.

Bốn mục không mạnh bằng nhau

Ở đây hãy tách đáp án đề thi và hành vi trình duyệt thật. Bốn mục trên là cái hình 2 của đề nêu như “chi tiết lỗi có thể hiện”, đừng đọc là mọi trình duyệt kiểm bốn cái với cùng độ chắc.

Nhà phát hành, tên máy chủ, hạn — ba cái phán được chỉ bằng thông tin trong tay lúc nhận chứng chỉ, nên luôn được kiểm. Cái đang chặn tấn công của đề này cũng là ba cái đó.

Ngược lại, chỉ xác nhận thu hồi khác tính chất. Đã thu hồi hay chưa không viết trong chứng chỉ, cần đi lấy thông tin khác, nên phụ thuộc hiện thực và cấu hình.

• Chrome thường không kiểm OCSP hay CRL trực tuyến. Thay vào đó phát CRLSet, danh sách hạn chế nhằm chặn nhanh chứng chỉ lúc khẩn; phần lấy từ danh sách thu hồi của CA chỉ là một phần⁷
• Hiện thực hỏi OCSP cũng hay dùng cấu hình soft-fail: không nhận được trả lời thì vẫn cho kết nối đi

Vì thế đừng lấy “khóa riêng rò thì thu hồi là xong” làm trụ đối phó. Thu hồi là việc nên làm, nhưng không phải cơ chế chắc chắn có hiệu trên mọi trình duyệt của người dùng. Việc rút ngắn thời hạn chứng chỉ những năm gần đây cũng là câu trả lời phía ngành trước việc thu hồi không đáng tin. Khi công ty mình nghi rò khóa, song song xin thu hồi hãy thay chứng chỉ và vô hiệu luôn thứ khóa đó đang bảo vệ (phiên, khóa API, v.v.).

Cạm bẫy thực tế ── “CA được tin” do ai quyết

Từ đây là chuyện ngoài đề. Mục 1 bảng trên phụ thuộc thiết bị đó đang tin gì. Danh sách tin do trình duyệt hay OS giữ; trên Windows đó là “Trusted Root Certification Authorities” của kho chứng chỉ.

Nghĩa là tình huống sau thì kiểm mục 1 cũng qua.

• Đang phát chứng chỉ gốc của CA nội bộ (CA riêng) tới PC nghiệp vụ. Khóa riêng của CA đó, hoặc thủ tục phát hành chứng chỉ, bị kẻ tấn công nắm
• Proxy hay sản phẩm bảo mật kiểm nội dung giao tiếp đang đưa chứng chỉ gốc tự làm vào thiết bị để kết thúc TLS. Sản phẩm hay vận hành đó bị kẻ tấn công nắm
• Vì “ra lỗi chứng chỉ” nên ai đó từng đăng ngoại lệ, hoặc đưa chứng chỉ tự ký vào gốc được tin

Mục 3 thật sự hay thấy trên hiện trường. Đưa tay một lần để tắt lỗi chứng chỉ hệ thống nội bộ, rồi nó sống sót trên image thừa kế từ PC người nghỉ việc. Nội dung kho Trusted Root Certification Authorities chính là tuyên bố thiết bị đó tin ai, nên hãy đưa vào đối tượng kiểm kê. Quyết định kho nào đưa gì vào được sắp trong hướng dẫn thực tế kho chứng chỉ Windows.

Với kiểm mục 2 (khớp tên máy chủ), lưu ý thực tế khác. Tấn công người dùng nhìn nhầm tên miền thì chứng chỉ bất lực. Kẻ tấn công lấy miền dễ nhầm kiểu b-serv1ce.example.com rồi lấy chứng chỉ hợp lệ cho miền đó thì trình duyệt không ra lỗi. Chứng chỉ bảo đảm “tên máy chủ đích khớp tên máy chủ trên chứng chỉ”, không bảo đảm “tên máy chủ đó là đối tác người dùng định tới”. Cơ chế không dựa bước cuối vào mắt người dùng là cách như passkey (WebAuthn) kiểm origin phía authenticator. Chi tiết nằm trong vì sao passkey an toàn.

5. Vì sao gõ http:// vẫn bị chặn ── câu 1(3)

Y không chịu. Khi đã nối AP giả, nhân viên nhập URL dịch vụ B trên trình duyệt web mà gõ nhầm http:// thì thông điệp lỗi sẽ không hiện chứ?

Nghi ngờ hợp lý. Kết nối HTTP thì bản thân chứng chỉ máy chủ không xuất hiện. Site giả có vẻ hiện màn hình đăng nhập mà không ra lỗi gì.

Ông S trả lời “không sao. Đã bật HSTS nên trường hợp đó vẫn hiện cùng thông điệp lỗi lúc nãy”. Câu 1(3) hỏi hành vi trình duyệt web đến ngay trước khi thông điệp lỗi hiện, trong 60 chữ.

Đáp án mẫu là “Thay truy cập HTTP bằng truy cập HTTPS rồi truy cập. Sau đó nhận chứng chỉ máy chủ từ site giả”.

Trong trình duyệt đang xảy ra gì

HSTS (HTTP Strict Transport Security) là cơ chế site tuyên bố “từ nay hãy tới host này luôn bằng HTTPS” bằng header Strict-Transport-Security, và trình duyệt nhớ điều đó. RFC 6797 quy định⁸.

Khi định truy cập host đang nhớ bằng http://, trình duyệt hành như sau.

1. Thay scheme URL từ http sang https. Cổng 80 nếu nêu tường minh thì đổi thành 443 (RFC 6797 mục 8.3)
2. Kết quả là kết nối HTTPS. Lúc này DNS đã bị chỉnh nên đích là site giả
3. Nhận chứng chỉ máy chủ từ site giả
4. Kiểm thất bại, thành cùng lỗi Chương 4

Quan trọng: bước thay 1 hoàn thành trước khi ra mạng. Yêu cầu HTTP thuần bản thân không được gửi. Vì thế không thành tình huống “kết nối HTTP nên chứng chỉ không ra”.

Không bấm được “bỏ qua rồi đi”

Còn một tính chất rất lớn của HSTS trên thực tế. Mục 8.4 RFC 6797 đòi khi lỗi xảy ra lúc thiết lập kênh an toàn với host HSTS đang bật, bất kể cảnh báo hay chí mạng, phải cắt kết nối. Và mục 12.1 diễn đạt hành vi đó là “No User Recourse” (không cho người dùng đường tránh), nêu không được đưa lựa chọn kiểu “kết nối này không an toàn nhưng vẫn tiếp tục?”.

Với lỗi chứng chỉ thông thường, nhiều trình duyệt chuẩn bị đường “Advanced” / “Continue” trên màn hình cảnh báo. Trên thực tế, cảnh người dùng đã quen lỗi chứng chỉ hệ thống nội bộ bấm phản xạ không hiếm. HSTS bịt phản xạ đó. Với phòng thủ site giả, có thể nói “không bấm được” còn có hiệu hơn bản thân kiểm chứng chỉ.

Tiền đề HSTS ── lần đầu không bảo vệ được

Tuy nhiên HSTS có tiền đề. Như mục 8.1 RFC 6797 định, một host trở thành “host HSTS đã biết” khi user agent nhận header Strict-Transport-Security trên kênh an toàn. Nghĩa là trình duyệt đó cần đã từng tới site thật bằng HTTPS.

Vì thế các trường hợp sau không được bảo vệ.

• PC nghiệp vụ mới phát, lần truy cập đầu diễn ra ngay dưới AP giả
• Tạo lại hồ sơ trình duyệt, hoặc xóa dữ liệu duyệt kèm cả bản ghi HSTS
• Hạn bản ghi (max-age) đã hết

Cái lấp bài toán lần đầu đó là danh sách preload HSTS. Nằm trên danh sách tên miền gắn sẵn trong trình duyệt thì bị ép HTTPS dù chưa từng truy cập.

Tuy nhiên nếu cân đăng ký site công ty, hãy kiểm điều kiện trước. Yêu cầu đăng ký như sau⁹.

• Đang cung cấp chứng chỉ hợp lệ
• Nếu đang chờ cổng 80, chuyển hướng HTTP sang HTTPS trên cùng host
• Mọi subdomain đang cung cấp bằng HTTPS (kể www nếu có bản ghi DNS)
• Trả header Strict-Transport-Security trên miền gốc với max-age 31536000 giây (1 năm) trở lên, includeSubDomains, preload

Cái có hiệu là mục 3 kết hợp includeSubDomains. Subdomain cũ hướng nội bộ chỉ HTTP, hoặc chưa có chứng chỉ, thì ngay lúc đăng ký sẽ không tới được. Trước đăng ký hãy kiểm kê hết subdomain.

Và hủy không dễ. Đơn xóa nhìn chung được nhận, nhưng thay đổi tới trình duyệt người dùng mất vài tháng, và không bảo đảm với trình duyệt ngoài Chrome⁹. Hãy vào với nghĩ preload không phải thiết lập “sai thì trả lại là xong”.

Ngược lại phía dùng, dịch vụ đám mây dùng cho nghiệp vụ có hỗ trợ HSTS không là góc nên đưa vào mục xác nhận lúc chọn.

6. Lúc phê duyệt hình thức hóa, chức năng chia sẻ thành đường mang ra ── câu 2(1)

Từ đây chuyển sang cân mang ra do nhân viên.

Ông S trước hết xác nhận vận hành chức năng chia sẻ tệp. Cấp trên có kiểm địa chỉ email đích và tệp rồi mới duyệt không. Y trả lời “hình như cũng có cấp trên chưa kiểm được”.

Ông S chỉ ra đó là câu 2(1). Trả lời cụ thể, trong 40 chữ, cách lạm dụng chức năng chia sẻ tệp để tải tệp được từ ngoài công ty M.

Đáp án mẫu là “Chỉ định địa chỉ email riêng của mình làm địa chỉ email người chia sẻ bên ngoài”.

Thiết kế đúng, vận hành hổng

Chức năng chia sẻ tệp của dịch vụ B được làm khá kỹ.

• Chia sẻ cần phê duyệt cấp trên
• Liên kết chia sẻ ngoài không được báo cho chính người đó cũng không cho cấp trên. Người chia sẻ không chuyển tiếp liên kết để mang ra được
• Liên kết chứa chuỗi ngẫu nhiên khó đoán, hạn 1 ngày

Đặc biệt mục 2 là thiết kế ý thức mang ra từ trong. Vậy mà vẫn phá được. Đích đặt thành mình thì liên kết “không báo cho chính người đó” lại tới tay chính người đó.

Và điều kiện để lối thoát này mở chỉ một: “cấp trên không kiểm đích”. Quy trình phê duyệt được thiết kế trên giả định người duyệt nhìn nội dung. Không nhìn thì đó chỉ còn đường gửi tự động.

Điều kiện phê duyệt hình thức hóa đã định

Khi phê duyệt hình thức hóa trên thực tế, nguyên nhân gần như một trong các mục sau.

Công ty M của đề thiếu chủ yếu hai mục cuối. Đưa cơ chế duyệt vào thì cũng cần cơ chế xem kết quả duyệt sau. Chỉ cần liệt kê được mỗi tháng có bao nhiêu chia sẻ ngoài tới miền email miễn phí, thủ đoạn này dễ tìm hơn nhiều.

Toàn cảnh doanh nghiệp vừa và nhỏ nên bắt đầu từ đâu nằm trong cách đi “Hướng dẫn biện pháp an ninh thông tin cho doanh nghiệp vừa và nhỏ” phiên bản 4.0 của IPA.

7. Phòng họp như lối thoát ── câu 2(2)

Câu hỏi tiếp của ông S: “Phòng họp có mang PC cá nhân vào được không”. Y trả lời “không cấm mang vào phòng họp nên mang được”.

Ở đây ra phương pháp 1 và phương pháp 2. Cả hai đều là kịch bản tải tệp từ dịch vụ B bằng PC cá nhân, rồi mang cả PC cá nhân đó ra. Thiết lập phần mềm chống rò rỉ trên PC nghiệp vụ không có hiệu gì trên PC cá nhân.

Phương pháp 1 ── giả mạo địa chỉ MAC

Phương pháp 1 là đổi [e] địa chỉ MAC của giao diện WLAN trên PC cá nhân thành địa chỉ MAC của giao diện WLAN trên PC nghiệp vụ, rồi nối PC cá nhân vào WLAN nhân viên. Trả lời ô trống e là câu 2(2).

Cái đang giữ cửa WLAN nhân viên là hai thứ: khóa chia sẻ trước WPA2-PSK, và lọc địa chỉ MAC. Nhân viên vượt được cả hai.

• Khóa chia sẻ trước được đặt trên PC nghiệp vụ, và nhân viên là người dùng PC nghiệp vụ. Đã là cách mọi người chia sẻ một khóa thì tiền đề là “người dùng có thể biết”
• Địa chỉ MAC bị phía thiết bị viết lại. Đổi từ thiết lập OS hay thuộc tính driver là chuyện thường, không cần công cụ đặc biệt. Hơn nữa địa chỉ MAC trên khung WLAN không được mã hóa, nên nhận sóng gần đó cũng biết được địa chỉ MAC của PC nghiệp vụ đã đăng ký

Lọc địa chỉ MAC và ẩn SSID có nghĩa như sắp xếp giảm kết nối nhầm. Nhưng không phải cơ chế xác thực chặn người cố ý vào. Hãy kiểm cấu hình công ty mình có đang đếm hai thứ này vào “biện pháp” không.

Phương pháp 2 ── chỉ việc nối WLAN khách

Phương pháp 2 đơn giản hơn. Nối PC cá nhân vào WLAN khách, tải tệp từ dịch vụ B, mang cả PC cá nhân ra. Chỉ thế.

Không cần giả mạo địa chỉ MAC. Cái cần chỉ là khóa chia sẻ trước của WLAN khách, và đó là thứ đang phát cho khách. Nhân viên không lý nào không biết.

Ở đây đương nhiên ra câu hỏi tiếp. Dịch vụ B chẳng hạn đã hạn chế “ID người dùng gán cho nhân viên công ty M chỉ đăng nhập được từ địa chỉ IP toàn cục của công ty M” sao?

Hạn chế địa chỉ IP nguồn đang cho phép gì

Đọc thiết lập firewall trong đề thì ra đáp án. Giao tiếp từ WLAN khách ra internet lẫn giao tiếp từ WLAN nhân viên đều được cùng NAT đổi thành cùng một địa chỉ IP toàn cục.

Nhìn từ dịch vụ B, ba cái này không phân biệt được. Hạn chế theo địa chỉ IP đi thẳng.

Khung này lặp lại cả ngoài đề thi. Hạn chế theo địa chỉ IP nguồn không nghĩa “chỉ từ thiết bị này”. Nó nghĩa “từ mọi người ra bằng địa chỉ IP toàn cục này”. Ví dụ điển hình phạm vi tưởng cho phép và phạm vi thật sự cho phép lệch nhau:

Không phải chuyện hạn chế theo địa chỉ IP nguồn vô nghĩa. Đó là chuyện đừng dùng hạn chế chỉ một lớp. Siết bằng địa chỉ IP rồi chồng cơ chế nhận diện bản thân thiết bị (chứng chỉ máy khách, chứng chỉ thiết bị) và cơ chế nhận diện người dùng (xác thực nhiều yếu tố) thì mới diễn đạt được “người này, trên thiết bị này”. Đối phó của đề này cũng đi đúng hướng đó.

8. Buộc thiết bị bằng chứng chỉ ── câu 3(1)–(4)

Để đối phó phương pháp 1, công ty M chọn EAP-TLS làm cách xác thực WLAN nhân viên, và chuẩn bị máy chủ xác thực.

Câu 3(1) ── RADIUS

Câu 3(1) hỏi giao thức trên UDP mà máy chủ xác thực dùng với EAP. Đáp án mẫu là RADIUS.

Sắp khung thì nhân vật có ba.

Giữa PC nghiệp vụ và AP là IEEE 802.1X (EAP over LAN); giữa AP và máy chủ xác thực là RADIUS. RADIUS chạy trên UDP¹⁰. Quy trình bản thân EAP-TLS do RFC 5216 quy định¹¹. Khi dựng trên Windows Server, vai máy chủ xác thực do Network Policy Server (NPS) đảm nhận¹².

Hãy nắm EAP-TLS đổi gì so với WPA2-PSK.

Hàng cuối cần bổ sung. Đối tượng máy khách kiểm chứng chỉ trong EAP-TLS là máy chủ xác thực chứ không phải AP. AP chỉ là authenticator chuyển tiếp trao đổi EAP; máy khách không xác nhận danh tính bản thân AP.

Vậy mà vẫn thành sự chuẩn bị trước evil twin Chương 4, vì nguyên liệu khóa chỉ sinh khi xác thực thành công chỉ tới AP thật giữ bí mật chia sẻ RADIUS. AP kẻ tấn công tự dựng, trừ khi phía sau có máy chủ xác thực thật, không hoàn thành thủ tục này đến cuối. Máy khách kiểm trực tiếp máy chủ xác thực; tính chính đáng của AP được suy gián tiếp từ đó.

Tuy nhiên có điều kiện. Nếu phía máy khách không đặt “tin chứng chỉ máy chủ do CA nào phát hành, tên nào” thì khi kẻ tấn công chuẩn bị máy chủ xác thực tự làm sẽ không phân biệt được. Cấu hình đã đưa EAP-TLS vào nhưng tắt kiểm chứng chỉ máy chủ trên hồ sơ máy khách thật sự tồn tại. Đưa vào rồi hãy xác nhận cả chỗ đó.

Câu 3(2) ── đáp án sai mà bình luận chấm điểm chỉ ra

Giải thích của Y tiếp. Chứng chỉ máy khách do máy chủ CA mới dựng phát hành, không phải nhân viên tự cài vào PC nghiệp vụ của mình mà cất vào PC nghiệp vụ bằng chức năng máy chủ thư mục. Và [f] tương ứng chứng chỉ máy khách được cất vào TPM của PC nghiệp vụ để [g].

Câu 3(2) hỏi ô trống f. Đáp án mẫu là khóa riêng.

Bình luận chấm điểm viết như sau.

Câu 3(2) tỷ lệ đúng hơi cao, nhưng một phần đáp án kiểu “khóa công khai” hay “chứng chỉ máy chủ” vẫn thấy. PKI là kỹ thuật quan trọng làm nền nhiều kỹ thuật bảo mật khác, nên hãy hiểu được đang dùng thế nào, ở tình huống nào.

Khóa công khai nằm trong chứng chỉ và được phát ra khắp thế giới. Không thành đối tượng bảo vệ. Cái phải bảo vệ là khóa riêng mà chỉ chủ chứng chỉ đó đáng ra đang giữ. “Xác thực bằng chứng chỉ máy khách” nói chính xác là “chứng minh mình giữ khóa riêng tương ứng khóa công khai trong chứng chỉ, bằng cách ký bằng khóa đó”. Vì thế nếu sao khóa riêng được thì xác thực bằng chứng chỉ mất nghĩa.

Cất vào TPM thì đổi gì ── câu 3(3)

Câu 3(3) hỏi ô trống g trong 20 chữ. Đáp án mẫu là “để không lấy ra khỏi PC nghiệp vụ”.

Khóa riêng để dạng tệp trên thiết bị thì đó là dữ liệu sao được. Sao sang PC cá nhân thì PC cá nhân đó xác thực thông như PC nghiệp vụ. Tưởng đã dập phương pháp 1 (giả mạo địa chỉ MAC) chỉ thành thay bằng “giả mạo chứng chỉ”.

TPM sinh khóa bên trong và giữ ở trạng thái không lấy ra ngoài. Phép toán như ký diễn ra trong TPM; bản thân khóa không tới OS, ứng dụng, cũng không tới malware. Kết quả: khóa riêng đó bị cố định vào một linh kiện vật lý của đúng một máy.

Hiện thực trên Windows: chỉ định Microsoft Platform Crypto Provider làm key storage provider (KSP) của mẫu chứng chỉ. Nhà cung cấp này bảo vệ khóa bằng TPM; nếu mẫu chứng chỉ đang tick “Allow private key to be exported” thì không chọn được¹³. Ràng buộc đương nhiên: xuất được thì bảo vệ chẳng còn nghĩa.

Vai trò bản thân linh kiện TPM được nói từ ngữ cảnh mã hóa ổ trong hướng dẫn thực tế BitLocker. Cách nghĩ “không đưa khóa riêng ra ngoài thiết bị” cùng phát kiến với thiết kế authenticator trong vì sao passkey an toàn.

Vì sao nói “không vấn đề” ── câu 3(4)

Nghe giải thích của Y, ông S đáp “cách cất đó thì tôi nghĩ không vấn đề”. Câu 3(4) hỏi lý do trong 40 chữ.

Đáp án mẫu là “vì thông tin xác thực cần cho EAP-TLS chỉ cất được trên PC nghiệp vụ”.

Theo luồng thì như sau.

1. Chứng chỉ máy khách không do nhân viên tự cài mà được phát tới PC nghiệp vụ bằng chức năng máy chủ thư mục. Không đi qua tay nhân viên
2. Khóa riêng nằm trong TPM, không lấy ra khỏi PC nghiệp vụ
3. Vì thế, nối WLAN nhân viên bằng EAP-TLS chỉ còn PC nghiệp vụ công ty phát
4. PC cá nhân dù giả mạo địa chỉ MAC cũng không qua xác thực. Phương pháp 1 bị bịt

Chú ý cách nói có điều kiện “cách cất đó thì”. Nếu khóa riêng để dạng tệp trên PC nghiệp vụ, ông S hẳn không nói không vấn đề. Cùng “xác thực bằng chứng chỉ máy khách”, phạm vi bảo vệ đổi theo chỗ đặt khóa riêng.

TPM không bảo vệ gì

Mặt khác, không phải cất vào TPM là yên tâm. TPM chỉ bảo đảm “khóa đó không bị sao sang thiết bị khác”. Các điều sau không được bảo vệ.

• Khi bản thân thiết bị bị mang ra. Mang PC nghiệp vụ ra là mang cả TPM. Quy tắc công ty M cấm mang PC nghiệp vụ ra ngoài, nhưng quy tắc và cưỡng chế kỹ thuật là hai chuyện. Cần mã hóa ổ (gồm xác thực trước khởi động) và vận hành thu hồi chứng chỉ lúc mất, riêng
• Mạo danh người dùng. TPM nhận diện thiết bị, không bảo đảm người đang thao tác thiết bị đó là ai. Xác thực người dùng cần riêng
• Malware chạy trên thiết bị. Không đọc được khóa riêng, nhưng mã chạy trên thiết bị đó vẫn “nhờ TPM ký” được. Chặn sao khóa, không chặn lạm dụng lúc thiết bị bị chiếm

9. Tách địa chỉ IP lối ra ── câu 3(5)

Để đối phó phương pháp 2 (chỉ việc nối WLAN khách), công ty M cân hai án. Án đổi thiết lập NAT của FW, và án dùng dịch vụ WLAN (dịch vụ D).

Câu 3(5) hỏi nội dung đổi án trước, trong 70 chữ. Đáp án mẫu là ý “khi truy cập internet từ WLAN khách, đặt địa chỉ IP nguồn thành địa chỉ IP khác địa chỉ IP toàn cục đang dùng” (đề ký hiệu địa chỉ IP toàn cục đó là a1.b1.c1.d1).

Như Chương 7, phương pháp 2 thành vì giao tiếp WLAN khách ra bằng cùng địa chỉ IP toàn cục với nhân viên. Vậy thì chỉ WLAN khách đổi thành địa chỉ IP toàn cục khác. Hạn chế địa chỉ IP phía dịch vụ B không đổi, chỉ truy cập từ WLAN khách rơi khỏi đó.

Việc này thành vì phía WAN của công ty M được gán nhiều địa chỉ IP toàn cục. Đọc thiết lập giao diện FW trong đề, mặt nạ subnet phía WAN là 255.255.255.248, tức /29, nên địa chỉ dùng được không phải một. Đó là phục bút mộc nhưng chắc, bắt đọc kỹ bảng đề.

Có làm cùng tay với công ty mình không phụ thuộc đường truyền đang ký có dùng được nhiều địa chỉ IP toàn cục không. Chỉ có một thì án này không lấy được. Khi đó sang án tách chương sau.

10. Đối phó chỉ xong khi xóa thiết lập không còn dùng ── câu 3(6)(7)

Kết quả cân nhắc, công ty M quyết dùng dịch vụ D.

• Đặt bộ định tuyến WLAN dịch vụ D cấp (bộ định tuyến D) trong phòng họp
• Trên bộ định tuyến D, bật chức năng máy chủ DHCP và máy chủ cache DNS
• Thiết bị khách mang theo kết nối internet bằng SIM gắn trên bộ định tuyến D, không đi qua mạng công ty M
• Máy chiếu không dùng WLAN khách, đổi sang nối bằng cáp HDMI

flowchart LR
    accTitle: Sau đối phó thì tách mạng khách
    accDescr: WLAN nhân viên dùng EAP-TLS và TPM; thiết bị khách mang theo ra internet bằng SIM của bộ định tuyến D mà không đi qua mạng công ty M
    subgraph M["Mạng nội bộ công ty M (sau đối phó)"]
        direction TB
        E["WLAN nhân viên<br/>EAP-TLS + RADIUS<br/>khóa riêng nằm trong TPM"]
        S["Mạng máy chủ"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Phòng họp"]
        T["Thiết bị khách mang theo"]
        D["Bộ định tuyến D<br/>ra internet trực tiếp bằng SIM"]
        T --> D
    end
    FW --> B["Dịch vụ B"]
    D --> I["Internet"]

Hình 3: Mạng khách đã tách khỏi mạng công ty M cả vật lý lẫn logic; cũng không còn ra bằng cùng một địa chỉ IP toàn cục.

Mạng khách đã tách khỏi mạng công ty M cả vật lý lẫn logic. Cũng không ra bằng cùng địa chỉ IP toàn cục.

Câu 3(6) ── giao tiếp trở nên không cần

Khi thiết bị khách mang theo không dùng mạng công ty M nữa, giao tiếp tới máy chủ DHCP và máy chủ [h] vốn cần đến nay trở nên không cần. Đáp án mẫu ô trống h là DNS.

Bản thân bộ định tuyến D có chức năng máy chủ DHCP và máy chủ cache DNS, nên thiết bị khách mang theo không cần dùng máy chủ DHCP, máy chủ DNS trên mạng máy chủ công ty M. Đọc lại mô tả đề thì viết nguyên.

Câu 3(7) ── liệt hết thiết lập nên xóa

Câu 3(7) bắt trả lời mọi số mục nên xóa khỏi thiết lập giao diện VLAN và thiết lập lọc của FW theo thay đổi này.

Đáp án: từ thiết lập giao diện VLAN là VLAN WLAN khách (mục 1); từ thiết lập lọc là hai quy tắc cho phép HTTP/HTTPS từ WLAN khách ra internet (mục 1) và cho phép truy cập DNS mạng máy chủ từ WLAN khách (mục 4). Kèm theo, xóa thiết lập SSID khách khỏi thiết lập AP.

Bình luận chấm điểm viết như sau.

Câu 3(7) tỷ lệ đúng cao. Cần hiểu ảnh hưởng đi kèm việc xem lại mọi thiết lập lọc của firewall và môi trường WLAN rồi trả lời, và đã được hiểu thích đáng.

Câu có tỷ lệ đúng cao, nhưng tổ chức làm tới mức đó trên thực tế không nhiều. Việc đưa cơ chế mới vào có ngân sách và hạn; việc xóa thiết lập cũ thì không. Và quên xóa hiện ra dạng sau.

Firewall của đề đánh giá từ quy tắc số mục nhỏ trước, áp quy tắc khớp đầu tiên (đề ghi rõ vậy). Với cách này, để quy tắc cho phép không còn dùng ở phía trên giống để lỗ không cho quy tắc từ chối ở cuối kịp tới.

Tuy nhiên, đừng khái quát cách đánh giá này cho mọi firewall. Sản phẩm quyết khác nhau.

Dù cách nào, việc để cho phép không dùng còn lại tự nó nguy hiểm không đổi. Đổi là “vì sao nguy hiểm” và “sửa thế nào”. Hãy xác nhận thiết bị công ty mình theo cách nào, rồi đưa góc “nguồn và đích nay còn tồn tại không” vào đối tượng kiểm kê định kỳ.

Chuyện firewall phía host — quản quy tắc nhận ứng dụng nghiệp vụ cần thế nào — nằm trong Windows Firewall và ứng dụng nghiệp vụ.

11. Biện pháp không có hiệu, và biện pháp có hiệu

Gom đề này vào một tờ thì bảng sau. Tương ứng biện pháp công ty M đang có và đường bị vượt.

Chỉ hàng cuối là “có hiệu”. Và xếp cái được lập như biện pháp thì như sau.

So thì khác tính chất rõ. Biện pháp bị vượt nhiều cái cấm “phương tiện”; biện pháp có hiệu và biện pháp được lập đổi “đường” hay “tính chất thông tin đăng nhập”. Bịt USB mà còn đường tới tệp thì mang ra vẫn thành; kéo dài khóa chia sẻ trước cũng không đổi việc đó là bí mật dùng chung.

12. Góc kiểm thực tế

Liệt kê mục xác nhận khi áp đề này lên cấu hình công ty mình.

1. Viết được chống mang ra theo đường chứ không theo phương tiện không. Không phải danh sách phương tiện USB, đính kèm email, webmail, mà làm “danh sách thiết bị và mạng tới được tệp nghiệp vụ”. Còn một đường thiết bị ngoài quản tới được thì cấm phương tiện bị đi vòng
2. Quy tắc mang vào / mang ra có đang giới hạn chỗ không. “Cấm mang vào phòng làm việc” là cho phép phòng họp, lễ tân, không gian dùng chung. Xác nhận khu vật lý và khu mạng có khớp không
3. Nói được phạm vi hạn chế địa chỉ IP nguồn thật sự đang cho phép không. Đếm hết thứ ra bằng địa chỉ IP toàn cục đó. Wi-Fi khách, mạng khách, VPN giữa chi nhánh, cổng tập trung làm việc từ xa, môi trường kiểm
4. Thông tin đăng nhập WLAN đã theo từng thiết bị chưa. Khóa chia sẻ trước là bí mật dùng chung mọi người giữ giống nhau; một người rò thì rò cả mọi người, cũng không dừng được chỉ một máy
5. Không đếm lọc địa chỉ MAC và ẩn SSID vào số biện pháp chứ. Cả hai là sắp xếp giảm kết nối nhầm, không phải xác thực
6. Khóa riêng chứng chỉ máy khách đang ở trạng thái không lấy ra khỏi thiết bị chưa. Khóa riêng để dạng tệp thì sao được. Chỉ định key storage provider dùng TPM, không cho phép xuất
7. Máy khách đã đưa EAP-TLS vào có đang kiểm chứng chỉ máy chủ xác thực không. Tắt chỗ này thì mất sức chịu với máy chủ xác thực giả
8. Lỗi chứng chỉ máy chủ có đang ở trạng thái người dùng “tiếp tục” vượt được không. Site công ty hãy đặt HSTS. Đừng để lỗi chứng chỉ hệ thống nội bộ, dạy người dùng “lỗi thì bấm đi tiếp”
9. Đang kiểm kê nội dung kho Trusted Root Certification Authorities chưa. Thứ vào đó chính là đối tác thiết bị đang tuyên bố “chứng chỉ CA này phát hành thì coi là thật”
10. Người duyệt quy trình phê duyệt có được đưa chất liệu phán không. Và có xem kết quả duyệt sau không. Định kỳ liệt kê chia sẻ tới miền ngoài, địa chỉ email miễn phí
11. Đang xóa thiết lập đường đã bãi chưa. Giao diện VLAN, quy tắc lọc, SSID, mục danh sách cho phép. Coi việc xóa cùng hạng với việc “đưa mới vào”, gắn hạn cho việc xóa

Kết ── biện pháp không viết “phạm vi” thì không bảo vệ

Nếu câu 1 hỏi “biện pháp đó chặn giai đoạn nào của cuộc tấn công nào”, câu 2 hỏi “biện pháp đó bảo vệ phạm vi nào”.

Mọi biện pháp của công ty M đều có phạm vi ngầm. Phạm vi phần mềm chống rò rỉ tới PC nghiệp vụ. Phạm vi cấm mang vào tới phòng làm việc. Phạm vi lọc địa chỉ MAC tới “đối tác không giả mạo”. Phạm vi hạn chế địa chỉ IP nguồn tới “mọi người ra bằng địa chỉ IP toàn cục đó”. Từng phạm vi đang làm việc đúng; chỉ chỗ nối với cái bên cạnh trống.

Đề này thực tế ở chỗ công ty M được vẽ như công ty đã nghiêm túc đối phó. Nhận vụ năm trước, dập cả hai đầu đường, còn đưa cả phần mềm riêng. Lỗ còn lại không vì người phụ trách lười, mà vì cách thêm từng biện pháp không thấy khe phạm vi.

Để tìm khe, không còn cách nào khác ngoài viết danh sách đường chứ không phải danh sách biện pháp. Việc Y và ông S của đề đang làm đúng là thế. Tách “kẻ tấn công bên ngoài” và “nhân viên”, rồi dập từng đường tới từng cái. “Năng lực giả định mối đe dọa trên môi trường dùng WLAN từ nhiều góc” mà IPA viết trong mục đích ra đề, hẳn là việc này.

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận đánh giá thiết kế lấy mạng và cấu hình thiết bị hiện có làm tiền đề, và hiện thực phân phối chứng chỉ cùng bảo vệ khóa trên môi trường Windows.

• Tư vấn kỹ thuật và đánh giá thiết kế
• Phát triển ứng dụng Windows
• Điều tra lỗi và nguyên nhân
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Đã cấm kết nối USB và cấm lưu đĩa cục bộ, vì sao vẫn mang tệp ra được?

Vì cái bị cấm là chức năng của PC nghiệp vụ công ty cấp, không phải đường tới nơi tệp đang nằm. Trong câu hỏi này, nhân viên dùng PC cá nhân của mình. Không chạm PC nghiệp vụ chút nào, họ nối PC cá nhân vào WLAN phòng họp, đăng nhập kho lưu trữ đám mây (dịch vụ B) bằng ID người dùng của mình, tải tệp xuống, rồi mang cả PC cá nhân đó về. Thiết lập phần mềm chống rò rỉ trên PC nghiệp vụ không có hiệu gì trên PC cá nhân. Công ty M đã cấm mang PC cá nhân vào, nhưng chỉ cấm phòng làm việc; phòng họp nằm ngoài đối tượng. Dù bịt từng phương tiện (USB, đính kèm email, webmail), việc mang ra vẫn thành nếu còn đường tới được tệp.

Dịch vụ B đã hạn chế "chỉ đăng nhập được từ địa chỉ IP toàn cục của công ty M". Vì sao WLAN khách vẫn lọt?

Vì giao tiếp WLAN khách cũng đi qua cùng NAT của cùng firewall, được đổi thành cùng địa chỉ IP toàn cục rồi mới ra internet. Nhìn từ dịch vụ B, truy cập từ PC nghiệp vụ trong công ty và truy cập từ PC cá nhân nối WLAN khách ở phòng họp đều cùng một địa chỉ IP nguồn. Không phân biệt được. Hạn chế theo địa chỉ IP nguồn cần hiểu là cho phép không phải "chỉ thiết bị này" mà "mọi người đang chia sẻ lối ra này". Wi-Fi khách, VPN giữa chi nhánh, cổng tập trung cho làm việc từ xa — thứ gì ra bằng cùng địa chỉ IP toàn cục đều vào phạm vi cho phép.

WLAN nhân viên đã có lọc địa chỉ MAC. Đó không phải biện pháp sao?

Không. Địa chỉ MAC bị phía thiết bị viết lại tùy ý. Phương pháp 1 của câu hỏi này là đổi địa chỉ MAC của giao diện WLAN trên PC cá nhân thành địa chỉ MAC của PC nghiệp vụ đã đăng ký rồi kết nối. Địa chỉ MAC trên khung WLAN bay không mã hóa, nên nhận sóng gần đó cũng biết được địa chỉ MAC đã đăng ký. Điều tương tự đúng với ẩn SSID. Tắt thông báo SSID thì SSID vẫn lộ từ trao đổi lúc thiết bị kết nối. Lọc địa chỉ MAC và ẩn SSID có hiệu giảm tai nạn kết nối nhầm, nhưng không phải cơ chế xác thực chặn người cố tình kết nối.

Dù bị chuẩn bị AP giả và site giả, vì sao nói nhân viên không bị lừa?

Vì đã kết nối HTTPS thì site giả không qua được kiểm chứng chỉ máy chủ. Hình 2 của đề liệt bốn mục có thể hiện như chi tiết lỗi lúc đó: không phải chứng chỉ do CA được tin phát hành; tên máy chủ ghi trên chứng chỉ khác tên máy chủ đích; đã thu hồi; hết hạn. Kẻ tấn công không lấy được chứng chỉ hợp lệ cho tên miền dịch vụ B, nên chứng chỉ tự ký trượt mục 1, chứng chỉ lấy hợp lệ cho miền của mình trượt mục 2. Theo bình luận chấm điểm của IPA, tỷ lệ đúng của câu hỏi kiểm nội dung kiểm tra này thấp. Lưu ý bốn mục không mạnh bằng nhau. Cái đang chặn tấn công là hai mục đầu (nhà phát hành và tên) cùng hạn; trình duyệt luôn kiểm chúng. Còn xác nhận thu hồi phụ thuộc hiện thực và cấu hình. Ví dụ Chrome thường không kiểm OCSP hay CRL trực tuyến, mà dùng danh sách hạn chế gọi CRLSet nhằm chặn khẩn. Đừng nghĩ thu hồi là chắc chắn loại. Và nếu PC nghiệp vụ được phát chứng chỉ gốc của CA nội bộ, khóa riêng hoặc thủ tục phát hành của CA đó bị kẻ tấn công nắm thì kiểm mục 1 cũng qua.

Gõ nhầm URL thành "http://" thì sao? HSTS đang làm gì?

Trình duyệt thay HTTP bằng HTTPS rồi mới kết nối, nên kết quả vẫn là lỗi chứng chỉ máy chủ. HSTS là cơ chế trình duyệt nhớ nội dung header nhận được lần trước kết nối HTTPS tới site đó. RFC 6797 đòi khi URL tới host đối tượng chứa scheme http, user agent thay bằng https, cổng 80 nếu nêu tường minh thì đổi thành 443. Nghĩa là yêu cầu HTTP thuần biến mất trước khi ra mạng. Quan trọng hơn: khi kiểm chứng chỉ thất bại lúc giao tiếp với host HSTS đang bật, đặc tả đòi cắt kết nối bất kể cảnh báo hay chí mạng. Nó nêu rõ không được đưa lựa chọn "kết nối này không an toàn nhưng vẫn tiếp tục?" cho người dùng. Tuy nhiên HSTS giả định trình duyệt đó đã từng tới site thật bằng HTTPS và nhận header. Lần truy cập đầu từ thiết bị mới toanh đụng ngay site giả thì không có hiệu. Danh sách preload gắn trong trình duyệt lấp khoảng trống lần đầu đó.

Cất khóa riêng của chứng chỉ máy khách vào TPM thì đổi gì?

Khóa riêng không lấy ra khỏi PC nghiệp vụ đó được nữa. Khóa riêng để dạng tệp trên thiết bị, sao chép sang PC cá nhân thì PC đó xác thực thông như PC nghiệp vụ. Sinh khóa trong TPM và đặt không xuất được thì phép toán như ký chỉ diễn ra trong TPM, bản thân khóa không tới OS cũng không tới malware. Kết quả: chỉ PC nghiệp vụ công ty phát mới hoàn thành xác thực EAP-TLS. Vì thế ông S mới nói "cách cất đó thì không vấn đề". Hiện thực trên Windows là chỉ định Microsoft Platform Crypto Provider làm key storage provider của mẫu chứng chỉ, và không cho phép xuất khóa riêng. Tuy nhiên TPM chỉ bảo vệ "khóa không bị sao sang thiết bị khác"; người đang cầm thiết bị đó vẫn dùng được. Mất/cắp thiết bị cần mã hóa ổ và thu hồi chứng chỉ riêng.

Nên mang gì từ câu hỏi này về thực tế?

Bốn điều. Thứ nhất, nghĩ chống mang ra theo đường chứ không theo phương tiện. Bịt từng USB, đính kèm email, webmail chẳng nghĩa gì nếu còn thiết bị tới được tệp. Thứ hai, viết ra phạm vi mà hạn chế địa chỉ IP nguồn thật sự cho phép. Wi-Fi khách hay VPN dùng cùng lối ra thì chỗ đó cũng trong phạm vi cho phép. Thứ ba, biến xác thực WLAN thành thông tin đăng nhập theo từng thiết bị. Khóa chia sẻ trước là bí mật dùng chung mọi người giữ giống nhau; một người rò thì rò cả mọi người. EAP-TLS với chứng chỉ máy khách, và cấu hình không đưa khóa riêng ra khỏi TPM, thì thông tin đăng nhập bị cố định vào thiết bị. Thứ tư, xóa thiết lập không còn dùng. Câu hỏi cuối của đề bắt liệt hết thiết lập giao diện VLAN và quy tắc lọc firewall còn lại sau khi bãi WLAN khách; theo bình luận chấm điểm IPA tỷ lệ đúng cao, nhưng tổ chức làm tới mức đó trên thực tế không nhiều.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.