Portspoof: Kỹ thuật mô phỏng dịch vụ hợp lệ trên toàn bộ 65535 cổng TCP

 (github.com/drk1wi)
1 điểm bởi GN⁺ 2024-12-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • Portspoof khiến toàn bộ 65535 cổng TCP trông như đang mở và mô phỏng chữ ký dịch vụ, biến giai đoạn trinh sát của kẻ tấn công từ một lượt quét nhanh thành công việc dài và tốn kém
  • Trả về SYN+ACK cho mọi nỗ lực kết nối và dùng hơn 9000 chữ ký dịch vụ động dựa trên regex để mỗi cổng phản hồi như một dịch vụ hợp lệ khác nhau
  • Gán cho từng cổng ngay từ lúc khởi động các chế độ phân phối hỗn hợp như gửi banner ngay, phản hồi trễ hoặc giữ im lặng, đồng thời thêm jitter vào thời gian giữ kết nối để gây khó cho việc lọc dựa trên timing
  • Với cấu hình tarpit mặc định, quét toàn bộ phiên bản bằng nmap -sV -p- có thể mất hơn 10 giờ và tạo ra hàng trăm MB dữ liệu giả, tiêu tốn thời gian và luồng của trình quét của kẻ tấn công
  • Triển khai dùng vòng lặp sự kiện epoll đơn luồng, chạy trong user space không cần quyền root và mỗi instance chạy chỉ bind một cổng TCP

Vấn đề mà Portspoof muốn giải quyết

  • Mục tiêu của Portspoof là khiến hoạt động trinh sát của kẻ tấn công trở nên chậm, tốn kém và khó tin cậy hơn
  • Thay vì một lượt quét Nmap 5 giây thông thường có thể ánh xạ các dịch vụ thực của hệ thống, trước Portspoof thì cả 65535 cổng đều hiện như đang mở
  • Mỗi cổng được thiết kế để trông như một dịch vụ hợp lệ khác nhau, khiến không có cách nhanh nào để phân biệt cổng nào là dịch vụ thật

Tính năng cốt lõi

  • Phản hồi như thể toàn bộ 65535 cổng TCP đều mở

    • Thay vì cho biết cổng là CLOSED hoặc FILTERED, nó trả về SYN+ACK cho mọi nỗ lực kết nối

  • Mô phỏng dịch vụ

    • Sử dụng hơn 9000 chữ ký dịch vụ động dựa trên regex
    • Mỗi cổng phản hồi probe của trình quét bằng một danh tính dịch vụ thuyết phục khác nhau

  • Chế độ phân phối hỗn hợp

    • Mỗi cổng nhận một profile hành vi khác nhau khi khởi động
    • Kết hợp giữa gửi banner ngay, phản hồi trễ và chế độ không phản hồi
    • Thời gian giữ kết nối được phân bố trên một dải rộng, khiến việc dò phiên bản toàn dải nmap -sV -p- vượt quá giới hạn thực tế

  • Phòng thủ chủ động

    • Có thể dùng như một “Exploitation Framework Frontend” nhắm vào chính các lỗ hổng của công cụ quét của kẻ tấn công

  • Mô hình vận hành gọn nhẹ

    • Chạy trong user space
    • Không cần quyền root
    • Mỗi instance chạy chỉ bind một cổng TCP
    • Mức dùng CPU và bộ nhớ thấp

Cách nó gây nhiễu trình quét và dò phiên bản

  • Trong quét cổng đơn giản, ngay cả các dải nhỏ như cổng 1~20 cũng đều hiện là open
    • Ví dụ đầu ra cho thấy lẫn các tên dịch vụ như tcpmux, compressnet, echo, daytime, ftp-data
  • Trong quét dò phiên bản, nó trả về các chữ ký động hợp lệ đối với probe dịch vụ
    • Trong ví dụ cổng 1~100 xuất hiện nhiều dịch vụ và chuỗi phiên bản như irc, http, pop3, ssh, ftp, smtp, telnet, tor-control
  • Kết quả là kẻ tấn công khó xác định hệ thống thực sự đang dùng cổng nào
  • Quét toàn bộ phiên bản nmap -sV -p- có thể mất hơn 10 giờ với cấu hình tarpit mặc định và tạo ra hàng trăm MB dữ liệu giả
  • Trình quét tiêu tốn thời gian và luồng vào những kết nối không dẫn tới kết quả thực

