เมลปลอม บายพาส SPF | องค์ประกอบที่ไม่เป็นมิตรสามารถดำเนินการโจมตีอีเมลปลอมและเลี่ยงการใช้งาน SPF ที่มีอยู่ได้อย่างไร | บทนำ | 1#2 |.ดอทคอม

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

นอกเหนือจากส่วนที่เราชี้ให้เห็นถึงช่องโหว่เชิงโครงสร้างของมาตรฐานเมล SPF แล้ว ฉันอยากจะไปที่ "ระดับถัดไป" และสาธิตวิธีดำเนินการโจมตีอีเมลหลอกลวงที่เลี่ยงการใช้งาน SPF ที่มีอยู่

ชุดบทความปัจจุบันมีสองบทความ
บทความถัดไปคือ - จะจำลองการโจมตีอีเมลปลอมและบายพาสการตรวจสอบผู้ส่ง SPF ได้อย่างไร | 2#2

ภาวะที่กลืนไม่เข้าคายไม่ออกที่รู้จักกันดี - ฉันควรเปิดเผยช่องโหว่ของ SPF ต่อสาธารณะหรือไม่ | หมวกดำ VS หมวกขาว

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

ความจริงง่ายๆ ก็คือ โดยส่วนใหญ่แล้ว “นิติบุคคลที่ไม่เป็นมิตร” นี้เป็นบุคคลที่เป็นมืออาชีพที่มีความรู้กว้างขวางและมีเส้นทางที่กำหนดไว้ว่าทำไมเขาจึงควรใช้ในการดำเนินการโจมตีด้วยการปลอมแปลงหรือฟิชชิ่ง และวิธีจัดการกับข้อมูลระบุตัวตนของผู้ส่งที่มีอยู่ มาตรฐานการตรวจสอบเช่น SPF

กล่าวอีกนัยหนึ่ง “นิติบุคคลที่ไม่เป็นมิตร” ไม่ต้องการความช่วยเหลือจากฉันและการสนับสนุนจากฉันในการเปิดเผยช่องโหว่ที่มีโครงสร้างของมาตรฐานเมล SPF ฉันรับรองกับคุณได้เลยว่าเขารู้อยู่แล้วเกี่ยวกับ “จุดบอด SPF ” นี้ และโอกาสก็คือถ้าเขาตัดสินใจโจมตีองค์กรของคุณ เขาจะใช้งานมัน!

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

แทนที่จะ “หลับตา” และเพิกเฉยต่อช่องโหว่ของโครงสร้างพื้นฐานเมลของเรา ฉันคิดว่าสภาพจิตใจที่ดีที่สุดควรจะเป็น - ไปสู่คำถามที่สร้างสรรค์และเป็นผู้ใหญ่มากขึ้น เช่น - เนื่องจากฉันตระหนักถึงภัยคุกคามที่มีอยู่นี้ กับโครงสร้างพื้นฐานเมลของฉัน ฉันจะทำอย่างไรเพื่อให้การป้องกันที่ดีขึ้นแก่องค์กรและผู้ใช้ของฉัน

SMTP เป็นโปรโตคอล Innocent | การปลอมแปลงอีเมลและ SPF เป็นวิธีแก้ปัญหาบางส่วน

ฉันอธิบายโปรโตคอล SMTP ว่าเป็น “โปรโตคอล Innocent” เนื่องจากวัตถุประสงค์หลักของโปรโตคอล SMTP คือการถ่ายโอนข้อความอีเมลจากโฮสต์ A ไปยังโฮสต์ B ในวิธีที่รวดเร็วและมีประสิทธิภาพมากที่สุด

เมื่อโฮสต์ต้นทาง (A) ระบุโฮสต์ปลายทาง (B) และขอให้เริ่มเซสชัน SMTP สมมติฐานพื้นฐานของโฮสต์ปลายทาง (B) คือโฮสต์ A เป็นคนที่เขาอ้างว่าเป็นจริงๆ

สมมติฐานเริ่มต้นนี้กำลังถูกใช้โดยองค์ประกอบที่ไม่เป็นมิตร ซึ่งปิดบังตัวตนที่แท้จริงด้วยการนำเสนอตัวตนของโฮสต์\ผู้รับที่ดูเหมือนจะถูกต้องตามกฎหมาย

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

หนึ่งในมาตรฐานความปลอดภัยเมลที่ได้รับความนิยมและเป็นที่รู้จักมากที่สุดซึ่งคิดค้นขึ้นเพื่อตอบสนองความจำเป็นในการตรวจสอบยืนยันตัวตนของผู้ส่งคือ SPF (Sender Policy Framework)

มาตรฐาน SPF อิงจากการทดสอบการตรวจสอบที่ง่ายมาก ซึ่งเราจะตรวจสอบว่าเซิร์ฟเวอร์อีเมลใดได้รับอนุญาตให้ส่งหรือเป็นตัวแทนชื่อโดเมนเฉพาะหรือไม่

“ชื่อโดเมนเฉพาะ” คือชื่อโดเมนที่ปรากฏในที่อยู่อีเมลของผู้ส่งที่ควบคุมเซิร์ฟเวอร์เมลของเรา

ปัญหาคือกลไก SPF มีจุดอ่อนโดยธรรมชาติ เนื่องจากขั้นตอนการตรวจสอบผู้ส่งถูกนำมาใช้โดยการตรวจสอบข้อมูลระบุตัวตนของผู้ส่งที่ปรากฏบน
ซองจดหมายจดหมาย< แต่ ไม่ใช่ข้อมูลระบุตัวตนของผู้ส่งที่สามารถปรากฏใน ส่วนหัวของเมล

จุดอ่อนโดยธรรมชาตินี้ถูกใช้ประโยชน์โดยองค์ประกอบที่ไม่เป็นมิตรซึ่งสามารถข้ามกำแพง SPF ที่มีอยู่ของเราได้อย่างง่ายดาย และทำการโจมตีด้วยอีเมลปลอม

สิ่งที่แนบมาด้วยคือใบเสนอราคาจากไซต์องค์กร SPF:

Sender Policy Framework (SPF) เป็นมาตรฐานเปิดที่ระบุวิธีการทางเทคนิคเพื่อป้องกันการปลอมแปลงที่อยู่ของผู้ส่ง แม่นยำยิ่งขึ้นคือ SPF เวอร์ชันปัจจุบันที่เรียกว่า SPF v1 หรือ SPF Classic จะปกป้องที่อยู่ผู้ส่งเอนเวโลป ซึ่งใช้สำหรับการส่งข้อความ ดูกล่องด้านขวาเพื่อดูคำอธิบายโดยย่อเกี่ยวกับที่อยู่ผู้ส่งประเภทต่างๆ ในอีเมล
(มีวิธีแก้ไขปัญหาอื่นๆ ที่ปกป้องที่อยู่ผู้ส่งส่วนหัวหรือไม่สนใจเลยเกี่ยวกับผู้ที่ส่งข้อความ เพียงแต่ ใครเป็นคนเขียนมันแต่แรก)

