Cách đọc một trao đổi IKE_SA_INIT mới trong bản ghi

Hãy bắt đầu từ một bản ghi bắt đầu trước gói đầu tiên của lần thử, nếu không bạn sẽ đọc phần giữa của cuộc trò chuyện. Một cuộc thương lượng đang chạy cho thấy các trao đổi đã mã hóa và việc gia hạn khóa, và cả hai đều không giống phần mở đầu. Phần mở đầu là chỗ bạn có thể giải mã mà không cần khóa, vì thế nó trả lời câu hỏi về khả năng tiếp cận tốt đến vậy. Bốn bước kiểm tra theo thứ tự đưa bạn từ một bản ghi mới đến một kết luận có thể bảo vệ về phía nào đã ngừng nói.

Đầu tiên, xác nhận bản ghi bắt đầu từ đầu

Bản ghi bắt đầu sau khi đường hầm được dựng sẽ chứa luồng dữ liệu đóng gói và keepalive định kỳ, và cả hai đều đã mã hóa hoặc gần như rỗng. Khởi động lại máy khách và ghi lại chính lần thử, hoặc cố ý tạo một kết nối mới trong khi bản ghi đang chạy. Nếu không thể tạo lần thử mới, hãy ghi điều đó vào ghi chú, vì không bản giải mã nào lấy lại được phần mở đầu bạn chưa từng ghi.

Giới hạn bản ghi ở hai đầu và ở UDP 500 và 4500 để tệp vẫn đủ nhỏ để đọc. Trên một máy chủ bận rộn, bản ghi không lọc chôn cuộc thương lượng dưới lưu lượng không liên quan.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Giữ tệp khi lần thử đáng chú ý, vì cùng bản ghi trả lời cả hai câu hỏi sau: trao đổi là gì, và có gì quay lại không. Gắn nhãn với thời điểm bắt đầu và cặp đầu mà bạn đã lọc. Một bản ghi không có hai dữ kiện đó là vô dụng sau một tuần, khi địa chỉ đã thay đổi và không ai nhớ lần thử nào đã được ghi.

Thứ hai, đọc phần đầu trước các tải trọng

Phần đầu IKE mang các chỉ số tham số an ninh, loại trao đổi và ID thông điệp, và trong một cuộc thương lượng mới những giá trị này rất đặc trưng. Bên khởi tạo tự nghĩ ra một SPI khác không, yêu cầu ban đầu mang SPI của bên trả lời bằng không vì chưa thấy phản hồi nào, loại trao đổi là IKE_SA_INIT, và ID thông điệp bằng không. Mọi thứ khác thuộc về giai đoạn sau của cùng cuộc thương lượng hoặc một lần thử hoàn toàn khác.

Các tải trọng đề nghị, trao đổi khóa và nonce trong trao đổi đầu tiên này đọc được công khai. Đọc được không có nghĩa là đã xác thực, và ở thời điểm này chưa bên nào chứng minh danh tính của mình.

Giá trị Diffie-Hellman riêng tư không bao giờ đi qua dây, nên bản ghi không cho phép bạn suy ra khóa phiên. Việc xác thực diễn ra trong trao đổi tiếp theo, được bảo vệ bằng những gì trao đổi đầu tiên đã thương lượng. Nếu ai đó hỏi một bên có thật không, trao đổi này không thể trả lời câu hỏi đó. Nó chỉ có thể cho thấy hai bên đã đồng ý một đề nghị và tạo ra một bí mật chung mà tệp không chứa.

Thứ ba, ghép yêu cầu với phản hồi của nó

Ghép theo cặp SPI, loại trao đổi và ID thông điệp, rồi kiểm tra cờ phản hồi. Việc truyền lại lặp lại ID thông điệp của bản gốc và không phải lần đăng nhập thứ hai. Đếm gói thay vì trao đổi là cách một cuộc thương lượng lành mạnh biến thành vòng lặp ma.

Phản hồi cũng có thể là từ chối: yêu cầu cookie, thông báo về nhóm không thể chấp nhận, hoặc lỗi về một đề nghị. Đó là những phản hồi hợp lệ, và chúng có nghĩa đường đi hoạt động trong khi chính sách thì không. Hãy giải mã thông báo thay vì coi mọi phản hồi là thành công. Khi thông báo nêu tên một nhóm hoặc một đề nghị, việc sửa nằm ở phía cấu hình chứ không phải ở tường lửa.

Hướng cũng quan trọng. Một yêu cầu không phản hồi và một phản hồi không bao giờ tới máy khách là hai lỗi khác nhau, và chỉ cái thứ hai trông giống hết thời gian chờ phía máy khách.

Thứ tư, tách IKE khỏi mọi thứ khác trên 4500

Cổng 4500 mang ba thứ trông giống nhau trong bản tóm tắt: IKE sau một dấu non-ESP không bốn byte, ESP đóng gói mà vị trí dấu có SPI khác không, và các keepalive ngắn. Chính dấu đó tách IKE khỏi ESP đóng gói, nên hãy đọc những byte ấy trước khi gọi lưu lượng là IKE. Nhãn bản ghi đọc 4500 là số cổng, không phải giao thức.

ESP đóng gói là tải trọng đã mã hóa mà bạn không thể diễn giải nếu không có khóa, và sự hiện diện của nó có thể là dấu hiệu của một đường hầm đang hoạt động chứ không phải lỗi.

Theo dõi cả hai cổng cho cùng một lần thử, vì IKE có thể chuyển sang 4500 sau khi phát hiện NAT dù đã mở trên 500. Một vết chỉ lọc trên 500 trông im lặng đúng lúc cuộc thương lượng thành công và di chuyển. Mở rộng bộ lọc và đọc lại cùng khung thời gian trước khi kết luận bất cứ điều gì từ sự vắng mặt.

Sự im lặng tại một điểm quan sát có nghĩa gì

Không có phản hồi tại máy khách chỉ chứng minh điều mà điểm đó quan sát được. Lọc, định tuyến, địa chỉ từ xa sai, dịch vụ đã dừng và khác biệt giao thức đều tạo ra cùng một vết trống.

Một ICMP unreachable liên quan bổ sung bằng chứng, nhưng hãy đọc gói được trích dẫn bên trong và ghi lại địa chỉ của thiết bị đã gửi nó.

Sự từ chối của bộ định tuyến là một sự kiện khác với lỗi đã xác thực do bên kia trả về, và chỉ cái thứ hai chứng minh dịch vụ còn sống. Hãy tương quan cùng lần thử với nhật ký máy chủ hoặc một quan sát đã được phê duyệt để biết yêu cầu có đến và phản hồi có đi ra hay không. Giữ các bản ghi trong phạm vi và riêng tư, vì các trường bắt tay đọc được không làm phần còn lại của tệp vô hại. Kết quả đáng có là một cặp yêu cầu và phản hồi khớp nhau, hoặc một khoảng trống được ghi lại với một điểm quan sát có tên.