Vì sao trang web đăng ký thị thực Mỹ lại quét các cổng mạng của tôi?

• Trang web đăng ký thị thực Mỹ bị phát hiện cố gắng thực hiện quét cổng mạng trên mạng của người dùng
• Một số người dùng quan sát thấy lưu lượng mạng bất thường khi truy cập trang web
• Mục đích của hành vi quét cổng này gây tranh cãi và làm dấy lên lo ngại về an toàn
• Một số người suy đoán đây là quy trình nhằm xác minh bảo mật
• Lo ngại về quyền riêng tư và việc truy cập mạng quá mức đang lan rộng

---

Tranh cãi về việc quét cổng mạng của trang đăng ký thị thực Mỹ

Nhiều người dùng truy cập trang web đăng ký thị thực Mỹ phát hiện rằng trang này đã cố gắng quét cổng trên mạng của họ. Vì điều này, người dùng xác nhận qua nhật ký và các dấu hiệu khác rằng khi truy cập trang bằng trình duyệt đã phát sinh lưu lượng mạng khác thường.

Những câu hỏi chính

• Chưa có hướng dẫn rõ ràng về việc liệu nỗ lực quét cổng này là quy trình xác minh nhằm tăng cường bảo mật hay có mục đích khác
• Các chuyên gia bảo mật cho rằng đây có thể là bước kiểm tra trước để lọc bot độc hại, máy chủ proxy hoặc người dùng VPN
• Tuy nhiên, đã xuất hiện tranh cãi về việc một trang web công khai xử lý dữ liệu cá nhân nhạy cảm lại truy cập các cổng mạng mà không có sự đồng ý trước, liệu có đi ngược lại các nguyên tắc bảo vệ quyền riêng tư hay không

Phản ứng và lo ngại từ cộng đồng

• Người dùng thông thường bày tỏ sự bất an trước việc truy cập mạng ngoài ý muốn
• Vì quét cổng có đặc điểm tương tự hành vi độc hại, độ tin cậy của trang web bị đặt dấu hỏi
• Một số ý kiến cho rằng tranh cãi càng lớn hơn vì hành động này diễn ra trên một trang chính thức của chính phủ Mỹ

Vấn đề bảo mật và quyền riêng tư

• Việc dò quét cổng mạng được thực hiện mà không có quyền của người dùng có thể bị xem là xâm phạm quyền hạn quá mức
• Cần thảo luận về hiệu quả kỹ thuật của cách làm này, liệu nó có thực sự giúp ích cho bảo mật hay không
• Cũng có ý kiến chỉ ra vấn đề thiếu hướng dẫn liên quan và quy trình xin sự đồng ý của người dùng còn chưa đầy đủ

Kết luận và hàm ý

Trường hợp này cho thấy khi các trang web của cơ quan công áp dụng những phương thức kỹ thuật mới vì mục tiêu bảo mật, cần tìm ra điểm cân bằng giữa bảo vệ quyền riêng tư và an toàn kỹ thuật. Đồng thời, việc cung cấp hướng dẫn rõ ràng cho người dùng và đảm bảo tính minh bạch sẽ trở thành nhiệm vụ quan trọng trong thời gian tới.

[GN⁺]

Ý kiến trên Hacker News

