Phát hiện kẻ gửi thư rác trên máy chủ của tôi

Gần đây tôi đã nhận được một Undelivered Mail Returned to Sendertrong khi gửi bản tin của mình cho một trong số 1500 khách hàng của tôi. Trang web của tôi sử dụng quy trình chọn tham gia kép để đảm bảo, người dùng rõ ràng muốn nhận bản tin của tôi.

Thông báo lỗi:

smtp; 554 ...
    Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
    refer to xyz.com if you feel this is in error.

Tôi đã nhận được một thư rác mẫu (từ nhà cung cấp thư của máy chủ nhận):

Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <posteitaliane@test123.it>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

Nhà cung cấp cũng tuyên bố rằng máy chủ của tôi dường như bị hack. Ông nói thêm rằng "máy chủ thư người nhận chỉ đơn giản ghi lại rDNS được trình bày bởi IP kết nối, trong trường hợp này mail.com ([94.130.34.42])" - điều này chắc chắn KHÔNG phải khi tôi định cấu hình mục nhập rDNS (mail.lotsearch.de) cho địa chỉ IP của tôi. Vì vậy, nếu tôi hiểu rDNS chính xác, máy chủ thư nhận được truy vấn IP của người gửi cho mục nhập rDNS (94.130.34.42 => nên giải quyết => mail.lotsearch.de, điều này chắc chắn sẽ xảy ra, khi tôi kiểm tra nó từ máy cục bộ của mình thông qua$ host 94.130.34.42 ).

Làm thế nào có thể giả mạo rDNS? Tôi không thể tưởng tượng bất kỳ cách nào điều này có thể hoạt động về mặt kỹ thuật (chỉ với một cuộc tấn công trung gian ở đâu đó trong cơ sở hạ tầng giữa máy chủ nhận và máy chủ của tôi).

Nhà cung cấp cũng đề cập rằng "có khả năng một máy kết nối từ IP của tôi đã bị xâm phạm và gửi các tin nhắn này qua các kết nối trực tiếp đến máy chủ thư người nhận (còn được gọi là MX trực tiếp)". Có direct MXnghĩa là gì? Ai đó đã đánh cắp hoặc tìm thấy thông tin thư bị rò rỉ cho một trong các tài khoản thư của tôi và sử dụng chúng để gửi thư?

Những gì tôi đã làm cho đến nay để đảm bảo rằng máy chủ của tôi KHÔNG / sẽ không bị hack:

• tìm kiếm nhật ký thư ( var/log/mail*): không có gì đặc biệt trong đó
• kiểm tra nhật ký đăng nhập ssh ( last, lastb): không có gì bất thường
• kiểm tra nếu postfix không chuyển tiếp: không nó không (kiểm tra qua telnet)
• đã kiểm tra phần mềm độc hại qua clamav: không có kết quả
• đã cài đặt và cấu hình fail2ban cho ssh, postfix và dovecot
• đã cài đặt các bản vá / cập nhật mới nhất cho Ubuntu 16.04 (tôi làm như vậy mỗi tuần)
• kiểm tra xem địa chỉ IP của tôi có trong danh sách đen không: nó không
• mục rDNS đã xác minh trong bảng điều khiển quản lý của nhà cung cấp dịch vụ lưu trữ của tôi: nó được đặt chính xác mail.lotsearch.de.
• thay đổi mật khẩu của tất cả các tài khoản thư
• đã thay đổi khóa công khai để truy cập shell

Quan trọng hơn: Không có thông tin về posteitaliane@test123.itnhật ký. Vì vậy, nếu máy chủ của tôi đã bị sử dụng sai bởi một người gửi thư rác (vì thông tin đăng nhập smtp bị rò rỉ của một trong các tài khoản thư) tôi sẽ thấy điều đó trong các tệp nhật ký.

Khả năng cuối cùng tôi có thể nghĩ đến là một kẻ xâm nhập đã đặt phần mềm độc hại vào máy chủ của tôi mà tôi chưa tìm thấy.

Làm cách nào tôi có thể theo dõi lưu lượng thư đi (mỗi quy trình và mỗi cổng)?

Chỉ giám sát cổng gửi đi 25 sẽ không giúp ích vì điều này sẽ chỉ bẫy các thư không thường xuyên được gửi qua bưu điện, chứ không phải lưu lượng thư do nhiễm phần mềm độc hại tiềm ẩn (nếu phần mềm độc hại sử dụng cổng khác hơn 25 để gửi thư trực tiếp / liên lạc với máy chủ thư người nhận) . Nếu tôi giám sát lưu lượng đi trên tất cả các cổng, tôi sẽ tìm được cách vào tệp nhật ký khổng lồ mà tôi không thể tìm kiếm thông qua hoạt động đáng ngờ một cách hiệu quả.

