Cisco FWSM -> Nâng cấp ASA đã phá vỡ máy chủ thư của chúng tôi

Chúng tôi gửi thư có các ký tự châu Á unicode đến máy chủ thư của chúng tôi ở phía bên kia của mạng LAN ... ngay sau khi nâng cấp từ FWSM chạy 2.3 (2) lên ASA5550 chạy 8.2 (5), chúng tôi đã thấy lỗi trong các công việc thư có chứa unicode và văn bản khác được mã hóa là Base64.

Các triệu chứng khá rõ ràng ... bằng cách sử dụng tiện ích chụp gói của ASA, chúng tôi đã chặn lưu lượng truy cập trước và sau khi nó rời khỏi ASA ...

access-list PCAP line 1 extended permit tcp any host 192.0.2.25 eq 25
capture pcap_inside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface inside
capture pcap_outside type raw-data access-list PCAP buffer 1500000 packet-length 9216 interface WAN

Tôi đã tải xuống pcaps từ ASA bằng cách đi đến https://<fw_addr>/pcap_inside/pcapvà https://<fw_addr>/pcap_outside/pcap... khi tôi nhìn chúng bằng Wireshark> Theo dõi TCP Stream, lưu lượng truy cập bên trong đi vào ASA trông như thế này

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

cZUplCVyXzRw

Nhưng cùng một thư để lại ASA trên giao diện bên ngoài trông như thế này ...

EHLO metabike

AUTH LOGIN

YzFwbUlciXNlck==

XXXXXXXXXXXX

Các ký tự XXXX có liên quan ... Tôi đã khắc phục sự cố bằng cách vô hiệu hóa kiểm tra ESMTP:

wan-fw1(config)# policy-map global_policy

wan-fw1(config-pmap)# class inspection_default

wan-fw1(config-pmap-c)# no inspect esmtp

wan-fw1(config-pmap-c)# end

Câu hỏi $ 5 ... FWSM cũ của chúng tôi đã sử dụng bản sửa lỗi SMTP mà không gặp sự cố ... thư đã đi vào đúng thời điểm mà chúng tôi đã đưa ASA mới lên mạng ... có gì khác biệt về ASA mà giờ đây nó đang phá vỡ thư này?

Lưu ý: tên người dùng / mật khẩu / tên ứng dụng đã được thay đổi ... đừng bận tâm đến việc giải mã Base64 - giải mã văn bản này.

— Mike Pennington
nguồn

Có các ký tự UTF-8 trong phiên bản 'thực' của tên người dùng đó (sau khi giải mã) không? Nếu kiểm tra đã kích hoạt nó, tôi đoán có một lý do mà nó đã chọn dòng cụ thể đó.

Nhưng có lẽ không; tính năng kiểm tra gần giống với khỉ hỗn loạn hơn là IPS. Cá nhân, điều duy nhất mà các tính năng kiểm tra thực sự cung cấp cho tôi là đau đầu (thông qua việc vệ sinh quá mức đối với lưu lượng truy cập hoàn toàn hợp lệ) và các lỗ hổng bảo mật. Từ một tìm kiếm nhanh:

CVE-2011-0394 (khởi động lại ASA từ inspect skinny)
CVE-2012-2472 (CPU DoS từ inspect sip)
CVE-2012-4660 / 4661/4662 (nhiều lần khởi động lại, bạn hiểu ý)

Khuyến cáo của tôi là không nên mất ngủ nhiều vì cần phải tắt các khía cạnh của việc kiểm tra giao thức của ASA; các ứng dụng máy chủ điểm cuối (hoặc một nền tảng bảo mật được nhắm mục tiêu như tường lửa ứng dụng web) có xu hướng thực hiện công việc tuân thủ giao thức tốt hơn nhiều.

— Shane Madden
nguồn

Tôi sẽ cần điều tra xem UTF-8 có hợp lệ không ... Tôi mất ngủ nhiều hơn từ các kết luận phi lý (quay trở lại FWSM) do các nhà điều hành chính trị trong công ty rút ra hơn là cần phải vô hiệu hóa kiểm tra vì lý do kỹ thuật ...

— Mike Pennington

Tôi với Mike về điều này. "sửa lỗi giao thức" thường bỏ qua tất cả các loại trường hợp góc trong RFC, vì (tôi cực kỳ nghi ngờ) họ không bao giờ khiến mọi người thành thạo trong mỗi giao thức để viết reqs cho mã sửa lỗi. Mặt khác, các MTA rất thành thạo trong nghệ thuật phức tạp của SMTP và được đặt tốt hơn nhiều để phát hiện sự kỳ lạ trong kết nối. Có được một MTA tốt, mạnh mẽ, giữ cho nó được vá tốt, tắt sửa chữa và ngủ ngon. Ngẫu nhiên, một rơle MTA mặt trước thường có thể làm tốt hơn nhiều việc bảo vệ kho thư chính đằng sau nó, nếu bạn thực sự lo lắng.

— MadHatter

Các ký tự được mã hóa trong Base64 là hợp lệ, kiểm tra ESMTP của ASA chỉ là thiếu sót ... bị vô hiệu hóa vĩnh viễn đối với chúng tôi ... và lưu ý đến bản thân trong tương lai.

— Mike Pennington