Cách tiếp cận thiết kế: tarpit epoll đơn luồng

  • Các dịch vụ thật như SSH, SMTP, FTP, HTTP gửi banner, giữ kết nối và chờ dữ liệu đầu vào từ client
  • Mô phỏng đủ thuyết phục cũng phải đi theo luồng accept, send, hold tương tự
  • Mô hình tạo một luồng cho mỗi client sẽ tiêu tốn bộ nhớ và CPU, và chi phí context switch có thể khiến bên phòng thủ cạn tài nguyên trước
  • Portspoof dùng vòng lặp sự kiện epoll đơn luồng
    • Mỗi cổng được gán chế độ phân phối khi khởi động
    • Một số cổng gửi banner ngay, một số phản hồi sau khi có dữ liệu từ client, một số thì im lặng
    • Thời gian giữ kết nối được phân bố từ vài chục mili giây đến vài phút trên nhiều bậc độ lớn
    • Mỗi kết nối có jitter nên ngay cả khi probe lặp lại cùng một cổng cũng không nhận timing giống nhau
  • Cách này khiến việc gửi dữ liệu rác tới mọi cổng rồi đo thời điểm phản hồi trở nên khó khăn
    • Tarpit đơn giản có thể giữ kết nối vài giây, trong khi dịch vụ thật có thể đóng nhanh khi nhận sai giao thức
    • Với chế độ hỗn hợp và phân bố timing rộng, hàng nghìn cổng giả cũng đóng trong phạm vi tương tự dịch vụ thật
    • Không còn ngưỡng rõ ràng để dùng cho việc lọc

Bất đối xứng chi phí

  • Chi phí phía phòng thủ là khoảng 1~2KB bộ nhớ kernel cho mỗi kết nối nhàn rỗi
  • Vòng lặp epoll là đơn luồng nên không có overhead context switch
  • Phần cứng tầm trung thông thường cũng có thể chịu được hơn 10.000 kết nối đồng thời
  • Chi phí được chuyển sang phía kẻ tấn công dưới dạng thời gian và công sức
    • Chỉ quét cổng thì khó thu được thông tin có ý nghĩa vì mọi cổng đều trông như đang mở
    • Muốn tìm dịch vụ thật phải dò phiên bản trên toàn bộ 65535 cổng và dò ở cấp giao thức với các mục tiêu có vẻ hợp lý
    • Một lượt quét 5 giây biến thành hơn 10 giờ làm việc chủ động mà kết quả vẫn chỉ là một đống kim cỏ hỗn độn

Thay đổi trong v2.0

  • v2.0 rời khỏi cách cũ là gửi banner rồi đóng kết nối
  • Cách cũ dễ bị kỹ thuật né tránh bằng cách phát hiện kết nối bị đóng như bài blog của Vicarius/Hored1971 đã đề cập
  • Engine tarpit mới giữ mọi kết nối ở trạng thái mở với timing hỗn hợp
  • Mục tiêu của cách này là ngăn lọc theo đóng kết nối, fingerprinting theo timing, phân tích banner và mô hình hóa mẫu thống kê

Cài đặt và cấu hình cơ bản

  • Việc build cần trình biên dịch C++ và CMake 3.10+
  • Quy trình build từ source như sau
mkdir build && cd build
cmake -DCMAKE_INSTALL_SYSCONFDIR=/etc ..
make
sudo make install
  • Portspoof chạy trong user space, nhưng để chặn và chuyển hướng lưu lượng đi tới các cổng khác thì cần rule tường lửa hệ thống
  • Cổng mặc định là 4444; trước tiên cần loại trừ các cổng dịch vụ thật rồi redirect phần lưu lượng TCP còn lại về Portspoof
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 4444
  • Cần thay eth0 bằng interface mạng thực tế
  • Phải thêm rule RETURN cho từng cổng đang chạy dịch vụ thật
  • Để áp dụng lâu dài có thể lưu các rule iptables hoặc dùng iptables-config trong thư mục system_files
  • Có thể dùng ví dụ script khởi động trong system_files/init.d/

Chế độ chạy

  • Chế độ mô phỏng dịch vụ là chế độ được khuyến nghị
    • Tạo và gửi chữ ký dịch vụ giả cho trình quét cổng
portspoof -c /etc/portspoof.conf -s /etc/portspoof_signatures -D
  • Có thể đặt timing tarpit tùy chỉnh bằng -t và -T
    • Ví dụ dưới đây giữ mỗi kết nối trong 10~60 giây
portspoof -s /etc/portspoof_signatures -t 10 -T 60 -D
  • Open Port Mode chỉ trả về trạng thái OPEN cho mọi nỗ lực kết nối mà không gửi banner dịch vụ
    • Kết nối vẫn tiếp tục bị xử lý theo kiểu tarpit
