WEBVTT

00:00:00.000 --> 00:00:22.180
[Vorspann]

00:00:22.180 --> 00:00:28.540
So, habt Ihr Euch jemals gefragt, wie man perfekt eine Email testen kann? Dann seid Ihr hier im

00:00:28.540 --> 00:00:33.369
richtigen Podcast. Wir haben hier unseren nächsten Sprecher. Andrew arbeitet gerade für das

00:00:33.369 --> 00:00:41.180
Nationale CERT in Lettland. Er ist ein Sicherheitsforscher.

00:00:41.180 --> 00:00:50.120
Und er wird gleich über E-Mail Fälschungen sprechen und Strategien für modernes Anti-Spoofing..

00:00:50.120 --> 00:00:53.356
Die Bühne gehört Dir.

00:00:53.356 --> 00:01:04.460
Applaus

00:01:04.460 --> 00:01:14.490
Also Grüße. Ich bin Andrew und ich habe für das Lettische National CERT gearbeitet. Eines unserer aktuellen Ziele ist

00:01:14.490 --> 00:01:21.440
die Verbesserung des Zustands der E-Mail-Sicherheit in unserem Land und

00:01:21.440 --> 00:01:26.400
das erreichen wir hauptsächlich durch die Erhöhung der Sensibilisierung für dieses Problem und die Vermittlung bewährter Praktiken.

00:01:26.400 --> 00:01:30.770
Und natürlich sind wir nicht die einzige Organisation, die dies tut.

00:01:30.770 --> 00:01:34.420
Es gibt viel mehr Gruppen in anderen Ländern und es gibt verschiedene Nichtregierungsorganisationen,

00:01:34.420 --> 00:01:39.299
die das Gleiche tun. Und konventionelle Einrichtungen.

00:01:39.299 --> 00:01:46.060
Doch bisher sind, offen gesagt, unsere
kollektiven Fortschritte ziemlich enttäuschend

00:01:46.060 --> 00:01:54.100
Daher ist hier zum Beispiel eine Statistik, die die Nutzung einer bestimmten

00:01:54.100 --> 00:01:59.770
Technologie in Dänemark zeigt, was, wie Sie in diesem Vortrag erfahren werden,

00:01:59.770 --> 00:02:06.770
ziemlich wichtig ist und ich hoffe, dass jeder diese Technologie verwendet. Auf der linken Seite

00:02:06.770 --> 00:02:11.060
werden 20.000 Domains weltweit angezeigt, die wichtige Domains sind für

00:02:11.060 --> 00:02:15.880
wichtige Organisationen, die es eigentlich besser wissen sollten. Und auf der rechten Seite

00:02:15.880 --> 00:02:24.799
sehen wir die Top 50 der TOP 500 EU-Einzelhändler und in beiden Gruppen haben 2/3

00:02:24.799 --> 00:02:29.799
DMARC bisher nicht einmal konfiguriert. Und von denen, die die Mehrheit konfiguriert haben,

00:02:29.799 --> 00:02:36.350
haben nicht keine strengen Richtlinien aktiviert. Wenn es also nur eine wichtige Erkenntnis aus

00:02:36.350 --> 00:02:41.459
diesem Vortrag gibt, hoffe ich, dass jeder damit beginnen sollte, DMARC zu verwenden. Es ist

00:02:41.459 --> 00:02:49.120
wichtig, es auch für Domains zu verwenden, die keine E-Mails senden sollen. Eine Erklärung

00:02:49.120 --> 00:02:56.760
für diese niedrige Akzeptanzrate ist meiner Meinung nach, dass es anscheinend zu viele

00:02:56.760 --> 00:03:04.310
konkurrierende Technologien gibt. Das ist der Inhalt meines Vortrags. Und ich habe wirklich

00:03:04.310 --> 00:03:12.449
mein Bestes gegeben, um ihn einzuschränken. Aber wie Sie sehen, gibt es 3 Abkürzungen, also

00:03:12.449 --> 00:03:18.739
und SMTP und außerdem SPF, DKIM und DMARC, an deren Namen ich mich

00:03:18.739 --> 00:03:25.570
nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass

00:03:25.570 --> 00:03:28.949
es zu viele Schlagworte gibt, zu viele Technologien, und es ist nicht klar

00:03:28.949 --> 00:03:34.590
welche wir davon verwenden sollten, das ist nicht spezifisch für E-Mails. Und wir haben dies

00:03:34.590 --> 00:03:39.760
in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir

00:03:39.760 --> 00:03:47.880
inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar mit Hilfe von

00:03:47.880 --> 00:03:53.370
Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt werden

00:03:53.370 --> 00:03:58.190
und die Ergebnisse veröffentlicht werden, können wir mit dem Gespräch beginnen. Wir

00:03:58.190 --> 00:04:03.510
können das Gespräch darüber führen, ob Ihre Organisation Technologie A oder B bevorzugt,

00:04:03.510 --> 00:04:09.620
oder wir können stattdessen die Fragen beantworten, die wirklich wichtig sind, wie:

00:04:09.620 --> 00:04:15.310
Ist es möglich, dass jemand für eine 3. Person die E-Mails ihrer Organisation fälscht und

00:04:15.310 --> 00:04:20.989
solche E-Mail zum Beispiel an Ihre Kunden oder Ihre Partner oder an Medienorganisationen so

00:04:20.989 --> 00:04:24.970
versendet, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation

00:04:24.970 --> 00:04:31.810
stammt? Deshalb sind Penetrationstester die wichtigste Zielgruppe für diesen Vortrag.

00:04:31.810 --> 00:04:36.020
Ich hoffe jedoch, dass alle Blue-Teamer im Publikum diesen

00:04:36.020 --> 00:04:40.650
Vortrag interessant finden. Ich bin sicher, dass Sie bereits alle Grundlagen über die

00:04:40.650 --> 00:04:43.620
E-Mail und über diese Technologien kennen, aber wenn man das Problem aus den

00:04:43.620 --> 00:04:50.440
verschiedenen Perspektiven des Angreifers betrachtet, kann man die Dinge ins rechte Licht

00:04:50.440 --> 00:04:54.819
rücken. Es kann Ihnen helfen zu verstehen, worauf Sie sich beim Schutz Ihrer Umwelt

00:04:54.819 --> 00:05:01.009
konzentrieren sollten. Und schließlich das SMTP Protokoll. Die Technologie, die in unseren

00:05:01.009 --> 00:05:07.720
E-Mail-Konversationen steckt, ist eigentlich relativ leicht zu verstehen.

00:05:07.720 --> 00:05:14.061
Und auch die Lehren, die man daraus gezogen hat. Diese Entwicklung von SMTP, wie es wurde

00:05:14.061 --> 00:05:20.979
und wie es möglich ist, es zu fälschen, und all die Technologien, die versuchen,

00:05:20.979 --> 00:05:27.530
Spoofing zu verhindern. Ich denke, es ist eine interessante Fallstudie und es sollte auch für

00:05:27.530 --> 00:05:33.719
solche Leute interessant sein sie zu verfolgen, die neu im E-Mail-Bereich sind. Nun final zur

00:05:33.719 --> 00:05:41.400
Bedrohungslandschaft. E-Mail Sicherheit ist ein ziemlich umfangreicher Themenbereich. Heute

00:05:41.400 --> 00:05:47.650
werde ich mich auf einen kleinen Teil fokussieren. Dieser ist das erfolgreiche

00:05:47.650 --> 00:05:54.689
Spoofing von E-Mails, also Manipulationsattacken. Ich weiß, dass viele Pentrationstester bereits teilweise

00:05:54.689 --> 00:06:01.250
Phishing oder Spear-Phishing-Emulation in ihre Arbeiten einbeziehen. So viel ich weiß, tun sie

00:06:01.250 --> 00:06:07.070
dies meist aus der Social-Engineering-Perspektive, indem sie beispielsweise Tools wie

00:06:07.070 --> 00:06:13.090
das Social-Engineering-Toolkit verwenden und ich möchte nicht behaupten, dass es wichtig ist,

00:06:13.090 --> 00:06:16.949
dies zu tun und dem Kunden zu zeigen, welche Risiken in dieser Hinsicht bestehen. Ich denke

00:06:16.949 --> 00:06:23.860
jedoch, dass Sie mit Social Engineering dem Kunden einen Dienst erweisen, wenn dies das

00:06:23.860 --> 00:06:28.099
Einzige ist, was Sie aus der E-Mail-Perspektive testen, denn aus der Perspektive der Kunden,

00:06:28.099 --> 00:06:32.650
beispielsweise von Managern, die Ihre Berichte lesen, erwähnen Sie dann nur Social-

00:06:32.650 --> 00:06:38.870
Engineering-Angriffe. Die logische Schlussfolgerung ist, dass der beste Weg, diese

00:06:38.870 --> 00:06:44.650
Bedrohungen einzudämmen. darin besteht, Ihr Personal zu schulen, insbesondere diejenigen,

00:06:44.650 --> 00:06:51.590
die am wenigsten technisch versiert sind, wie dies in diesem Vortrag zu sehen ist.

00:06:51.590 --> 00:06:55.379
Es gibt ziemlich viele Angriffe und viele Organisationen sind anfällig für diese Angriffe.

00:06:55.379 --> 00:07:00.230
Und hier hilft auch keine noch so große Benutzerschulung, denn wir können von den

00:07:00.230 --> 00:07:03.889
Benutzer nicht erwarten, dass sie beispielsweise die Kopfzeilen manuell

00:07:03.889 --> 00:07:10.699
überprüfen. Deshalb müssen wir unsere E-Mail-Infrastruktur tatsächlich verbessern. Daran

00:07:10.699 --> 00:07:17.009
führt kein Weg vorbei. Bevor wir uns schließlich den eigentlich technischen Dingen zuwenden,

00:07:17.009 --> 00:07:21.889
gibt es noch ein kleines Geheimnis. Ich denke, es könnte Leute helfen zu verstehen , die nicht

00:07:21.889 --> 00:07:28.159
in der E-Mail-Branche arbeiten, warum wir solche Probleme haben, und für E-Mail-

00:07:28.159 --> 00:07:38.040
Administratoren, die in der Vergangenheit die Verfügbarkeit ihres Systems und die

00:07:38.040 --> 00:07:44.680
Zuverlässigkeit viel mehr schätzten, als die Sicherheit. Und das liegt daran, dass das keine

00:07:44.680 --> 00:07:50.469
ideologische Entscheidung ist. Es ist eine sehr pragmatische. Wenn Sie also beispielsweise

00:07:50.469 --> 00:07:56.090
ein E-Mail-Administrator in einer Organisation sind und einige ihrer Kunden keine Rechnungen

00:07:56.090 --> 00:08:01.470
mehr erhalten, wird Ihr Management Sie finden, sie darüber informieren und Sie freundlich

00:08:01.470 --> 00:08:06.210
bitten, das Problem so schnell wie möglich zu beheben, auch wenn es nicht Ihre Schuld ist.

00:08:06.210 --> 00:08:13.509
Es könnte sein, dass das Problem möglicherweise auf einer anderen Seite liegt,

00:08:13.509 --> 00:08:20.449
nicht auf Ihrem Server. Ein anderes Beispiel ist, dass Sie, dass einige Ihrer Mitarbeiter bald

00:08:20.449 --> 00:08:24.969
keine E-Mails mehr empfangen können, oder E-Mails nicht früh genug erhalten, um das

00:08:24.969 --> 00:08:30.190
Passwort wiederherzustellen oder um die E-Mail zu verifizieren oder ein

00:08:30.190 --> 00:08:33.969
Mehrfaktor-Authentifizierungs-Token zu verwenden und sie können sich bei einigen

00:08:33.969 --> 00:08:39.539
wichtigen Systeme nicht mehr einloggen. Dann müssen Sie das lösen. Aber wenn Ihr System

00:08:39.539 --> 00:08:45.540
Sicherheitslücken hat, wenn es für Spoofing-Angriffe und so weiter anfällig ist, dann wird es

00:08:45.540 --> 00:08:50.670
normalerweise weder den Anwendern, noch dem Management auffallen. Aber Sie haben

00:08:50.670 --> 00:08:55.930
diese Schwachstelle. Deshalb sind Penetrationstester natürlich wichtig. Okay.

00:08:55.930 --> 00:09:01.250
Jetzt können wir endlich anfangen, über die Technik zu sprechen. Wir starten mit der

00:09:01.250 --> 00:09:07.190
kurzen Einführung in das SMTP-Protokoll. SMTP ist das Protokoll, das der gesamten E-Mail-

00:09:07.190 --> 00:09:12.360
Kommunikation zugrunde liegt und es ist ziemlich einfach zu befolgen. Hier ist also

00:09:12.360 --> 00:09:18.370
ein Datenfluss, der zeigt, was passiert, wenn eine Person E-Mails an eine andere Person

00:09:18.370 --> 00:09:21.269
sendet. Zum Bespielt sendet Alice an Bob und sie arbeiten für unterschiedliche Unternehmen.

