내 서버에서 스패머 탐지

최근에 Undelivered Mail Returned to Sender뉴스 레터를 1500 명의 고객 중 한 명에게 보내는 동안 하나 를 받았습니다 . 내 웹 사이트는 이중 옵트 인 절차를 사용하여 사용자가 내 뉴스 레터를 명시 적으로 받고 싶어하는지 확인합니다.

오류 메시지 :

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.

스팸 메일의 예를 받았습니다 (수신 메일 서버의 메일 공급자로부터).

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

공급자는 또한 내 서버가 해킹 된 것 같습니다. 또한 "수신자 메일 서버는 연결 IP에 의해 제공되는 rDNS를 단순히 기록했습니다.이 경우 mail.com ([94.130.34.42])IP 주소에 대해 rDNS 항목 (mail.lotsearch.de)을 구성한 것은 아닙니다. 따라서 rDNS를 올바르게 이해하면 수신 메일 서버가 발신자 IP에 rDNS 항목을 쿼리합니다 (94.130.34.42 => => mail.lotsearch.de로 확인해야합니다. $ host 94.130.34.42).

rDNS를 스푸핑하는 방법은 무엇입니까? 이것이 기술적으로 어떻게 작동하는지 상상할 수 없습니다 (수신 메일 서버와 내 서버 사이의 인프라 어딘가에 중간자 공격이있는 경우에만).

공급자는 또한 "내 IP에서 연결하는 시스템이 손상되어 수신자 메일 서버 (직접 MX라고도 함)에 직접 연결을 통해 이러한 메시지를 전송했을 가능성이 높습니다"라고 언급했습니다. 무슨 direct MX뜻입니까? 누군가 내 메일 계정 중 하나에 유출 된 메일 자격 증명을 훔치거나 발견하여 메일 전송에 사용 했습니까?

내 서버가 해킹되지 않았는지 확인하기 위해 지금까지 수행 한 작업 :

• 메일 로그를 검색했습니다 ( var/log/mail*) : 특별한 내용이 없습니다.
• ssh 로그인 로그 ( last, lastb)를 확인했습니다.
• postfix가 중계를 수행하는지 확인 : 아니오 (telnet을 통해 점검)
• clamav를 통한 맬웨어 검사 : 결과 없음
• ssh, postfix 및 dovecot에 대한 설치 및 구성 fail2ban
• Ubuntu 16.04의 최신 패치 / 업데이트 설치 (매주 변경)
• 내 IP 주소가 블랙리스트에 있는지 확인하십시오.
• 호스팅 제공 업체의 관리 콘솔에서 rDNS 항목을 확인했습니다 :이 (가)로 올바르게 설정되었습니다 mail.lotsearch.de.
• 모든 메일 계정의 비밀번호 변경
• 쉘 액세스를 위해 변경된 공개 키

더 중요 : posteitaliane@test123.it로그 에 대한 정보가 없습니다 . 따라서 스패머가 내 서버를 잘못 사용했을 경우 (메일 계정 중 하나의 smtp 자격 증명이 유출되어 fe) 로그 파일에서 볼 수 있습니다.

내가 생각할 수있는 마지막 가능성은 침입자가 아직 찾지 못한 서버에 맬웨어를 설치 한 것입니다.

발신 메일 트래픽 (프로세스 및 포트 당)을 어떻게 모니터링 할 수 있습니까?

발신 포트 25 만 모니터링하면 postfix를 통해 전송되는 불규칙한 메일 만 트랩 할 수 있지만 잠재적 인 맬웨어 감염으로 인한 메일 트래픽은 발생하지 않습니다 (맬웨어가 메일을 직접 보내거나받는 사람 메일 서버와 통신하기 위해 25 이외의 다른 포트를 사용하는 경우) . 모든 포트에서 나가는 트래픽을 모니터링하면 의심스러운 활동을 효율적으로 검색 할 수없는 거대한 로그 파일을 얻을 수 있습니다.

편집-오픈 릴레이 테스트 추가 :

$ 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

편집-웹앱 실행