EDIT - Đã thêm kiểm tra cho rơle mở:

$ telnet mail.lotsearch.de 25
$ HELO test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: Relay access denied

EDIT - Chạy webapps

• Nền tảng tùy chỉnh dựa trên Zend Framework 3 ( https://framework.zend.com/ )
• Mediawiki ( https://www.mediawiki.org/ )
• Trình theo dõi lỗi của bọ ngựa ( https://www.mantisbt.org/ )

Trước khi tôi nhận được đề xuất của mình, tôi muốn bình luận một chút về điều mà nhà cung cấp của bạn đã nói với bạn:

 Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100

Điều này không chỉ ra rằng DNS ngược cho 94.130.34.42 là (hoặc là) mail.com. Thay vào đó, nó chỉ ra rằng máy khách SMTP được gửi mail.comtrong dòng HELO(hoặc EHLO) của nó . (Một máy chủ thư được cấu hình tốt sẽ hoàn toàn từ chối kết nối này, nhưng đó là trên Swisscom, không phải bạn ...) Dòng này không cho biết bất kỳ mục nhập DNS ngược nào. Nếu có, nó sẽ xuất hiện trong ngoặc đơn. Ví dụ:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

Trong trường hợp này, tên máy chủ đầu tiên là tên mà máy chủ thư tự nhận là trong tên của nó EHLO. Tên máy chủ thứ hai là DNS ngược được ghi lại tại thời điểm kết nối được thực hiện.

RFC 5321 phần 4.4 giải thích định dạng của dòng Nhận: với ngữ pháp chính thức.

Trong trường hợp của bạn, không có DNS ngược được ghi lại. Vì địa chỉ IP của bạn có bản ghi PTR, điều này có thể là do họ không tìm kiếm hoặc có lỗi DNS tạm thời.

Bây giờ, có vẻ như bạn chạy một dịch vụ lưu trữ web và có nhiều ứng dụng web. Nếu một trong số này bị xâm phạm, nó có thể bắt đầu gửi thư rác. Những người này thường tạo kết nối trực tiếp đến các máy chủ thư từ xa bằng cách tra cứu các bản ghi MX của họ và kết nối với cổng 25, như thể họ thực sự là một máy chủ thư, thay vì gửi thư đến bộ đệm thư cục bộ hoặc dịch vụ thư được xác thực trên các cổng 587 hoặc 465 như các ứng dụng web hợp pháp làm.

Một cách tôi ngăn chặn điều này là bằng cách thực hiện quy tắc tường lửa ngăn chặn các kết nối đi trên cổng 25 trừ khi người dùng là người dùng máy chủ thư. Ví dụ:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

Các ứng dụng web không còn có thể gửi thư trực tiếp đến các máy chủ SMTP từ xa mà phải sử dụng bộ đệm thư cục bộ hoặc dịch vụ thư được xác thực.

Trong thời đại ngày nay, cố gắng làm máy chủ thư của riêng bạn, phần lớn, là một trận chiến lỏng lẻo và tốt hơn hết là bạn nên tìm một dịch vụ giá cả phải chăng. Có nói rằng..

• Nhìn vào nhật ký của bạn đến nhà cung cấp đã chặn bạn và xem liệu bạn có thể tìm thấy điều gì khả nghi không. Có thể, và thường xảy ra, ai đó quên rằng họ đã đăng ký nhận bản tin của bạn và đánh dấu bạn là thư rác. Sau đó, tùy thuộc vào nhà cung cấp mà bạn có thể có trong danh sách đen của nhà cung cấp mặc dù bạn không làm gì sai.

• Tách thư hàng loạt từ tất cả các email khác của bạn vào hai máy chủ.

• Giữ nhật ký trong nhiều tuần ở mức tối thiểu và tốt hơn. Vì vậy, bất cứ điều gì xảy ra bạn nghiên cứu.

• Kiểm tra nhật ký của bạn hàng ngày để biết các tình huống tương tự từ bất kỳ nhà cung cấp nào và xem xét nó hàng ngày hoặc nhanh hơn .. Lần thứ hai bạn bị chặn và nếu bạn tiếp tục gửi nó có thể trở nên tồi tệ hơn. Bạn có thể đi từ một khối tạm thời đến một khối vĩnh viễn .. để được báo cáo vào danh sách đen.

• Không chắc chắn cách họ triển khai nó, nhưng một điều tôi biết nhiều nhà cung cấp làm cho các dịch vụ thư đi là nhà cung cấp / IP thứ hai chặn email sau đó không có email nào khác được thử gửi. Lý tưởng nhất là bạn muốn một cái gì đó như thế. Bởi vì cái thứ hai bị chặn, việc gửi thêm sẽ chỉ làm vấn đề trở nên trầm trọng hơn.