00:09:21.269 --> 00:09:24.970
Sie verwenden unterschiedliche Domains. Was also passiert ist, dass beide sagen würden

00:09:24.970 --> 00:09:29.290
benutze E-Mail-Clients wie Outlook oder Thunderbird. Alice sendet E-Mails. Sie geht

00:09:29.290 --> 00:09:34.580
über dieses Protokoll SMTP an Alices Mail-Server. Wichtig ist aber zu beachten dass dies

00:09:34.580 --> 00:09:41.740
ein Server für ausgehende E-Mails ist. Üblicherweise verfügen Organisationen über

00:09:41.740 --> 00:09:44.790
2 Arten von Diensten, einen für eingehende und Transaktionen und einen für ausgehenden.

00:09:44.790 --> 00:09:48.680
Und auch für kleine Organisationen kann es einer sein, aber auch hier ist es für

00:09:48.680 --> 00:09:52.470
Penetrationstester wichtig, sich dies als unterschiedliche Systeme vorzustellen. Denn

00:09:52.470 --> 00:09:56.680
selbst wenn es physisch ein einziger Computer ist, wird er eine unterschiedliche Konfiguration

00:09:56.680 --> 00:10:00.620
für ausgehende und eingehende E-Mails haben. Als Penetrationstester müssen Sie also

00:10:00.620 --> 00:10:04.899
überprüfen, ob beide in Ordnung sind. Wenn Alices Server nun versucht, E-Mails an Bobs

00:10:04.899 --> 00:10:11.940
Server zu senden, gibt es eine Art von Problem, das darin besteht, dass der Server irgendwie

00:10:11.940 --> 00:10:16.480
automatisch den richtigen Server zum Versenden von E-Mails finden muss. Dies

00:10:16.480 --> 00:10:25.220
geschieht über diese blaue Box MX und DNS-spezfischen MX typen.

00:10:25.220 --> 00:10:29.680
Das ist also etwas, das von Bobs Organisation gepflegt wird,

00:10:29.680 --> 00:10:35.360
Bobs Organisation wird also, wenn sie E-Mails erhalten möchten, diesen DNS-Eintrag erstellen.

00:10:35.360 --> 00:10:38.830
Und ich sage: Okay, wenn Sie uns eine E-Mail senden möchten, benutzen Sie bitte diesen

00:10:38.830 --> 00:10:44.290
speziellen Server. Es sollte also auf Bobs verwiesen werden. Und jetzt kann Alices

00:10:44.290 --> 00:10:50.670
Ausgangsserver, der die eingehende Serveradresse von Bob kennt, mit diesem

00:10:50.670 --> 00:10:54.970
kommunizieren und Bob wird später seine E-Mail erhalten. Wir als Penetrationstester

00:10:54.970 --> 00:10:59.839
versuchen eigentlich, zwischen dem Server von Alice und dem von Bob zu vermitteln. Dann

00:10:59.839 --> 00:11:03.511
müssen wir über das 2. Beispiel nachdenken, das umgekehrt ist. Sie denken vielleicht, dass

00:11:03.511 --> 00:11:07.110
es sich um ein sinnloses Beispiel handelt, weil wir im Grunde nur die Richtung des

00:11:07.110 --> 00:11:11.449
Datenverkehrs ändern. Aber das Wichtigste hier ist, dass wir als Penetrationstester verstehen,

00:11:11.449 --> 00:11:17.220
dass unser Kunde nur einen Teil der Transaktion kontrolliert. Falls unser Kunde,

00:11:17.220 --> 00:11:20.760
sagen wir mal, für den Rest dieser Präsentation Alice oder Alices Organisation ist,

00:11:20.760 --> 00:11:26.750
dann werden im 2. Beispiel, wenn wir eine E-Mail von Bob an Alice senden, nur E-Mails

00:11:26.750 --> 00:11:34.600
gesendet. Grundsätzlich läuft ein Teil dieser Transaktion im 1. Beispiel über Alices Server.

00:11:34.600 --> 00:11:40.980
Wenn wir E-Mails von Alice an Bob senden, wäre dies nicht der Fall. Wenn es also etwas

00:11:40.980 --> 00:11:45.940
verwirrend ist, ist das in Ordnung. Wir werden etwas später darauf zurückkommen. Und

00:11:45.940 --> 00:11:51.600
schließlich gibt es noch ein 3. Beispiel, das ähnlich, aber nicht ganz so aussieht. Und zwar

00:11:51.600 --> 00:11:56.260
nur, wenn Alice kommuniziert. Alice ist unser Kunde. Und wenn sie mit ihren Kollegen

00:11:56.260 --> 00:12:01.070
kommuniziert, die in der gleichen Organisation sind, denselben E-Mail-Server und die gleiche

00:12:01.070 --> 00:12:04.320
Domain haben, wird es in diesem Beispiel logischerweise 2 E-Mail-Server geben, ein

00:12:04.320 --> 00:12:09.000
Ausgangsserver und ein Eingangsserver.

00:12:09.000 --> 00:12:15.850
Aber beide gehören unserem Kunden. Also können Sie im Moment, wenn Sie sich mit

00:12:15.850 --> 00:12:20.149
E-Mail nicht auskennen, versuchen darüber nachzudenken, welche dieser 3 Szenarien

00:12:20.149 --> 00:12:27.740
leichter zu schützen sind. Später werden wir sehen, sie es tatsächlich abläuft. Okay.

00:12:27.740 --> 00:12:31.769
Dann müssen wir uns ansehen, was tatsächlich gesendet wird, wenn eine E-Mail versandt wird.

00:12:31.769 --> 00:12:38.410
Also noch einmal, es wird das SMTP-Protokoll verwendet und es ist ein wirklich gutes

00:12:38.410 --> 00:12:44.790
Protokoll. Wie Sie sehen können, handelt es sich nur um Text. Es handelt sich also um ein

00:12:44.790 --> 00:12:48.029
reines Textprotokoll und es ist sehr einfach zu bedienen, weil man einfach eine Telnet-

00:12:48.029 --> 00:12:54.410
Verbindung zum richtigen Server öffnet und man versuchen kann, die Befehle einfach mit

00:12:54.410 --> 00:12:58.680
den Händen aufzuschreiben. Um zu versuchen, etwas zu zerstückeln oder zu modifizieren, oder

00:12:58.680 --> 00:13:05.149
zu versuchen, verschiedene Typen auszuprobieren und in Echtzeit zu sehen, wie

00:13:05.149 --> 00:13:11.209
es weitergeht. Auf der linken Seiten sehen wir hier also 2 Teile, die durch SMTP definiert sind.

00:13:11.209 --> 00:13:14.720
Als erstes kommt der SMTP-Umschlag, den Sie im Grund mit dem Server verbinden. Sagen Sie

00:13:14.720 --> 00:13:22.070
"Hallo". Dann sagen Sie, was der Absender der E-Mail und der Empfänger der E-Mail

00:13:22.070 --> 00:13:26.980
angegeben haben. "Mail von" ist der Absender. Empfänger ist zum Beispiel Bob. Und dann

00:13:26.980 --> 00:13:32.160
beginnt der 2. Teil mit Daten und endet mit "Beenden". Und das ist der Teil, der sich

00:13:32.160 --> 00:13:35.480
Inhalt/Nachricht nennt. Wenn Sie also ein bisschen damit herumspielen wollen, wird dies

00:13:35.480 --> 00:13:38.029
durch einen anderen Standard definiert, der für Penetrationstester nicht so wichtig ist. Aber

00:13:38.029 --> 00:13:43.890
wenn Sie sich die Details ansehen möchten, dann könnte es wichtig sein. Und diese interne

00:13:43.890 --> 00:13:49.069
Nachricht, die entweder Inhalt oder SMTP genannt wird, enthält wiederum 2. Teile. Der

00:13:49.069 --> 00:13:53.300
eine Teil ist die Kopfzeile und der andere der Hauptteile. Und ich denke, dass einige Leute

00:13:53.300 --> 00:13:57.569
vielleicht nicht mit der E-Mail vertraut sind, aber wahrscheinlich ist jeder Zuhörer mit HTTP

00:13:57.569 --> 00:14:02.600
vertraut und das sieht ganz ähnlich aus. Also leicht zu verstehen. Aber der interessante Teil

00:14:02.600 --> 00:14:08.550
ist, dass sie vielleicht bemerkt haben, dass wir

00:14:08.550 --> 00:14:14.350
Alices und Bobs Adressen zweimal haben. Das stimmt. Zum Beispiel ist Alices Adresse in der

00:14:14.350 --> 00:14:19.709
zweiten Zeile "Mail von". Und dann haben wir die gleiche Adresse. Alice @ ihre Organisation in

00:14:19.709 --> 00:14:26.810
der Kopfzeile "Von". Die roten Bereiche sind die Kopfzeilen. Und das gleiche gilt für Bob. Und

00:14:26.810 --> 00:14:33.471
warum ist das so? Nun, es kommt darauf an, wie wir E-Mails sehen. Ich als eine normale

00:14:33.471 --> 00:14:39.139
Person, die E-Mails in den letzten Jahren benutzt hat, sehe sie normalerweise so, wie

00:14:39.139 --> 00:14:44.980
auf der linken Seite beschrieben, wie eine Art Postkarte. Auf der Postkarte steht also jemand,

00:14:44.980 --> 00:14:48.980
der sie abgeschickt hat. Der Absender. Da ist dann noch der Empfänger. Das bin ich

00:14:48.980 --> 00:14:53.569
normalerweise. Ich empfange. Und dann ist da noch eine Nachricht. Zumindest habe ich das so

00:14:53.569 --> 00:14:58.670
wahrgenommen, bevor ich etwas mehr darüber gelernt habe. Aber E-Mail Administratoren und

00:14:58.670 --> 00:15:04.610
die Standardgremien sehen diese Situation, wie sie rechts dargestellt ist. Da ist ein Umschlag

00:15:04.610 --> 00:15:10.480
und darin befindet sich diese Nachricht oder vielleicht eine Postkarte. Sie haben also 2

00:15:10.480 --> 00:15:15.350
Adressen in diesem Szenario. Sie haben die Adresse von und an wen sie sich den Umschlag

00:15:15.350 --> 00:15:20.730
senden. Dies ist beispielsweise der Teil, den die Post einsehen wird. Aber das Postbüro wird im

00:15:20.730 --> 00:15:24.589
Allgemeinen nicht in Ihrem Umschlag nachsehen und sehen, dass sich dort eine

00:15:24.589 --> 00:15:28.880
weitere Nachricht, die interne Nachricht befindet, die eigentliche für den Empfänger

00:15:28.880 --> 00:15:33.889
bestimmt ist. Man könnte also eigentlich sogar noch mehr machen und man könnte sogar den

00:15:33.889 --> 00:15:40.060
ganzen Umschlag mit der Nachricht der Postkarte in einen anderen Umschlag stecken.

00:15:40.060 --> 00:15:46.500
Und das klingt für mich als normalen Menschen verrückt, aber tatsächlich ist das bei E-Mail.

00:15:46.500 --> 00:15:50.029
möglich. Und in dem RFC, dem Standarddokument, gibt es einige Beispiele,

00:15:50.029 --> 00:15:56.939
warum das notwendig ist. Warum solche Dinge erlaubt sind. Aber sie sind doch verwirrend.

00:15:56.939 --> 00:16:03.009
Und so als Ergebnis sehen wir in diesem ersten Beispiel , dass wir im Allgemeine die gleiche

00:16:03.009 --> 00:16:07.940
Adresse zweimal angeben. Aber als Penetrationstester sollten wir uns die Frage

00:16:07.940 --> 00:16:12.170
stellen: Ist das aktuell erforderlich? Ist das immer wahr, oder handelt es sich nur um

00:16:12.170 --> 00:16:17.120
Wunschdenken? Und es ist tatsächlich ein Wunschdenken. Standards schreiben nicht

00:16:17.120 --> 00:16:20.870
ausdrücklich vor, dass Sie die gleiche Adresse für den Empfänger oder für das "Von" des

00:16:20.870 --> 00:16:27.140
Absenders auf dem Umschlag und innerhalb einer Nachricht angeben. Es gibt also

00:16:27.140 --> 00:16:32.300
tatsächlich viel mehr Kopfzeilen als die, die ich gezeigt habe. Die, die ich gezeigt habe, sind

00:16:32.300 --> 00:16:38.519
meiner Meinung nach nur die, mit denen wir alle Erfahrung haben, denn wenn man nur

00:16:38.519 --> 00:16:42.850
E-Mail benutzt, sind das normalerweise die Dinge, die man sieht oder man sieht das

00:16:42.850 --> 00:16:45.920
Datum, den Betreff, den Inhalt, wer Dir etwas gesendet hat und an wen es gesendet wurde.

00:16:45.920 --> 00:16:52.680
Üblicherweise Du selbst. Und dort könnten es natürlich auch mehrere Empfänger geben.

