Là ICMP giả mạo thực tế?

Làm thế nào thực tế là giả mạo ICMP?

kịch bản 1: trong môi trường NAT, NAT theo dõi các phiên ICMP như thế nào (không phải là phiên kỹ thuật vì nó không hướng kết nối?) Đối với phản hồi ECHO / ECHO, Windows sử dụng cùng một mã định danh (0x1) và số thứ tự với 256 lần tăng cho mỗi gói . Nếu hai máy chủ đang ping cùng một máy chủ bên ngoài, làm thế nào để NAT phân biệt các gói ICMP đến? Nếu mạng nội bộ không lọc địa chỉ nguồn, việc giả mạo phản hồi ECHO sẽ khó khăn như thế nào? trường hợp sử dụng: ping icmp được sử dụng để theo dõi, bộ cân bằng tải có thể thực hiện các hành động không chính xác / không cần thiết khi nhận được phản hồi ICMP giả mạo (không thể truy cập đích, độ trễ cao, v.v.)

kịch bản 2: Một số thiết bị IPS, giả sử là GFW, kiểm tra các gói trên đường truyền. Làm thế nào thực tế là giả mạo các thông báo lỗi ICMP giết chết một kết nối với tàng hình. Thay vì gửi TCP RST, nó sẽ gửi cổng đích không thể truy cập / gói quá lớn (điều này có thể trở nên thú vị :)) với ip nguồn giả mạo (IP hợp pháp ở phía bên kia hoặc một số bước nhảy xuống đường dẫn). Theo dõi tiêu đề IP ban đầu và 64 byte đầu tiên có thể tốn kém nhưng với khả năng tính toán hiện có, liệu có thể thực hiện được?

Về cơ bản, từ bên trong hoặc bên ngoài NAT, khả năng ICMP giả mạo có thể gây ra thiệt hại / nhầm lẫn như thế nào? Tôi không nói về lũ ICMP.

BTW NAT có thể xử lý bất kỳ giao thức IP nào ngoài TCP / UDP không? Tôi thực sự không chắc chắn chính xác làm thế nào nó xử lý các loại ICMP khác nhau.

RFC 5508 "Yêu cầu hành vi của NAT đối với ICMP" cho biết (phần 3.1):

Ánh xạ truy vấn ICMP bởi các thiết bị NAT là cần thiết để các ứng dụng dựa trên truy vấn ICMP hiện tại hoạt động. Điều này đòi hỏi một thiết bị NAT chuyển tiếp các gói Truy vấn ICMP trong suốt được khởi tạo từ các nút phía sau NAT và các phản hồi cho các gói Truy vấn này theo hướng ngược lại. Như được chỉ định trong [NAT-Trad], điều này yêu cầu dịch tiêu đề IP. Một thiết bị NAPT dịch thêm Id Truy vấn ICMP và tổng kiểm tra liên quan trong tiêu đề ICMP trước khi chuyển tiếp.

Vì vậy, một thiết bị NAT thực sự có thể đặt một giá trị duy nhất vào trường Định danh khi chuyển tiếp yêu cầu ra bên ngoài. Hai máy ở bên trong sử dụng cùng một mã định danh không có vấn đề gì, thiết bị NAT sẽ sử dụng hai giá trị khác nhau và ghi nhớ sự kết hợp của ID gốc và địa chỉ IP bên trong.

Một số thông tin cụ thể (cũ) của Cisco có thể được tìm thấy ở đây: http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=3 . Trang này cũng bao gồm một danh sách các giao thức / ứng dụng được hỗ trợ cho NAT.

Nếu thông báo ICMP được gửi để thông báo lỗi do kết nối TCP gây ra, thông báo ICMP phải bao gồm tiêu đề và một phần tải trọng của phân đoạn TCP gây ra lỗi. Điều này là cần thiết để cho phép máy chủ nhận xác định kết nối TCP.

Một thiết bị NAT có thể thực hiện chính xác điều tương tự để tìm ra nơi gửi lỗi ICMP mà nó nhận được. Nếu nó có ánh xạ tương ứng với tiêu đề TCP trong tải trọng ICMP, nó biết nơi gửi thông điệp ICMP.

Kẻ tấn công muốn giả mạo lỗi ICMP sẽ cần biết các cổng và địa chỉ IP nguồn và đích để tạo tin nhắn của mình. Vì tải trọng thông báo ICMP cũng sẽ chứa số thứ tự TCP, điểm cuối TCP cũng có thể xác minh xem số thứ tự này có hợp lệ không (tức là đã gửi và chưa được xác nhận). Điều này sẽ làm cho việc giả mạo khó khăn hơn nhiều, nhưng việc xác thực này có thể không được thực hiện trong tất cả các hệ thống.

Có lẽ bạn nên có một cái nhìn tốt về RFC 5927 "Tấn công ICMP chống lại TCP".

Trong bất kỳ triển khai NAT hiện đại nào, theo dõi kết nối thường là một phần cơ bản của việc hỗ trợ nó. NAT thực sự không có bất kỳ giới hạn nào về giao thức IP có thể được xử lý bởi NAT - Linux Netfilter có thể vui vẻ NAT bất kỳ giao thức ip nào, nhưng rõ ràng, với giới hạn là nếu không có xử lý đặc biệt cho giao thức đó (ví dụ như phân biệt đối xử bổ sung) thì chỉ có một bên trong máy chủ lưu trữ sẽ có thể liên lạc với một máy chủ bên ngoài cụ thể tại một thời điểm.

Trong trường hợp của ICMP echo request, trường định danh và dấu thời gian rất khó khớp với máy chủ khác có cùng điểm cuối từ xa - do đó, cung cấp triển khai theo dõi kết nối NAT / kết nối có khả năng sử dụng dữ liệu này, nó có thể phân biệt giữa hai dữ liệu này. Đối với destination unreachablethiết bị NAT sẽ phải theo dõi dữ liệu tải trọng (cụ thể là 8 byte đầu tiên) để đảm bảo tính hợp lệ của thông báo lỗi ICMP - nhưng ngay cả như vậy, điểm cuối của máy chủ chắc chắn phải xác thực chính xác thông báo đó.

Nói chung, giả sử ngăn xếp mạng tuân thủ RFC, các tin nhắn ICMP giả mạo không phải là vấn đề do thực tế là một số trường là duy nhất ... Trừ khi kẻ tấn công là người trực tiếp ở giữa, tại đó chúng có thể can thiệp khá tự do - tất nhiên, đây là lý do tại sao những thứ như IPsec, TCP-MD5 và TCP-AO tồn tại.

nb: trong khi một số RFC tồn tại liên quan đến NAT, thì nó không nên được coi là một tiêu chuẩn đã được thống nhất theo cách mà những thứ như giao thức định tuyến là.