ตรวจจับผู้ส่งอีเมลขยะบนเซิร์ฟเวอร์ของฉัน


12

ฉันเพิ่งได้รับหนึ่งUndelivered Mail Returned to Senderในขณะที่ส่งจดหมายข่าวของฉันไปยังหนึ่งใน 1,500 ลูกค้าของฉัน เว็บไซต์ของฉันใช้ขั้นตอนการเลือกเข้าคู่เพื่อให้แน่ใจว่าผู้ใช้ต้องการรับจดหมายข่าวของฉันอย่างชัดเจน

ข้อความแสดงข้อผิดพลาด:

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

ผู้ให้บริการยังกล่าวอีกว่าเซิร์ฟเวอร์ของฉันดูเหมือนจะถูกแฮ็ก เขากล่าวเพิ่มเติมว่า "เซิร์ฟเวอร์อีเมลผู้รับได้บันทึก rDNS ที่นำเสนอโดย IP ที่เชื่อมต่อในกรณีนี้mail.com ([94.130.34.42])" - ซึ่งไม่แน่นอนเนื่องจากฉันกำหนดค่ารายการ rDNS ของฉัน (mail.lotsearch.de) สำหรับที่อยู่ IP ของฉัน ดังนั้นถ้าฉันเข้าใจ rDNS อย่างถูกต้องเซิร์ฟเวอร์การรับจะสอบถาม IP ของผู้ส่งสำหรับรายการ rDNS (94.130.34.42 => ควรแก้ไขเป็น => mail.lotsearch.de ซึ่งจะทำอย่างแน่นอนเมื่อฉันทดสอบจากเครื่องท้องถิ่นของฉันผ่านทาง$ host 94.130.34.42)

เป็นไปได้ที่จะหลอก rDNS ได้อย่างไร ฉันไม่สามารถจินตนาการได้ว่าวิธีการนี้สามารถทำงานได้ทางเทคนิค (เฉพาะกับการโจมตีแบบคนกลางกลางบางแห่งในโครงสร้างพื้นฐานระหว่างเมลเซิร์ฟเวอร์ที่รับและเซิร์ฟเวอร์ของฉัน)

ผู้ให้บริการดังกล่าวยังกล่าวว่า "เป็นไปได้ว่าเครื่องที่เชื่อมต่อจาก IP ของฉันถูกโจมตีและส่งข้อความเหล่านี้ผ่านการเชื่อมต่อโดยตรงไปยังเซิร์ฟเวอร์จดหมายของผู้รับ (หรือที่เรียกว่า Direct MX)" อะไรdirect MXหมายถึง? มีคนขโมยหรือพบข้อมูลประจำตัวของอีเมลที่รั่วไหลไปยังหนึ่งในบัญชีอีเมลของฉันและใช้พวกเขาสำหรับการส่งจดหมาย?

สิ่งที่ฉันได้ทำไปแล้วเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ของฉันไม่เป็น / จะไม่ถูกแฮ็ก:

  • ค้นหาบันทึกจดหมาย ( var/log/mail*): ไม่มีสิ่งใดในนั้น
  • ตรวจสอบบันทึกการเข้าสู่ระบบ ssh ( last, lastb): ไม่มีอะไรผิดปกติ
  • ตรวจสอบว่า postfix กำลังทำการส่งสัญญาณ: ไม่มีมันไม่ใช่ (ทำเครื่องหมายผ่าน telnet)
  • ตรวจสอบมัลแวร์ผ่านทาง clamav: ไม่มีผลลัพธ์
  • ติดตั้งและกำหนดค่า fail2ban สำหรับ ssh, postfix และ dovecot
  • ติดตั้งแพทช์ / อัปเดตล่าสุดสำหรับ Ubuntu 16.04 (ฉันทำทุกสัปดาห์)
  • ตรวจสอบว่าที่อยู่ IP ของฉันอยู่ในบัญชีดำหรือไม่: ไม่ใช่
  • ได้รับการยืนยันรายการ rDNS mail.lotsearch.deในคอนโซลการจัดการของผู้ให้บริการโฮสติ้งของเรามีการตั้งค่าอย่างถูกต้อง
  • เปลี่ยนรหัสผ่านของบัญชีเมลทั้งหมด
  • เปลี่ยนพับลิกคีย์สำหรับการเข้าถึงเชลล์

สำคัญกว่า: ไม่มีข้อมูลเกี่ยวกับposteitaliane@test123.itในบันทึก ดังนั้นหากเซิร์ฟเวอร์ของฉันถูกผู้ใช้สแปมเมอร์ใช้ในทางที่ผิด (fe เนื่องจากข้อมูลประจำตัว smtp ที่รั่วไหลของหนึ่งในบัญชีอีเมล) ฉันจะเห็นว่าในไฟล์บันทึก