• Trong quá trình xin visa có vô số trò lừa đảo. Từ những trang chỉ đơn giản tính phí gấp đôi, cho tới những trang lừa rằng người nộp đã bị từ chối rồi làm giấy tờ giả dưới tên của họ. Vì vậy có vẻ hệ thống visa đang cố xác minh xem người dùng có phải người thật hay không, hay là kẻ lừa đảo đang dùng máy chủ trung gian hoặc kênh C2
  • Với một website tệ hại đến vậy thì đây lại là một cách phòng thủ khá thông minh. Bạn đời của tôi là công dân Thổ Nhĩ Kỳ nên gần đây đã nộp đơn xin visa; sau hơn 30 phút điền cực kỳ cẩn thận thì phiên làm việc hết hạn và mất sạch. Nếu không tạo tài khoản hoặc không ghi lại ID hồ sơ hiện tại thì coi như không còn cách cứu. Trong quá trình đó còn bị chuyển hướng sang một trang đáng ngờ không phải .gov, ban đầu tôi tưởng là lừa đảo nhưng hóa ra không phải. Có thể hiểu vì sao lại xuất hiện các dịch vụ trả phí giúp quá trình ác mộng này dễ thở hơn đôi chút. Việc tiếp nhận hồ sơ liên quan chủ yếu do VFS Global xử lý, mà bản thân công ty này cũng đầy vấn đề nên trên danh nghĩa chỉ là đại lý chứ thực tế không giúp được bao nhiêu. Gần đây EU đã đơn giản hóa thủ tục xin visa Schengen cho công dân Thổ Nhĩ Kỳ, vì các đại lý visa chính thức lại chính là bên lừa đảo khi bán các suất đặt lịch “giờ đẹp” trên chợ đen. Cả Mỹ lẫn EU đều thường xuyên khiến người ta đánh mất những cơ hội quý giá như học bổng vì thời gian chờ quá dài. Thêm vào đó là cả đống vấn đề nhỏ nhưng rắc rối như chuyển đổi ký tự hay lỗi mã hóa, nên tôi nghĩ nếu xuất hiện một AI agent thực sự hữu ích thì thị trường này có thể có cơ hội
  • Hệ thống visa của Ấn Độ cũng tương tự. Trang .gov.in chính thức rất khó tìm còn visa thì chỉ khoảng 10 đô và làm khá đơn giản. Các trang lừa đảo chỉ giỏi SEO thì bán đúng thứ đó với giá 80 đô, thực chất chỉ chuyển tiếp nội dung nộp đơn sang trang chính thức rồi ăn chênh lệch. Sẽ tốt hơn nếu chính phủ Ấn Độ chặn kiểu lừa đảo này, nhưng có vẻ chưa phải ưu tiên trước mắt
  • Tôi không rành mảng mạng, nên tò mò không biết quét cổng thì phát hiện kẻ lừa đảo bằng cách nào
  • Tôi khó hình dung cách đó có thể hoạt động thật sự. Nếu kiểu “quét” này chạy bằng JavaScript phía client, thì việc gửi tệp qua máy chủ proxy dường như không giúp phát hiện được gì về proxy cả
• Tính năng này đến từ script của F5; F5 là công ty bán giải pháp bảo mật chống bot. (Một script bị làm rối được tải từ đường dẫn /TSPD, và đây là dấu hiệu đặc trưng của F5)
  https://www.f5.com/
  • TS có vẻ là viết tắt của TrafficShield, công ty mà F5 đã mua từ trước, còn PD có lẽ là viết tắt của Proactive Defense
• Mãi gần đây tôi mới biết uBlock Origin có danh sách mặc định tên là "Block Outsider Intrusion into LAN". Thông tin này thật sự rất hữu ích
  • Xem yêu cầu tính năng trên github xong tôi lại thắc mắc vì sao cần đến tính năng này. Tôi không hiểu vì sao trình duyệt lại cung cấp hoặc cần phải cung cấp khả năng truy cập mạng cục bộ. Tôi từng thấy một vài yêu cầu kiểu này khi truy cập vào thứ gì đó gắn với socket như lưu lượng mDNS, nên có thể cũng từ đó mà ra
    https://github.com/uBlockOrigin/uAssets/issues/4318
  • Chỉ riêng việc kiểu truy cập này được cho phép đã đủ gây sốc. Tôi không hiểu vì sao lại có thể nảy ra ý tưởng cho phép mọi website mình ghé thăm truy cập vào mạng cục bộ của mình
  • uBlock Origin đang dần bỏ bớt các tính năng JS, nên tôi tò mò không biết bản lite có còn tính năng này không
  • Bật tùy chọn này lên thì mức độ an toàn của tôi tăng đáng kể. Cảm ơn mọi người
  • Tôi cũng không biết có tính năng này, nhưng trên laptop và trình duyệt di động của tôi nó đã được bật sẵn rồi
• Tôi không hiểu vì sao trình duyệt lại cho phép chuyện này, và vì sao không yêu cầu người dùng đồng ý như quyền truy cập microphone. Việc một website bất kỳ có thể quét cổng trong LAN của tôi là quá nguy hiểm để có thể chấp nhận. Thay vì coi đây là một “tính năng”, chẳng phải nên xem nó là lỗ hổng bảo mật sao
  • Trên Chrome thì kiểu truy cập này không được cho phép. Dịch vụ mạng cục bộ muốn được truy cập từ website bên ngoài thì phải opt-in(
    https://github.com/WICG/private-network-access
    ), và hiện đang được chuyển sang mô hình cần sự đồng ý của người dùng(
    https://github.com/WICG/local-network-access
    ). Có tranh cãi về việc PNA đã thực sự được triển khai hay chưa, nhưng vài năm trước tôi đã từng gặp trên Chrome stable nên không rõ tình trạng mới nhất chính xác ra sao. Firefox thì không hỗ trợ kiểu truy cập này. Tôi đoán là do thiếu nguồn lực phát triển