• Zend Framework 3 기반의 사용자 지정 플랫폼 ( https://framework.zend.com/ )
• 미디어 위키 ( https://www.mediawiki.org/ )
• 사마귀 버그 추적기 ( https://www.mantisbt.org/ )

제안을 받기 전에 귀하의 서비스 제공자가 귀하에게 말한 내용에 대해 약간의 의견을 남기고 싶습니다.

 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

이것은 94.130.34.42의 역방향 DNS가 mail.com이라는 것을 나타내지 않습니다 . 오히려 SMTP 클라이언트 mail.com가 HELO(또는 EHLO) 행으로 전송되었음을 나타냅니다 . (잘 구성된 메일 서버는이 연결을 완전히 거부했을 것입니다.하지만 스위스 콤은 아닙니다.)이 줄은 역방향 DNS 항목을 나타내지 않습니다. 그렇다면 괄호 안에 표시되었을 것입니다. 예를 들면 다음과 같습니다.

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

이 경우 첫 번째 호스트 이름은 메일 서버가 자신과 동일 함을 식별 한 것 EHLO입니다. 두 번째 호스트 이름은 연결 시점에 기록 된 역방향 DNS입니다.

RFC 5321 4.4 절 에는 공식 문법과 함께 Received : 행의 형식이 설명되어 있습니다.

귀하의 경우에는 역방향 DNS가 기록되지 않았습니다. IP 주소에 PTR 레코드가 있으므로 조회하지 않았거나 일시적인 DNS 오류가 있었기 때문일 수 있습니다.

이제 웹 호스팅 서비스를 실행하고 수많은 웹 앱이있는 것으로 보입니다. 이 중 하나가 손상되면 스팸 발송이 시작될 수 있습니다. 이들은 종종 메일을 로컬 메일 스풀이나 포트 587 또는 465의 인증 된 메일 서비스로 전달하지 않고 실제로 메일 서버 인 것처럼 MX 레코드를 조회하고 포트 25에 연결하여 원격 메일 서버에 직접 연결합니다. 합법적 인 웹 앱처럼.

이것을 막는 한 가지 방법은 사용자가 메일 서버 사용자가 아닌 한 포트 25에서 나가는 연결을 방지하는 방화벽 규칙을 구현하는 것입니다. 예를 들면 다음과 같습니다.

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

웹 응용 프로그램은 더 이상 원격 SMTP 서버로 직접 메일을 배달 할 수 없지만 로컬 메일 스풀 또는 인증 된 메일 서비스를 사용해야합니다.

이 시대에 나만의 메일 서버를 만드는 것은 대부분의 경우 잃어버린 전투이며 저렴한 서비스를 찾는 것이 좋습니다. 라고 한..

• 귀하를 차단 한 서비스 제공자에게가는 로그를보고 의심스러운 것을 찾을 수 있는지 확인하십시오. 누군가가 귀하의 뉴스 레터 구독을 잊고 스팸으로 표시하는 것이 가능하며 종종 발생합니다. 그런 다음 제공자에 따라 아무 잘못도하지 않았더라도 제공자의 블랙리스트에 올라갈 수 있습니다.

• 대량 메일을 다른 모든 전자 메일에서 두 서버로 분리하십시오.

• 최소 몇 개월 동안 로그를 몇 주 이상 유지하십시오. 그래서 언제든 어떤 일이 발생하면 연구하십시오.

• 매일 공급자의 유사한 상황에 대해 로그를 확인하고 매일 또는 더 빨리 조사하십시오. 두 번째 차단 및 전송을 계속 시도하면 악화 될 수 있습니다. 임시 블록에서 영구 블록으로 갈 수 있습니다. 블랙리스트에보고됩니다.

• 그들이 어떻게 그것을 구현하는지 확실하지 않지만, 많은 공급자가 아웃 바운드 메일 서비스를 위해하는 것은 공급자 / IP가 두 번째로 전자 메일을 차단하면 다른 전자 메일이 전송되지 않는다는 것입니다. 이상적으로는 그런 것을 원합니다. 두 번째 항목은 차단되므로 더 많이 보내면 문제가 악화됩니다.