00:16:52.680 --> 00:16:57.800
Oh ja. Und die Frage ist dann noch eine andere:

00:16:57.800 --> 00:17:03.769
Was ist eigentlich, wenn wir aus irgendeinem Grund etwas versehentlich angegeben haben

00:17:03.769 --> 00:17:07.300
oder vor allem, wenn wir unterschiedliche Adressen in diesem Umschlag angegeben

00:17:07.300 --> 00:17:11.890
haben, welche der Benutzer sehen wird. Der Empfänger, das ist eigentlich die Kopfzeile. Ok.

00:17:11.890 --> 00:17:18.010
Wie ich schon sagte, gibt es tatsächlich Standards, die mehr Kopfzeilen erlauben. Und

00:17:18.010 --> 00:17:22.510
es gibt aktuell 3 Kopfzeilen "Von", "Absender", "Antwort an", die semantisch wirklich nahe

00:17:22.510 --> 00:17:25.880
beieinander liegen und im Standard ist eigentlich erklärt, wann man welche Überschrift

00:17:25.880 --> 00:17:31.080
verwenden sollte. Und das Lustige für mich ist, dass zum Beispiel die "Von" Überschrift ist,

00:17:31.080 --> 00:17:34.040
diejenige ist, in der wir sehen, was sie beinhaltet. Wenn Sie den RFC lesen, werden Sie

00:17:34.040 --> 00:17:39.310
sehen, dass man nicht mehr als eine solche Kopfzeile haben sollte, aber die Kopfzeile selbst

00:17:39.310 --> 00:17:44.450
könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail

00:17:44.450 --> 00:17:48.020
erhalten, die von verschiedenen Personen stammen würde, aber das ist erlaubt. Aber das

00:17:48.020 --> 00:17:53.110
Wichtigste, was Sie hier noch einmal verstehen müssen, ist dies bereits erwähnte

00:17:53.110 --> 00:17:57.530
Rückwärtskompatibilität. Obwohl die Standards erklären, wie Sie die Haupt-Kopfzeile

00:17:57.530 --> 00:18:02.480
verwenden sollten, und dass Sie in der Praxis nicht mehr als eine dieser Kopfzeilen haben

00:18:02.480 --> 00:18:07.130
sollten, können Sie bei einer Zustimmung zu fehlerhaften E-Mails diese mit mehreren

00:18:07.130 --> 00:18:12.480
Kopfzeilen in der selben Kopfzeile senden. Sie könnten Kopfzeilen senden, die laut RFC kein

00:18:12.480 --> 00:18:17.040
"Von" enthält, aber einen "Absender". Das ist nicht korrekt. In der Praxis wird es.

00:18:17.040 --> 00:18:21.240
funktionieren. Die meisten Organisationen, die meisten E-Mail-Dienste werden Ihr Bestes tun,

00:18:21.240 --> 00:18:27.550
ihre völlig fehlerhafte E-Mail nach besten Kräften zu analysieren, weil sie wirklich daran

00:18:27.550 --> 00:18:33.720
interessiert sind, die Supportkosten zu senken. Wenn etwas also nicht funktioniert, wird man

00:18:33.720 --> 00:18:37.580
zu Ihnen kommen. Es ist also besser, dafür zu sorgen, dass meistens alles funktioniert.

00:18:37.580 --> 00:18:42.160
Für Penetrationstester bedeutet das natürlich, dass Sie damit herumspielen können, weil es

00:18:42.160 --> 00:18:45.670
verschiedene Implementierungen gibt und es genau darauf ankommt, welche Gefahr besteht.

00:18:45.670 --> 00:18:49.480
Wenn beispielsweise 2 Kopfzeilen angezeigt werden oder für einen Algorithmus verwendet,

00:18:49.480 --> 00:18:53.830
hängt dies von der jeweiligen Implementierung ab. Da es so viele Implementierungen gibt, sind

00:18:53.830 --> 00:18:59.150
diese auf unterschiedliche Weise miteinander verbunden. Sie können und sollten als

00:18:59.150 --> 00:19:03.720
Penetrationstester verschiedene Dinge ausprobieren, zum Beispiel die gleiche

00:19:03.720 --> 00:19:09.270
Kopfzeile mehrmals hinzufügen. OK. Nachdem wir nun diese Grundlagen behandelt haben,

00:19:09.270 --> 00:19:13.990
wollen wir uns ansehen, Wie Sie versuchen würden, zum Beispiel eine E-Mail zu fälschen.

00:19:13.990 --> 00:19:18.360
Ja, genau. Und hier sind wir wieder, wir kommen zurück zu diesem Diagramm, das wir

00:19:18.360 --> 00:19:23.930
schon einmal gesehen haben. Und beispielsweise in dem 1. Beispiel, wo Alice eine

00:19:23.930 --> 00:19:29.960
E-Mail an Bob gesendet hat. Sagen wir mal, wir sind Chuck. Wir sind also eine dritte Partei. Wir

00:19:29.960 --> 00:19:33.700
sind lizenzierte Penetrationstester, wir haben eine Vereinbarung, die uns erlaubt, dies zu tun

00:19:33.700 --> 00:19:38.920
und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In diesem Beispiel versuchen

00:19:38.920 --> 00:19:44.440
wir, die Nachricht von Alice zu fälschen. Unsere Absicht ist es, dass Bob will, dass Bob eine

00:19:44.440 --> 00:19:52.580
E-Mail erhält. Es sollte für Bob so aussehen, dass die E-Mail von Alice gesendet

00:19:52.580 --> 00:19:57.580
wurde. Also ein Risiko. Okay. Ich möchte das Risiko nicht übernehmen. Ich denke, Sie können

00:19:57.580 --> 00:20:01.430
das verstehen. Ich kann mir vorstellen, dass gefälschte Nachrichten eines der Probleme

00:20:01.430 --> 00:20:06.330
sind, die wir in Lettland gesehen haben. Sie wurden gegen Regieurngsbehörden eingesetzt.

00:20:06.330 --> 00:20:13.660
Und als jemand gefälschte Nachrichten per E-Mail an andere Leute, Organisationen etc.

00:20:13.660 --> 00:20:19.510
sendete und versucht hat, sich als jemand anderes auszugeben. Und natürlich können Sie

00:20:19.510 --> 00:20:23.710
sich vorstellen, dass das keine gute Sache ist. Aber das Interessante hier ist, dass Chuck zwar

00:20:23.710 --> 00:20:28.450
angreift, es aber von Ihrer Perspektive abhängt. Es könnte wie ein Angriff auf Alice oder Bob

00:20:28.450 --> 00:20:32.480
aussehen. In diesem Fall werden E-Mails nicht durch Alices Systeme geleitet. Wie Sie sehen

00:20:32.480 --> 00:20:37.590
können, sendet Chuck E-Mails an Bobs Posteingangsserver. Nun gibt es eine 2. Art von

00:20:37.590 --> 00:20:44.490
Angriffsart, die wir uns ansehen werden. Wenn wir eine E-Mail in die andere Richtung senden,

00:20:44.490 --> 00:20:48.540
von Bob an Alice. Und unser Kunde ist Alice. Und in diesem Fall versuchen wir wieder, Chuck

00:20:48.540 --> 00:20:52.900
zu sein. Wir senden E-Mails. in diesem Fall wird die E-Mail durch das System

00:20:52.900 --> 00:20:58.570
von Alice geleitet. Die interessante Frage ist daher, was einfacher zu schützen ist.

00:20:58.570 --> 00:21:03.790
Es könnte den Anschein haben, dass seit dem 2. Beispiel, die E-Mail tatsächlich durch die

00:21:03.790 --> 00:21:07.270
Systeme von Alice läuft. Das bedeutet, dass Alice mehr Befugnisse hat, etwas zu tun, um

00:21:07.270 --> 00:21:11.880
einige zusätzliche Kontrollen und Abgleiche usw. durchzuführen. Aber wie wir in Zukunft

00:21:11.880 --> 00:21:16.190
sehen werden, ist es tatsächlich einfacher, das 1. Beispiel zu schützen. Auch wenn unser Kunde

00:21:16.190 --> 00:21:21.710
Alice ist, versuchen wir Alice zu schützen. Aber in der Praxis ist es einfacher, dieses Beispiel zu

00:21:21.710 --> 00:21:26.540
schützen und in die Praxis umzusetzen, in dem jemand E-Mail verkauft und versucht, sich als

00:21:26.540 --> 00:21:32.800
Alice auszugeben. Okay. Oh, ja. Es gibt noch das 3. Beispiel: Wenn Alice mit ihren Kollegen

00:21:32.800 --> 00:21:37.690
innerhalb derselben Organisation kommuniziert, sind wir Chuck.

00:21:37.690 --> 00:21:41.821
In diesem Fall werden wir die E-Mail nur an den Posteingangsserver von Alice senden, nicht an

00:21:41.821 --> 00:21:47.590
Postausgangsserver. Richtig. Das ist wichtig zu beachten. Im Prinzip ist dieses 3. Beispiel am

00:21:47.590 --> 00:21:54.460
einfachsten zu erkennen weil Alices Organisation vermutlich weiß, dass ihre E-Mails

00:21:54.460 --> 00:21:59.790
immer von einem, von diesem bestimmten Postausgangsserver kommen sollen. Richtig.

00:21:59.790 --> 00:22:03.790
Wenn wir beispielsweise eine E-Mail von Alices Kollegen senden, sollte der Posteingangsserver im

00:22:03.790 --> 00:22:08.780
Prinzip auch ohne Standards oder ähnliches, die volle Leistung haben.

00:22:08.780 --> 00:22:15.610
Aber in der Praxis gibt es tatsächlich ziemlich oft eine spezielle Whitelist für Alices eigene Organisation.

00:22:15.610 --> 00:22:24.140
Es finden keine Überprüfungen statt, falls der Posteingangsserver von Alice E-Mails empfängt,

00:22:24.140 --> 00:22:28.880
die wiederum von Alice stammen.

00:22:28.880 --> 00:22:34.610
Übrigens gibt es dieses Beispiel, das wir in den letzten Jahren gesehen haben.

00:22:34.610 --> 00:22:38.730
Ich denke, das ist nicht spezifisch für Lettland. Deshalb ist hier als Beispiel eine kanadische Adresse und auch

00:22:38.730 --> 00:22:43.590
andere, wie Sie sehen können. Es handelt sich hierbei um gefälschte E-Mails, wie Ransomware-Sachen.

00:22:43.590 --> 00:22:48.290
Im Grunde sagen sie Ihnen, dass Sie in diesem Fall Ihren Computer oder Ihre E-Mails gehackt haben. Und

00:22:48.290 --> 00:22:53.820
alle möglichen Aktivitäten arrangiert haben oder Sie erpresst.

00:22:53.820 --> 00:22:59.160
Und senden Sie uns bitte das Geld. Ihr Geld. Ich meine Ihr Geld in Bitcoins an deren Adresse.

00:22:59.160 --> 00:23:04.520
Soweit diese E-Mails. Der interessante Teil dieser E-Mails besteht darin, dass sie normalerweise

00:23:04.520 --> 00:23:08.920
dazu dienen; Ihnen zu beweisen, dass Sie Zugang zu Ihrem E-Mail-Konto haben.

00:23:08.920 --> 00:23:13.210
Sie senden E-Mails von Ihrer Adresse an Ihre Adresse.

00:23:13.210 --> 00:23:20.100
Bei vielen Menschen funktioniert das, Sie sehen also, dass jemand Ihr Konto gehackt hat, weil Sie eine

00:23:20.100 --> 00:23:22.730
E-Mail von sich selbst erhalten haben.

00:23:22.730 --> 00:23:28.620
Wie Sie also später sehen werden, ist es sehr einfach, solche E-Mails zu fälschen, falls keine

00:23:28.620 --> 00:23:34.100
Schutzvorkehrungen vorgenommen wurden. Das Wichtigste ist also, dass ich hoffe, dass niemand in

00:23:34.100 --> 00:23:38.120
diesem Publikum auf einen solchen Betrug hereinfällt.

00:23:38.120 --> 00:23:43.910
Aber vielleicht haben Sie Freunde oder Kollegen, die Sie kontaktiert haben und Ihnen von solchen E-Mails

00:23:43.910 --> 00:23:48.230
erzählt haben. Aber eines der Dinge, die neben der Überprüfung der Passwörter zum Einsatz kommen

00:23:48.230 --> 00:23:53.110
sollte, ist eine effektivere Authentifizierung zu nutzen. Vielleicht könnten Sie Ihnen sagen, dass sie Ihre E-Mail

00:23:53.110 --> 00:23:57.770
Administratoren oder ihr IT-Team kontaktieren und nach dem Anti-Spoofing-Schutz fragen sollten.

00:23:57.770 --> 00:24:03.470
Denn wenn sie solche E-Mails empfangen können und diese nicht gefiltert werden,

00:24:03.470 --> 00:24:09.020
stimmt etwas nicht. Okay.