portspoof -D
  • Fuzzing Mode có thể dùng để gửi payload ngẫu nhiên hoặc dựa trên wordlist tới công cụ quét
portspoof -1 -v
portspoof -f payloads.txt -v

Gia cố bằng iptables

  • Chỉ với rule REDIRECT cơ bản là đã hoạt động, nhưng trình quét hung hăng có thể gây áp lực lên Portspoof bằng số lượng kết nối lớn
  • Các rule gia cố bổ sung giới hạn tốc độ và chặn tự động
    • Loại trừ các cổng dịch vụ thật khỏi redirect
    • Trong ví dụ thì loại trừ cổng SSH 22
    • Rule chặn toàn cục cũng áp dụng cho cả dịch vụ thật
  • Ví dụ rule bao gồm các yếu tố sau
    • Cho phép loopback
    • Drop các IP bị gắn nhãn PORTSCAN trong 60 giây
    • Drop nếu SYN mới từ mỗi IP nguồn vượt quá 10 gói/giây, burst 30
    • Nếu một IP đơn lẻ giữ hơn 100 kết nối tới cổng Portspoof 4444 thì gắn nhãn rồi drop
    • Cho phép lưu lượng established/related và SYN mới, sau đó drop phần còn lại
  • Với triển khai lưu lượng cao, có thể tăng kích thước danh sách xt_recent
echo "options xt_recent ip_list_tot=10000" > /etc/modprobe.d/xt_recent.conf
  • Cũng có thể điều chỉnh các thiết lập liên quan đến connection tracking của kernel và backlog
sysctl -w net.netfilter.nf_conntrack_max=131072
sysctl -w net.core.somaxconn=4096

Portspoof Pro

  • Portspoof Pro mở rộng deception từ một host đơn lẻ lên cấp độ toàn mạng
  • Một sensor duy nhất có thể mô phỏng toàn bộ mạng /16
    • Cung cấp hàng nghìn IP
    • Mỗi IP có dịch vụ riêng trên mọi cổng
    • Duy trì các cuộc hội thoại nhiều bước có trạng thái
  • Cung cấp khả năng deception trên toàn mạng
    • Biến không gian dark IP và các subnet không dùng thành một lưới deception đang hoạt động
    • Mỗi host được mô phỏng trình bày các dịch vụ độc nhất với tính cách khác nhau tùy theo IP nguồn
    • Tarpit chủ động làm cạn kiệt socket pool của kẻ tấn công và throttling các công cụ tự động
  • Hỗ trợ phát hiện quét và fingerprinting công cụ
    • Phát hiện các kỹ thuật quét SYN, FIN, NULL, XMAS, ACK
    • Fingerprinting Nmap, Masscan, ZMap và các scanner tùy biến
    • Stream telemetry JSON có cấu trúc tới SIEM kèm mapping MITRE ATT&CK
  • Được tính đến cho triển khai môi trường vận hành
    • Chạy trong môi trường sandbox bên cạnh lưu lượng production
    • Dùng chính sách định tuyến để đưa lưu lượng deception tới sensor
    • Được mô tả là không cần inline tap và không gây rủi ro cho workload thật
  • Hỗ trợ NIS2, DORA, ISO 27001, NIST CSF, CIS Controls