• Tôi dùng uMatrix, mặc định chặn mọi kết nối ngoài site đang truy cập và domain cấp cao hơn của nó. Ví dụ khi vào mail.yahoo.com thì phải tự cho phép yimg.com, nên kiểu quét cổng/lập hồ sơ này không có tác dụng. Lúc đầu cực kỳ bất tiện, nhưng sau vài tháng mở rộng whitelist thì khoảng 90% các site tôi vào đã nằm trong đó. Trên máy tôi, ceac.state.gov/genniv/ cố kết nối tới captcha.com, Google Analytics, Tag Manager, 127.0.0.1, và burp (một hostname cục bộ không có trong mạng của tôi). Điều thú vị là trong console của trình duyệt thì các lần thử tới localhost hoặc burp lại không hiện rõ. Sau khi cho phép 127.0.0.1 rồi xem bằng tcpdump, tôi thấy có lưu lượng đang cố kết nối tới cổng 8888 (cổng đó không mở)
  • Tôi tò mò không biết uMatrix có chặn được Facebook tracking pixel hay giải pháp thay thế gần đây là Conversions API Gateway không. Conversions API Gateway được host dưới chính domain của bạn dưới dạng container, có thể ngay dưới domain chính, rồi chuyển dữ liệu người dùng sang Facebook từ phía server. Chỉ cần chèn JS là toàn bộ dữ liệu đều bị gửi đi
  • uMatrix hiện đã ở trạng thái archive (ngừng hỗ trợ), và hiện nay nên dùng uBlockOrigin với thiết lập nâng cao được bật (cấu trúc này đã hấp thụ chức năng của uMatrix). Nếu muốn chặn mạnh hơn nữa thì nên dùng hard mode rồi tận dụng phím tắt để chuyển sang chế độ nới lỏng chặn. Cũng rất nên dùng các danh sách lọc, đặc biệt là yokoffing/filterlists và các danh sách theo khu vực/ngôn ngữ
    https://github.com/gorhill/uBlock/wiki/Blocking-mode:-hard-mode
  • Có vẻ mục đích là kiểm tra xem Burp Suite có đang kết nối với web app hay không
  • Tôi tò mò không biết họ làm cách nào để ẩn các yêu cầu tới 127.0.0.1 khỏi tab network
  • burp thực ra chính là Burp Suite như có nhắc ở
    https://portswigger.net/burp/documentation/desktop/tools/proxy
    . Có vẻ họ đang muốn làm cho việc phân tích website trở nên khó khăn hơn
• Một số tiện ích mở rộng yêu cầu quyền “truy cập dữ liệu trên mọi website”. Nếu không phải công ty nổi tiếng hay nhà phát triển đáng tin cậy thì tôi không thể hiểu nổi vì sao lại cấp quyền này. Đặc biệt tiện ích tên "Hacks and Hops" còn dùng
  https://g666gle.me/
  làm trang chủ dù đó là domain không tồn tại. Dù tiện ích kiểu này có hấp dẫn đến đâu tôi cũng sẽ không bao giờ cài
  • Kiểu mâu thuẫn này gần như là chuyện phổ biến trên các diễn đàn như HN. Tôi cảm giác ai cài tiện ích đó thì đúng là mất trí. Có quá nhiều người tiêu dùng bị ám ảnh với ảo tưởng rằng có thể “cài đặt quyền riêng tư”, để rồi lại đi tải VPN trá hình rootkit hay tiện ích ngẫu nhiên. Nếu bạn đã cài một tiện ích lừa đảo, thì biện pháp tối thiểu gần như chỉ còn là đốt cái PC đi, cán qua nó bằng ô tô, rồi tạo lại toàn bộ tài khoản ngân hàng và đặt lại mật khẩu trên một thiết bị hoàn toàn mới