00:24:09.020 --> 00:24:16.990
Und nun sehen wir uns eine gefälschte SMTP-Konversation an, also ein ähnliches Beispiel wie eben.

00:24:16.990 --> 00:24:22.090
Aber in diesem Beispiel jetzt sind wir tatsächlich Chuck, also wird dies von Chuck an Bob gesendet.

00:24:22.090 --> 00:24:25.920
Aber wir tun so, als wären wir Alice. Die Frage ist, können Sie den Unterschied zu der vorherigen

00:24:25.920 --> 00:24:30.110
erkennen? Und es ist schwer, den Unterschied zu erkennen, da es keinen Unterschied gibt, da es

00:24:30.110 --> 00:24:33.230
sich um das gleiche Gespräch handelt.

00:24:33.230 --> 00:24:39.540
Der Punkt hier ist also, dass das SMTP-Protokoll an sich eigentlich keinen Schutz bietet.

00:24:39.540 --> 00:24:43.640
Oh ja, Sie könnten es einfach zum Beispiel tun, wenn Sie dieser Typ sind, der die gefälschten Lösegeldbrief verschickt.

00:24:43.640 --> 00:24:49.580
verschickt. Sie können diesen Text einfach aufschreiben und ihn einfach an Telnet senden.

00:24:49.580 --> 00:24:55.830
Das funktioniert bei vielen Organisationen. Aber nicht bei allen. Und natürlich kennen die E-Mail-

00:24:55.830 --> 00:25:01.210
Administratoren sich damit aus. Sie wissen, dass SMTP in diesem Fall nicht sehr zuverlässig ist.

00:25:01.210 --> 00:25:05.070
Das ist leicht zu fälschen und so weiter. Und es gäbe viele Versuche, einen gewissen Schutz hinzuzufügen,

00:25:05.070 --> 00:25:11.520
einfach auf Ad-hoc-Art. Also ohne Standards. Fügen Sie einfachen paar zusätzliche Filter und ähnliches in

00:25:11.520 --> 00:25:15.950
Ihre eigene Mail ein. Und einige dieser Schutzmaßnahmen verstoßen tatsächlich gegen RFC,

00:25:15.950 --> 00:25:20.640
Aber wen interessiert das schon? RFC ist ja kein heiliger Text, den ich zum Beispiel absolut

00:25:20.640 --> 00:25:26.260
befürworte. Also machen Sie weiter. Aber das Problem ist, dass es nicht genügend Informationen gibt.

00:25:26.260 --> 00:25:31.640
Wenn Sie also zurückdenken, sind wir Bob und versuchen, unsere Systeme zu schützen.

00:25:31.640 --> 00:25:35.100
Wir sind also Bob, irgendein Systemadministrator, oder Bob ist der Systemadministrator und wir

00:25:35.100 --> 00:25:39.730
versuchen, einige zusätzliche Regeln und so etwas hinzuzufügen.

00:25:39.730 --> 00:25:44.590
Was können wir dann eigentlich tun? Ein Beispiel, das ich hier aufgelistet habe, ist die Durchführung dieses

00:25:44.590 --> 00:25:49.980
SMTP-Rückrufs. Das bedeutet, dass wir E-Mails von Alice erhalten. Wir prüfen tatsächlich, ob

00:25:49.980 --> 00:25:56.970
diese E-Mail überhaupt vorhanden ist. Denn viele Spammer senden einfach E-Mail von nicht

00:25:56.970 --> 00:26:02.000
existierenden E-Mails. Und es wird funktionieren, wenn Sie nur einen einfachen

00:26:02.000 --> 00:26:08.640
SMTP-Server haben. SMTP-Callback bedeutet also, dass Sie, eine E-Mail erhalten,

00:26:08.640 --> 00:26:13.300
Wenn Sie beispielsweise E-Mails von Alice erhalten, versuchen Sie, einen separaten

00:26:13.300 --> 00:26:17.220
Prozess zu starten. Dieser wird eine Verbindung zu Alices Server herzustellen, etc.

00:26:17.220 --> 00:26:24.500
Und er wird versuchen, ihr eine E-Mail zu senden. Wenn ein Server sagt, "Ja, das ist OK",

00:26:24.500 --> 00:26:27.540
eine solche E-Mail existiert und so weiter, dann ist es nicht so, als hätten Sie die Konversation

00:26:27.540 --> 00:26:31.290
tatsächlich beendet. Aber dann kann Ihr System automatisch feststellen, dass diese E-Mail auch

00:26:31.290 --> 00:26:36.570
wirklich existiert. Eine andere Möglichkeit, dies zu tun, ist durch Überprüfung dieses "Hello".

00:26:36.570 --> 00:26:42.030
Und das ist die erste Zeile und in der ersten Zeile sollte normalerweise der Hostname des

00:26:42.030 --> 00:26:48.000
Servers stehen, der die E-Mail sendet.

00:26:48.000 --> 00:26:52.580
Interessanter Teil. Laut RFC sollten Sie also nicht überprüfen, ob man es verifizieren kann.

00:26:52.580 --> 00:26:56.540
Und wenn es sich um eine zufällige Zeichenfolge handelt, sollten Sie es akzeptieren.

00:26:56.540 --> 00:27:04.520
Aber viele Server werden zunächst versuchen, diesen Hostname zu überprüfen, von dem Sie

00:27:04.520 --> 00:27:07.800
sagen, dass Sie dieser Hostname sind. Zunächst ob es tatsächlich auf dieselbe IP-Adresse

00:27:07.800 --> 00:27:12.800
verweist und dann machen Sie das Gegenteil. Sie nehmen die IP-Adresse und versuchen,

00:27:12.800 --> 00:27:18.880
eine umgekehrte DNS-PTR-Abfrage auszuführen. Und Sie werden versuchen

00:27:18.880 --> 00:27:23.150
herauszufinden, ob diese IP-Adresse wirklich auf diesen Hostname antwortet. Also nochmal.

00:27:23.150 --> 00:27:26.520
Als Penetrationstester sollten wir uns über diese Schutzmaßnahmen, Ad-Hoc-

00:27:26.520 --> 00:27:31.040
Schutzmaßnahmen im Klaren sein. Denn wenn Sie sie nicht kennen, werden Sie versuchen

00:27:31.040 --> 00:27:34.700
etwas auszuführen und es wird bei Ihnen nicht funktionieren. Aber Sie einfach, wenn Sie

00:27:34.700 --> 00:27:40.470
kennen und erkannt haben, dass diese Organisation sie verwendet. Sie sind leicht zu

00:27:40.470 --> 00:27:44.530
umgehen, so dass sie keinen guten Schutz bieten. Sie sollen vor massenhaftem

00:27:44.530 --> 00:27:52.910
Missbrauch durch Spam schützen. Ok. Also bietet SMTP, wie wir gesehen haben, keinen

00:27:52.910 --> 00:27:59.380
Schutz. Welche Ergänzungen zum Protokoll können also nachträglich tatsächlich verwendet

00:27:59.380 --> 00:28:06.860
werden, um uns zu schützen? Eines dieser Protokolle ist SPF. SPF versucht wie ein Spiegel

00:28:06.860 --> 00:28:12.870
MX-System sein. Das MX-System ist ein gemischtes System, das Alice grundsätzlich

00:28:12.870 --> 00:28:18.150
benutzen kann, damit Alices Server automatisch den Server finden kann, der Bob und seinem

00:28:18.150 --> 00:28:24.580
Posteingangsserver gehört. SPF ist also das Gegenteil davon. Da ist also eine Idee, das

00:28:24.580 --> 00:28:30.270
System automatisch auf dem Posteingangsserver von Bob auszuführen.

00:28:30.270 --> 00:28:35.720
Wenn Bob nun die E-Mail erhalt, können sie wieder eine DNS-Abfrage ausführen und

00:28:35.720 --> 00:28:41.820
herausfinden, welche IP-Adressen eigentlich zu Alices Postausgangsserver gehören. Das

00:28:41.820 --> 00:28:45.780
stimmt. Ich denke, es ist einfach zu verstehen, dass dies tatsächlich ein sinnvoller Weg ist. Es

00:28:45.780 --> 00:28:52.570
ist eine Ergänzung. Und das eine Feld, das in diesem Beispiel überprüft wird, ist der

00:28:52.570 --> 00:28:59.360
Absender des Umschlags. OK. Und hier ist ein Beispiel für minimale SPF-Syntax. Wie wir

00:28:59.360 --> 00:29:04.610
sehen können, ist es meiner Meinung nach leicht zu verstehen, auch wenn man die Syntax

00:29:04.610 --> 00:29:08.470
nicht kennt. Die Syntax besteht darin, dass sie IP-Adresse aufgelistet wird, die die IP-Adresse

00:29:08.470 --> 00:29:12.780
des Postausgangsservers ist. Und dann steht da noch dieses "alle", was wiederum leicht zu

00:29:12.780 --> 00:29:18.700
verstehen ist. In diesem Fall bedeutet es, das dies das einzige Mal ist. Wenn Sie also eine

00:29:18.700 --> 00:29:22.980
Nachricht erhalten, kommt diese von dieser IP-Adresse, Das ist cool. Ich akzeptiere es. Wenn es

00:29:22.980 --> 00:29:27.190
etwas anderes ist, dann lösche ich es einfach. Und es gibt mehrere Möglichkeiten, die IP-

00:29:27.190 --> 00:29:31.610
Adresse anzugeben. Sie könnten einfach die IP-Adresse angeben. Sie könnten ein IP-Subnetz

00:29:31.610 --> 00:29:37.070
angeben, Sie könnten einen DNS-Hostname angeben. Es ist also nur für den Administrator.

00:29:37.070 --> 00:29:44.750
Für einen Penetrationstest ist es grundsätzlich nicht viel anders, für Administratoren ist es

00:29:49.620 --> 00:29:56.160
einfacher, diese Systeme zu warten. Und dann gibt es diese Qualifikanten. Das ist etwas, das

00:29:56.160 --> 00:30:00.100
man den Methoden voranstellt. Hier in diesem Beispiel hat IPv4 keinen Qualifikanten. Es gibt

00:30:00.100 --> 00:30:03.910
kein Plus oder Minus oder so etwas. Das liegt daran, dass das Plus standardmäßig

00:30:03.910 --> 00:30:12.600
angenommen wird. Dadurch wird standardmäßig alles, was im SPF-Eintrag

00:30:12.600 --> 00:30:15.850
aufgeführt ist, mit einem legitimen SMTP-Ausgangsserver übereinstimmen sollte. Es

00:30:15.850 --> 00:30:20.380
gibt jedoch andere Optionen, die Sie verwenden können. Minus verwenden, das heißt "Fehler".

00:30:20.380 --> 00:30:26.710
Und das bedeutet, wenn etwas mit diesem Datensatz übereinstimmt, das ist

00:30:26.710 --> 00:30:32.090
normalerweise die letzte Möglichkeiten, dann senden Sie bitte die Mail ab. Es ist nicht echt. Es

00:30:32.090 --> 00:30:37.150
ist eine gefälschte Mail. Un dann ist da noch die 3. Option, bei der es sich um eine Software

00:30:37.150 --> 00:30:42.690
handelt, die für die Testphase gedacht ist. Wenn Sie also gerade mit der Implementierung von

00:30:42.690 --> 00:30:47.730
SPF beginnen, könnte es welche geben. Problematisch könnte sein, dass Sie vergessen,

00:30:47.730 --> 00:30:52.750
einige SMTP-Server hinzuzufügen. Weil Sie das noch nicht getan haben, denken Sie vielleicht,

00:30:52.750 --> 00:30:56.360
Sie haben nur einen SMTP-Postausgangsserver. Aber in Wirklichkeit haben Sie tatsächlich

00:30:56.360 --> 00:31:03.600
mehrere Möglichkeiten, E-Mail zu senden. Wenn Sie in diesem Fall beginnen würden, den

00:31:03.600 --> 00:31:07.230
oben genannten SPF-Eintrag mit der "Fail"-Strong-Richtlinie festzulegen, könnten Ihre

00:31:07.230 --> 00:31:13.460
Benutzer die Nachricht nicht mehr senden. Deshalb ist das Testen gut. Hier sind einige

00:31:13.460 --> 00:31:16.400
andere Beispiele, die etwas komplizierter sind. Eines davon wurde aufgenommen. Anstatt also

00:31:16.400 --> 00:31:19.270
die Richtlinie selbst zu definieren, weil Sie in diesem Beispiel einen Drittanbieter verwenden,

00:31:19.270 --> 00:31:24.720
zum Beispiel Google, dann schließen Sie einfach das ein, was Google veröffentlicht hat. Und das

00:31:24.720 --> 00:31:31.530
Interessante daran ist de Verwendung von SPF. Wenn wir uns nur die Anzahl der Domains

00:31:31.530 --> 00:31:36.890
ansehen, die eine Art Richtlinie definiert haben, dann sieht die Zahl ziemlich gut aus. Ich denke,