ความเป็นไปได้สุดท้ายที่ฉันคิดได้ก็คือผู้บุกรุกวางมัลแวร์ที่เซิร์ฟเวอร์ของฉันซึ่งฉันยังไม่พบ

ฉันจะตรวจสอบปริมาณการใช้งานจดหมายขาออก (ต่อกระบวนการและต่อพอร์ต) ได้อย่างไร

การตรวจสอบพอร์ตขาออก 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

แก้ไข - เรียกใช้ webapps


"ถ้าฉันตรวจสอบปริมาณการใช้ข้อมูลขาออกบนพอร์ตทั้งหมด" ... ทำไมล่ะ ปริมาณการใช้งานอื่น ๆ ที่ส่งเมลเซิร์ฟเวอร์นี้คืออะไร แน่ใจหรือไม่ว่าคุณไม่ได้กำหนดค่ารีเลย์แบบเปิด และไม่มีใครที่สามารถเข้าถึงการส่งจดหมายบนเซิร์ฟเวอร์ได้รั่วไหลออกมารับรอง?
Daniel Widrick

@DanielWidrick mailserver ใช้เป็นเว็บเซิร์ฟเวอร์ด้วยดังนั้นปริมาณการใช้งานที่ 443 และ 80 จึงเป็นไปได้ ฉันคิดว่ามีมัลแวร์บางประเภทวางอยู่บนเซิร์ฟเวอร์ของฉันสื่อสารโดยตรงกับเซิร์ฟเวอร์จดหมายภายนอก เกี่ยวกับรีเลย์แบบเปิด: ฉันแก้ไขคำถามด้วยเช็คที่ฉันทำเพื่อให้มั่นใจว่าไม่มีรีเลย์แบบเปิด คำถามสุดท้ายของคุณตอบยากเพราะฉันไม่รู้เกี่ยวกับ "สุขภาพ" ของคอมพิวเตอร์ลูกค้าของฉัน (ที่มีการกำหนดค่าบัญชีอีเมลของเซิร์ฟเวอร์ของฉัน) หรือหากพวกเขาติดมัลแวร์ / keylogger ซึ่งได้รับสิทธิเป็นต้น
mfuesslin

ดิสก์ราคาถูก ในสถานการณ์ของคุณมีกรณีที่ถูกต้องในการรักษามูลค่าของบันทึกหนึ่งปี พิจารณาใช้ syslog ฯลฯ เพื่อจัดส่งพวกเขาออกจากเซิร์ฟเวอร์โดยตรง
Criggie

คำตอบ:


13

ก่อนที่ฉันจะได้รับคำแนะนำของฉันฉันต้องการแสดงความคิดเห็นเล็กน้อยเกี่ยวกับสิ่งที่ผู้ให้บริการของคุณพูดกับคุณ:

 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

นี่ไม่ได้ระบุว่า DNS ย้อนกลับสำหรับ 94.130.34.42 คือ (หรือเคย) mail.com ค่อนข้างจะเป็นการระบุว่าไคลเอ็นต์ SMTP ที่ส่งmail.comในบรรทัดHELO(หรือEHLO) ของมัน (เมลเซิร์ฟเวอร์ที่กำหนดค่าไว้อย่างดีจะปฏิเสธการเชื่อมต่อนี้โดยสิ้นเชิง แต่อยู่ใน Swisscom ไม่ใช่คุณ ... ) บรรทัดนี้ไม่ได้ระบุรายการ DNS ย้อนกลับใด ๆ ถ้าเป็นเช่นนั้นมันจะปรากฏขึ้นภายในวงเล็บ ตัวอย่างเช่น:

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

EHLOในกรณีนี้ชื่อโฮสต์แรกคือสิ่งที่เซิร์ฟเวอร์อีเมลที่ระบุตัวเองในขณะที่ของมัน ชื่อโฮสต์ที่สองคือ DNS ย้อนกลับที่บันทึกในเวลาที่ทำการเชื่อมต่อ

RFC 5321 ส่วน 4.4อธิบายรูปแบบของสายที่ได้รับ: พร้อมไวยากรณ์อย่างเป็นทางการ

ในกรณีของคุณจะไม่มีการบันทึก DNS ย้อนกลับ เนื่องจากที่อยู่ IP ของคุณมีระเบียน PTR อาจเป็นเพราะพวกเขาไม่ได้ค้นหาหรือมีความล้มเหลว DNS ชั่วคราว


ตอนนี้ดูเหมือนว่าคุณจะใช้บริการเว็บโฮสติ้งและมีเว็บแอปมากมาย หากหนึ่งในนั้นถูกบุกรุกมันอาจเริ่มส่งสแปม สิ่งเหล่านี้มักจะทำการเชื่อมต่อโดยตรงไปยังเมลเซิร์ฟเวอร์ระยะไกลโดยการค้นหาเรคคอร์ด MX และการเชื่อมต่อกับพอร์ต 25 ราวกับว่าพวกเขาเป็นเมลเซิร์ฟเวอร์เองแทนที่จะส่งเมลไปยังสปูลโลคัลหรือบริการจดหมายรับรองความถูกต้องบนพอร์ต 587 หรือ 465 แอปพลิเคชันเว็บที่ถูกกฎหมายทำ