Giấy phép và báo cáo sự cố

  • Portspoof dùng giấy phép GNU GPLv2
  • Với các ứng dụng thương mại và hợp pháp, tài liệu hướng dẫn liên hệ tác giả để trao đổi về giấy phép phù hợp
  • Có thể báo lỗi và yêu cầu tính năng qua GitHub Issue Tracker hoặc email

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-26
Ý kiến trên Hacker News

  • Có 65536 cổng, và cổng 0 trên một số hệ điều hành cũng là cổng có thể chạy dịch vụ truy cập được từ Internet
    Và nếu nhà phát triển MariaDB thấy điều này, thì cấu hình mặc định để database lắng nghe trên cổng 0 nhằm chặn truy cập từ Internet thực ra không chặn được truy cập Internet vào DB trên khá nhiều hệ thống

    • MariaDB kiểm tra tường minh rằng cổng không phải 0 trước khi lắng nghe trên TCP socket: https://github.com/MariaDB/server/blob/ae998c22b2ce4f1023a6c...
      if (mysqld_port) có nghĩa là khi mysqld_port khác 0, và có vẻ đây là hành vi đã tồn tại ít nhất từ MariaDB 5.5
    • Trên Linux, nếu muốn thì vẫn có thể dùng cổng 0. Không thể bind trực tiếp, nhưng có thể dùng firewall để redirect cổng 0 sang một cổng khác

  • Bảo mật máy tính rốt cuộc có vẻ sẽ buộc phải tiếp tục tiến hóa theo hướng phòng thủ chủ động như trên
    Nhìn vào hệ miễn dịch phức tạp và nhiều tầng đến mức nào, có lẽ một ngày nào đó máy tính hay mạng cũng sẽ trông tương tự như vậy

    • Cái này vẫn có vẻ gần với bảo mật thụ động dựa vào obfuscation. Phòng thủ chủ động thì giống kiểu gửi ngược zip bomb cho kẻ xâm nhập đã biết để làm chết tiến trình hơn
    • IT cũng đang dần trưởng thành. Chúng ta mới lo về bảo mật được vài chục năm, và tôi đã tận mắt chứng kiến phần lớn quãng đó
      Một ngày nào đó IT sẽ trở thành một lĩnh vực đủ lão luyện, nhưng hôm nay thì chưa
    • Tôi không thích phép ví von này lắm, vì hệ miễn dịch cũng thường trục trặc và gây hại cho vật chủ, như dị ứng hay ung thư
      Tuy vậy, nếu tính cả điểm đó thì lại thấy có những nét song song đáng lo ngại
    • AI có vẻ sẽ giúp tạo ra các honeypot chất lượng cao và có chiều sâu. Đây là use case rất hợp với năng lực LLM hiện nay, vì chỉ cần trông có vẻ thuyết phục là được
    • Tôi không nghĩ da giả vờ làm miệng

  • Để chặn spambots thu thập email, tôi từng tạo một trang web sinh ra vô hạn địa chỉ email ngẫu nhiên: http://web.archive.org/web/20020610054821/http://www.sourtim...

  • Nếu chạy thứ này, có thể ai đó sẽ scan máy của tôi rồi gửi hàng chục yêu cầu bug bounty, nói rằng “phiên bản X đã biết có lỗ hổng đang chạy”

  • Giữa thập niên 90 từng có một sản phẩm honeypot tên là CyberCop Sting, ra trước Ballista của Secure Networks
    CyberCop Sting có thể mô phỏng các dịch vụ TCP/UDP của nhiều implementation, và nếu tôi nhớ đúng thì còn có thể cấu hình hành vi TCP/IP stack để trông giống các hệ điều hành khác nhau. Với thời điểm gần 30 năm trước, đó là tính năng khá đột phá
    [1] https://theswissbay.ch/pdf/Gentoomen%20Library/Security/0321...
    [2] https://news.ycombinator.com/item?id=26440139

    • Thú vị thật. Tôi cũng đang định hỏi liệu đã có dự án tương tự nào chưa
      Rõ ràng đây là việc chắc hẳn đã có người làm, nhưng cũng hơi ngạc nhiên là trước đây tôi chưa từng nghĩ tới, và còn ngạc nhiên hơn là giờ mới lần đầu nghe ý tưởng này

  • Làm vậy cuối cùng có khiến hacker hoặc bot soi kỹ server hơn, hoặc ít nhất là khiến lưu lượng đổ vào nhiều hơn không nhỉ
    Tôi không nghĩ phần lớn script kiddie sẽ lọc các honeypot tiềm năng hay thiết bị kiểu này trong công cụ của họ

    • Nếu 3 dịch vụ ngẫu nhiên trông như không còn ai dùng nữa, có lẽ sẽ nhanh chóng lộ ra server đang chạy portspoof
      Nhưng sau khi biết host còn sống, vấn đề là nên đụng vào cổng nào. Giả sử chi phí scan hoặc tấn công từng cổng trên từng server là tương đương, thì ngay cả khi có thể phân biệt các cổng bị spoof, tốt hơn vẫn là đi tìm máy khác có xác suất thành công cao hơn. Cũng có thể chạy portspoof trên 127.0.0.35 cục bộ để so sánh dữ liệu phản hồi hoặc khác biệt timing, nhưng không gian tìm kiếm bỗng lớn hơn khoảng 5000 lần so với vài cổng thường mở, và cổng trên server khác có thể trông có khả năng thành công cao hơn
    • Trả về banner có vẻ hợp lý trên các cổng phổ biến có khả năng khiến người ta soi nhiều hơn chứ không phải ít đi
      Phần lớn công cụ không tính đến tình huống mọi cổng đều mở và tạo ra dương tính giả. Trong pentest thì đây là tình huống phổ biến và có thể làm lãng phí thời gian, nhưng tôi không muốn cho kẻ tấn công thêm lý do để nhìn kỹ hơn vào hạ tầng của mình. Tôi thích port knocking hơn, gần như là hướng ngược lại của cách này
    • Tôi không phải chuyên gia an ninh mạng, nhưng mức lưu lượng cần thiết để biết cái gì là thật có khả năng sẽ vướng vào các cơ chế phát hiện khác trong quá trình đó
    • Nếu lo về scan Internet quy mô lớn thì có thể thấy nhược điểm. Nhưng nếu lo về tình huống một kẻ tấn công cụ thể chỉ scan dải IP của tổ chức, thì có vẻ nó sẽ gây cản trở khá nhiều
    • Nghĩ nhanh thì có vẻ mô hình đe dọa mà công cụ này hữu ích khá hạn chế
      Với các cuộc tấn công diện rộng, nó phải được triển khai trên hàng chục triệu host mới có hiệu quả phần nào, khi đó việc kẻ tấn công chỉ tìm honeypot để tương tác mới trở nên phi thực tế. Nếu bị tấn công có mục tiêu, nó có thể làm chậm lại đôi chút khi đối phương cố exploit các cổng honeypot, nhưng nếu bạn đang chạy dịch vụ dễ bị tấn công thì cuối cùng vẫn bị đột nhập. Ngoài ra, nếu là vendor, bạn có thể phải trả lời các bảng câu hỏi bảo mật cực kỳ phiền phức khi đội bảo mật của khách hàng tiềm năng scan thấy

  • Trên website của tôi cũng làm một thứ tương tự. https://bini.wales trả về 200 cho mọi endpoint và ghi lại mọi lần thử, nên trở thành một honeypot khá ổn trước các cuộc tấn công tự động
    Chủ yếu bắt được những đợt quét hàng loạt các plugin WordPress dễ bị tổn thương hoặc các backdoor bị bỏ quên. Tương tự, https://varun.ch/login mô phỏng một website WordPress nhưng có chút bất ngờ

    • Dù bạn trả về gì thì quét WordPress vẫn cứ kéo đến

  • Hay. Mừng là từ “honeypot” không xuất hiện lấy một lần
    Trước đây tôi từng tiếp quản một honeypot “thật”, kiểm tra thì thấy có khoảng 30 cổng đang mở, và tôi đã thực sự thốt ra “cái rác gì đây”

    • Tôi nghĩ đó chính là việc honeypot muốn làm mà
      Mở các cổng để khiến script kiddie phấn khích vì tưởng đã truy cập được thứ gì đó, nhưng thực ra chẳng có gì cả. Một honeypot bị khóa thì đến mức đó trông không còn giống honeypot cho lắm
    • Có thể một trong hai ta đang hiểu sai thuật ngữ honeypot, cũng có thể là phía tôi. Dù vậy, cái này có vẻ đủ để dùng vào việc dựng một hệ thống honeypot trong mạng
      Honeypot được dùng để thu hút và phát hiện kẻ tấn công, thường ghi lại hành vi và mẫu hoạt động của chúng để phân tích hoặc chặn. Công cụ này sẽ tốt hơn nếu có nhiều logging hơn ngoài iptables, và tự thân nó không phải là honeypot, nhưng ý tưởng thì không quá xa. Chỉ có điều trang GitHub nói nó “tăng cường bảo mật OS” thì tôi hoàn toàn không tin. Nó có thể cung cấp chút che giấu trước các trình quét dịch vụ tự động, nhưng nếu máy chủ MySQL đang lắng nghe ở 3306 và kẻ tấn công kết nối tới 3306, thì họ vẫn đang nói chuyện với MySQL. Việc 65534 cổng còn lại trả về phản hồi rác hay không chẳng quan trọng

  • Tài liệu ghi rằng “mỗi instance đang chạy chỉ bind vào một cổng TCP”, tôi tò mò không biết nó hoạt động thế nào
    Muốn phủ tất cả các cổng thì phải chạy 65535 instance à?

  • Liệu thứ này có khả năng trở thành bộ khuếch đại DoS không?
    Nếu gửi các gói được giả mạo phù hợp, có thể khiến nó gửi nhiều gói trả về nguồn nhìn thấy được không?

    • Nếu là dịch vụ TCP thì nó sẽ không gửi gói lớn trước khi “client” gửi gói ACK hợp lệ để hoàn tất bắt tay 3 bước
      Nếu là UDP thì chuyện đó có thể trở nên thật sự vô lý
    • Tấn công khuếch đại chủ yếu là vấn đề với UDP. Vì UDP không có bước xác minh đường trả về có thực sự khả dụng hay không, còn TCP thì có