00:31:36.890 --> 00:31:42.290
das gilt zum Beispiel für die beliebtesten Domains, ungefähr 70 %. Aber das Problem

00:31:42.290 --> 00:31:45.710
ist, dass die meisten von ihnen entweder schlecht konfiguriert sind, oder nur die Softfail-

00:31:45.710 --> 00:31:51.790
Option benutzen. Und was die Softfail praktisch tut, ist nichts. Auch wenn es eine Richtlinie für

00:31:51.790 --> 00:31:56.700
Softfail gibt, können Sie in den meisten Fällen Ihre E-Mail fälschen und sie wird trotzdem

00:31:56.700 --> 00:32:00.720
ankommen, weil der Empfänger denkt, dass sie sich nur im Testmodus befindet. Sie sollten E-

00:32:00.720 --> 00:32:07.940
Mails nicht automatische löschen. Ja. Eigentlich ist der Prozentsatz nicht so groß. Aber das

00:32:07.940 --> 00:32:13.910
Wichtigste für uns als Penetrationstester ist es, dies zu verstehen. Was sollen wir also tun, wenn

00:32:13.910 --> 00:32:18.420
wir diese SPF sehen? Bedeutet das, dass wir jetzt keine E-Mail mehr fälschen können? Nein,

00:32:18.420 --> 00:32:24.670
das bedeutet es nicht. Damit ist das Spiel für uns vorbei. Wir können einige Sachen tun.

00:32:24.670 --> 00:32:30.060
Also zunächst einmal ist diese Softtail, die ich erwähnt habe. Und dass bedeutet im Grunde,

00:32:30.060 --> 00:32:33.830
dass Sie einige Regeln, Regeln, Regeln haben und am Ende setzen Sie typischerweise nur

00:32:33.830 --> 00:32:41.460
diese Softfail ein. Falls wir als Penetrationstester also versuchen, von einer unbekannten IP-

00:32:41.460 --> 00:32:46.330
Adresse aus zu fälschen, die nicht in den vorherigen Regeln aufgeführt ist, dann tun sie

00:32:46.330 --> 00:32:51.520
nichts. Machen Sie nichts. Ich meine, lassen Sie keine E-Mail fallen. Das ist doch gut für uns,

00:32:51.520 --> 00:32:56.720
oder? Das bedeutet, dass wir tatsächlich auf die gleiche Art und Weise fälschen können und es

00:32:56.720 --> 00:33:02.250
wird meistens funktionieren. Eine Anmerkung hier ist, dass einige Systeme nicht nur diese

00:33:02.250 --> 00:33:06.590
binäre Klassifikation benutzen, egal ob etwas gut oder schlecht ist, sondern sie versuchen

00:33:06.590 --> 00:33:11.320
eine Bewertung vorzunehmen. Und dann kann es sein, dass Sie, Ihre E-Mail nicht automatisch

00:33:11.320 --> 00:33:16.370
löschen, obwohl Sie diese Softfail haben. Aber vielleicht fügen Sie ihr eine verdächtige Ebene

00:33:16.370 --> 00:33:22.540
hinzu. Aber wichtig ist, das es nicht automatisch zu Ende ist.

00:33:22.540 --> 00:33:29.970
Eine andere Sache ist dieses Include. Also Include ist sehr praktisch, wenn man mit

00:33:29.970 --> 00:33:36.330
Drittparteien arbeitet. Aber das Problem ist, dass es für einige Leute nicht das ist, was es

00:33:36.330 --> 00:33:43.100
scheint. Zumindest wird im Standard erwähnt, dass es ein schlecht gewählter Name war. Und

00:33:43.100 --> 00:33:48.110
der Grund dafür ist, dass es sich nicht um ein Macro handelt. Um also zu verstehen, was

00:33:48.110 --> 00:33:52.720
passiert, wenn dies eingeschlossen ist, sollten Sie nicht einfach alles von innen kopieren und

00:33:52.720 --> 00:33:58.340
auf der obersten Ebene einfügen. Das ist nicht die Funktionsweise. Es wird versuchen, alle

00:33:58.340 --> 00:34:05.480
darin enthaltenen Prüfungen durchzuführen. Aber wenn dies fehlschlägt, wird die Nachricht

00:34:05.480 --> 00:34:10.250
nicht automatisch gelöscht. Es wird auf die oberste Ebene gehen und versuchen, die

00:34:10.250 --> 00:34:14.510
anderen Regeln auszuführen. Das Problem dabei ist, dass es in 2 der häufigsten Fälle,

00:34:14.510 --> 00:34:20.570
entweder vergessen hat, dieses Minus zu ergänzen, oder Ihr Administrator hat es

00:34:20.570 --> 00:34:26.470
vergessen. In diesem Fall, selbst wenn Sie dieses Minus eingeschlossen haben, wird es

00:34:26.470 --> 00:34:34.089
nicht funktionieren. Ich denke, dass es funktionieren würde, weil, wenn der Empfänger

00:34:34.089 --> 00:34:39.569
es mit "Minus" überprüft hat, "all inside include" nicht dasselbe bedeutet wie auf der obersten

00:34:39.569 --> 00:34:43.799
Ebene. Und das Zweite wäre, wenn Sie alles außer der Software hinzugefügt hätten. Und

00:34:43.799 --> 00:34:47.809
einige Admins könnten das denken. Aber das ist okay, weil ich Gmail mit einbeziehe, und GMail

00:34:47.809 --> 00:34:54.409
diesen schwerwiegenden Fehler hat. Auf diesem Weg funktioniert es nicht. Und dann

00:34:54.409 --> 00:35:00.000
ist, glaube ich vielleicht der häufigste Fall, dass man oft diese Art von SPF-Einträgen sieht. Aber

00:35:00.000 --> 00:35:03.569
da ist viel Zeug in den IP-Adressen. Es gibt diese A-Rekorde, es gibt einen MX. Es gibt einen

00:35:03.569 --> 00:35:07.890
Zeiger. Im Grund genommen alles, was den Administratoren einfällt und der Grund dafür

00:35:07.890 --> 00:35:12.990
ist, dass sie einfach nicht sicher sind, wie es funktioniert. Sie wissen nicht, was sie eingeben

00:35:12.990 --> 00:35:17.100
sollen. Eine Sache, die darauf hinweist, ist zum Beispiel,

00:35:17.100 --> 00:35:24.840
ob es einen MX-Eintrag im SPF gibt. Die meisten Organisationen, sofern sie nicht sehr klein sind

00:35:24.840 --> 00:35:27.930
und nur einen Server haben, haben verschiedene Server, verschiedene IP-Adressen

00:35:27.930 --> 00:35:31.059
für ausgehende Mails und für eingehende Mails. Das heißt, dass es für Organisationen

00:35:31.059 --> 00:35:34.500
keinen praktischen Grund gibt, MX in SPF aufzunehmen, denn keine E-Mail sollte durch

00:35:34.500 --> 00:35:41.109
ihren Posteingangsserver werden. Und ein anderer Fall könnte sein, dass die

00:35:41.109 --> 00:35:45.900
Administratoren verstehen, wie es funktioniert. Ihre Architektur ist aber wirklich

00:35:45.900 --> 00:35:51.470
chaotisch und sie senden E-Mails von vielen, vielen unterschiedlichen Stellen senden, was

00:35:51.470 --> 00:35:55.730
für Penetrationstester gut ist.

00:35:55.730 --> 00:36:03.359
Das bedeutet, dass sie nicht gut organisiert sind. OK. Und dann gibt es noch einen

00:36:03.359 --> 00:36:09.220
Schwachpunkt, der darin besteht, dass die Granularität nicht sehr gut geeignet ist. Das

00:36:09.220 --> 00:36:13.799
einzige, was Sie tun können, sind mehrere dieser Datensatztypen. Aber alles was sie tun,

00:36:13.799 --> 00:36:19.650
ist die Auflösung der IP-Adresse. Aber wie Sie sich vorstellen können. ist die IP in vielen Fällen

00:36:19.650 --> 00:36:24.230
nicht nur mit dem Mailserver verknüpft. Auf einer IP kann möglicherweise ein Mailserver

00:36:24.230 --> 00:36:28.069
und eine Webserver oder eine Datenbank oder etwas anderes vorhanden sein. Das bedeutet,

00:36:28.069 --> 00:36:32.339
dass Sie als Penetrationstester dieses ausnutzen können. Nicht den Mailserver selbst,

00:36:32.339 --> 00:36:36.740
denn der Mailserver ist üblicherweise ziemlich unauffällig. Es gibt nicht viele Schwachstellen.

00:36:36.740 --> 00:36:42.740
Sie können sie einfach ausbessern, und das wars. Aber diese anderen Systeme, zum

00:36:42.740 --> 00:36:46.680
Beispiel das Web, lassen sich in den meisten Fällen leicht ausnutzen. In gewisser Weise kann

00:36:46.680 --> 00:36:50.809
man die Privilegien erhöhen, indem man sich Zugriff verschafft auf einem anderen Server mit

00:36:50.809 --> 00:36:59.859
dieser IP-Adresse oder IP-Bereich. Sie können mit dem Versenden von E-Mails beginnen. Sie

00:36:59.859 --> 00:37:04.950
werden alle SPF-Filter passieren. OK. Ein Beispiel ist "Shared Hosting", was sehr häufig

00:37:04.950 --> 00:37:10.359
der Fall ist. Das Problem besteht darin, dass Sie in diesem Fall eine IP des SMTP-Servers haben.

00:37:10.359 --> 00:37:15.900
Vielleicht ist das ein Server, der nur zum Versenden von E-Mails verwendet wird. Aber

00:37:15.900 --> 00:37:18.849
der Server selbst arbeitet nicht nur für Sie. Er arbeitet für viele Domains, vielleicht Hunderte

00:37:18.849 --> 00:37:24.289
bis Tausende. Das heißt, als Angreifer könne Sie mindestens einen von ihnen ausnutzen, oder

00:37:24.289 --> 00:37:26.940
für Shared Hosting kaufen. Sie können Kunde dieses Shared Hosting werden. Sie müssen

00:37:26.940 --> 00:37:31.750
nicht einmal etwas nutzen. Und dann können Sie möglicherweise eine E-Mail starten, die in

00:37:31.750 --> 00:37:38.140
Bezug auf SPF genauso gut aussieht, wie die eigene. Und das andere ist die falsche

00:37:38.140 --> 00:37:44.960
Überprüfung. Und das ist wahrscheinlich das schlimmste Problem mit SPF. Es gibt, wie ich

00:37:44.960 --> 00:37:49.640
bereits erwähnt habe, mindestens 2 Identifikatoren. Der Umschlagabsender, der

00:37:49.640 --> 00:37:53.740
externe also, der den Absender angibt. Und dann gibt es eine interne, die normalerweise

00:37:53.740 --> 00:37:58.589
die "Von" Kopfzeile ist. Aber von diesen beiden überprüft SPF nur, ob SPF die einzige

00:37:58.589 --> 00:38:03.140
Technologie ist, die Sie verwenden. SPF überprüft nur den ersten: den Umschlag-

00:38:03.140 --> 00:38:09.059
Absender. Und wie ich bereits erwähnt habe, sehen tatsächliche Benutzer, die die E-Mail

00:38:09.059 --> 00:38:13.279
erhalten, in den meisten Fällen keinen Umschlag-Absender. Sie werden

00:38:13.279 --> 00:38:17.559
beispielsweise dies sehen und eine "Von" oder eine der anderen Kopfzeilen. Dieses Verhalten

00:38:17.559 --> 00:38:22.830
wird tatsächlich durch DMARC behoben, was die Technologie ist, die ich erwähnt habe. Aber

00:38:22.830 --> 00:38:27.319
die Mehrheit der SPF-Installationen, Domains, die SPF nutzen, haben kein DMARC. Also sind

00:38:27.319 --> 00:38:31.329
dadurch nicht geschützt. Selbst wenn deren SPF großartig für Angreifer ist, bedeutet das, dass

00:38:31.329 --> 00:38:36.630
Sie zum Weitergeben von SPF nur den Umschlag-Absender auf etwas anderes setzen.

00:38:36.630 --> 00:38:40.430
Zum Beispiel Ihre eigene kontrollierte Adresse, die alle SPF-Prüfungen bestehen wird. Aber

00:38:40.430 --> 00:38:49.010
dann können Sie die Kopfzeile innerhalb der "Von"-Adresse sehen, der mit der Organisation

00:38:49.010 --> 00:38:56.776
übereinstimmt, die Sie vorgeben wollen zu sein. Okay, Dann gibt es eine andere Technologie, die

00:38:56.776 --> 00:39:02.309
dies beheben soll und das ist DKIM. Wie wir gesehen haben, reicht SPF nicht aus. Also DKIM.

00:39:02.309 --> 00:39:11.450
Sorry für die Abkürzungen. Es heißt: Domainkeys identified mail. Sie müssen sich