วิธีหนึ่งในการหยุดสิ่งนี้คือการใช้กฎไฟร์วอลล์ที่ป้องกันการเชื่อมต่อขาออกที่พอร์ต 25 เว้นแต่ผู้ใช้นั้นเป็นผู้ใช้เซิร์ฟเวอร์อีเมล ตัวอย่างเช่น:

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

แอปพลิเคชันบนเว็บไม่สามารถส่งจดหมายโดยตรงไปยังเซิร์ฟเวอร์ SMTP ระยะไกล แต่ต้องใช้สปูลอีเมลในพื้นที่หรือบริการอีเมลที่ได้รับการรับรอง


ขอบคุณสำหรับคำตอบ. ฉันจะต้องระบุiptablesกฎเพื่อให้ผู้ใช้ postfix และ plesk ส่งอีเมลได้อย่างไร (อย่างที่ฉันคิดว่า Plesk Panel จะส่งอีเมลโดยตรงไม่ใช่ผ่าน postfix) เป็นไปได้ไหมที่จะกำหนดค่า crondaemon (cronjobs ของฉัน) เพื่อส่งอีเมลผ่าน smtp ผ่าน postfix? ฉันไม่ต้องการที่จะเพิ่มผู้ใช้ cron ใน iptables (เป็นข้อยกเว้นอื่น) เพราะมันจะปลอดภัยมากขึ้นที่จะให้การรับส่งจดหมายเมื่อเป็นไปได้ที่จะผ่าน postfix เป็นไปได้ไหมที่จะให้ crontab ใช้ postfix ในการส่งบันทึกข้อผิดพลาด? ฉันควรตั้งคำถามใหม่ที่นี่ใน serverfault หรือไม่
mfuesslin

ฉันไม่รู้จะทำอย่างไรกับ Plesk เราไม่ตอบคำถามเกี่ยวกับ Plesk ที่นี่อยู่ดี
Michael Hampton

ตกลง แต่ถ้าฉันต้องการระบุผู้ใช้หลายคนที่อนุญาตให้ส่งข้อมูลผ่านพอร์ต 25 ฉันสามารถคัดลอกกฎ iptables และเพิ่มอีกหนึ่งวินาทีกับผู้ใช้รายอื่นหรือฉันต้องระบุไว้ในกฎเดียวหรือไม่
mfuesslin

อาจจะไม่; ฉันคิดว่าคุณต้องสร้างห่วงโซ่ผู้ใช้
Michael Hampton

สิ่งหนึ่งที่เกี่ยว iptables ให้ปกครอง: คุณแน่ใจว่าเราไม่จำเป็นต้องตั้งค่ากฎสำหรับผู้ใช้root? เนื่องจากกระบวนการหลักของ postfix นั้นดำเนินการโดยrootส่วนใหญ่ หรือกระบวนการหลัก postfix วางไข่กระบวนการย่อยโดยใช้postfix-user เพื่อส่งอีเมล / ทำสิ่งต่างๆ ฉันลองกฎ iptables ของคุณไม่สามารถส่งอีเมลได้ ... ถ้าฉันps -ef | grep "postfix"เห็นกระบวนการย่อยบางอย่างที่ทำงานโดยผู้postfixใช้และกระบวนการหลักหนึ่งกระบวนการที่ดำเนินการโดยroot...
mfuesslin

7

