Các phương pháp tốt nhất để bắt thư rác snowshoe là gì?

Tôi đang sử dụng Smartermail cho máy chủ thư nhỏ của mình. Gần đây, chúng tôi đã gặp phải một vấn đề về việc nhận được làn sóng spam snowshoe theo cùng một mô hình. Họ đến theo đợt 3 hoặc 4 lần. Các cơ quan gần như giống hệt nhau lưu cho tên miền mà họ liên kết đến. Các IP nguồn có xu hướng từ cùng một khối / 24 trong một thời gian, sau đó chúng chuyển sang một khối khác / 24. Các lĩnh vực có xu hướng là thương hiệu mới. Họ có các bản ghi PTR và SPF hợp lệ và có tiếng nói ngẫu nhiên ở dưới cùng của cơ thể để giả mạo các bộ lọc bayesian.

Tôi đang sử dụng hàng tá RBL khác nhau bao gồm Barracuda, Spamhaus, SURBL và URIBL. Họ làm một công việc tốt để bắt hầu hết trong số họ, nhưng chúng tôi vẫn bị trượt rất nhiều vì IP và tên miền chưa được đưa vào danh sách đen.

Có bất kỳ chiến lược nào tôi có thể sử dụng, bao gồm các RBL chặn các tên miền mới được tạo hoặc xử lý cụ thể với spam snoeshow không? Tôi hy vọng tránh phải sử dụng dịch vụ lọc của bên thứ 3.

Đây có phải là một vấn đề thực sự cho người dùng của bạn?

Tôi muốn giới thiệu một dịch vụ lọc thư đầy đủ vào thời điểm này. Bayesian không thực sự nóng nữa. Danh tiếng, RBL, phân tích tiêu đề / ý định và các yếu tố khác dường như sẽ giúp nhiều hơn. Hãy xem xét một dịch vụ lọc đám mây để kết hợp nhiều cách tiếp cận ( và khối lượng tập thể ) để bảo vệ tốt hơn ( tôi sử dụng giải pháp đám mây ESS của Barracuda cho khách hàng của mình ).

Và tất nhiên: Chống thư rác - Tôi có thể làm gì với tư cách: Quản trị viên email, Chủ sở hữu tên miền hoặc Người dùng?

Chúng tôi đã không bị ảnh hưởng tiêu cực bởi sự gia tăng trong các cuộc tấn công Snowshoe. Tôi đã thấy một khoảng thời gian mà khối lượng thư tăng gấp ba lần mỗi ngày với các cuộc tấn công này. Nhưng không có điều gì xấu làm cho nó thông qua. Trong 3 ngày, Barracuda đã đưa khối lượng xuống mức bình thường.

Tôi nghĩ rằng các giải pháp lọc có cái nhìn bao quát về hoạt động thư trên toàn thế giới có thể phản ứng với các cuộc tấn công tốt hơn các bộ lọc thư riêng lẻ.

Chỉnh sửa:

Điều này cũng đã được thảo luận gần đây trên danh sách gửi thư LOPSA :

Đóng góp của tôi: https://www.mail-archive.com/tech@lists.lopsa.org/msg04180.html
Một ý kiến ​​khác: https://www.mail-archive.com/tech@lists.lopsa.org/msg04181 .html

Tôi là một anh chàng DNS Ops, người làm việc chặt chẽ với một nhóm thường xuyên phải chịu các cuộc tấn công này. Đối phó với các cuộc tấn công của Snowshoe chủ yếu là một vấn đề về quy trình, và như ewwhite chỉ ra rằng nó có thể vượt quá phạm vi của công ty bạn để giải quyết nội bộ. Tôi có thể nói rằng trừ khi bạn có một hoạt động khá lớn và một số nguồn cấp dữ liệu RBL thương mại, có lẽ bạn không nên cố gắng tự giải quyết vấn đề này bằng cách sử dụng dịch vụ lọc thương mại.

Điều đó nói rằng, chúng tôi có một số kinh nghiệm với điều này và nó thú vị hơn để chia sẻ hơn là không. Một số điểm tiếp xúc là:

• Nếu có thể, hãy đào tạo nền tảng thư của bạn để xác định các đặc điểm của một cuộc tấn công Snowshoe đang diễn ra và tạm thời từ chối các thư từ các mạng được đề cập. Các khách hàng cư xử tốt sẽ cố gắng gửi lại tin nhắn trong một thất bại tạm thời, những người khác có xu hướng không.
• Đảm bảo quản trị viên DNS của bạn đang theo dõi UDP-MIB::udpInErrorsthông qua SNMP, vì các nền tảng thư rất có khả năng vượt qua hàng đợi nhận của người nghe UDP khi cuộc tấn công Snowshoe đang diễn ra. Nếu họ không làm như vậy, một cách nhanh chóng để nói với Linux là chạy netstat -s | grep 'packet receive errors'trên các máy chủ DNS được đề cập; một số lượng lớn cho thấy rằng họ cần phải rời khỏi duffs của họ và bắt đầu chú ý. Họ sẽ cần thêm dung lượng hoặc tăng kích thước bộ đệm nhận nếu xảy ra sự cố tràn thường xuyên. (có nghĩa là các truy vấn DNS bị mất và mất cơ hội ngăn chặn thư rác)
• Nếu bạn thường xuyên thấy các cuộc tấn công này sử dụng các tên miền mới được tạo, các RBL làm nổi bật chúng sẽ tồn tại. Một ví dụ về một là FarSight NOD (những người đọc nó nên thực hiện nghiên cứu của riêng họ), nhưng nó không miễn phí.

Tiết lộ đầy đủ: Farsight Security được thành lập bởi Paul Vixie, người mà tôi có thói quen xấu khi mạo hiểm khi mọi người vi phạm các tiêu chuẩn DNS.

Tôi đã cài đặt Declude (miễn phí) và Message Sniffer (không phải) và trong 4 ngày qua tôi đã thấy một tin nhắn rác đến trong tài khoản email thử nghiệm của mình, trái ngược với hàng tá tin nhắn nhận được mỗi ngày. Theo như tôi có thể nói, chúng tôi đã không lọc được email tốt. Spamassassin có lẽ cũng là một giải pháp tốt mặc dù tôi không gặp may mắn với nó khi thử dùng Spam Assassin in a Box ..

Rất nhiều câu trả lời ở đây là để chống thư rác nói chung. Ở một mức độ nào đó, điều này có ý nghĩa vì những kẻ gửi thư rác dường như đang hướng tới snowshoe như một phương thức giao hàng ưa thích.

Snowshoe ban đầu luôn được gửi từ các trung tâm dữ liệu với khối lượng thấp (trên cơ sở mỗi IP) và luôn bao gồm một liên kết hủy đăng ký (không nói gì về việc nó có hoạt động không). Ngày nay, snowshoe hầu như không bao giờ hủy đăng ký thông tin và được gửi với khối lượng lớn từ các IP của nó, nhưng được gửi trong một vụ nổ để đến khi IP bị đưa vào danh sách đen, nó đã hoàn tất việc gửi thư. Đây được gọi là thư rác mưa đá .

Bởi vì điều này, DNSBL và thậm chí chữ ký dựa trên mô hình chặt chẽ là khủng khiếp trong việc bắt thư rác snowshoe. Có một số trường hợp ngoại lệ, chẳng hạn như danh sách CSS của Spamhaus (đặc biệt nhắm vào các mạng snowshoe và là một phần của cả SBL và ZEN), nhưng nói chung, bạn sẽ cần greylning / tarpits (có thể trì hoãn việc phân phối cho đến khi DNSBL bắt kịp ) và quan trọng nhất là hệ thống máy học điều khiển mã thông báo như lọc thư rác Bayes . Bayes đặc biệt tốt trong việc phát hiện snowshoe.

Câu trả lời của Andrew B đề cập đến Tên miền và Tên máy chủ mới sở hữu của Farsight Security (NOD), cố gắng dự đoán các mạng snowshoe khi chúng xuất hiện nhưng trước khi chúng bắt đầu spam. Spamhaus CSS có thể làm một cái gì đó tương tự. CSS đã sẵn sàng để sử dụng trong môi trường chặn, trong khi NOD thực sự được thiết kế để trở thành nguồn cấp dữ liệu cho hệ thống tùy chỉnh thay vì hệ thống chặn / độc lập.