Ich denke, Sie haben ein kleines Detail übersehen, das in der obigen Dramatisierung erwähnt wurde und das eigentlich sehr einfach zu überprüfen ist:
Gefälschte E-Mails stammen nicht von einer E-Mail-Adresse, die rechtmäßig zu der gehört Domäne, von der sie behaupten zu stammen. Ein Teil des SMTP-Protokolls enthält eine Reihe von vollständigen Nachrichtenkopfzeilen , die immer den Rückweg der Nachricht enthalten. Dies ist die E-Mail-Adresse, die tatsächlich ist hat die Nachricht gesendet. Darüber hinaus haben IP-Adressen eine bestimmte geografische Region, der sie zugewiesen sind. Sie können diese Diskrepanzen also mit ein wenig Graben abfangen.
Nehmen Sie zum Beispiel die Dramatisierung.
Es wird erwähnt, dass die E-Mail von whitehouse.gov stammt. Hier ist die IP-Adresse:
calyodelphi @ dragonpad: ~ $ dig + short whitehouse.gov173.223.0.110
Nehmen wir nun an, dass nastyhackerz.cn wird in eine IP-Adresse irgendwo im Block 1.0.32.0-1.0.63.255 aufgelöst (als Referenz: http://www.nirsoft.net/countryip/cn.html erster Block in der Liste). Diese IP-Adresse befindet sich in den vollständigen Nachrichtenkopfzeilen. Alles, was Sie tun müssen, ist, diese IP online zu nehmen, um ihre Geolokalisierung zu ermitteln (Sie können beispielsweise http://www.geoiptool.com/ verwenden).
Die IP für Whitehouse. gov (173.223.0.110) zum Zeitpunkt des Schreibens dieses Beitrags geolociert nach Boston, Massachusetts (aus irgendeinem Grund lässt mich ein Spam-Präventionssystem meine Suche aufgrund von Reputationspunkten nicht auf geoiptool veröffentlichen, sodass Sie die Suche selbst durchführen können). Das ist ziemlich nah an zu Hause (District of Columbia)! Nehmen wir einfach an, dass whitehouse.gov in einem Rechenzentrum in Boston gehostet wird, um die Erklärung zu vereinfachen.
Solange die IP- und E-Mail-Adresse, an der die E-Mail tatsächlich strong war > gesendet von stimmt nicht mit der IP- und E-Mail-Adresse überein, von der die E-Mail behauptet gesendet werden soll. Dies kann als Parodie bestimmt werden. Sie müssen nur in den vollständigen Nachrichtenkopfzeilen nachsehen.
Sehen wir uns die Header einer E-Mail an, die ich von einer meiner eigenen Domains (dragon-architect.com) an meine persönliche E-Mail-Adresse gesendet habe:
Übermittelt an: dragon.architect @ gmail.comReceived: von 10.180.89.68 mit der SMTP-ID bm4csp105911wib; Di, 29. Januar 2013 08:54:47 -0800 (PST) X-Received: bis 10.60.30.38 mit SMTP-ID p6mr1296792oeh.2.1359478487251; Di, 29. Januar 2013 08:54:47 -0800 (PST) Rückweg: <[email protected]>Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) von mx.go .com mit ESMTP-ID m7si14056914oee.29.2013.01.29.08.54.45; Di, 29 Jan 2013 08:54:46 -0800 (PST) Received-SPF: neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) client-ip = 69.93. 154,35; Authentifizierungsergebnisse: mx.google.com; spf = neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) [email protected]: von gateway14.websitewelcome.com (Postfix, von Benutzer-ID 5007) id 0530E1DFDB334; Di, 29 Jan 2013 10:54:43 -0600 (CST) Eingegangen: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) von gateway14.websitewelcome.com (Postfix) mit der ESMTP-ID EA7191DFDB314 für <dragon .architect @ gmail.com>; Di, 29 Jan 2013 10:54:42 -0600 (CST) Eingegangen: von [127.0.0.1] (port = 43458 helo = dragon-architect.com) von bentley.websitewelcome.com mit esmtpa (Exim 4.80) (Umschlag-) von <[email protected]>) id 1U0ESK-0001KE-DP für [email protected]; Di, 29. Januar 2013 10:54:44 -0600MIME-Version: 1.0Inhaltstyp: text / plain; Zeichensatz = UTF-8; format = flowedContent-Transfer-Encoding: 7bitDate: Di, 29 Jan 2013 10:54:44 -0600Von: [email protected] An: <[email protected]>Subject: Headers Test
Nachrichten-ID: <[email protected]>X-Sender: [email protected]: Roundcube Webmail / 0.8.4X-AntiAbuse: Dieser Header wurde hinzugefügt, um Missbrauch zu verfolgen : Primärer Hostname - bentley.websitewelcome.comX-AntiAbuse: Originaldomäne - gmail.comX-AntiAbuse: UID / GID des Absenders / Anrufers - [47 12] / [47 12] X-AntiAbuse: Absenderadressdomäne - dragon -itect.com.com -BWhitelist: noX-Quelle: X-Source-Args: X-Source-Dir: X-Source-Absender: (dragon-architect.com) [127.0.0.1]: 43458X-Source-Auth: calyodelphi @ dragon -itect. comX-Email-Count: 1X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20 = Testen testen!
Das sind viele zufällige Daten, die durchgesehen werden müssen. Rückweg und von. Da ich diese E-Mail zu Recht an mich selbst gesendet habe, stimmen beide überein. Der Rückweg kann nicht gefälscht werden. Wenn dies möglich ist, ist es unglaublich schwierig, effektiv zu fälschen, und es ist eine gezielte Konfiguration des SMTP-Dämons erforderlich, der zum Senden von E-Mails verwendet wird. Der Vergleich des Rückweges und der From-Datenfelder in den vollständigen Headern ist eine Möglichkeit, mit der ich und meine Mitarbeiter, bei denen ich arbeite, Parodien identifizieren und feststellen können, ob ein Support-Ticket eingereicht werden muss.
Also, was ist, wenn beide passen zusammen, aber die E-Mail sollte immer noch gefälscht sein? Ich werde im nächsten Abschnitt darauf zurückkommen ...
Nun, wie bereits erwähnt, gibt es andere Möglichkeiten, die Spoofiness einer E-Mail zu bestimmen. SPF-Aufzeichnungen sind eine dieser Möglichkeiten, aber sie sind nicht immer perfekt. Nehmen Sie zum Beispiel den SPF von whitehouse.gov und vergleichen Sie ihn mit dem SPF meiner eigenen Domain:
calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all "
Normalerweise enthält ein guter SPF-Eintrag auch die IP-Adresse des Servers, der die E-Mail gesendet hat. Wer also den SPF-Eintrag für whitehouse.gov erstellt hat, weiß dies wahrscheinlich nicht. Ich würde den SPF-Datensatz von whitehouse.gov als zu allgemein betrachten, um die tatsächliche Herkunft von Nachrichten, die angeblich von whitehouse.gov stammen, effektiv bestimmen zu können. Der SPF für meine eigene Domain hingegen, der automatisch von dem Server generiert wurde, der meine Domain hostet (mit freundlicher Genehmigung meines Webhosts), ist sehr spezifisch und enthält die IP-Adresse des Servers selbst.
Ich gebe zu, dass ich nicht genau weiß, wie SPF-Datensätze formatiert sind und wie sie funktionieren, aber ich habe bei meiner Arbeit genug gelernt, um zumindest generische und spezifische SPF-Datensätze identifizieren zu können. Ich denke, das ist etwas, in das ich mich wahrscheinlich an einem Wochenende vertiefen sollte, wenn mir langweilig ist und ich technisches Lesematerial möchte!
Wie auch immer, hier wieder auf Kurs. Schauen Sie sich die empfangenen Zeilen an. Einer von ihnen lautet wie folgt: Erhalten: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
Ratet mal, was? Dies entspricht der IP-Adresse im SPF-Eintrag meiner Domain.
Wenn die IP im SPF nicht mit der IP des Servers übereinstimmt, der die E-Mail tatsächlich gesendet hat, ist dies ein weiterer Hinweis darauf, dass Sie eine Parodie auf Ihre Domain haben Hände. Daher wird ein generischer SPF-Datensatz wie "v = spf1 + mx ~ all"
den Sicherheitssenf einfach nicht abschneiden. Ich würde nicht einmal E-Mails vertrauen, die von einer legitimen Domain stammen, die einen generischen SPF wie diesen hat.
Vielleicht sollten wir eine Petition auf petitions.whitehouse.gov einreichen, um dies zu fordern Sicherheitsadministratoren besuchen den SPF-Datensatz, den sie für die Domain erstellt haben, erneut! (Ich scherze, ich scherze.)
BEARBEITEN
Ich muss mich tatsächlich MASSIV über SPF-Datensätze korrigieren! Ich habe heute einige falsche Annahmen getroffen und ein paar Dinge gelernt, nachdem ich einen Kollegen gefragt hatte, der mehr über SPF-Aufzeichnungen wusste als ich. Also werde ich die beiden SPFs für whitehouse.gov und dragon-architect.com in meiner Selbstkorrektur verwenden:
calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all "
Der SPF für meine eigene Domain ist tatsächlich milder als der SPF für whitehouse.gov (etwas, das ich heute Abend korrigieren möchte, nachdem ich diese Bearbeitung abgeschlossen habe). Ich werde erklären, warum:
"v = spf1 + mx ~ all"
besagt im Grunde, dass E-Mails von whitehouse.gov von den in den MX-Datensätzen für definierten Hostnamen stammen sollen whitehouse.gov und alle E-Mails, die nicht von diesen Hostnamen stammen, sollen gefälscht sein. Ob sie jedoch als gefälscht markiert sind oder nicht, hängt vom Empfänger der E-Mail ab.
calyodelphi @ Dragonpad: ~ $ dig + short mx whitehouse.gov110 mail6.eop.gov.105 mail2.eop.gov.110 mail5.eop.gov.105 mail1.eop.gov.105 mail4.eop.gov.105 mail3.eop. gov.
"v = spf1 + a + mx + ip4: 70.84.243.130? all"
sagt, dass E-Mails von dragon-architect.com kommen sollen entweder von der IP-Adresse für dragon-architect.com (67.18.28.78), den in den MX-Datensätzen für dragon-architect.com definierten Hostnamen oder der IP-Adresse des Servers, auf dem dragon-architect.com gehostet wird (70.84) .243.130). Alle E-Mails, die nicht von diesen stammen, bedeuten am Ende nur, dass es keinen Rat gibt, ob die E-Mails weitergeleitet oder abgelehnt werden sollen.
Was ist also das Fleisch und die Kartoffeln eines SPF-Datensatzes? Das "Alles" ganz am Ende. Um diesen Mitarbeiter über das "All" zu zitieren:
+ all bedeutet im Grunde ALL pass - der Datensatz ist nutzlos, Absenderdomain ist das egal? All zeigt neutral an und rät, nicht zu bestehen oder Mail ablehnen
~ all zeigt einen Fehler an, und der Server wird als ungültig angesehen, schlägt jedoch keine Aktion vor. -all ist ein schwerer Fehler, alles andere ist ungültig, lehnen Sie ihn ab oder markieren Sie ihn.
Damit Mit "all" legen Sie fest, wie streng Ihr SPF-Datensatz ist. Ob der SPF-Datensatz tatsächlich verwendet wird, um die Spoofiness einer E-Mail zu bestimmen, hängt jedoch vollständig vom empfangenden E-Mail-Dienst ab.
Also, da sind Sie habe es. SPF auf den Punkt gebracht.
Also ja. TL; DR: Überprüfen Sie Ihre vollständigen Header, um festzustellen, ob der Rückweg und die Felder von übereinstimmen. Überprüfen Sie dann Ihre SPF-Einträge, falls vorhanden, um festzustellen, ob Sie übereinstimmende IP-Adressen erhalten.