ในวันนี้และอายุการพยายามทำเซิร์ฟเวอร์อีเมลของคุณคือส่วนใหญ่การต่อสู้ที่หายไปและคุณดีกว่าที่จะหาบริการที่เหมาะสม ต้องบอกว่า ..

  • ดูบันทึกของคุณไปยังผู้ให้บริการที่บล็อกคุณและดูว่าคุณสามารถพบสิ่งที่น่าสงสัยหรือไม่ เป็นไปได้และเกิดขึ้นบ่อยครั้งที่มีคนลืมพวกเขาสมัครรับจดหมายข่าวของคุณและทำเครื่องหมายว่าคุณเป็นสแปม จากนั้นขึ้นอยู่กับผู้ให้บริการคุณสามารถขึ้นบัญชีดำของผู้ให้บริการแม้ว่าคุณจะไม่ได้ทำอะไรผิด

  • แยกการส่งจดหมายจำนวนมากจากอีเมลอื่นทั้งหมดของคุณเป็นสองเซิร์ฟเวอร์

  • เก็บบันทึกเป็นสัปดาห์อย่างน้อยเดือนและดีกว่า ดังนั้นทุกครั้งที่มีสิ่งใดเกิดขึ้นคุณค้นคว้า

  • ตรวจสอบบันทึกประจำวันของคุณสำหรับสถานการณ์ที่คล้ายกันจากผู้ให้บริการรายใด ๆ และตรวจสอบบันทึกรายวันหรือเร็วกว่า .. ครั้งที่สองที่คุณถูกบล็อกและหากคุณพยายามส่งต่อไปจะยิ่งแย่ลง คุณสามารถเปลี่ยนจากบล็อกชั่วคราวเป็นบล็อกถาวร .. เพื่อรับรายงานไปยังบัญชีดำ

  • ไม่แน่ใจว่าพวกเขาใช้งานอย่างไร แต่สิ่งหนึ่งที่ฉันรู้ว่าผู้ให้บริการจำนวนมากทำกับบริการอีเมลขาออกคือผู้ให้บริการ / IP รายที่สองทำการบล็อกอีเมลจากนั้นจึงไม่มีการพยายามส่งอีเมลอื่น เป็นการดีที่คุณต้องการอะไรแบบนั้น เนื่องจากบล็อกที่สองถูกบล็อกการส่งที่มากขึ้นจะทำให้ปัญหารุนแรงขึ้น


4
@mfuesslin Mailchimp จะเป็นแพลตฟอร์มที่ผิดที่จะใช้ Mailchimp เป็นบริการการตลาดผ่านอีเมลสิ่งที่คุณต้องการคือบริการอีเมลธุรกรรม ดู Mandrill (เป็นของคนเดียวกันที่เป็นเจ้าของ Mailchimp) คือ $ 20 ต่อเดือนสำหรับบล็อกอีเมล 25,000 ฉบับ ไม่แพงมาก การส่งอีเมลจำนวนมากนี้ทุกวันจากที่อยู่ IP ของคุณจะส่งผลให้มีอัตราสแปมสูง ... เป็นการต่อสู้ที่แพ้ คุณสามารถจ้างทีมงานทั้งหมดเพื่อไม่ทำอะไรเลย แต่มีแนวโน้มที่อัตราการส่งมอบของคุณทุกวันทุกวันและยังไม่ดีเท่าการใช้บริการธุรกรรม
SnakeDoc

1
ผู้ที่ใช้ serverfault.com ควรสามารถใช้งานเซิร์ฟเวอร์อีเมลได้ มันไม่ยากเลยที่จะทำ ที่กล่าวมาดูเหมือนว่าเซิร์ฟเวอร์อีเมลนั้นไม่ถูกต้อง แต่ดูเหมือนว่าหน้าเว็บที่ถูกบุกรุกบางส่วนกำลังส่งสแปมโดยตรง
wurtel

1
@wurtel เพียงเพราะมีความรู้ในการทำสิ่งที่ไม่ได้หมายความว่ามันมีเหตุผลที่จะทำ หากคุณสามารถหาบริการสำหรับ X / เดือนเพื่อทำสิ่งที่คุณต้องการและมันจะพาคุณ 4X / เดือนมูลค่าของเวลา / ความพยายามที่จะทำมันด้วยตัวคุณเองแล้วมันไม่สมเหตุสมผลที่จะทำมันเอง
Francisco1844

1
@wurtel Capable? ใช่. ส่งไปยังกล่องจดหมายอย่างต่อเนื่องส่งอีเมลมากกว่า 1,500 ฉบับต่อวันหรือไม่ น่าสงสัยและอาจไม่ใช่ - ไม่มีใครบอกว่าคุณไม่สามารถทำได้ ... เพียงแค่ทำมันให้ดีสม่ำเสมอและตลอดระยะเวลานานคุณจะเสียค่าใช้จ่ายมากกว่า $ 20 ต่อเดือน .
SnakeDoc

2
ฉันดูแลเซิร์ฟเวอร์ดังกล่าวมานานกว่า 15 ปีส่งข้อความเมลลิงลิสต์รายการส่งข้อความมากกว่า 30,000 รายการทุกวันเป็นจำนวนหลายโดเมนและฉันไม่ค่อยใช้เวลามากกว่าหนึ่งชั่วโมงต่อเดือน (นอกเหนือจากการอัพเกรดความถนัดทั่วไป) เซิร์ฟเวอร์กำลังให้บริการหลายเว็บไซต์อยู่แล้วดังนั้นจึงไม่มีการลงทุนเพิ่มเติม ฉันเสียใจเล็กน้อยที่ผู้คนสนับสนุนการซื้อบริการเพื่อทำสิ่งที่คุณสามารถทำได้ด้วยตนเอง ไม่มีอะไรผิดปกติกับการเรียนรู้เล็กน้อยระหว่างทาง
wurtel
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.