ฉันคิดว่าพวกเราส่วนใหญ่ไม่ทราบหรือมีความรู้เพียงบางส่วนเกี่ยวกับคำศัพท์ต่างๆ เช่น
ซองจดหมาย, ส่วนหัวของเมล และวิธีการ SMTP ที่ผู้ส่งใช้ “การระบุตัวตนผู้ส่งหลายราย”

หากคุณมีความอดทน ฉันสัญญาว่าหลังจากอ่านบทความปัจจุบัน คุณจะเข้าใจแนวคิดเหล่านี้ดีขึ้น

เพื่อประโยชน์ในการเปิดเผยข้อมูลโดยสมบูรณ์ ความเห็นของฉันคือว่ามาตรฐาน SPF นั้นมีความจำเป็น และถือเป็นมาตรฐานการรักษาความปลอดภัยของอีเมลที่จำเป็น ซึ่งต้องนำมาใช้โดยทุกองค์กรที่ใช้โครงสร้างพื้นฐานของอีเมล .

วัตถุประสงค์หลักของฉันคือการแจ้งให้คุณทราบถึง “จุดบอด” ของมาตรฐาน SPF และทำให้คุณเข้าใจว่าคุณอาจต้องใช้มาตรฐานและกลไกการรักษาความปลอดภัยของอีเมลเพิ่มเติม ร่วมกันหรือเคียงข้างกันกับมาตรฐาน SPF

แล้ววิธีแก้ปัญหาสำหรับ “จุดบอด” SPF นี้คืออะไร?

ฉันต้องการขยายคำถามนี้ไปยังคำถามที่กว้างขึ้น:

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

ข่าวดีน้อยกว่าก็คือไม่มีสูตรวิเศษหรือ "ปุ่มสีแดง" ง่ายๆ ที่เราสามารถใช้เพื่อสร้าง "โดมพลังงานที่โปร่งใส" ที่จะปกป้ององค์กรของเราจาก "คนเลว" และในขณะเดียวกันก็ช่วยให้เรา ผู้ใช้ “ทำสิ่งที่พวกเขา” อย่างสม่ำเสมอและโปร่งใสโดยไม่มีการแทรกแซงใดๆ

วิธีแก้ปัญหาของเราคือการผสมผสานหรือ "ค็อกเทล" ของมาตรฐานความปลอดภัยเมลที่แตกต่างกันซึ่งช่วยให้เราสามารถตรวจสอบข้อมูลระบุตัวตนของผู้ส่ง เช่น DKIM, DMARC, กฎอีเมล Exchange Online Spoof, โปรแกรมการรับรู้ของผู้ใช้ ฯลฯ

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

งานหลักของเราคือ:

• รับทราบถึงความเสี่ยงของการโจมตีด้วยการปลอมแปลงหรือฟิชชิ่ง และข้อเท็จจริงที่ว่าแม้ไม่ทางใดก็ทางหนึ่ง เราก็ประสบกับอันตรายจากสิ่งที่กล่าวมาข้างต้น
• เพื่อให้คุ้นเคยกับแต่ละวิธีแก้ปัญหาที่เป็นไปได้ และลักษณะของวิธีแก้ปัญหาที่เป็นไปได้แต่ละข้อ (ข้อดี ข้อเสีย ฯลฯ)
• ตัดสินใจว่าอะไรคือการผสมผสานโซลูชันที่ดีที่สุดที่จะตอบสนอง DNA ขององค์กรและความต้องการทางธุรกิจเฉพาะองค์กรได้ดีที่สุด
• ใช้กลไกการป้องกันที่มีอยู่ และมีความอดทนที่จำเป็นสำหรับเวลาที่จำเป็นซึ่งจำเป็นในการปรับใช้และซึมซับโซลูชันนี้ (ระยะโหมดการเรียนรู้ ขั้นตอนการทดสอบ การจัดการกับสถานการณ์ที่เป็นผลบวกลวง ฯลฯ)

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างของแนวคิดที่ฉันอธิบายว่าเป็น "ค๊อกเทลการรักษาความปลอดภัย"
ความหมายของคำนี้คือสถานการณ์ที่เราใช้มาตรฐานเมลตั้งแต่สองรายการขึ้นไปหรือกลไกอื่นรวมกัน เช่นกฎการแลกเปลี่ยนที่จะเสริมซึ่งกันและกัน

ตัวอย่างเช่น ในกรณีที่โครงสร้างพื้นฐานอีเมลของคุณขึ้นอยู่กับสถาปัตยกรรม Exchange เราสามารถใช้กฎ Exchange ที่จะระบุ
ผู้รับที่ไม่ได้รับการรับรองความถูกต้องซึ่งใช้ที่อยู่อีเมลกับชื่อโดเมนของเรา + การนำมาตรฐานการตรวจสอบผู้ส่ง SPF ไปใช้ ซึ่งจะกำหนดสถานการณ์ที่ผู้รับซึ่งใช้ที่อยู่อีเมลที่มีชื่อโดเมนของเราส่งอีเมลผ่านเซิร์ฟเวอร์อีเมลที่ไม่ได้รับอนุญาต

อีกทางเลือกหนึ่งอาจเป็นการใช้มาตรฐานเมล DMARC ที่ใช้มาตรฐาน DKIM + SPF และให้การป้องกันที่ดีเยี่ยมสำหรับสถานการณ์ส่วนใหญ่ของการโจมตีด้วยการปลอมแปลง

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

หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการใช้กฎ Exchange ที่จะระบุและจะตอบสนองตามนั้น ฉันได้เขียนชุดบทความจำนวน 12 บทความที่ตรวจสอบตัวเลือกที่เป็นไปได้ที่คุณสามารถใช้ได้ - การจัดการกับการโจมตีด้วยการปลอมแปลงอีเมลใน Office 365 สภาพแวดล้อมพื้นฐาน | บทนำ | ตอนที่ 1#12

หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการใช้งาน DKIM ใน Office 365 (สภาพแวดล้อมที่ใช้ Exchange Online ฉันได้เขียนชุดบทความจำนวน 5 บทความที่ทบทวนหัวข้อ - DKIM - จดหมายระบุคีย์โดเมน | บทนำพื้นฐาน | ส่วนที่ 1#5

โครงสร้างของชุดบทความปัจจุบัน

บทความชุด “องค์ประกอบที่ไม่เป็นมิตรสามารถดำเนินการโจมตีอีเมลปลอมและเลี่ยงการใช้งาน SPF ที่มีอยู่ได้อย่างไร” มีสองบทความ

บทความปัจจุบันที่เรามุ่งเน้นหลักคือ:

1. โครงสร้างข้อมูลของเซสชัน SMTP และข้อความอีเมล
2. วิธีดำเนินการตามกระบวนการตรวจสอบ SPF
3. วิธีทางทฤษฎีที่องค์ประกอบที่ไม่เป็นมิตรสามารถใช้เพื่อข้ามการใช้งาน SPF ที่มีอยู่ได้

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

โครงสร้างข้อมูลของเซสชัน SMTP และข้อความอีเมล

ข้อมูลเมตาและข้อความอีเมล

โดยส่วนใหญ่แล้วเมื่อเราใช้คำว่าข้อความอีเมล เราจะเกี่ยวข้องกับเนื้อหาข้อความอีเมล เช่น ข้อความที่รวมอยู่ในข้อความอีเมลหรือสิ่งที่แนบมาในข้อความอีเมล

ในความเป็นจริง ข้อความอีเมลแต่ละข้อความจะมีชั้นข้อมูลเพิ่มเติม ซึ่งสามารถอธิบายได้ว่าเป็นข้อมูลเมตาหรือเป็น "ข้อมูลเกี่ยวกับข้อมูล"

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

ซองจดหมายและส่วนหัวของจดหมายเป็นคอนเทนเนอร์แบบลอจิคัลสำหรับข้อมูลเมตาของข้อความอีเมล

โปรโตคอล SMTP กำหนด "คอนเทนเนอร์แบบลอจิคัล" สองประเภทที่จะเก็บข้อมูลเมตาที่เกี่ยวข้องกับข้อความอีเมลเฉพาะ:

ซองจดหมาย และ ส่วนหัวของจดหมาย

• ซองจดหมายอีเมล ถูกใช้โดยเซิร์ฟเวอร์อีเมลที่เป็นตัวแทนของผู้ส่งและผู้รับ
• ส่วนหัวของเมล ถูกใช้โดยโปรแกรมรับส่งเมล (โดยผู้ใช้)

ข้อมูลที่บันทึกไว้ใน Mail Envelope

ซองจดหมาย มีข้อมูลประเภทต่อไปนี้:

1. เก็บข้อมูลเกี่ยวกับ “เซิร์ฟเวอร์เมลต้นทาง” ที่แสดงถึงผู้ส่ง ตัวอย่างเช่น ที่อยู่ IP ของเซิร์ฟเวอร์เมลที่เตรียมใช้งานเซสชัน SMTP หรือข้อมูลเกี่ยวกับมาตรฐานความปลอดภัยเฉพาะที่เซิร์ฟเวอร์เมลต้นทางรองรับ เช่น DKIM
2. ระงับข้อมูลเกี่ยวกับเมลเซิร์ฟเวอร์ทั้งหมดที่เกี่ยวข้องกับการรับส่งเมล
3. เก็บข้อมูลเกี่ยวกับตัวตนผู้ส่ง + ผู้รับ - ที่อยู่อีเมลของผู้ส่งและที่อยู่อีเมลของผู้รับปลายทาง

โครงสร้างเมล - ส่วนหัวของเมลและเนื้อหาเมล

“องค์ประกอบเมล” ของข้อความอีเมลประกอบด้วยสองส่วน:

1. ส่วนหัวของเมล - นี่คือ “คอนเทนเนอร์เพิ่มเติม” ที่เก็บข้อมูลเมตาดาต้า หากคุณสงสัยว่าเหตุใดเราจึงต้องใช้คอนเทนเนอร์ลอจิคัลเพิ่มเติมสำหรับข้อมูลเมตา นอกเหนือจาก ซองจดหมาย องค์ประกอบ คำตอบง่ายๆ คือมีความคล้ายคลึงกับสถานการณ์ในชีวิตจริงมาก
ซองจดหมาย ถือเป็น “ยานพาหนะชั่วคราว” ซึ่งใช้สำหรับ “ขนส่ง” ข้อความอีเมลจากจุด A ไปยังจุด B

หลังจากอีเมล ข้อความจะได้รับการยอมรับโดยเซิร์ฟเวอร์เมลปลายทางที่เป็นตัวแทนของผู้รับ โดยเซิร์ฟเวอร์เมลจะอ่านข้อมูลที่ปรากฏใน ซองจดหมายเมล คัดลอกข้อมูลส่วนใหญ่ในส่วน ส่วนหัวของเมล จากนั้น “ฉีกขาด แยกกัน ” ซองจดหมาย

2. Mail Body - เนื้อหาจดหมายคือส่วนที่มีข้อความและสิ่งที่แนบมาซึ่งเพิ่มลงในข้อความอีเมลโดยบุคคลที่เขียนอีเมล

ส่วนหัวของเมลประกอบด้วยข้อมูลประเภทต่อไปนี้:

1. เก็บข้อมูลเกี่ยวกับอักขระของข้อความอีเมลเฉพาะ เช่น ชุดอักขระของข้อความอีเมลเฉพาะ ประเภท MIME เป็นต้น

2. เก็บข้อมูลที่คัดลอกมาจาก ซองจดหมาย ตามที่กล่าวไว้ ซองจดหมายจดหมาย จะถูกลบออกโดยเซิร์ฟเวอร์จดหมายก่อนที่จะส่งข้อความอีเมล ไปยังผู้รับปลายทาง

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

ข้อมูลเกี่ยวกับ “ผลการตรวจสอบความปลอดภัย” เช่น ค่า SCL (ระดับความเชื่อมั่นของสแปม) จะถูกบันทึกลงใน ส่วนหัวของอีเมล
อีกตัวอย่างหนึ่งคือสถานการณ์ที่เซิร์ฟเวอร์อีเมลได้รับการกำหนดค่าให้ดำเนินการตรวจสอบความถูกต้องของข้อมูลระบุตัวตนของผู้ส่งโดยใช้มาตรฐาน เช่น - SPF, DKIM, DMARC เป็นต้น ผลลัพธ์ของการทดสอบข้อมูลระบุตัวตนของผู้ส่งจะถูกเขียนลงใน ส่วนหัวของเมล

4. เก็บข้อมูลเกี่ยวกับตัวตนผู้ส่ง + ผู้รับ - ข้อมูลเกี่ยวกับที่อยู่อีเมลของผู้ส่งและที่อยู่อีเมลของผู้รับปลายทาง

สถานการณ์ทางเลือกอื่นๆ คือสถานการณ์ที่ ซองจดหมายเมล จะรวมข้อมูลระบุตัวตนของผู้ส่ง\ผู้รับที่ ข้อมูลระบุตัวตนของผู้ส่ง\ผู้รับที่ระบุไว้ใน ส่วนหัวของเมล

ข้อมูลระบุตัวตนประเภทหลักในโครงสร้างพื้นฐานที่ใช้เมล

ในบทความนี้ เราได้กล่าวถึงคำว่า "ข้อมูลประจำตัว" หลายครั้ง
หากไม่ต้องพูดถึงการอภิปรายทางเทคนิคเชิงลึก การกำหนดความหมายของคำนี้เมื่อเกี่ยวข้องกับโครงสร้างพื้นฐานในการส่งไปรษณีย์ถือเป็นสิ่งสำคัญ

เมื่อเกี่ยวข้องกับโครงสร้างพื้นฐานของเมล คำจำกัดความง่ายๆ ของคำว่า “ตัวตน” สามารถแปลเป็น:

1. ที่อยู่อีเมล
2. ที่อยู่ IP
3. ข้อมูลรับรองผู้ใช้
4. ใบรับรอง

เกี่ยวกับเรื่องของโครงสร้างพื้นฐานเมลและมาตรฐาน SPF ข้อมูลประจำตัวหลักที่เราจะเกี่ยวข้องกับการระบุตัวตนของที่อยู่อีเมลและข้อมูลประจำตัวของที่อยู่ IP เป็นส่วนใหญ่

เมื่อเราบอกว่าผู้ส่งต้องการส่งอีเมลไปยังผู้รับปลายทาง เราจะเกี่ยวข้องกับที่อยู่อีเมลของผู้สร้างและที่อยู่อีเมลของผู้รับปลายทาง

“ข้อมูลประจำตัว” อีกประเภทหนึ่งคือข้อมูลประจำตัวของเมลเซิร์ฟเวอร์ที่ส่งอีเมลในนามของผู้รับรายใดรายหนึ่ง ในกรณีนี้ เราเชื่อมโยงกับข้อมูลระบุตัวตนของเมลเซิร์ฟเวอร์โดยเป็นที่อยู่ IP ที่เมลเซิร์ฟเวอร์ใช้

ความจำเป็นในการตรวจสอบตัวตนของผู้ส่ง

ความต้องการด้านความปลอดภัยขั้นพื้นฐานที่สุดประการหนึ่งในโครงสร้างพื้นฐานของเมลคือ ความจำเป็นในการตรวจสอบอย่างไม่ต้องสงสัยหรือตรวจสอบด้วยความแน่นอนถึงตัวตนของฝ่ายที่เกี่ยวข้องในเซสชันการรับส่งเมล

หากเราต้องการให้แม่นยำยิ่งขึ้นเมื่อเราบอกว่าจำเป็นต้องตรวจสอบตัวตนโดยเฉพาะโดยส่วนใหญ่ฝ่ายที่สนใจจะดำเนินการตามขั้นตอนนี้คือ - “ฝ่ายรับ” หมายถึงโครงสร้างพื้นฐานเมลของปลายทาง ผู้รับ

เมื่อ “หน่วยงานภายนอก” ระบุถึงเซิร์ฟเวอร์อีเมลที่แสดงถึงโดเมนเฉพาะ (ผู้รับเฉพาะ) และแนะนำตัวเองโดยใช้ “ตัวตน” ที่แตกต่างกัน (ที่อยู่อีเมลเฉพาะหรือที่อยู่ IP เฉพาะ) โครงสร้างพื้นฐานของอีเมลที่แสดงถึงผู้รับปลายทางจะต้อง รู้ว่าผู้ส่งคือคนที่เขาอ้างจริงๆ

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

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

หนึ่งในวิธีที่ได้รับความนิยมมากที่สุดในการตรวจสอบตัวตนของผู้ส่งคือมาตรฐาน SPF เมื่อใช้มาตรฐาน SPF เมลเซิร์ฟเวอร์ที่เป็นตัวแทนของผู้รับปลายทางจะตรวจสอบตัวตนของ “เมลเซิร์ฟเวอร์ต้นทาง” ซึ่งหมายถึง เมลเซิร์ฟเวอร์ที่เป็นตัวแทนของผู้ส่งโดยการตรวจสอบที่อยู่ IP ของ IP เซิร์ฟเวอร์เมลต้นทางจะปรากฏในข้อความ “ที่ได้รับอนุญาต รายการ. ”

ข้อมูลระบุตัวตนที่แตกต่างกันในการรับส่งอีเมลแบบธรรมดา

เพื่ออธิบายแนวคิด "อัตลักษณ์" นี้ ให้ใช้แผนภาพต่อไปนี้

ในสถานการณ์ของเรา ด้าน A ต้องการส่งข้อความอีเมลไปยังด้าน B

1. ข้อมูลประจำตัวแรก (หมายเลข 1) คือที่อยู่อีเมลที่แสดงถึงผู้ใช้\ ผู้รับที่ต้องการส่งอีเมล ในสถานการณ์ของเรา ข้อมูลระบุตัวตนของผู้ใช้รายนี้คือ - angelina@Thankyouforsharing.org

2. ข้อมูลระบุตัวตนประเภทที่สอง (หมายเลข 2) ถูกนำมาใช้ในสถานการณ์ที่ “ผู้ส่งดั้งเดิม” ต้องการส่งข้อความอีเมลในนามของผู้ส่งรายอื่น

สถานการณ์คลาสสิกคือฉากของผู้ช่วยและผู้จัดการที่เลขานุการต้องการส่งอีเมลไปยังผู้รับภายนอกในนามของผู้จัดการของเธอ

ในตัวอย่างเฉพาะของเรา ข้อมูลระบุตัวตนของผู้จัดการคือ - Brad@Thankyouforsharing.org

3. ข้อมูลระบุตัวตนที่สาม (หมายเลข 3) คือข้อมูลระบุตัวตนของเมลเซิร์ฟเวอร์ที่เป็นตัวแทนของผู้ส่ง

เราเกี่ยวข้องกับข้อมูลระบุตัวตนของเซิร์ฟเวอร์เมลต้นทางโดยการระบุที่อยู่ IP ของเซิร์ฟเวอร์เมล

4. ข้อมูลประจำตัวที่สี่ (หมายเลข 4) คือข้อมูลประจำตัวของเมลเซิร์ฟเวอร์ที่แสดงถึงผู้รับปลายทาง

เราเกี่ยวข้องกับข้อมูลระบุตัวตนของเซิร์ฟเวอร์อีเมลเป้าหมายโดยการระบุที่อยู่ IP ของเซิร์ฟเวอร์อีเมล

ในกรณีที่เมลเซิร์ฟเวอร์ปลายทางรองรับ SPF กระบวนการตรวจสอบตัวตนของผู้ส่งจะถูกนำมาใช้โดยการตรวจสอบว่าที่อยู่ IP ของเซิร์ฟเวอร์เมลต้นทางได้รับการลงทะเบียนเป็น IP ที่ได้รับอนุญาตสำหรับชื่อโดเมนเฉพาะ (ชื่อโดเมนที่ปรากฏใน E- ที่อยู่ทางไปรษณีย์ของผู้ส่ง)

ในสถานการณ์เฉพาะของเรา กระบวนการตรวจสอบ SPF จะตรวจสอบว่าเซิร์ฟเวอร์อีเมลเฉพาะได้รับอนุญาตให้ส่งอีเมลสำหรับชื่อโดเมนหรือไม่ - Thankyouforsharing.org

5. ตัวตนที่ห้า (หมายเลข 5) คือที่อยู่อีเมลที่แสดงถึงผู้รับปลายทาง ในตัวอย่างของเรา ผู้รับปลายทางจะแสดงด้วยที่อยู่อีเมล - Bob@o365pilot.com

ฟิลด์เมลที่มีค่าข้อมูลเฉพาะตัวของผู้ส่งและผู้รับ

ในส่วนปัจจุบัน ฉันต้องการตรวจสอบ "ฟิลด์อีเมล" เฉพาะที่ใช้โดยโปรโตคอล SMTP เพื่อแสดงถึง "ข้อมูลประจำตัว" ของผู้ส่งและที่อยู่อีเมลของผู้รับ

ตามที่กล่าวไว้ ข้อความอีเมลมาตรฐานประกอบด้วยสองส่วน ได้แก่ ซองจดหมาย และ
ส่วนหัวของเมล

แต่ละองค์ประกอบเหล่านี้ใช้ "ช่องอีเมล" ที่แตกต่างกันเพื่อแสดงตัวตนของผู้ส่งและผู้รับ

Mail envelope (RFC 5321)

จาก

Mail header (RFC 5322)

จดหมายจาก

ซองจดหมาย - “ช่องจดหมาย” ที่เก็บค่าของผู้ส่งและผู้รับ

1. ข้อมูลระบุตัวตนของผู้ส่ง - ซองจดหมายเมล ใช้ “ฟิลด์เมล ” ชื่อ - MAIL FROM เพื่อ “เก็บ” ข้อมูลเกี่ยวกับตัวตนของผู้ส่ง (ที่อยู่อีเมลของผู้ส่ง)
2. ข้อมูลประจำตัวของผู้รับ - ซองจดหมายอีเมล ใช้ “ฟิลด์อีเมล” ชื่อ - RCPT TO สำหรับ “การถือครอง” ข้อมูลเกี่ยวกับตัวตนของผู้รับ (ที่อยู่อีเมลของผู้รับปลายทาง)

ส่วนหัวของเมล - “เขตข้อมูลเมล ” ที่เก็บค่าของผู้ส่งและผู้รับ

ในส่วนของ “องค์ประกอบเมล” ส่วนที่เก็บข้อมูลเกี่ยวกับตัวตนของผู้ส่งและผู้รับคือ ส่วนหัวของเมล< /แข็งแกร่ง>.

1. ข้อมูลระบุตัวตนของผู้ส่ง - ส่วนหัวของอีเมล ใช้ “ฟิลด์อีเมล” ชื่อ - FROM สำหรับ “การถือครอง” ข้อมูลเกี่ยวกับตัวตนของผู้ส่ง (ที่อยู่อีเมลของผู้ส่ง)
2. ข้อมูลระบุตัวตนของผู้รับ - ส่วนหัวของอีเมล ใช้ “ฟิลด์อีเมล” ชื่อ - TO สำหรับ “การถือครอง” ข้อมูลเกี่ยวกับตัวตนของผู้รับ (ที่อยู่อีเมลของผู้รับปลายทาง)

ความสัมพันธ์ระหว่างโครงสร้างพื้นฐานเมลเอนเวโลปและโครงสร้างพื้นฐานส่วนหัวเมล

วิธีที่เราใช้ข้อมูลประจำตัวที่แตกต่างกันสองชุด (ซองจดหมายเมล ข้อมูลประจำตัวและ ข้อมูลประจำตัวของส่วนหัวจดหมาย) อาจถือว่าสร้างความสับสนได้

ในตอนนี้ เรามาตอบคำถามพื้นฐานกันดีกว่าว่า "การแยก" นี้สร้างขึ้นโดยโปรโตคอล SMTP เพื่อตอบสนองความต้องการของสถานการณ์ทางธุรกิจต่างๆ

ในบางสถานการณ์ ข้อมูลเกี่ยวกับข้อมูลประจำตัวของผู้ส่งและผู้รับใน ซองจดหมาย จะเหมือนกันกับ ข้อมูลใน ส่วนหัวของเมล span> และในบางสถานการณ์ไม่ใช่

สถานการณ์ทั่วไป - ข้อมูลประจำตัวใน ซองจดหมายอีเมล เหมือนกับข้อมูลประจำตัวใน ส่วนหัวของเมล

สถานการณ์ที่พบบ่อยที่สุดคือสถานการณ์ที่เราใช้ข้อมูลระบุตัวตนของผู้ส่งและผู้รับปลายทางเพียงชุดเดียว

ตัวอย่างเช่น เมื่อผู้ใช้เขียนที่อยู่อีเมลใหม่ ที่อยู่อีเมลของเขาจะถูกกำหนดค่าโดยอัตโนมัติในฟิลด์อีเมล MAIL FROM และที่อยู่อีเมลของผู้รับปลายทางได้รับการกำหนดค่าในฟิลด์อีเมล RCPT TO

เนื่องจากเมลเซิร์ฟเวอร์ปลายทางได้ตรวจสอบความปลอดภัยทั้งหมดแล้ว และเขายินดีที่จะยอมรับข้อความอีเมล ข้อมูลเกี่ยวกับผู้ส่งและตัวตนผู้รับจะถูกคัดลอกจาก ซองจดหมายเมลไปที่ ส่วนหัวของเมล

• ข้อมูลจากฟิลด์ MAIL FROM จะถูกคัดลอกไปยัง ชื่อฟิลด์ส่วนหัวของจดหมาย - FROM
• ข้อมูลจากฟิลด์ RCPT TO จะถูกคัดลอกไปยัง ชื่อฟิลด์ส่วนหัวของจดหมาย - TO

สถานการณ์อื่น - ข้อมูลประจำตัวใน ซองจดหมายอีเมล ไม่เหมือนกับข้อมูลประจำตัวใน ส่วนหัวของเมล

ในสถานการณ์สมมตินี้ มี "ชุดข้อมูลระบุตัวตน" ที่แตกต่างกันซึ่งแสดงถึงแหล่งที่มา ผู้ส่ง และ "ข้อมูลระบุตัวตน" ที่แตกต่างกันซึ่งแสดงถึงผู้รับปลายทาง

เพื่อให้สามารถสาธิตกรณีดังกล่าวได้ ลองใช้สถานการณ์ต่อไปนี้:

• Suzan เป็นผู้ช่วยส่วนตัวของ John
• John ขอให้ Suzan ส่งข้อความอีเมลถึงลูกค้าคนหนึ่งของเขา

เมื่อ Suzan สร้างข้อความอีเมลใหม่ ข้อมูลเกี่ยวกับตัวตนของ Suzan จะถูกบันทึกไว้ใน Mail ซองจดหมาย ในช่อง MAIL FROM

ข้อมูลเกี่ยวกับตัวตนของ John จะถูกกำหนดไว้ในฟิลด์ FROM

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

ข้อมูลระบุตัวตน "เพิ่มเติม" ที่เกี่ยวข้องกับการรับส่งอีเมล SMTP

ในส่วนปัจจุบัน ฉันต้องการตรวจสอบ “ข้อมูลระบุตัวตน” เพิ่มเติมสามรายการสั้นๆ ที่เกี่ยวข้องกับการรับส่งอีเมล SMTP

ข้อมูลระบุตัวตนของเซิร์ฟเวอร์เมลต้นทาง | คำสั่ง HELO \EHLO

ดังที่ได้กล่าวไปแล้ว “ตัวตนหลัก” ของ “เซิร์ฟเวอร์เมลต้นทาง” คือที่อยู่ IP ของเซิร์ฟเวอร์

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

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

ในกรณีที่เมลเซิร์ฟเวอร์ต้นทางต้องการระบุตัวตนประเภทนี้ (ชื่อโฮสต์ ชื่อโดเมนที่เขาเป็นตัวแทน หรือชื่อโฮสต์ + ชื่อโดเมนรวมกันซึ่งเรียกว่า FQDN) เมลเซิร์ฟเวอร์สามารถให้ข้อมูลนี้หลังจาก SMTP คำสั่ง HELO (หรือ EHLO)

ข้อมูลระบุตัวตนการตอบกลับ

“ข้อมูลประจำตัว” ประเภทที่สองที่สามารถรวมไว้ในข้อความอีเมลได้คือฟิลด์อีเมล
ชื่อ - ตอบกลับ-TO.

ตามชื่อที่บอกเป็นนัย วัตถุประสงค์ของฟิลด์อีเมลนี้คือเพื่อรวมข้อมูลเกี่ยวกับ
ที่อยู่อีเมลที่เราต้องการให้ผู้รับปลายทางใช้หากเขา "กดปุ่ม" ตอบกลับ

โดยค่าเริ่มต้น ช่องเมลนี้จะว่างเปล่า และค่าเริ่มต้น (ที่อยู่อีเมล) ที่จะใช้ในกรณีที่ผู้รับปลายทางใช้ตัวเลือกการตอบกลับคือ - ที่อยู่อีเมลที่ปรากฏใน ถึง ช่องเมล

เส้นทางการกลับมา ตัวตน

“ข้อมูลประจำตัว” ประเภทที่สามที่สามารถรวมไว้ในข้อความอีเมลได้คือฟิลด์อีเมล
ชื่อ - RETURN-PATH.

วัตถุประสงค์ของช่องเมลนี้คือเพื่อให้มีที่อยู่อีเมลซึ่งเซิร์ฟเวอร์เมลปลายทางจะใช้เพื่อแจ้งให้ “ผู้ส่ง” เกี่ยวกับปัญหา เช่น ผู้รับไม่มีอยู่จริง เป็นต้น
ตามค่าเริ่มต้น ค่า (ที่อยู่อีเมล) ของฟิลด์เมล RETURN-PATH ไม่ได้ถูกกำหนดโดยผู้ส่งต้นทางหรือโดยเซิร์ฟเวอร์เมลต้นทาง แต่โดยเซิร์ฟเวอร์เมลปลายทางแทน

เมื่อเมลเซิร์ฟเวอร์ปลายทางได้รับข้อความอีเมล เขาจะ "แยก" ที่อยู่อีเมลออกจากฟิลด์ MAIL FROM และคัดลอกที่อยู่อีเมลนี้ไปยังฟิลด์อีเมล RETURN-PATH ที่จะถูกบันทึกเป็นส่วนหนึ่งของ ส่วนหัวของเมล

โดยส่วนใหญ่ แม้ว่าผู้ส่งต้นทางจะระบุค่าของที่อยู่อีเมลของฟิลด์อีเมล RETURN-PATH โดยเฉพาะ เซิร์ฟเวอร์เมลปลายทาง จะเพิกเฉยต่อข้อมูลนี้ และจะใช้ที่อยู่อีเมลที่ปรากฏใน ซองจดหมาย< ส่วนใน อีเมลจาก

คำอธิบายของการรับส่งอีเมล SMTP มาตรฐานและการใช้ซองจดหมายและส่วนหัวของอีเมล

ในส่วนปัจจุบัน ฉันอยากจะ "สรุป" ข้อมูลที่เราได้ตรวจสอบในส่วนก่อนหน้าของบทความปัจจุบัน เพื่อให้เราสามารถเข้าใจได้ดีขึ้นว่าส่วนประกอบต่างๆ ทำงานอย่างไรในเซสชัน SMTP มาตรฐาน

มาอธิบายเซสชัน SMTP มาตรฐานที่ผู้ส่ง A ต้องการส่งข้อความอีเมลไปยังผู้รับ B

• เซิร์ฟเวอร์เมลต้นทางระบุที่อยู่เซิร์ฟเวอร์เมลของผู้รับปลายทางและขออนุญาตเพื่อเริ่มเซสชัน SMTP (โดยใช้คำสั่ง SMTP HELO หรือ EHLO)
• เซิร์ฟเวอร์เมลปลายทางยินดีที่จะยอมรับคำขอสำหรับเซสชัน SMTP
• เมลเซิร์ฟเวอร์ต้นทางจะส่งข้อมูลที่ถูกเก็บไว้ใน ซองจดหมายเมล
• เมลเซิร์ฟเวอร์ปลายทางจะดูข้อมูลและค้นหาข้อมูลที่จำเป็นเกี่ยวกับข้อมูลระบุตัวตนของผู้ส่ง (ที่อยู่อีเมล) และข้อมูลระบุตัวตนของผู้รับ (ที่อยู่อีเมล)
• จากข้อมูลที่ปรากฏใน ซองจดหมาย เซิร์ฟเวอร์อีเมลปลายทางสามารถตรวจสอบความปลอดภัยและการตรวจสอบการระบุผู้ส่งได้หลากหลาย
  ตัวอย่างเช่น ตรวจสอบว่าที่อยู่ IP ของเซิร์ฟเวอร์เมลต้นทางปรากฏเป็นบัญชีดำหรือไม่ ตรวจสอบว่าเมลของเซิร์ฟเวอร์ต้นทางได้รับอนุญาตให้เป็นตัวแทนของชื่อโดเมนที่ระบุหรือไม่ เป็นต้น
• เซิร์ฟเวอร์อีเมลปลายทางจะเพิ่มข้อมูล ส่วนหัวของอีเมล เกี่ยวกับการทดสอบความปลอดภัยทั้งหมดและผลลัพธ์
• เซิร์ฟเวอร์เมลปลายทางจะคัดลอกข้อมูลส่วนใหญ่ที่ปรากฏ ซองจดหมายเมล ไปยัง ส่วนหัวของจดหมาย

เกี่ยวกับฟิลด์เมลที่ "มี" ข้อมูลเกี่ยวกับตัวตนของผู้ส่งและผู้รับ หนึ่งในสองสถานการณ์ที่เป็นไปได้สามารถเกิดขึ้นได้:

กรณีที่ 1

ในกรณีที่ข้อมูลที่ส่งจากเมลเซิร์ฟเวอร์ต้นทางไม่รวมค่าสำหรับฟิลด์เมล - FROM และ ถึง เมลเซิร์ฟเวอร์ปลายทางจะใช้ขั้นตอนต่อไปนี้:

• คัดลอกที่อยู่อีเมลในช่อง MAIL FROM ไปยังช่อง ส่วนหัวของจดหมาย FROM
• คัดลอกที่อยู่อีเมลในช่อง RCPT TO ไปยังช่อง ส่วนหัวของจดหมาย ถึง
• คัดลอกที่อยู่อีเมลในช่อง MAIL FROM ไปยังช่อง ส่วนหัวของจดหมาย RETURN-PATH

กรณีที่ 2

ในกรณีที่ข้อมูลที่ส่งจากเมลเซิร์ฟเวอร์ต้นทางมีค่าสำหรับหนึ่งหรือสำหรับฟิลด์เมลต่อไปนี้ - FROM หรือ ถึง เมลเซิร์ฟเวอร์ปลายทางจะดำเนินการตามขั้นตอนต่อไปนี้:

ในกรณีที่ช่องเมลช่องใดช่องหนึ่ง “เป็นของ ” ของ ส่วนหัวของเมล (FROM หรือ TO) รวมค่าเฉพาะ (ที่อยู่อีเมล) ข้อมูล จะไม่ถูกคัดลอก หรืออีกนัยหนึ่ง จะไม่ถูกเขียนทับ ด้วยค่าที่ปรากฏใน ซองจดหมาย

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

จุดสิ้นสุดของกระบวนการจะรวมถึงงานต่อไปนี้ที่จะนำไปใช้โดยเซิร์ฟเวอร์เมลปลายทาง:

• เมลเซิร์ฟเวอร์ปลายทางจะลบ ซองจดหมาย (เมล ซองจดหมายไม่ได้เป็นส่วนหนึ่งของข้อความอีเมลที่ส่งถึงผู้รับ)
• เมลเซิร์ฟเวอร์ปลายทางจะส่งข้อความอีเมลไปยังผู้รับปลายทาง

กระบวนการตรวจสอบ SPF - สถานการณ์ทั่วไป

ในส่วนต่อไปนี้ ฉันต้องการตรวจสอบกระบวนการตรวจสอบ SPF โดยคร่าวๆ ที่เซิร์ฟเวอร์เมลปลายทางนำไปใช้

เพื่อสาธิตกระบวนการตรวจสอบ SPF ให้ใช้สถานการณ์ต่อไปนี้:

• Suzan เป็นผู้ส่งต้นทางที่ใช้ที่อยู่อีเมล - Suzan@Thankyouforsharing.org
• บ๊อบผู้รับปลายทางที่ใช้ที่อยู่อีเมล - Bob@Thankyouforsharing.org

เซิร์ฟเวอร์อีเมลต้นทางที่เป็นตัวแทนของ Suzan จะจัดการกับเซิร์ฟเวอร์อีเมลที่เป็นตัวแทนของผู้รับปลายทาง - Bob

ในสถานการณ์ของเรา ซองจดหมาย มีข้อมูลเกี่ยวกับผู้ส่ง (MAIL FROM) และเกี่ยวกับผู้รับปลายทาง (RCPT TO) แต่ ฟิลด์ส่วนหัวของเมล (FROM และ < span style="color: #800080;">TO) ว่างเปล่า

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

1. “ดึงข้อมูล ” จากที่อยู่ผู้ส่ง (MAIL FROM) ส่วนที่แสดงถึงชื่อโดเมนของผู้ส่ง ในสถานการณ์ของเรา ชื่อโดเมน - Thankyouforsharing.org
2. “จดบันทึก” ที่อยู่ IP ของเซิร์ฟเวอร์เมลต้นทาง
3. จัดการเซิร์ฟเวอร์ DNS และตรวจสอบว่าโดเมน Thankyouforsharing.org มีระเบียน SPF (ระเบียน TXT) หรือไม่ ในกรณีที่บันทึกดังกล่าวมีอยู่ "อ่าน" เนื้อหาของบันทึก SPF
4. ตรวจสอบว่าที่อยู่ IP ของเซิร์ฟเวอร์อีเมลต้นทางปรากฏเป็นหนึ่งในที่อยู่ IP ในระเบียน SPF หรือไม่
5. ในกรณีที่ที่อยู่ IP ของเมลเซิร์ฟเวอร์ต้นทางปรากฏในรายการ การทดสอบการตรวจสอบ SPF จะถือว่า "สำเร็จ" ความหมายก็คือ เมลเซิร์ฟเวอร์ต้นทางได้รับอนุญาตให้ส่งข้อความอีเมลไปยังผู้รับ Thankyouforsharing.org

สถานการณ์ที่ซับซ้อนมากขึ้น และช่องโหว่ของวิธีการตรวจสอบ SPF

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

การโจมตีขึ้นอยู่กับองค์ประกอบต่อไปนี้:

1. มาตรฐาน SMTP | ใช้ข้อมูลระบุตัวตนของผู้ส่งหลายราย

โปรโตคอล SMTP มีตัวเลือกที่ "แหล่งที่มา" หมายถึงองค์ประกอบที่ส่งข้อความอีเมลไปยังผู้รับปลายทางสามารถระบุตัวตนที่แตกต่างกันได้สองแบบ:

• ข้อมูลประจำตัวของผู้ส่ง A จะปรากฏบนฟิลด์อีเมล MAIL FROM (ฟิลด์อีเมลที่ปรากฏในฟิลด์อีเมล ซองจดหมาย)
• ข้อมูลระบุตัวตนของผู้ส่ง B จะปรากฏในฟิลด์อีเมล FROM (ฟิลด์อีเมลที่ปรากฏในฟิลด์อีเมล ส่วนหัวของเมล)

2. กระบวนการตรวจสอบผู้ส่ง SPF | ช่องจดหมายจากจดหมายและฟิลด์จดหมายจาก

• กระบวนการยืนยันผู้ส่ง SPF ถูกนำมาใช้เฉพาะกับข้อมูลประจำตัว (ที่อยู่อีเมล) ของผู้ส่งที่ปรากฏบน MAIL FROM
• กระบวนการตรวจสอบผู้ส่ง SPF ไม่ได้นำไปใช้เฉพาะสำหรับข้อมูลระบุตัวตน (ที่อยู่อีเมล) ของผู้ส่งที่ปรากฏบน จาก

ความหมายก็คือมาตรฐาน SPF มี “จุดบอด” เนื่องจากข้อมูลประจำตัว “FROM ” ไม่ได้ตรวจสอบหรือยืนยัน โดยการทดสอบการตรวจสอบ SPF

ปัญหาที่ใหญ่ที่สุดคือองค์ประกอบที่ไม่เป็นมิตรที่รู้เกี่ยวกับ "Deadly Cocktail" นี้ สามารถใช้ประโยชน์จาก "จุดบอด" ที่มีอยู่ในมาตรฐาน SPF ได้อย่างง่ายดาย

DNA ของการโจมตีทางอีเมลหลอกลวงที่ใช้ประโยชน์จาก “จุดบอด” SPF

การใช้ประโยชน์จาก "จุดบอด" ของ SPF นั้นถูกนำไปใช้โดยองค์ประกอบที่ไม่เป็นมิตรในลักษณะต่อไปนี้:

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

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

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

ในการทำให้ “กลไกบายพาส SPF” นี้เป็นจริง องค์ประกอบที่ไม่เป็นมิตรจะต้องทำตามขั้นตอนต่อไปนี้:

1. ซื้อชื่อโดเมนจำลอง - ฉันใช้คำว่า “โดเมนจำลอง ” เนื่องจากชื่อโดเมนไม่มีความหมายที่แท้จริง วัตถุประสงค์ของชื่อโดเมนจำลองคือเพื่อใช้เป็นตัวล่อสำหรับกระบวนการตรวจสอบผู้ส่ง SPF ที่จะนำไปใช้โดยเซิร์ฟเวอร์อีเมลที่เป็นตัวแทนของผู้รับปลายทาง
2. กำหนดค่าระเบียน SPF ที่จำเป็นในเซิร์ฟเวอร์ DNS ซึ่งโฮสต์ชื่อโดเมนจำลอง
3. เพิ่มข้อมูลที่จำเป็นซึ่งหมายถึงที่อยู่ IP ของเมลเซิร์ฟเวอร์ที่เขาใช้ในการปลอมแปลงหรือโจมตีแบบฟิชชิ่ง

การโจมตีด้วยอีเมล์ปลอมมีการดำเนินการในลักษณะต่อไปนี้:

องค์ประกอบที่ไม่เป็นมิตรจะสร้างอีเมลที่มีที่อยู่อีเมลของผู้ส่งสองคน

• ที่อยู่อีเมลแรก (MAIL FROM) ใช้ “ชื่อโดเมนที่ถูกต้องตามกฎหมาย ” (ชื่อโดเมนจำลอง) ในตัวอย่างเฉพาะของเรา ที่อยู่อีเมล MAIL FROM คือที่อยู่อีเมล "โดเมนสีแดง"
• ที่อยู่อีเมลที่สอง (FROM) ใช้ชื่อโดเมนของผู้รับที่เขาต้องการโจมตี ในตัวอย่างเฉพาะของเรา ที่อยู่อีเมล FROM คือ “โดเมนสีเขียว ”
  ที่อยู่อีเมล

เนื่องจากเมลเซิร์ฟเวอร์ที่แสดงถึงผู้รับปลายทางรองรับ SPF กระบวนการตรวจสอบผู้ส่งจะถูกนำไปใช้โดยการตรวจสอบ "ที่อยู่อีเมลสีแดง" (ที่อยู่อีเมลที่ใช้ชื่อโดเมนจำลอง)

ระบุว่าเป็นธาตุที่ไม่เป็นมิตร

• สร้างระเบียน SPF ที่จำเป็น
• ใช้เมลเซิร์ฟเวอร์ที่เป็นที่อยู่ IP ปรากฏในบันทึก SPF (เมลเซิร์ฟเวอร์ที่ส่งข้อความอีเมลโดยใช้ชื่อโดเมนจำลอง)

การตรวจสอบความถูกต้องของผู้ส่ง SPF จะเสร็จสมบูรณ์

เซิร์ฟเวอร์อีเมลปลายทางจะลบ ซองจดหมายอีเมล รวมถึง MAIL FORM ที่อยู่ และปล่อยให้ “ที่อยู่อีเมลสีเขียว ” (FROM ที่อยู่อีเมล ).
จากมุมมองของผู้รับ ข้อความอีเมลถูกส่งโดยผู้ส่งโดยมี "ที่อยู่อีเมลสีเขียว" ผู้รับเป้าหมายไม่ทราบว่า “ที่อยู่อีเมลแรก ” ที่ปรากฏใน ซองจดหมาย ถูกลบออกแล้ว

การสาธิตวิธีที่องค์ประกอบที่ไม่เป็นมิตรข้ามการตรวจสอบการตรวจสอบ SPF

เพื่อให้สามารถสาธิตวิธีที่องค์ประกอบที่ไม่เป็นมิตรสามารถใช้เพื่อเลี่ยงผ่านการตรวจสอบการยืนยันผู้ส่ง SPF ลองใช้สถานการณ์ต่อไปนี้:

องค์ประกอบที่ไม่เป็นมิตรวางแผนที่จะโจมตี (ดำเนินการโจมตีด้วยการปลอมแปลง\หอกฟิชชิ่ง) บริษัทชื่อ - o365pilot.com

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

• CIO ของบริษัทคือ Bob ที่ใช้ที่อยู่อีเมล Bob@o365pilot.com
• CFO ของบริษัทคือ Suzan ที่ใช้ที่อยู่อีเมล Suzan@o365pilot.com

องค์ประกอบที่ไม่เป็นมิตรกำลังวางแผนที่จะส่งอีเมลหลอกลวงไปยัง Bob ที่ดูเหมือนว่าจะส่งมาจาก Suzan

องค์ประกอบที่ไม่เป็นมิตรรู้ว่าโครงสร้างพื้นฐานอีเมลของ o365pilot.com ใช้การตรวจสอบการยืนยันผู้ส่ง SPF สำหรับอีเมลขาเข้าแต่ละรายการ

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

องค์ประกอบที่ไม่เป็นมิตรจะสร้างข้อความอีเมลใหม่ที่มีที่อยู่อีเมลของผู้ส่งสองคน:

• evil@Thankyouforsharing.org
• suzan@o365pilot.com

ผู้รับปลายทางที่องค์ประกอบที่ไม่เป็นมิตรต้องการโจมตีคือ Bob ซึ่งเป็น CEO ของบริษัท

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

เมลเซิร์ฟเวอร์ปลายทางจะทำการทดสอบการตรวจสอบผู้ส่ง SPF สำหรับที่อยู่อีเมลที่ปรากฏใน MAIL FROM

ในสถานการณ์ของเรา เมลเซิร์ฟเวอร์จะพยายามตรวจสอบระเบียน SPF ของโดเมน - Thankyouforsharing.org

เนื่องจากการกำหนดค่าระเบียน SPF อย่างถูกต้อง การทดสอบการตรวจสอบผู้ส่ง SPF จึงเสร็จสมบูรณ์ และเซิร์ฟเวอร์อีเมลที่เป็นตัวแทนของผู้รับเป้าหมาย “ประกาศ” ว่าผู้ส่งสามารถเชื่อถือได้ (ผู้ส่งคือผู้ส่งที่ถูกต้อง)

เมลเซิร์ฟเวอร์ปลายทางจะคัดลอกที่อยู่อีเมลที่ปรากฏใน MAIL FROM
(evil@Thankyouforsharing.org) ไปยังช่องอีเมล - เส้นทางการส่งคืน

เมลเซิร์ฟเวอร์ปลายทางจะลบ ซองจดหมายเมล ที่มีข้อมูลเกี่ยวกับที่อยู่อีเมล - evil@Thankyouforsharing.org

เซิร์ฟเวอร์อีเมลจะส่งต่อข้อความอีเมลไปยังผู้รับปลายทาง (Bob)
Bob เห็นข้อความอีเมลเป็นข้อความอีเมลที่ส่งจาก suzan@o365pilot.com

บทความถัดไปในชุดบทความปัจจุบัน

ในบทความถัดไป - จะจำลองการโจมตีอีเมลปลอมและบายพาสการตรวจสอบผู้ส่ง SPF ได้อย่างไร | 2#2 เราจะได้เรียนรู้วิธีจำลองการโจมตีอีเมลปลอมและบายพาสการตรวจสอบผู้ส่ง SPF