00:39:11.450 --> 00:39:15.099
den langen Namen nicht Mehrken, nur die Abkürzung. Und was es im Grunde genommen

00:39:15.099 --> 00:39:20.223
macht, es verwendet Kryptographie, was schön ist, oder? Es ist Mathematik. Es ist für Angreifer

00:39:20.223 --> 00:39:24.640
schwer zu knacken. Es signiert jede Email, sodass jede E.Mail, die über den DKIM

00:39:24.640 --> 00:39:29.870
aktivierten Server versendet wird, eine Signatur erhält, die Sie als Empfänger kryptographisch

00:39:29.870 --> 00:39:35.059
verifizieren können. Wie Sie sehen können, ist es eigentlich ziemlich schwierig zu sehen, weil

00:39:35.059 --> 00:39:39.940
es nicht dafür gedacht ist, von Menschen verarbeitet zu werden. Es handelt sich um

00:39:39.940 --> 00:39:44.160
Kryptographie. Sie ist dafür gedacht, von Computern verarbeitet zu werden. Aber der

00:39:44.160 --> 00:39:48.300
wichtige Teil hier ist im Grunde, dass das gelbe Zeug diese kryptische Signatur ist. Aber er

00:39:48.300 --> 00:39:55.880
grüne Teil ist das, was man Domain-Erkennung nennt. Und den roten Teil nennt man - ich weiß

00:39:55.880 --> 00:40:02.269
es nicht mehr. Lachen! Aber im Grund ist es eine Idee, dass Sie mehrere Schlüssel für Ihre

00:40:02.269 --> 00:40:07.160
Organisation haben können, zum Beispiel könnte die Organisation E-Mails von Ihrem

00:40:07.160 --> 00:40:12.390
ursprünglichen SMTP-Server senden und dann können Sie einen Backup-Server haben, oder

00:40:12.390 --> 00:40:17.650
Sie haben vielleicht einige Nachrichten von Google oder eine Marketingkampagne und

00:40:17.650 --> 00:40:21.759
so weiter. Und dann könnte jede von ihnen unterschiedliche "Rot"-Parameter haben. Das

00:40:21.759 --> 00:40:26.970
Problem ist, dass der Empfänger dann eine DNS-Abfrage ausführen, was das 2. Beispiel ist,

00:40:26.970 --> 00:40:32.532
bei dem diese Kombination aus grün und rot verwendet wird. Und dann erhalten Sie den

00:40:32.532 --> 00:40:36.993
öffentlichen Schlüssel und können diesen verwenden, um die Signatur zu überprüfen.

00:40:36.993 --> 00:40:43.799
Das hört sich also wirklich gut an. Das Problem hier ist, dass es noch ein anderes Problem gibt.

00:40:43.799 --> 00:40:48.730
Wie man löst man es? Ich denke, es ist einfach, wenn man die öffentliche Kryptographie.

00:40:48.730 --> 00:40:52.440
versteht. Auf der Absenderseite müssen Sie zuerst ein öffentliches und ein privates

00:40:52.440 --> 00:40:56.270
Schlüsselpaar generieren. Dann veröffentlichen Sie den öffentlichen Teil im DNS. Dann

00:40:56.270 --> 00:41:00.480
verwenden Sie den privaten Schlüssel, um jede Nachricht zu signieren. Der Empfänger macht

00:41:00.480 --> 00:41:04.380
jetzt sozusagen das Gegenteil. Sobald er die E-Mail erhalten hat, findet er anhand dieses roten

00:41:04.380 --> 00:41:09.000
und grünen Teils den richtigen DNS-Eintrag heraus, führen ihn aus, erhalten den

00:41:09.000 --> 00:41:12.526
öffentlichen Schlüssen und vergleichen dann, ob dieser öffentliche Schlüssel mit der Signatur

00:41:12.526 --> 00:41:19.170
übereinstimmt. Das klingt doch ganz gut, oder? Was ist das Problem? Also wählt der Kunde den

00:41:19.170 --> 00:41:27.309
Namen aus, Das Problem dabei ist, dass es mehrere Selektoren als DKIM sein können,

00:41:27.309 --> 00:41:31.670
wenn Sie die Konfiguration durchführen. Sie können so viele Selektoren auswählen, wie Sie

00:41:31.670 --> 00:41:37.170
wollen und der Empfänger weiß nicht, ob Sie tatsächlich einen Selektor hätten verwenden

00:41:37.170 --> 00:41:41.599
sollen und welchen Selektor Sie hätten verwenden sollen. Das Problem liegt darin, dass

00:41:41.599 --> 00:41:48.690
wenn wir nur über das normale DKIM sprechen, es für einen Penentrationstester oder einen

00:41:48.690 --> 00:41:52.630
Angreifer schwierig ist, die vorhandene Signatur zu ändern. Aber es ist einfach, es zu entfernen.

00:41:52.630 --> 00:41:57.619
Denn wenn man DKIM aus allen Kopfzeilen entfernt hat, weiß der Empfänger nicht, dass

00:41:57.619 --> 00:42:03.550
sie da sein sollte, denn um das zu prüfen, müsste sie dort sein. Hier also zum Beispiel,

00:42:03.550 --> 00:42:08.640
muss ich, statt die Signatur zu überprüfen, diesen grünen Teil kennen. Diese Domain-

00:42:08.640 --> 00:42:14.712
Kennung und den Selektor, die Teil dieser Kopfzeile sind. Richtig. Das ist also ein großes

00:42:14.712 --> 00:42:20.818
Problem. Und das bedeutet, dass wir, obwohl wir DKIM selbst nicht fälschen können, können

00:42:20.818 --> 00:42:26.700
wir die DKIM einfach abschneiden und die Nachricht ohne sie senden. Und falls die DKIM

00:42:26.700 --> 00:42:31.499
das Einzige wäre, das das System geschützt hat, würde es funktionieren. Es könnte also sein,

00:42:31.499 --> 00:42:37.310
dass es kein grünes Häkchen oder was auch immer gibt, aber es wird beim Empfänger

00:42:37.310 --> 00:42:43.040
ankommen. Eine andere Sache ist dieser Domain-Selektor. Warum müssen wir das

00:42:43.040 --> 00:42:48.280
überhabt einstellen? Weil die beste Übung natürlich ist, dass der Umschlag-Absender

00:42:48.280 --> 00:42:52.430
gleich der Kopfzeile und gleich diesem DKIM Domain-Sektor ist. Wenn Sie also von Alice

00:42:52.430 --> 00:42:59.029
senden, dann sind alle drei Alice.org oder was auch immer. Das Problem ist, dass es im RFC

00:42:59.029 --> 00:43:04.029
nicht erwähnt wird, dass dies der Fall sein sollte. Was also passiert genau, wenn es nicht

00:43:04.029 --> 00:43:09.619
so ist? Zum Beispiel gibt es auf der rechten Seite eine echte Domain, die Gmail, Google

00:43:09.619 --> 00:43:17.470
Mail, Google Suite verwendet hat. In diesem Fall signiert Google Suite standardmäßig alle

00:43:17.470 --> 00:43:22.430
Nachrichten. Wenn Sie jedoch keine eigene Konfiguration vornehmen, wird sie signiert mit

00:43:22.430 --> 00:43:28.369
der von ihm kontrollierten Domain "gappssmtp". Und das bedeutet, dass, obwohl

00:43:28.369 --> 00:43:32.579
technisch gesehen etwas mit DKIM signiert wurde, es aber nicht so signiert wurde, dass

00:43:32.579 --> 00:43:36.406
man es zu seiner Organisation zurückführen kann. Es ist etwas völlig anderes. Was genau

00:43:36.406 --> 00:43:40.069
sollte der Empfänger in diesem Fall tun? Sollten Sie es einfach ignorieren? Sollten Sie die

00:43:40.069 --> 00:43:43.859
Nachricht zurückweisen oder etwas ähnliches? Der richtige Weg wäre also, sie nicht

00:43:43.859 --> 00:43:49.380
abzulehnen, sondern sie einfach als ungültig, zumindest nicht als gültige DKIM zu betrachten,

00:43:49.380 --> 00:43:53.829
aber es kommt darauf an. Also werden einige Validierer, sobald sie irgendeine DKIM sehen,

00:43:53.829 --> 00:44:01.228
diese validieren und sagen, das ist cool, das entspricht dem RFC. Aber nun kommt der

00:44:01.228 --> 00:44:06.710
interessante Teil. Ändern von DKIM, wofür ich keine Zeit habe. Aber die Idee ist, dass dies in

00:44:06.710 --> 00:44:11.339
manchen, nicht in allen Fällen so ist, aber manchmal kann man es tatsächlich ändern.

00:44:11.339 --> 00:44:17.190
Der am einfachsten zu ändernde Teil in den Nachrichten sind die Kopfzeilen. Weil DKIM,

00:44:17.190 --> 00:44:21.304
da es in den Kopfzeilen selbst platziert ist, nicht automatisch alte Kopfzeilen signiert. Das ist wie

00:44:21.304 --> 00:44:26.170
das Henne-Ei-Problem. Es werden standardmäßig nur 1 oder 2 Kopfzeilen signiert

00:44:26.170 --> 00:44:30.910
und Sie können weitere Kopfzeilen angeben, die signiert werden sollen, aber das passiert nicht

00:44:30.910 --> 00:44:35.569
automatisch. Für den Angreifer ist es eine einfache Sache, eine andere Kopfzeile

00:44:35.569 --> 00:44:40.400
hinzuzufügen. Wenn das Ihrem Plan in irgendeiner Weise hilft, dann ist das einfach

00:44:40.400 --> 00:44:43.940
zu machen. Sie fügen einfach eine weitere Kopfzeile hinzu. Ein interessante Teil ist, obwohl

00:44:43.940 --> 00:44:49.180
obwohl RFC, ist, wie ich vorhin erwähnt habe, dass einige Kopfzeilen wie "Gegenstand" oder

00:44:49.180 --> 00:44:53.093
"Von", nur in einer Kopie vorhanden sein sollten. Aktuell könnte man mehr, als eine

00:44:53.093 --> 00:44:59.367
"Von" Kopfzeile hinzufügen. Was in diesem Fall passiert ist ziemlich interessant. DKIM wird

00:44:59.367 --> 00:45:04.150
einverstanden sein, wenn Sie DKIM mitteilen, dass die Kopfzeile "Von" beispielsweise signiert

00:45:04.150 --> 00:45:11.279
werden soll. Dann wird es übereinstimmen und signiert die erste "Von" Kopfzeile von unten.

00:45:11.279 --> 00:45:16.807
Aber ziemlich viele Software E-Mail Kunden in einer Software werden dem Benutzer eigentlich

00:45:16.807 --> 00:45:23.940
nur zuerst von der anderen Seite, der oberen Seite angezeigt. Das bedeutet also, dass der

00:45:23.940 --> 00:45:29.546
Angreifer die Kopfzeilen verfälschen oder überschreiben kann, indem er einfach neue

00:45:29.546 --> 00:45:33.089
Kopfzeilen hinzufügt. Und dieses eigentliche Problem wird im DKIM RFC erwähnt und der

00:45:33.089 --> 00:45:38.885
Schutz, den sie vorschlagen ist dieser Code Over-Signing, damit Sie den RFC lesen können.

00:45:38.885 --> 00:45:44.919
Aber nicht jeder macht das tatsächlich. Und wie auch immer, gilt das nur für die Kopfzeilen.

00:45:44.919 --> 00:45:49.499
Manchmal ist das also gut. Manchmal ist das nicht gut. Ändern des Nachrichtentextes ist

00:45:49.499 --> 00:45:54.069
tatsächlich viel schwieriger. Im Grunde genommen ist die naive Art es zu tun durch

00:45:54.069 --> 00:45:58.140
Kryptographie, was wir aber nicht tun wollen. Und ein anderer Weg führt über diesen

00:45:58.140 --> 00:46:05.118
Parameter, der die Textkörperlänge angibt und das ist eigentlich wie fragwürdig die

00:46:05.118 --> 00:46:08.789
Funktionalität ist, die DKIM hat. Manchmal kann man festlegen, dass der Hash für Signierung-

00:46:08.789 --> 00:46:13.790
zwecke verwendet werden soll. Wir sollten nicht den ganzen Körper betrachten, sondern nur die

00:46:13.790 --> 00:46:18.866
ersten Bytes. Das ist in einigen Fällen bei Mailinglisten tatsächlich nützlich, aber in den

00:46:18.866 --> 00:46:24.500
meisten Fällen nicht nützlich. Die meisten E-Mail-Programme tun dies in der Praxis nicht.

00:46:24.500 --> 00:46:28.869
Falls sie es tun, besteht die Gefahr, dass der Textkörper möglicherweise überschrieben wird.

00:46:28.869 --> 00:46:34.245
Sie können einen anderen Mime-Typ hinzufügen und dann die Kopfzeilen ändern,

00:46:34.245 --> 00:46:37.569
um zu zeigen, dass dieser andere Mime-Typ DKIM passieren wird. In diesem Fall wird zum