• Kiểu quét cổng, fingerprint thiết bị, và anti-anonymity SAAS như thế này xảy ra trên rất nhiều website. Ebay và Facebook cũng đều làm. Nhưng trong trường hợp này mục đích chính trước hết là chặn chính trình chặn quảng cáo. Họ dùng cả fingerprint bị làm rối cỡ 1MB + quét cổng + WebGL. Điều lạ là có cả nỗ lực tìm đường dẫn của burp suite
  • Tôi tò mò không biết có thể harden mạng của mình thế nào trước kiểu tấn công này
  • Tôi từng gặp đúng kiểu quét cổng này trên một website đăng ký thẻ mới
• Lần “quét cổng” này chỉ ở mức thử kết nối cục bộ tới 127.0.0.1:8888. Tôi không rõ chính xác để làm gì, nhưng trên các website chính phủ đôi khi người ta dùng cách này để giao tiếp với phần mềm native phục vụ ký điện tử tài liệu. Tôi tò mò không biết có thêm nỗ lực kết nối tới IP nào khác không
  • Hiện tượng này cũng có thể xuất phát từ đầu đọc thẻ, máy chủ debug, hoặc lỗi của lập trình viên. Theo kinh nghiệm của tôi, từng có trường hợp URL trỏ tới localhost được baked-in từ môi trường phát triển thay vì host bên ngoài rồi bị phát hành luôn. Họ cũng có thể dùng cổng 8888 cho máy chủ dev cục bộ, nên không phải quá khó tin
  • Khả năng cao đây là nỗ lực kết nối nhằm thu thập dữ liệu/theo dõi nếu trên thiết bị người dùng (cục bộ) có một web server nào đó. Trước đây Facebook/meta cũng từng bị phát hiện theo dõi kiểu tương tự trên Android (theo dõi thông qua web server qua Messenger/Instagram). Xem thêm bên dưới
    https://news.ycombinator.com/item?id=44169115
    https://news.ycombinator.com/item?id=44175940
• Trong bối cảnh như vậy thì việc website cố kết nối tới các cổng cục bộ như đầu đọc thẻ có khi lại là điều bình thường. Ở một số hoặc phần lớn quốc gia EU, người dân dùng chip trên thẻ căn cước hoặc giấy đăng ký xe để xác thực và truy cập dịch vụ hành chính; trước đây chỉ hỗ trợ Java + Internet Explorer, nhưng từ khi IE bị khai tử và chuyển sang Chromium thì tôi không rõ họ làm theo cách nào, nên gần đây cũng chưa dùng thử
  • Giờ đây thường cần cài một dịch vụ cục bộ làm cầu nối giữa trình duyệt và driver smart card. Dịch vụ bridge này thay phần việc mà applet Java từng đảm nhiệm trước kia. Driver riêng của thẻ và dịch vụ bridge thường được cài cùng nhau
  • Có lần họ yêu cầu đọc chip NFC trong hộ chiếu bằng app iPhone/Android. Có vẻ đây là phương án thay thế hiện đại cho IE/Java
• Tôi thấy hơi xấu hổ vì trước giờ không biết đến thực tế này. Ngoài fingerprinting ra, tôi tò mò không biết còn mục đích lạm dụng nào khác không
  • Thực ra Facebook từng dùng cách này trên Android. Ứng dụng Android của Meta dựng một server trên localhost và trao đổi dữ liệu theo dõi bị chặn bởi cơ chế bảo vệ của trình duyệt thông qua server cục bộ đó. Về bản chất vẫn là fingerprinting, nhưng có thể xem là cách khai thác cực đoan nhất
    https://news.ycombinator.com/item?id=44169115
  • Có thể tồn tại router với URL dễ bị tấn công. Tìm “router authentication bypass” sẽ thấy các trường hợp như vậy
  • Trên console của Safari macOS, khi vào website thì có thể quan sát thấy hiện tượng như này
    https://files.catbox.moe/g1bejn.png
    . Tôi tò mò cụ thể cổng 8888 thường được dịch vụ nào sử dụng
  • Chủ yếu được dùng cho mục đích theo dõi, nhưng nếu người dùng đang chạy một dịch vụ nhạy cảm trên localhost thì cũng có thể bị lạm dụng để rò rỉ dữ liệu
    https://www.digitalsamba.com/blog/metas-localhost-spyware-how-webrtc-was-abused-and-how-to-stay-safe