00:46:37.569 --> 00:46:42.634
Beispiel der grüne Button oder was auch immer angezeigt, weil DKIM gültig sein wird. Nun gibt

00:46:42.634 --> 00:46:47.640
es also die 3. Technologie, die DMARC genannt wird. Und auch hier steht der vollständige

00:46:47.640 --> 00:46:52.424
Name, der lang ist, aber in diesem Fall tatsächlich etwas bedeutet. Es gibt 2 Schlüssel-

00:46:52.424 --> 00:46:56.660
wörter: Berichterstattung und Konformität. Berichterstattung ist das Wort, mit dem die

00:46:56.660 --> 00:47:01.619
meisten Administratoren vertraut sind, denn das ist es, was DMARC meiner Meinung oft an

00:47:01.619 --> 00:47:08.390
sie verkauft. Berichterstattung bedeutet, dass man bei Problemen in diesem Fall, der anderen

00:47:08.390 --> 00:47:13.309
Seite sagen kann, was in diesem Fall zu tun ist. Grundsätzlich sagen Sie Ihnen, dass Sie Ihnen

00:47:13.309 --> 00:47:16.886
entweder einmal am Tag oder jedes Mal Berichte senden sollen. Für Penetrationstester

00:47:16.886 --> 00:47:20.509
ist das nicht sehr nützlich. Möglicherweise könnten wir verwenden, um zu verstehen,

00:47:20.509 --> 00:47:25.000
welche Art von Konfiguration auf der anderen Seite läuft. Aber im Moment ist diese Funktion

00:47:25.000 --> 00:47:30.309
noch nicht so weit verbreitet. Aber der andere Teil, die Konformität, ist wirklich sehr, sehr

00:47:30.309 --> 00:47:35.251
leistungsstark. Es korrigiert die großem Fehler, die ich in SPF und DKIM erwähnt habe. DKIM

00:47:35.251 --> 00:47:39.381
hatte dieses massive Problem, dass wenn man einfach die Kopfzeilen entfernt, dann hat der

00:47:39.381 --> 00:47:43.109
Empfänger keine Möglichkeit zu wissen, ob DKIM an erster Stelle stehen sollte. Wenn Sie

00:47:43.109 --> 00:47:49.377
DKIM zusammen mit DMARC verwenden, ist das Problem behoben, denn DMARC gibt nur

00:47:49.377 --> 00:47:55.269
an, dass Sie DMARC selbst haben. Das bedeutet, dass Sie automatisch mindestens

00:47:55.269 --> 00:47:59.220
eines von SPF oder DKIM passieren sollte. Also hat DKIM als Maßnahme das Problem

00:47:59.220 --> 00:48:03.576
automatisch gelöst. Die andere Sache, die sich ändert, ist die Änderung Semantik für SPF.

00:48:03.576 --> 00:48:08.599
Falls Sie nun beide, SPF und DMARC haben, könnte SPF gegen die "Von" Kopfzeile sein.

00:48:08.599 --> 00:48:13.150
Wie ich schon anmerkte, war das die größte Schwachstelle von SPF, denn wenn Sie selbst

NOTE Paragraph

00:48:13.150 --> 00:48:17.319
SPF selbst verwenden, war es sogar der Hard-to-Fail-Modus usw. Das bedeutet, dass

00:48:17.319 --> 00:48:21.440
Angreifer die "Von" Kopfzeilen immer noch modifizieren können und der Empfänger wird

00:48:21.442 --> 00:48:26.710
es nicht besser wissen. Ein minimales Beispiel für DMARC ist also wirklich sehr, sehr klein.

00:48:26.710 --> 00:48:31.210
Und ich denke, es ist einfach zu verstehen. Sie haben gerade eine DMARC Ablehnung. Sie müssen

00:48:31.210 --> 00:48:36.890
die richtige Stelle für die Angabe herausfinden. Aber es ist einfach und alles, was Sie tun müssen, ist

00:48:36.890 --> 00:48:40.740
diesen einen DNS-Eintrag zu erstellen. Und der Vorteil davon bestseht darin, wenn Sie DKIM

00:48:40.740 --> 00:48:46.190
und DMARC nicht haben, wenn Sie es erstellt haben. Sorry, falls Sie DKIM nicht haben, aber Sie

00:48:46.190 --> 00:48:50.680
haben DMARC erstellt. Das bedeutet, dass diese Domain keine E-Mails senden soll.

00:48:50.680 --> 00:48:57.550
Denn der Empfänger sieht eine E-Mail als gültig an, sollte mindestens SPF oder DKIM gültig

00:48:57.550 --> 00:49:02.279
sein. Wenn dies nicht der Fall ist, können sie nicht gültig sein. Das bedeutet also, dass die

00:49:02.279 --> 00:49:07.480
meisten Domains da draußen darüber nachdenken sollten, die DMARC zu aktivieren.

00:49:07.480 --> 00:49:15.471
Das ist genau das Richtige. OK. Es gibt noch mehr Stichworte. Die DMARC-Datensätze könnten viel

00:49:15.471 --> 00:49:22.019
länger sein, aber es ist für die Penetratrionstester nicht von großem Nutzen.

00:49:22.019 --> 00:49:26.009
So, ein wichtiger Teil hier ist wieder die Richtlinie, die diese drei Werte annehmen kann:

00:49:26.009 --> 00:49:31.184
"keine", "Quarantäne" und "Ablehnung".Und wenn es "Quarantäne" ist, bedeutet das,

00:49:31.184 --> 00:49:39.109
dass die Nachricht im Falle eines Fehlers, im Spam-Ordner landen sollte.

00:49:39.109 --> 00:49:42.619
Wenn es "Ablehnung" ist, sollte sie direkt abgewiesen werden. Und wenn es "keine" ist, bedeutet es,

00:49:42.619 --> 00:49:47.960
dass sie sich im Test-Modus befindet. Und das ist das Bild, das ich vorher gezeigt habe.

00:49:47.960 --> 00:49:52.400
Es zeigt dass, obwohl DMARC die wirklich beste Technologie unter diesen 3 Technologien ist.

00:49:52.400 --> 00:49:59.655
Sie ist nicht wirklich weit verbreitet. Unglücklicherweise für die Befürworter.

00:49:59.655 --> 00:50:05.070
Eine ganz nette Tasche für alle Penetrationstester da draußen. Das bedeutet, dass man

00:50:05.070 --> 00:50:14.550
tatsächlich die meisten E-Mails da draußen fälschen kann. Okay. Wie können wir das umgehen?

00:50:14.550 --> 00:50:18.480
Was passiert, wenn jemand DMARC implementiert hat? Können Penetrationstester nun nichts tun?

00:50:18.480 --> 00:50:23.526
nichts tun? Sie müssen nicht einmal Nachforschungen anstellen?

00:50:23.526 --> 00:50:29.039
Nein, das ist nicht nötig. Also in der Praxis, wenn jemand sowohl DKIM als auch DMARC

00:50:29.039 --> 00:50:33.859
implementiert hat, aber nicht SPF, also hat er nur zwei davon. Das ist wirklich eine coole Kombination.

00:50:33.859 --> 00:50:38.470
DKIM ist sehr leistungsstark und DMARC behebt den Mangel. Das ist cool in der Theorie.

00:50:38.470 --> 00:50:44.680
In der Praxis besteht das Problem darin, statt ihre eigenen E-Mails zu schützen, sollte die

00:50:44.680 --> 00:50:49.751
Empfängerseite sowohl DKIM, als DMARC validieren. Unglücklicherweise tut dies eine

00:50:49.751 --> 00:50:53.932
ganze Menge von Software immer noch nicht Eine solche Software ist Microsoft Exchange.

00:50:53.932 --> 00:50:57.920
Und selbst wenn Sie nicht mit Microsoft Exchange arbeiten, stehen die Chancen gut, dass

00:50:57.920 --> 00:51:02.049
einige der Partner, mit denen Sie kommunizieren, Microsoft Exchange ausführen.

00:51:02.049 --> 00:51:05.700
Und standardmäßig gibt es keine Funktion zu DKIM.

00:51:05.700 --> 00:51:12.619
Die meisten Systeme müssen tatsächlich SPF immer noch aus praktischen Gründen aktivieren.

00:51:12.619 --> 00:51:16.609
Das ist gut für Penetrationstester. Wenn SPF und DMARC standardmäßig zusammen

00:51:16.609 --> 00:51:21.502
aktiviert sind, dann behebt das wiederum eines der Hauptprobleme mit SPF, aber

00:51:21.502 --> 00:51:25.864
es behebt nicht automatisch andere Probleme, weil nicht genug Potential für Fehlkonfigurationen

00:51:25.864 --> 00:51:32.119
da ist. So. Und die interessante Tatsache ist, dass DMARC nur fordert, dass eine der anderen

00:51:32.119 --> 00:51:37.970
Technologien SPF oderDKIM mitgegeben wird, um die E-Mail als gültig zu sehen.

00:51:37.970 --> 00:51:42.749
Es gibt in DMARC keine Möglichkeit anzugeben, dass beide gültig sein sollen, oder dass DKIM

00:51:42.749 --> 00:51:45.680
dem SPF vorgezogen werden soll, obwohl es viele andere Sektoren gibt.

00:51:45.680 --> 00:51:50.019
In der Praxis bedeutet dies, dass die meisten Systeme alle drei aktivieren,

00:51:50.019 --> 00:51:54.950
was eine gute praktische Lösung von Seiten der Penetrationstester ist.

00:51:54.950 --> 00:51:59.849
Wir ignorieren DKIM komplett und konzentrieren uns nur auf SPF, was das schwächste Glied in

00:51:59.849 --> 00:52:05.170
dieser Situation ist. Okay. Also nur eine Minute für Rekapitulation.

00:52:05.170 --> 00:52:11.559
Ich bin nicht sicher, ob ich noch mehr Zeit habe. Viel Zeit habe ich nicht. Okay.

00:52:11.559 --> 00:52:17.140
Okay. Entschuldigung. Yeah. Ein wirklich wichtiger Hinweis ist, wenn man die Systeme testet,

00:52:17.140 --> 00:52:22.270
dass beide Szenarien berücksichtigt werden sollen. Konzentrieren Sie sich also nicht

00:52:22.270 --> 00:52:27.599
nicht nur auf das Senden. Wenn es um das Testen von Alice geht, ist Alice die Organisation, die Ihr

00:52:27.599 --> 00:52:33.569
Kunde ist. Konzentrieren Sie sich nicht nur auf das Testen von E-Mails, die als Alice versendet

00:52:33.569 --> 00:52:38.670
werden, sondern auch auf die andere Seite. Denn es ist einfach, z.B. SPF und DMARC zu

00:52:38.670 --> 00:52:43.961
implementieren, denn für beide brauchen Sie nur eine DNS-Konfiguration. Gerade eine für

00:52:43.961 --> 00:52:48.779
jede. Aber sie zu testen, sie richtig zu validieren ist schwieriger.

00:52:48.779 --> 00:52:52.643
Zunächst benötigen Sie die Software-Unterstützung, die man richtig konfigurieren muss.

00:52:52.643 --> 00:52:56.585
In der Praxis könnte es sein, dass viele Organisationen, die DMARC oder SPF auf der

00:52:56.585 --> 00:53:01.500
DNS-Seite für ausgehende E-Mailsaktiviert haben, es nicht richtig validieren.

00:53:01.500 --> 00:53:07.960
Yeah Okay. Sorry ich habe keine Zeit dafür.

00:53:07.960 --> 00:53:16.009
Das wars. Sorry. Vielleicht einige Fragen.

00:53:16.009 --> 00:53:24.601
Applaus

00:53:24.601 --> 00:53:29.719
Herald: Danke Andrew für diesen schönen Vortrag. Natürlich haben wir Zeit für ein paar Fragen.

00:53:29.719 --> 00:53:33.839
Ich sehe schon eine Person. Mikrophon Nr.2

00:53:33.839 --> 00:53:40.150
M2: Hey, vielen Dank. Kennen Sie einige gute Tools zur Überwachung von DMARC-

00:53:40.150 --> 00:53:44.339
Berichten, die ich von meinen Empfängern bekommen habe? A: Yeah. Das ist eine wirklich gute

00:53:44.339 --> 00:53:49.940
Frage. Wir als CERT empfehlen jedem, dies zu aktivieren. Aber leider sammeln alle Tools, die im

00:53:49.940 --> 00:53:55.190
Internet verbreitet sind, einige Daten über Sie.

00:53:55.190 --> 00:53:59.670
Sie verwenden diese für Marketingzwecke.

00:53:59.670 --> 00:54:04.412
Das ist nicht gut für Ihre Privatsphäre.

00:54:04.412 --> 00:54:07.880
Wenn Sie darüber besorgt sind, müssen Sie selbst etwas implementieren oder

00:54:07.880 --> 00:54:12.180
Sie müssen vielleicht ein Open-Source-Projekt starten. Herald: OK, Mikrophone Nr. 1

00:54:12.180 --> 00:54:16.428
M1: Danke für das gute Gespräch. Ich würde mich selbst als Administrator bezeichnen.

00:54:16.428 --> 00:54:23.609
Mir wird geraten, den SPF-Eintrag zu kürzen, denn wenn er zu lang ist, wird er gelöscht.

00:54:23.609 --> 00:54:28.859
Daher bekomme ich den Rat, den PTR-Eintrag zu löschen.

00:54:28.859 --> 00:54:34.930
Aber in Ihrem Vortrag sagen Sie, dass er für Revers-DNS-Überprüfung nützlich ist,

00:54:34.930 --> 00:54:39.549
was ich auch auch für nützlich halte.

00:54:39.549 --> 00:54:42.920
Wie stehen Sie zu Verkürzung Ihres SPF und zum PTR-Datensatz im Allgemeinen?

00:54:42.920 --> 00:54:47.530
A. Das hängt vom jeweiligen Anwendungsfall ab. Es kann sein, dass einige

00:54:47.530 --> 00:54:51.230
Organisationen tatsächlich diesen langen SPF benötigen und daran

00:54:51.230 --> 00:54:55.799
führt kein Weg vorbei. Was Sie tun können, ist, dieses Include einzuschließen. Verwenden Sie

00:54:55.799 --> 00:55:01.479
Includes, da diese nicht vorhanden sind. Sie sind keine Macros, sie werden nicht erweitert.

00:55:01.479 --> 00:55:07.755
Überlegen Sie, ob Sie wirklich so viele Datensätze brauchen, die so lang sind.

00:55:07.755 --> 00:55:12.119
Häufige Probleme darin, sofern Sie nicht Google oder etwas Ähnliches verwenden,

00:55:12.119 --> 00:55:16.970
benötigen Sie einen so langen SPF nicht wirklich.

00:55:16.970 --> 00:55:20.499
Es ist wahrscheinlich ein Problem mit einigen.

00:55:20.499 --> 00:55:26.660
Ja genau. Es ist wahrscheinlich ein Fehler bei den meisten Organisationen.

00:55:26.660 --> 00:55:36.489
Herald: OK. Nun, sehr. Nur ganz kurz.

00:55:36.489 --> 00:55:40.496
Nummer 1. M1: Aber auf der PTI-Rocker-Platte habe ich gehört, dass es mich dramatisch unter

00:55:40.496 --> 00:55:43.489
den Standards gelandet ist. Aber sie ist nicht in den Standards enthalten .

00:55:43.489 --> 00:55:48.859
A: Er ist im Standard. Nein. Der PTR-Eintrag selbst ist, wenn es wirklich Ihr Anwendungsfall ist.

00:55:48.859 --> 00:55:53.599
Ich bin mir nicht bewusst, dass er automatisch irgendwo abgelegt wird. Müsste kein Problem sein.

00:55:53.599 --> 00:55:56.380
Herald: Wir haben ein Menge weiterer Fragen hier.

00:55:56.380 --> 00:55:59.349
Nummer 6, ganz, ganz hinten.

00:55:59.349 --> 00:56:07.420
M6: Danke für Ihren Vortrag. Das hängt zwar nicht direkt damit zusammen, aber es könnt.

00:56:07.420 --> 00:56:13.800
Falls der Mailserver DKIM, DKARC und SPF akzeptiert, ist alles in Ordnung. Aber vor allem bei

00:56:13.800 --> 00:56:18.779
Google wird die E-Mail bei vielen Organisationen zugestellt, aber als Spam eingestuft.

00:56:18.779 --> 00:56:24.089
Das bedeutet, dass Sie im Posteingang des Empfängers nicht angezeigt wird.

00:56:24.089 --> 00:56:28.069
Haben Sie eine Lösung, um diese Problem gegen Google zu lösen?

00:56:28.069 --> 00:56:33.630
A. Ja, Ok. Also, ich habe verschiedene Meinungen darüber, denn eine Sache, die tatsächlich

00:56:33.630 --> 00:56:38.787
ermöglicht, was wir eigentlich tun sollten, ist, dass Sie so streng sind. Vielen Dank Google.

00:56:38.787 --> 00:56:42.859
Denn das ist der einzige Grund, warum wir überhaupt einen hohen Prozentsatz

00:56:42.859 --> 00:56:47.879
von SPF haben, der selbst falsch konfiguriert ist. Der einzige Grund, warum 70% Webseiten SPF

00:56:47.879 --> 00:56:52.829
verwenden, ist, dass sie mit Google kommunizieren müssen. Und Google wird Ihre E-Mail

00:56:52.829 --> 00:56:56.690
nicht akzeptieren, wenn SPF nicht auf der Grundlinie ist. So.

00:56:56.690 --> 00:57:04.269
Eigentlich macht mir der Job, den ich mache, Spaß. Ich würde es vorziehen, dass Google das tut,

00:57:04.269 --> 00:57:09.527
was es sagt, Ich verstehe die echten Administratoren, die dieses Problem haben. Google hat das

00:57:09.527 --> 00:57:15.239
Werkzeug. Sie kenne es wahrscheinlich. Hier können Sie überprüfen, was es über Ihre

00:57:15.239 --> 00:57:19.323
Domain denkt. Sie müssen dieses Problem also von Fall zu Fall prüfen.

00:57:19.323 --> 00:57:23.559
Oftmals kommt es vor, dass es trotz DKIM,DMARC etc. nicht richtig konfiguriert ist.

00:57:23.559 --> 00:57:28.576
Also ist es das, was es ist. Darum ging es im Vortrag. Sie haben es. und sie denken vielleicht, dass Sie

00:57:28.576 --> 00:57:31.259
es richtig konfiguriert haben, aber es bist einige Fehler.

00:57:31.259 --> 00:57:35.249
Herald: Okay. Geben wir dem Internet den Vorrang.

00:57:35.249 --> 00:57:40.170
Signal Angel: Wir haben eine Frage aus dem Internet. Wenn wir versuchen, eine Adresse zu

00:57:40.170 --> 00:57:43.819
überprüfen, wie wird mit E-Mail-Adressen ohne Antwort umgegangen.

00:57:43.819 --> 00:57:49.999
A. Keine Antwort, Es tut mir leid. Können Sie es bitte noch einmal vorlesen?

00:57:49.999 --> 00:57:55.170
Signal Angel: Wenn ich versuche, eine E-Mail Adresse zu überprüfen, wie geht man

00:57:55.170 --> 00:58:04.529
dann mit No-reply-E-Mails um? A: Vielleicht ging es um die No-reply Kopfzeile?

00:58:04.529 --> 00:58:10.650
Oder nicht vorhandene IP-Adressen? Signal Angel: Wie geht man mit E-Mails um?

00:58:10.650 --> 00:58:14.809
No-reply-E-mail-Adressen. A: Ich werde versuchen, eine Antwort darauf zu geben, wie ich es

00:58:14.809 --> 00:58:21.532
verstehe. Was also oft passiert ist, dass die E-Mail von nicht existierenden Adressen

00:58:21.532 --> 00:58:25.294
gesendet wird. Das war vielleicht die Frage. Die Beispielfrage "keine Antwort"

00:58:25.294 --> 00:58:29.789
ist nicht das Problem selbst. Keine Antwort. Das Problem ist, dass es sich nicht um eine echte

00:58:29.789 --> 00:58:34.339
Adresse handelt. Es gibt keine solche Adresse. Richtig. Und deshalb habe ich keine Antwort

00:58:34.339 --> 00:58:38.816
darauf. Denn laut RFC sollten Sie es praktisch trotzdem akzeptieren.

00:58:38.816 --> 00:58:43.627
Ich sagte bereits, dass viele Mailsysteme diese Adressen bereits löschen, wenn sie von

00:58:43.627 --> 00:58:46.420
nicht vorhandenen Adressen senden. Es sei denn, Sie sind Google oder etwas Großes.

00:58:46.420 --> 00:58:50.150
Dann werden Sie auf die weiße Liste gesetzt. Sie können es einfach nicht tun.

00:58:50.150 --> 00:58:54.779
Sie können keine E-Mails von einer nicht existierenden Adresse senden. Falls Sie in einer

00:58:54.779 --> 00:59:00.309
erartigen Situation sind, erstellen Sie die Adresse entfernen Sie alle E-Mails, die dort eintreffen, aber

00:59:00.309 --> 00:59:03.640
erstellen Sie die echte Adresse, damit Sie akzeptabel sind, wenn Sie auf der anderen Seite sind,

00:59:03.640 --> 00:59:08.269
und diese E-Mail erhalten. Das hängt von diesem speziellen Anwendungsfall ab.

00:59:08.269 --> 00:59:12.099
Überprüfen Sie also einfach, was los ist. Wenn Sie sie kontaktieren können, kontaktieren Sie sie.

00:59:12.099 --> 00:59:16.220
Wenn Sie sie nicht kontaktieren, dann sollten Sie entscheiden, welches Risiko besteht, wenn Sie

00:59:16.220 --> 00:59:23.920
dieselben Adressen weglassen. Sind sie wichtig für Sie? Laut RFC sollten Sie diese Adressen

00:59:23.920 --> 00:59:28.660
also erhalten und verarbeiten. Herald: Okay. Mikrophon Nummer 4 bitte.

00:59:28.660 --> 00:59:33.040
M4: Hey, danke für diesen Vortrag. Kennen Sie die Bemühungen, Probleme mit großen

00:59:33.040 --> 00:59:40.630
E-mail-Versendern wie Online- Buchhändlern zu lösen, die sehr groß sind, weil sie anscheinend

00:59:40.630 --> 00:59:47.450
keine eigenen SPF-Datensätze haben, zum Beispiel in der Kontrolle?

00:59:47.450 --> 00:59:53.253
A: Ja. In vielen Fällen kann man einfach mit ihnen Kontakt aufnehmen.

00:59:53.253 --> 00:59:56.711
Die Frage, ob sie nicht darüber nachgedacht haben oder ob ihnen vielleicht niemand gesagt hat, was

00:59:56.711 --> 01:00:01.770
sie tun sollen oder vielleicht wissen sie nicht, wie sie es besser machen sollen. Das stimmt.

01:00:01.770 --> 01:00:05.249
Das ist also eine der Sachen, die wir als CERT tun. Falls Sie dieses Problem mit einem großen

01:00:05.249 --> 01:00:10.619
Unternehmen in einem bestimmten Land haben, schlage ich vor, das CERT zu kontaktieren.

01:00:10.619 --> 01:00:14.470
Auch wenn es sich nicht um eine Regierungsorganisation handelt, zum Beispiel in Lettland, wenn es

01:00:14.470 --> 01:00:18.700
sich um ein lettisches Unternehmen handelt. Wir würden die Trage vornehmen.

01:00:18.700 --> 01:00:21.892
Wir würden versuchen mit ihnen zu reden, ihnen zu erklären, warum sie sich ändern müssen

01:00:21.892 --> 01:00:26.289
und so weiter. Das ist vielleicht eine Möglichkeit für sie. Aber in der Praxis gilt: Wenn etwas für Sie

01:00:26.289 --> 01:00:30.060
als Dritte als falsche Konfiguration erscheint, kann ich das in diesem Vortrag nicht erwähnen.

01:00:30.060 --> 01:00:34.400
Wenn etwas nicht perfekt ist, heißt das nicht, dass es falsch ist.

01:00:34.400 --> 01:00:39.460
Es könnte tatsächlich einen geschäftlichen Grund dafür geben. Richtig. Es ist zum Beispiel so,

01:00:39.460 --> 01:00:42.229
wenn es sich um ein großes, ich weiß nicht, Amazon oder etwas in der Art handelt, und wenn sie es

01:00:42.229 --> 01:00:46.700
getestet haben und wissen, dass sie, wenn sie eine sehr strenge Konfiguration haben, dass dann

01:00:46.700 --> 01:00:51.697
ein gewisser Prozentsatz ihrer E-Mails einfach nicht ankommen. Nicht wegen ihrer Problems,

01:00:51.697 --> 01:00:55.762
sofern wegen des Problems von jemand anderem. Richtig.

01:00:55.762 --> 01:00:59.759
Aber dann gibt es tatsächlich einen echten Geschäftsfall, dass sie das nicht tun.

01:00:59.759 --> 01:01:04.489
Es wäre dumm, wenn sie diese strikte Konfiguration ermöglichen würden, weil sie wissen, dass es

01:01:04.489 --> 01:01:08.970
ihrem Geschäft schadet. Das macht Sinn, oder?

01:01:08.970 --> 01:01:13.479
Herald: Okay. Leider läuft die Zeit für diejenigen aus, die an den Mikrofonen sitzen. Bitte stellen Sie

01:01:13.479 --> 01:01:17.755
sich einfach bei dem Sprecher neben dem Pult auf. Er wird ganz sicher mit Ihnen sprechen.

01:01:17.755 --> 01:01:21.195
Applaus