1
00:00:00,000 --> 00:00:22,180


2
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

3
00:00:28,540 --> 00:00:33,369
richtigen Podcast. Wir haben hier unseren nächsten Sprecher. Andrew arbeitet gerade für das

4
00:00:33,369 --> 00:00:41,180
Nationale CERT in Lettland. Er ist ein Sicherheitsforscher.

5
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..

6
00:00:50,120 --> 00:00:53,356
Die Bühne gehört Dir.

7
00:00:53,356 --> 00:01:04,460
Applaus

8
00:01:04,460 --> 00:01:14,490
Also Grüße. Ich bin Andrew und ich habe für das Lettische National CERT gearbeitet. Eures unserer aktuellen Ziele ist

9
00:01:14,490 --> 00:01:21,440
idie Verbesserung des Zustands der E-Meil-Sicherheit in unserem Land und

10
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

11
00:01:26,400 --> 00:01:30,770
Praktiken. Und natürlich sind wir nicht die einzige Organisation, die dies tut.

12
00:01:30,770 --> 00:01:34,420
Es gibt viel mehr Gruppen in anderen Ländern und es gibt verschiedene

13
00:01:34,420 --> 00:01:39,299
Nichtregierungsorganisationen, die das Gleiche tun. Und konventionelle Einrichtungen.

14
00:01:39,299 --> 00:01:46,060
Doch bisher sind, offen gesagt, unsere
kollektiven Fortschritte ziemlich

15
00:01:46,060 --> 00:01:54,100
enttäuschend. Daher ist hier zum Beispiel eine Statistik, die die Nutzung einer bestimmten

16
00:01:54,100 --> 00:01:59,770
Technologie in Dänemark zeigt, was , wie Sie in diesem Vortrag erfahren werden, ziemlich

17
00:01:59,770 --> 00:02:06,770
wichtig ist und ich hoffe, dass jeder diese Technologie verwendet. Auf der linken Seite

18
00:02:06,770 --> 00:02:11,060
werden 20.000 Domains weltweit angezeigt, die wichtige Domains sind für

19
00:02:11,060 --> 00:02:15,880
wichtige Organisationen, die es eigentlich besser wissen sollten. Und auf der rechten Seite

20
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

21
00:02:24,799 --> 00:02:29,799
Dänemark bisher nicht einmal konfiguriert. Und von denen, die die Mehrheit konfiguriert haben,

22
00:02:29,799 --> 00:02:36,350
haben nicht keine strengen Richtlinien aktiviert. Wenn es also nur eine wichtige Erkenntnis aus

23
00:02:36,350 --> 00:02:41,459
diesem Vortrag gibt, hoffe ich, dass jeder damit beginnen sollte, Dänemark zu verwenden. Es ist

24
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

25
00:02:49,120 --> 00:02:56,760
für diese niedrige Akzeptanzrate ist meiner Meinung nach, dass es anscheinend zu viele

26
00:02:56,760 --> 00:03:04,310
konkurrierende Technologien gibt. Das ist der Inhalt meines Vortrags. Und ich habe wirklich

27
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

28
00:03:12,449 --> 00:03:18,739
und SMTP und außerdem SPF, DKIM und DMARC und aktuelle 2, an deren Namen ich mich

29
00:03:18,739 --> 00:03:25,570
nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass

30
00:03:25,570 --> 00:03:28,949
es zufiele Schlagworte gibt, zu viele Technologien, und es ist nicht klar

31
00:03:28,949 --> 00:03:34,590
welche wir davon verwenden sollten, das ist nicht spezifisch für E-Mails. Und wir haben das

32
00:03:34,590 --> 00:03:39,760
in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir

33
00:03:39,760 --> 00:03:47,880
inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar

34
00:03:47,880 --> 00:03:53,370
Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt wurde

35
00:03:53,370 --> 00:03:58,190
und die Ergebnisse veröffentlicht wurden, können wir mit dem Gespräch beginnen. Wir

36
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,

37
00:04:03,510 --> 00:04:09,620
wir können stattdessen die Fragen beantworten, die wirklich wichtig sind, wie:

38
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

39
00:04:15,310 --> 00:04:20,989
solche E-Mail zum Beispiel an Ihre Kunden oder Ihre Partner oder an Medienorganisationen so

40
00:04:20,989 --> 00:04:24,970
zu versenden, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation

41
00:04:24,970 --> 00:04:31,810
stammen? Deshalb sind Penetrationstester die wichtigste Zielgruppe für diesen Vortrag.

42
00:04:31,810 --> 00:04:36,020
Ich hoffe jedoch, dass alle Blue-Teamer im Publikum diesen

43
00:04:36,020 --> 00:04:40,650
Vortrag interessant finden. Ich bin sicher, dass Sie bereits alle Grundlagen über die

44
00:04:40,650 --> 00:04:43,620
E-Mail und über diese Technologien kennen, aber wenn man das Problem aus den

45
00:04:43,620 --> 00:04:50,440
verschiedenen Perspektiven des Angreifers betrachtet, kann man die Dinge ins rechte Licht

46
00:04:50,440 --> 00:04:54,819
rücken. Es kann Ihnen helfen zu verstehen, worauf Sie sich beim Schutz Ihrer Umwelt

47
00:04:54,819 --> 00:05:01,009
konzentrieren sollten. Und schließlich das SMTP Protokoll. Die Technologie, die in unseren

48
00:05:01,009 --> 00:05:07,720
E-Mail-Konversationen steckt, ist eigentlich relativ leicht zu verstehen.

49
00:05:07,720 --> 00:05:14,061
Und auch die Lehren, die man daraus gezogen hat. Diese Entwicklung von SMTP, wie es wurde

50
00:05:14,061 --> 00:05:20,979
und wie es möglich ist, es zu fälschen, und all die Technologien, die versuchen,

51
00:05:20,979 --> 00:05:27,530
Spoofing zu verhindern. Ich denke, es ist eine interessante Fallstudie und es sollte auch für

52
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

53
00:05:33,719 --> 00:05:41,400
Bedrohungslandschaft. E-Mail Sicherheit ist ein ziemlich umfangreicher Themenbereich. Heute

54
00:05:41,400 --> 00:05:47,650
werde ich mich auf einen kleinen Teil fokussieren. Dieser ist das erfolgreiche

55
00:05:47,650 --> 00:05:54,689
Spoofing von E-Mails, also Manipulationsattacken. Ich weiß, dass viele Pentrationstester bereits teilweise

56
00:05:54,689 --> 00:06:01,250
Phishing oder Spear-Phishing-Emulation in ihre Arbeiten einbeziehen. So viel ich weiß, tun sie

57
00:06:01,250 --> 00:06:07,070
dies meist aus der Social-Engineering-Perspektive, indem sie beispielsweise Tools wie

58
00:06:07,070 --> 00:06:13,090
das Social-Engineering-Toolkit verwenden und ich möchte nicht behaupten, dass es wichtig ist,

59
00:06:13,090 --> 00:06:16,949
dies zu tun und dem Kunden zu zeigen, welche Risiken in dieser Hinsicht bestehen. Ich denke

60
00:06:16,949 --> 00:06:23,860
jedoch, dass Sie mit Social Engineering dem Kunden einen Dienst erweisen, wenn dies das

61
00:06:23,860 --> 00:06:28,099
Einzige ist, was Sie aus der E-Mail-Perspektive testen, denn aus der Perspektive der Kunden,

62
00:06:28,099 --> 00:06:32,650
beispielsweise von Managern, die Ihre Berichte lesen, erwähnen Sie dann nur Social-

63
00:06:32,650 --> 00:06:38,870
Engineering-Angriffe. Die logische Schlussfolgerung ist, dass der beste Weg, diese

64
00:06:38,870 --> 00:06:44,650
Bedrohungen einzudämmen. darin besteht, Ihr Personal zu schulen, insbesondere diejenigen,

65
00:06:44,650 --> 00:06:51,590
die am wenigsten technisch versiert sind, wie dies in diesem Vortrag zu sehen ist.

66
00:06:51,590 --> 00:06:55,379
Es gibt ziemlich viele Angriffe und viele Organisationen sind anfällig für diese Angriffe.

67
00:06:55,379 --> 00:07:00,230
Und hier hilft auch keine noch so große Benutzerschulung, denn wir können von den

68
00:07:00,230 --> 00:07:03,889
Benutzer nicht erwarten, dass sie beispielsweise die Kopfzeilen manuell

69
00:07:03,889 --> 00:07:10,699
überprüfen. Deshalb müssen wir unsere E-Mail-Infrastruktur tatsächlich verbessern. Daran

70
00:07:10,699 --> 00:07:17,009
führt kein Weg vorbei. Bevor wir uns schließlich den eigentlich technischen Dingen zuwenden,

71
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

72
00:07:21,889 --> 00:07:28,159
in der E-Mail-Branche arbeiten, warum wir solche Probleme haben, und für E-Mail-

73
00:07:28,159 --> 00:07:38,040
Administratoren, die in der Vergangenheit die Verfügbarkeit ihres Systems und die

74
00:07:38,040 --> 00:07:44,680
Zuverlässigkeit viel mehr schätzten, als die Sicherheit. Und das liegt daran, dass das keine

75
00:07:44,680 --> 00:07:50,469
ideologische Entscheidung ist. Es ist eine sehr pragmatische. Wenn Sie also beispielsweise

76
00:07:50,469 --> 00:07:56,090
ein E-Mail-Administrator in einer Organisation sind und einige ihrer Kunden keine Rechnungen

77
00:07:56,090 --> 00:08:01,470
mehr erhalten, wird Ihr Management Sie finden, sie darüber informieren und Sie freundlich

78
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.

79
00:08:06,210 --> 00:08:13,509
Es könnte sein, dass das Problem möglicherweise auf einer anderen Seite liegt,

80
00:08:13,509 --> 00:08:20,449
nicht auf Ihrem Server. Ein anderes Beispiel ist, dass Sie, dass einige Ihrer Mitarbeiter bald

81
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

82
00:08:24,969 --> 00:08:30,190
Passwort wiederherzustellen oder um die E-Mail zu verifizieren oder ein

83
00:08:30,190 --> 00:08:33,969
Mehrfaktor-Authentifizierungs-Token zu verwenden und sie können sich bei einigen

84
00:08:33,969 --> 00:08:39,539
wichtigen Systeme nicht mehr einloggen. Dann müssen Sie das lösen. Aber wenn Ihr System

85
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

86
00:08:45,540 --> 00:08:50,670
normalerweise weder den Anwendern, noch dem Management auffallen. Aber Sie haben

87
00:08:50,670 --> 00:08:55,930
diese Schwachstelle. Deshalb sind Penetrationstester natürlich wichtig. Okay.

88
00:08:55,930 --> 00:09:01,250
Jetzt können wir endlich anfangen, über die Technik zu sprechen. Wir starten mit der

89
00:09:01,250 --> 00:09:07,190
kurzen Einführung in das SMTP-Protokoll. SMTP ist das Protokoll, das der gesamten E-Mail-

90
00:09:07,190 --> 00:09:12,360
Kommunikation zugrunde liegt und es ist ziemlich einfach zu befolgen. Hier ist also

91
00:09:12,360 --> 00:09:18,370
ein Datenfluss, der zeigt, was passiert, wenn eine Person E-Mails an eine andere Person

92
00:09:18,370 --> 00:09:21,269
sendet. Zum Bespielt sendet Alice an Bob und sie arbeiten für unterschiedliche Unternehmen.

93
00:09:21,269 --> 00:09:24,970
Sie verwenden unterschiedliche Domains. Was also passiert ist, dass beide sagen würden

94
00:09:24,970 --> 00:09:29,290
benutze E-Mail-Clients wie Outlook oder Thunderbird. Alice sendet E-Mails. Sie geht

95
00:09:29,290 --> 00:09:34,580
über dieses Protokoll SMTP an Alices Mail-Server. Wichtig ist aber zu beachten dass dies

96
00:09:34,580 --> 00:09:41,740
ein Server für ausgehende E-Mails ist. Üblicherweise verfügen Organisationen über

97
00:09:41,740 --> 00:09:44,790
2 Arten von Diensten, einen für eingehende und Transaktionen und einen für ausgehenden.

98
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

99
00:09:48,680 --> 00:09:52,470
Penetrationstester wichtig, sich dies als unterschiedliche Systeme vorzustellen. Denn

100
00:09:52,470 --> 00:09:56,680
selbst wenn es physisch ein einziger Computer ist, wird er eine unterschiedliche Konfiguration

101
00:09:56,680 --> 00:10:00,620
für ausgehende und eingehende E-Mails haben. Als Penetrationstester müssen Sie also

102
00:10:00,620 --> 00:10:04,899
überprüfen, ob beide in Ordnung sind. Wenn Alices Server nun versucht, E-Mails an Bobs

103
00:10:04,899 --> 00:10:11,940
Server zu senden, gibt es eine Art von Problem, das darin besteht, dass der Server irgendwie

104
00:10:11,940 --> 00:10:16,480
automatisch den richtigen Server zum Versenden von E-Mails finden muss. Dies

105
00:10:16,480 --> 00:10:25,220
geschieht über diese Bluebox und eine Mischung aus DNS-spezfifischen DNS-

106
00:10:25,220 --> 00:10:29,680
Eintragstypen und -mischungen. Das ist also etwas, das von Bobs Organisation gepflegt wird,

107
00:10:29,680 --> 00:10:35,360
Bobs Organisation wird also, wenn sie E-Mails erhalten möchten, diesen DNS-Eintrag erstellen.

108
00:10:35,360 --> 00:10:38,830
Und ich sage: Okay, wenn Sieuns eine E-Mail senden möchten, benutzen Sie bitte diesen

109
00:10:38,830 --> 00:10:44,290
speziellen Server. Es sollte also auf Bobs verwiesen werden. Und jetzt kann Alices

110
00:10:44,290 --> 00:10:50,670
Ausgangsserver, der die eingehende Serveradresse von Bob kennt, mit diesem

111
00:10:50,670 --> 00:10:54,970
kommunizieren und Bob wird später seine E-Mail erhalten. Wir als Penetrationstester

112
00:10:54,970 --> 00:10:59,839
versuchen eigentlich, zwischen dem Server von Alice und dem von Bob zu vermitteln. Dann

113
00:10:59,839 --> 00:11:03,511
müssen wir über das 2. Beispiel nachdenken, das umgekehrt ist. Sie denken vielleicht, dass

114
00:11:03,511 --> 00:11:07,110
es sich um ein sinnloses Beispiel handelt, weil wir im Grunde nur die Richtung des

115
00:11:07,110 --> 00:11:11,449
Datenverkehrs ändern. Aber das Wichtigste hier ist, dass wir als Penetrationstester verstehen,

116
00:11:11,449 --> 00:11:17,220
dass unser Kunde nur einen Teil der Transaktion kontrolliert. Falls unser Kunde,

117
00:11:17,220 --> 00:11:20,760
sagen wir mal, für den Rest dieser Präsentation Alice oder Alices Organisation ist,

118
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

119
00:11:26,750 --> 00:11:34,600
gesendet. Grundsätzlich läuft ein Teil dieser Transaktion im 1. Beispiel über Alices Server.

120
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

121
00:11:40,980 --> 00:11:45,940
verwirrend ist, ist das in Ordnung. Wir werden etwas später darauf zurückkommen. Und

122
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

123
00:11:51,600 --> 00:11:56,260
nur, wenn Alice kommuniziert. Alice ist unser Kunde. Und wenn sie mit ihren Kollegen

124
00:11:56,260 --> 00:12:01,070
kommuniziert, die in der gleichen Organisation sind, denselben E-Mail-Server und die gleiche

125
00:12:01,070 --> 00:12:04,320
Domain haben, wird es in diesem Beispiel logischerweise 2 E-Mail-Server geben, ein

126
00:12:04,320 --> 00:12:09,000
Ausgagnsserver und ein Eingangsserver.

127
00:12:09,000 --> 00:12:15,850
Aber beide gehören unserem Kunden. Also können Sie im Moment, wenn Sie sich mit

128
00:12:15,850 --> 00:12:20,149
E-Mail nicht auskennen, versuchen darüber nachzudenken, welche dieser 3 Szenarien

129
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.

130
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.

131
00:12:31,769 --> 00:12:38,410
Also noch einmal, es wird das SMTP-Protokoll verwendet und es ist ein wirklich gutes

132
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

133
00:12:44,790 --> 00:12:48,029
reines Testprotokoll und es ist sehr einfach zu bedienen, weil man einfach eine Telnet-

134
00:12:48,029 --> 00:12:54,410
Verbindung zum richtigen Server öffnet und man versuchen kann, die Befehle einfach mit

135
00:12:54,410 --> 00:12:58,680
den Händen aufzuschreiben. Um zu versuchen, etwas zu zerstückeln oder zu modifizieren, oder

136
00:12:58,680 --> 00:13:05,149
zu versuchen, verschiedene Typen auszuprobieren und in Echtzeit zu sehen, wie

137
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.

138
00:13:11,209 --> 00:13:14,720
Als erstes kommt der SMTP-Umschlag, den Sie im Grund mit dem Server verbinden. Sagen Sie

139
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

140
00:13:22,070 --> 00:13:26,980
angegeben haben. "Mail von" ist der Absender. Empfänger ist zum Beispiel Bob. Und dann

141
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

142
00:13:32,160 --> 00:13:35,480
Inhalt/Nachricht nennt. Wenn Sie also ein bisschen damit herumspielen wollen, wird dies

143
00:13:35,480 --> 00:13:38,029
durch einen anderen Standard definiert, der für Penetrationstester nicht so wichtig ist. Aber

144
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

145
00:13:43,890 --> 00:13:49,069
Nachricht, die entweder Inhalt oder SMTP genannt wird, enthält wiederum 2. Teile. Der

146
00:13:49,069 --> 00:13:53,300
eine Teil ist die Kopfzeile und der andere der Hauptteile. Und ich denke, dass einige Leute

147
00:13:53,300 --> 00:13:57,569
vielleicht nicht mit der E-Mail vertraut sind, aber wahrscheinlich ist jeder Zuhörer mit HTTP

148
00:13:57,569 --> 00:14:02,600
vertraut und das sieht ganz ähnlich aus. Also leicht zu verstehen. Aber der interessante Teil

149
00:14:02,600 --> 00:14:08,550
ist, dass sie vielleicht bemerkt haben, dass wir

150
00:14:08,550 --> 00:14:14,350
Alices und Bobs Adressen zweimal haben. Das stimmt. Zum Beispiel ist Alices Adresse in der

151
00:14:14,350 --> 00:14:19,709
zweiten Zeile "Mail von". Und dann haben wir die gleiche Adresse. Alice @ ihre Organisation in

152
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

153
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

154
00:14:33,471 --> 00:14:39,139
Person, die E-Mails in den letzten Jahren benutzt hat, sehe sie normalerweise so, wie

155
00:14:39,139 --> 00:14:44,980
auf der linken Seite beschrieben, wie eine Art Postkarte. Auf der Postkarte steht also jemand,

156
00:14:44,980 --> 00:14:48,980
der sie abgeschickt hat. Der Absender. Da ist dann noch der Empfänger. Das bin ich

157
00:14:48,980 --> 00:14:53,569
normalerweise. Ich empfange. Und dann ist da noch eine Nachricht. Zumindest habe ich das so

158
00:14:53,569 --> 00:14:58,670
wahrgenommen, bevor ich etwas mehr darüber gelernt habe. Aber E-Mail Administratoren und

159
00:14:58,670 --> 00:15:04,610
die Standardgremien sehen diese Situation, wie sie rechts dargestellt ist. Da ist ein Umschlag

160
00:15:04,610 --> 00:15:10,480
und darin befindet sich diese Nachricht oder vielleicht eine Postkarte. Sie haben also 2

161
00:15:10,480 --> 00:15:15,350
Adressen in diesem Szenario. Sie haben die Adresse von und an wen sie sich den Umschlag

162
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

163
00:15:20,730 --> 00:15:24,589
Allgemeinen nicht in Ihrem Umschlag nachsehen und sehen, dass sich dort eine

164
00:15:24,589 --> 00:15:28,880
weitere Nachricht, die interne Nachricht befindet, die eigentliche für den Empfänger

165
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

166
00:15:33,889 --> 00:15:40,060
ganzen Umschlag mit der Nachricht der Postkarte in einen anderen Umschlag stecken.

167
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.

168
00:15:46,500 --> 00:15:50,029
möglich. Und in dem RFC, dem Standarddokument, gibt es einige Beispiele,

169
00:15:50,029 --> 00:15:56,939
warum das notwendig ist. Warum solche Dinge erlaubt sind. Aber sie sind doch verwirrend.

170
00:15:56,939 --> 00:16:03,009
Und so als Ergebnis sehen wir in diesem ersten Beispiel , dass wir im Allgemeine die gleiche

171
00:16:03,009 --> 00:16:07,940
Adresse zweimal angeben. Aber als Penetrationstester sollten wir uns die Frage

172
00:16:07,940 --> 00:16:12,170
stellen: Ist das aktuell erforderlich? Ist das immer wahr, oder handelt es sich nur um

173
00:16:12,170 --> 00:16:17,120
Wunschdenken? Und es ist tatsächlich ein Wunschdenken. Standards schreiben nicht

174
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

175
00:16:20,870 --> 00:16:27,140
Absenders auf dem Umschlag und innerhalb einer Nachricht angeben. Es gibt also

176
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

177
00:16:32,300 --> 00:16:38,519
meiner Meinung nach nur die, mit denen wir alle Erfahrung haben, denn wenn man nur

178
00:16:38,519 --> 00:16:42,850
E-Mail benutzt, sind das normalerweise die Dinge, die man sieht oder man sieht das

179
00:16:42,850 --> 00:16:45,920
Datum, den Betreff, den Inhalt, wer Dir etwas gesendet hat und an wen es gesendet wurde.

180
00:16:45,920 --> 00:16:52,680
Üblicherweise Du selbst. Und dort könnten es natürlich auch mehrere Empfänger geben.

181
00:16:52,680 --> 00:16:57,800
Oh ja. Und die Frage ist dann noch eine andere:

182
00:16:57,800 --> 00:17:03,769
Was ist eigentlich, wenn wir aus irgendeinem Grund etwas versehentlich angegeben haben

183
00:17:03,769 --> 00:17:07,300
oder vor allem, wenn wir unterschiedliche Adressen in diesem Umschlag angegeben

184
00:17:07,300 --> 00:17:11,890
haben, welche der Benutzer sehen wird. Der Empfänger, das ist eigentlich die Kopfzeile. Ok.

185
00:17:11,890 --> 00:17:18,010
Wie ich schon sagte, gibt es tatsächlich Standards, die mehr Kopfzeilen erlauben. Und

186
00:17:18,010 --> 00:17:22,510
es gibt aktuell 3 Kopfzeilen "Von", "Absender", "Antwort an", die semantisch wirklich nahe

187
00:17:22,510 --> 00:17:25,880
beieinander liegen und im Standard ist eigentlich erklärt, wann man welche Überschrift

188
00:17:25,880 --> 00:17:31,080
verwenden sollte. Und das Lustige für mich ist, dass zum Beispiel die "Von" Überschrift ist,

189
00:17:31,080 --> 00:17:34,040
diejenige ist, in der wir sehen, was sie beinhaltet. Wenn Sie den RFC lesen, werden Sie

190
00:17:34,040 --> 00:17:39,310
sehen, dass man nicht mehr als eine solche Kopfzeile haben sollte, aber die Kopfzeile selbst

191
00:17:39,310 --> 00:17:44,450
könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail

192
00:17:44,450 --> 00:17:48,020
erhalten, die von verschiedenen Personen stammen würde, aber das ist erlaubt. Aber das

193
00:17:48,020 --> 00:17:53,110
Wichtigste, was Sie hier noch einmal verstehen müssen, ist dies bereits erwähnte

194
00:17:53,110 --> 00:17:57,530
Rückwärtskompatibilität. Obwohl die Standards erklären, wie Sie die Haupt-Kopfzeile

195
00:17:57,530 --> 00:18:02,480
verwenden sollten, und dass Sie in der Praxis nicht mehr als eine dieser Kopfzeilen haben

196
00:18:02,480 --> 00:18:07,130
sollten, können Sie bei einer Zustimmung zu fehlerhaften E-Mails diese mit mehreren

197
00:18:07,130 --> 00:18:12,480
Kopfzeilen in der selben Kopfzeile senden. Sie könnten Kopfzeilen senden, die laut RFC kein

198
00:18:12,480 --> 00:18:17,040
"Von" enthält, aber einen "Absender". Das ist nicht korrekt. In der Praxis wird es.

199
00:18:17,040 --> 00:18:21,240
funktionieren. Die meisten Organisationen, die meisten E-Mail-Dienste werden Ihr Bestes tun,

200
00:18:21,240 --> 00:18:27,550
ihre völlig fehlerhafte E-Mail nach besten Kräften zu analysieren, weil sie wirklich daran

201
00:18:27,550 --> 00:18:33,720
interessiert sind, die Supportkosten zu senken. Wenn etwas also nicht funktioniert, wird man

202
00:18:33,720 --> 00:18:37,580
zu Ihnen kommen. Es ist also besser, dafür zu sorgen, dass meistens alles funktioniert.

203
00:18:37,580 --> 00:18:42,160
Für Penetrationstester bedeutet das natürlich, dass Sie damit herumspielen können, weil es

204
00:18:42,160 --> 00:18:45,670
verschiedene Implementierungen gibt und es genau darauf ankommt, welche Gefahr besteht.

205
00:18:45,670 --> 00:18:49,480
Wenn beispielsweise 2 Kopfzeilen angezeigt werden oder für einen Algorithmus verwendet,

206
00:18:49,480 --> 00:18:53,830
hängt dies von der jeweiligen Implementierung ab. Da es so viele Implementierungen gibt, sind

207
00:18:53,830 --> 00:18:59,150
diese auf unterschiedliche Weise miteinander verbunden. Sie können und sollten als

208
00:18:59,150 --> 00:19:03,720
Penetrationstester verschiedene Dinge ausprobieren, zum Beispiel die gleiche

209
00:19:03,720 --> 00:19:09,270
Kopfzeile mehrmals hinzufügen. OK. Nachdem wir nun diese Grundlagen behandelt haben,

210
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.

211
00:19:13,990 --> 00:19:18,360
Ja, genau. Und hier sind wir wieder, wir kommen zurück zu diesem Diagramm, das wir

212
00:19:18,360 --> 00:19:23,930
schon einmal gesehen haben. Und beispielsweise in dem 1. Beispiel, wo Alice eine

213
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

214
00:19:29,960 --> 00:19:33,700
sind lizenzierte Penetrationstester, wir haben eine Vereinbarung, die uns erlaubt, dies zu tun

215
00:19:33,700 --> 00:19:38,920
und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In diesem Beispiel versuchen

216
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

217
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

218
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

219
00:19:57,580 --> 00:20:01,430
das verstehen. Ich kann mir vorstellen, dass gefälschte Nachrichten eines der Probleme

220
00:20:01,430 --> 00:20:06,330
sind, die wir in Lettland gesehen haben. Sie wurden gegen Regieurngsbehörden eingesetzt.

221
00:20:06,330 --> 00:20:13,660
Und als jemand gefälschte Nachrichten per E-Mail an andere Leute, Organisationen etc.

222
00:20:13,660 --> 00:20:19,510
sendete und versucht hat, sich als jemand anderes auszugeben. Und natürlich können Sie

223
00:20:19,510 --> 00:20:23,710
sich vorstellen, dass das keine gute Sache ist. Aber das Interessante hier ist, dass Chuck zwar

224
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

225
00:20:28,450 --> 00:20:32,480
aussehen. In diesem Fall werden E-Mails nicht durch Alices Systeme geleitet. Wie Sie sehen

226
00:20:32,480 --> 00:20:37,590
können, sendet Chuck E-Mails an Bobs Posteingangsserver. Nun gibt es eine 2. Art von

227
00:20:37,590 --> 00:20:44,490
Angriffsart, die wir uns ansehen werden. Wenn wir eine E-Mail in die andere Richtung senden,

228
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

229
00:20:48,540 --> 00:20:52,900
zu sein. Wir senden E-Mails. in diesem Fall wird die E-Mail durch das System

230
00:20:52,900 --> 00:20:58,570
von Alice geleitet. Die interessante Frage ist daher, was einfacher zu schützen ist.

231
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

232
00:21:03,790 --> 00:21:07,270
Systeme von Alice läuft. Das bedeutet, dass Alice mehr Befugnisse hat, etwas zu tun, um

233
00:21:07,270 --> 00:21:11,880
einige zusätzliche Kontrollen und Abgleiche usw. durchzuführen. Aber wie wir in Zukunft

234
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

235
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

236
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

237
00:21:26,540 --> 00:21:32,800
Alice auszugeben. Okay. Oh, ja. Es gibt noch das 3. Beispiel: Wenn Alice mit ihren Kollegen

238
00:21:32,800 --> 00:21:37,690
innerhalb derselben Organisation kommuniziert, sind wir Chuck.

239
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

240
00:21:41,821 --> 00:21:47,590
Postausgangsserver. Richtig. Das ist wichtig zu beachten. Im Prinzip ist dieses 3. Beispiel am

241
00:21:47,590 --> 00:21:54,460
einfachsten zu erkennen weil Alices Organisation vermutlich weiß, dass ihre E-Mails

242
00:21:54,460 --> 00:21:59,790
immer von einem, von diesem bestimmten Postausgangsserver kommen sollen. Richtig.

243
00:21:59,790 --> 00:22:03,790
Wenn wir beispielsweise eine E-Mail von Alices Kollegen senden, sollte der Posteingangsserver im

244
00:22:03,790 --> 00:22:08,780
Prinzip auch ohne Standards oder ähnliches, die volle Leistung haben.

245
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.

246
00:22:15,610 --> 00:22:24,140
Es finden keine Überprüfungen statt, falls der Posteingangsserver von Alice E-Mails empfängt,

247
00:22:24,140 --> 00:22:28,880
die wiederum von Alice stammen.

248
00:22:28,880 --> 00:22:34,610
Übrigens gibt es dieses Beispiel, das wir in den letzten Jahren gesehen haben.

249
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

250
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.

251
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

252
00:22:48,290 --> 00:22:53,820
alle möglichen Aktivitäten arrangiert haben oder Sie erpresst.

253
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.

254
00:22:59,160 --> 00:23:04,520
Soweit diese E-Mails. Der interessante Teil dieser E-Mails besteht darin, dass sie normalerweise

255
00:23:04,520 --> 00:23:08,920
dazu dienen; Ihnen zu beweisen, dass Sie Zugang zu Ihrem E-Mail-Konto haben.

256
00:23:08,920 --> 00:23:13,210
Sie senden E-Mails von Ihrer Adresse an Ihre Adresse.

257
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

258
00:23:20,100 --> 00:23:22,730
E-Mail von sich selbst erhalten haben.

259
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

260
00:23:28,620 --> 00:23:34,100
Schutzvorkehrungen vorgenommen wurden. Das Wichtigste ist also, dass ich hoffe, dass niemand in

261
00:23:34,100 --> 00:23:38,120
diesem Publikum auf einen solchen Betrug hereinfällt.

262
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

263
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

264
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

265
00:23:53,110 --> 00:23:57,770
Administratoren oder ihr IT-Team kontaktieren und nach dem Anti-Spoofing-Schutz fragen sollten.

266
00:23:57,770 --> 00:24:03,470
Denn wenn sie solche E-Mails empfangen können und diese nicht gefiltert werden,

267
00:24:03,470 --> 00:24:09,020
stimmt etwas nicht. Okay.

268
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.

269
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.

270
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

271
00:24:25,920 --> 00:24:30,110
erkennen? Und es ist schwer, den Unterschied zu erkennen, da es keinen Unterschied gibt, da es

272
00:24:30,110 --> 00:24:33,230
sich um das gleiche Gespräch handelt.

273
00:24:33,230 --> 00:24:39,540
Der Punkt hier ist also, dass das SMTP-Protokoll an sich eigentlich keinen Schutz bietet.

274
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.

275
00:24:43,640 --> 00:24:49,580
verschickt. Sie können diesen Text einfach aufschreiben und ihn einfach an Telnet senden.

276
00:24:49,580 --> 00:24:55,830
Das funktioniert bei vielen Organisationen. Aber nicht bei allen. Und natürlich kennen die E-Mail-

277
00:24:55,830 --> 00:25:01,210
Administratoren sich damit aus. Sie wissen, dass SMTP in diesem Fall nicht sehr zuverlässig ist.

278
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,

279
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

280
00:25:11,520 --> 00:25:15,950
Ihre eigene Mail ein. Und einige dieser Schutzmaßnahmen verstoßen tatsächlich gegen RFC,

281
00:25:15,950 --> 00:25:20,640
Aber wen interessiert das schon? RFC ist ja kein heiliger Text, den ich zum Beispiel absolut

282
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.

283
00:25:26,260 --> 00:25:31,640
Wenn Sie also zurückdenken, sind wir Bob und versuchen, unsere Systeme zu schützen.

284
00:25:31,640 --> 00:25:35,100
Wir sind also Bob, irgendein Systemadministrator, oder Bob ist der Systemadministrator und wir

285
00:25:35,100 --> 00:25:39,730
versuchen, einige zusätzliche Regeln und so etwas hinzuzufügen.

286
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

287
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

288
00:25:49,980 --> 00:25:56,970
diese E-Mail überhaupt vorhanden ist. Denn viele Spammer senden einfach E-Mail von nicht

289
00:25:56,970 --> 00:26:02,000
existierenden E-Mails. Und es wird funktionieren, wenn Sie nur einen einfachen

290
00:26:02,000 --> 00:26:08,640
SMTP-Server haben. SMTP-Callback bedeutet also, dass Sie, eine E-Mail erhalten,

291
00:26:08,640 --> 00:26:13,300
Wenn Sie beispielsweise E-Mails von Alice erhalten, versuchen Sie, einen separaten

292
00:26:13,300 --> 00:26:17,220
Prozess zu starten. Dieser wird eine Verbindung zu Alices Server herzustellen, etc.

293
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",

294
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

295
00:26:27,540 --> 00:26:31,290
tatsächlich beendet. Aber dann kann Ihr System automatisch feststellen, dass diese E-Mail auch

296
00:26:31,290 --> 00:26:36,570
wirklich existiert. Eine andere Möglichkeit, dies zu tun, ist durch Überprüfung dieses "Hello".

297
00:26:36,570 --> 00:26:42,030
Und das ist die erste Zeile und in der ersten Zeile sollte normalerweise der Hostname des

298
00:26:42,030 --> 00:26:48,000
Servers stehen, der die E-Mail sendet.

299
00:26:48,000 --> 00:26:52,580
Interessanter Teil. Laut RFC sollten Sie also nicht überprüfen, ob man es verifizieren kann.

300
00:26:52,580 --> 00:26:56,540
Und wenn es sich um eine zufällige Zeichenfolge handelt, sollten Sie es akzeptieren.

301
00:26:56,540 --> 00:27:04,520
Aber viele Server werden zunächst versuchen, diesen Hostname zu überprüfen, von dem Sie

302
00:27:04,520 --> 00:27:07,800
sagen, dass Sie dieser Hostname sind. Zunächst ob es tatsächlich auf dieselbe IP-Adresse

303
00:27:07,800 --> 00:27:12,800
verweist und dann machen Sie das Gegenteil. Sie nehmen die IP-Adresse und versuchen,

304
00:27:12,800 --> 00:27:18,880
eine umgekehrte DNS-PTR-Abfrage auszuführen. Und Sie werden versuchen

305
00:27:18,880 --> 00:27:23,150
herauszufinden, ob diese IP-Adresse wirklich auf diesen Hostname antwortet. Also nochmal.

306
00:27:23,150 --> 00:27:26,520
Als Penetrationstester sollten wir uns über diese Schutzmaßnahmen, Ad-Hoc-

307
00:27:26,520 --> 00:27:31,040
Schutzmaßnahmen im Klaren sein. Denn wenn Sie sie nicht kennen, werden Sie versuchen

308
00:27:31,040 --> 00:27:34,700
etwas auszuführen und es wird bei Ihnen nicht funktionieren. Aber Sie einfach, wenn Sie

309
00:27:34,700 --> 00:27:40,470
kennen und erkannt haben, dass diese Organisation sie verwendet. Sie sind leicht zu

310
00:27:40,470 --> 00:27:44,530
umgehen, so dass sie keinen guten Schutz bieten. Sie sollen vor massenhaftem

311
00:27:44,530 --> 00:27:52,910
Missbrauch durch Spam schützen. Ok. Also bietet SMTP, wie wir gesehen haben, keinen

312
00:27:52,910 --> 00:27:59,380
Schutz. Welche Ergänzungen zum Protokoll können also nachträglich tatsächlich verwendet

313
00:27:59,380 --> 00:28:06,860
werden, um uns zu schützen? Eines dieser Protokolle ist SPF. SPF versucht wie ein Spiegel

314
00:28:06,860 --> 00:28:12,870
MX-System sein. Das MX-System ist ein gemischtes System, das Alice grundsätzlich

315
00:28:12,870 --> 00:28:18,150
benutzen kann, damit Alices Server automatisch den Server finden kann, der Bob und seinem

316
00:28:18,150 --> 00:28:24,580
Posteingangsserver gehört. SPF ist also das Gegenteil davon. Da ist also eine Idee, das

317
00:28:24,580 --> 00:28:30,270
System automatisch auf dem Posteingangsserver von Bob auszuführen.

318
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

319
00:28:35,720 --> 00:28:41,820
herausfinden, welche IP-Adressen eigentlich zu Alices Postausgangsserver gehören. Das

320
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

321
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

322
00:28:52,570 --> 00:28:59,360
Absender des Umschlags. OK. Und hier ist ein Beispiel für minimale SPF-Syntax. Wie wir

323
00:28:59,360 --> 00:29:04,610
sehen können, ist es meiner Meinung nach leicht zu verstehen, auch wenn man die Syntax

324
00:29:04,610 --> 00:29:08,470
nicht kennt. Die Syntax besteht darin, dass sie IP-Adresse aufgelistet wird, die die IP-Adresse

325
00:29:08,470 --> 00:29:12,780
des Postausgangsservers ist. Und dann steht da noch dieses "alle", was wiederum leicht zu

326
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

327
00:29:18,700 --> 00:29:22,980
Nachricht erhalten, kommt diese von dieser IP-Adresse, Das ist cool. Ich akzeptiere es. Wenn es

328
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-

329
00:29:27,190 --> 00:29:31,610
Adresse anzugeben. Sie könnten einfach die IP-Adresse angeben. Sie könnten ein IP-Subnetz

330
00:29:31,610 --> 00:29:37,070
angeben, Sie könnten einen DNS-Hostname angeben. Es ist also nur für den Administrator.

331
00:29:37,070 --> 00:29:44,750
Für einen Penetrationstest ist es grundsätzlich nicht viel anders, für Administratoren ist es

332
00:29:49,620 --> 00:29:56,160
einfacher, diese Systeme zu warten. Und dann gibt es diese Qualifikanten. Das ist etwas, das

333
00:29:56,160 --> 00:30:00,100
man den Methoden voranstellt. Hier in diesem Beispiel hat IPv4 keinen Qualifikanten. Es gibt

334
00:30:00,100 --> 00:30:03,910
kein Plus oder Minus oder so etwas. Das liegt daran, dass das Plus standardmäßig

335
00:30:03,910 --> 00:30:12,600
angenommen wird. Dadurch wird standardmäßig alles, was im SPF-Eintrag

336
00:30:12,600 --> 00:30:15,850
aufgeführt ist, mit einem legitimen SMTP-Ausgangsserver übereinstimmen sollte. Es

337
00:30:15,850 --> 00:30:20,380
gibt jedoch andere Optionen, die Sie verwenden können. Minus verwenden, das heißt "Fehler".

338
00:30:20,380 --> 00:30:26,710
Und das bedeutet, wenn etwas mit diesem Datensatz übereinstimmt, das ist

339
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

340
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

341
00:30:37,150 --> 00:30:42,690
handelt, die für die Testphase gedacht ist. Wenn Sie also gerade mit der Implementierung von

342
00:30:42,690 --> 00:30:47,730
SPF beginnen, könnte es welche geben. Problematisch könnte sein, dass Sie vergessen,

343
00:30:47,730 --> 00:30:52,750
einige SMTP-Server hinzuzufügen. Weil Sie das noch nicht getan haben, denken Sie vielleicht,

344
00:30:52,750 --> 00:30:56,360
Sie haben nur einen SMTP-Postausgangsserver. Aber in Wirklichkeit haben Sie tatsächlich

345
00:30:56,360 --> 00:31:03,600
mehrere Möglichkeiten, E-Mail zu senden. Wenn Sie in diesem Fall beginnen würden, den

346
00:31:03,600 --> 00:31:07,230
oben genannten SPF-Eintrag mit der "Fail"-Strong-Richtlinie festzulegen, könnten Ihre

347
00:31:07,230 --> 00:31:13,460
Benutzer die Nachricht nicht mehr senden. Deshalb ist das Testen gut. Hier sind einige

348
00:31:13,460 --> 00:31:16,400
andere Beispiele, die etwas komplizierter sind. Eines davon wurde aufgenommen. Anstatt also

349
00:31:16,400 --> 00:31:19,270
die Richtlinie selbst zu definieren, weil Sie in diesem Beispiel einen Drittanbieter verwenden,

350
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

351
00:31:24,720 --> 00:31:31,530
Interessante daran ist de Verwendung von SPF. Wenn wir uns nur die Anzahl der Domains

352
00:31:31,530 --> 00:31:36,890
ansehen, die eine Art Richtlinie definiert haben, dann sieht die Zahl ziemlich gut aus. Ich denke,

353
00:31:36,890 --> 00:31:42,290
das gilt zum Beispiel für die beliebtesten Domains, ungefähr 70 %. Aber das Problem

354
00:31:42,290 --> 00:31:45,710
ist, dass die meisten von ihnen entweder schlecht konfiguriert sind, oder nur die Softfail-

355
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

356
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

357
00:31:56,700 --> 00:32:00,720
ankommen, weil der Empfänger denkt, dass sie sich nur im Testmodus befindet. Sie sollten E-

358
00:32:00,720 --> 00:32:07,940
Mails nicht automatische löschen. Ja. Eigentlich ist der Prozentsatz nicht so groß. Aber das

359
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

360
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,

361
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.

362
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,

363
00:32:30,060 --> 00:32:33,830
dass Sie einige Regeln, Regeln, Regeln haben und am Ende setzen Sie typischerweise nur

364
00:32:33,830 --> 00:32:41,460
diese Softfail ein. Falls wir als Penetrationstester also versuchen, von einer unbekannten IP-

365
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

366
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,

367
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

368
00:32:56,720 --> 00:33:02,250
wird meistens funktionieren. Eine Anmerkung hier ist, dass einige Systeme nicht nur diese

369
00:33:02,250 --> 00:33:06,590
binäre Klassifikation benutzen, egal ob etwas gut oder schlecht ist, sondern sie versuchen

370
00:33:06,590 --> 00:33:11,320
eine Bewertung vorzunehmen. Und dann kann es sein, dass Sie, Ihre E-Mail nicht automatisch

371
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

372
00:33:16,370 --> 00:33:22,540
hinzu. Aber wichtig ist, das es nicht automatisch zu Ende ist.

373
00:33:22,540 --> 00:33:29,970
Eine andere Sache ist dieses Include. Also Include ist sehr praktisch, wenn man mit

374
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

375
00:33:36,330 --> 00:33:43,100
scheint. Zumindest wird im Standard erwähnt, dass es ein schlecht gewählter Name war. Und

376
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

377
00:33:48,110 --> 00:33:52,720
passiert, wenn dies eingeschlossen ist, sollten Sie nicht einfach alles von innen kopieren und

378
00:33:52,720 --> 00:33:58,340
auf der obersten Ebene einfügen. Das ist nicht die Funktionsweise. Es wird versuchen, alle

379
00:33:58,340 --> 00:34:05,480
darin enthaltenen Prüfungen durchzuführen. Aber wenn dies fehlschlägt, wird die Nachricht

380
00:34:05,480 --> 00:34:10,250
nicht automatisch gelöscht. Es wird auf die oberste Ebene gehen und versuchen, die

381
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,

382
00:34:14,510 --> 00:34:20,570
entweder vergessen hat, dieses Minus zu ergänzen, oder Ihr Administrator hat es

383
00:34:20,570 --> 00:34:26,470
vergessen. In diesem Fall, selbst wenn Sie dieses Minus eingeschlossen haben, wird es

384
00:34:26,470 --> 00:34:34,089
nicht funktionieren. Ich denke, dass es funktionieren würde, weil, wenn der Empfänger

385
00:34:34,089 --> 00:34:39,569
es mit "Minus" überprüft hat, "all inside include" nicht dasselbe bedeutet wie auf der obersten

386
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

387
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

388
00:34:47,809 --> 00:34:54,409
diesen schwerwiegenden Fehler hat. Auf diesem Weg funktioniert es nicht. Und dann

389
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

390
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

391
00:35:03,569 --> 00:35:07,890
Zeiger. Im Grund genommen alles, was den Administratoren einfällt und der Grund dafür

392
00:35:07,890 --> 00:35:12,990
ist, dass sie einfach nicht sicher sind, wie es funktioniert. Sie wissen nicht, was sie eingeben

393
00:35:12,990 --> 00:35:17,100
sollen. Eine Sache, die darauf hinweist, ist zum Beispiel,

394
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

395
00:35:24,840 --> 00:35:27,930
und nur einen Server haben, haben verschiedene Server, verschiedene IP-Adressen

396
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

397
00:35:31,059 --> 00:35:34,500
keinen praktischen Grund gibt, MX in SPF aufzunehmen, denn keine E-Mail sollte durch

398
00:35:34,500 --> 00:35:41,109
ihren Posteingangsserver werden. Und ein anderer Fall könnte sein, dass die

399
00:35:41,109 --> 00:35:45,900
Adminisgtratoren verstehen, wie es funktioniert. Ihre Architektur ist aber wirklich

400
00:35:45,900 --> 00:35:51,470
chaotisch und sie senden E-Mails von vielen, vielen unterschiedlichen Stellen senden, was

401
00:35:51,470 --> 00:35:55,730
für Penetrationstester gut ist.

402
00:35:55,730 --> 00:36:03,359
Das bedeutet, dass sie nicht gut organisiert sind. OK. Und dann gibt es noch einen

403
00:36:03,359 --> 00:36:09,220
Schwachpunkt, der darin besteht, dass die Granularität nicht sehr gut geeignet ist. Das

404
00:36:09,220 --> 00:36:13,799
einzige, was Sie tun können, sind mehrere dieser Datensatztypen. Aber alles was sie tun,

405
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

406
00:36:19,650 --> 00:36:24,230
nicht nur mit dem Mailserver verknüpft. Auf einer IP kann möglicherweise ein Mailserver

407
00:36:24,230 --> 00:36:28,069
und eine Webserver oder eine Datenbank oder etwas anderes vorhanden sein. Das bedeutet,

408
00:36:28,069 --> 00:36:32,339
dass Sie als Penetrationstester dieses ausnutzen können. Nicht den Mailserver selbst,

409
00:36:32,339 --> 00:36:36,740
denn der Mailserver ist üblicherweise ziemlich unauffällig. Es gibt nicht viele Schwachstellen.

410
00:36:36,740 --> 00:36:42,740
Sie können sie einfach ausbessern, und das wars. Aber diese anderen Systeme, zum

411
00:36:42,740 --> 00:36:46,680
Beispiel das Web, lassen sich in den meisten Fällen leicht ausnutzen. In gewisser Weise kann

412
00:36:46,680 --> 00:36:50,809
man die Privilegien erhöhen, indem man sich Zugriff verschafft auf einem anderen Server mit

413
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

414
00:36:59,859 --> 00:37:04,950
werden alle SPF-Filter passieren. OK. Ein Beispiel ist "Shared Hosting", was sehr häufig

415
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.

416
00:37:10,359 --> 00:37:15,900
Vielleicht ist das ein Server, der nur zum Versenden von E-Mails verwendet wird. Aber

417
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

418
00:37:18,849 --> 00:37:24,289
bis Tausende. Das heißt, als Angreifer könne Sie mindestens einen von ihnen ausnutzen, oder

419
00:37:24,289 --> 00:37:26,940
für Shared Hosting kaufen. Sie können Kunde dieses Shared Hosting werden. Sie müssen

420
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

421
00:37:31,750 --> 00:37:38,140
Bezug auf SPF genauso gut aussieht, wie die eigene. Und das andere ist die falsche

422
00:37:38,140 --> 00:37:44,960
Überprüfung. Und das ist wahrscheinlich das schlimmste Problem mit SPF. Es gibt, wie ich

423
00:37:44,960 --> 00:37:49,640
bereits erwähnt habe, mindestens 2 Identifikatoren. Der Umschlagabsender, der

424
00:37:49,640 --> 00:37:53,740
externe also, der den Absender angibt. Und dann gibt es eine interne, die normalerweise

425
00:37:53,740 --> 00:37:58,589
die "Von" Kopfzeile ist. Aber von diesen beiden überprüft SPF nur, ob SPF die einzige

426
00:37:58,589 --> 00:38:03,140
Technologie ist, die Sie verwenden. SPF überprüft nur den ersten: den Umschlag-

427
00:38:03,140 --> 00:38:09,059
Absender. Und wie ich bereits erwähnt habe, sehen tatsächliche Benutzer, die die E-Mail

428
00:38:09,059 --> 00:38:13,279
erhalten, in den meisten Fällen keinen Umschlag-Absender. Sie werden

429
00:38:13,279 --> 00:38:17,559
beispielsweise dies sehen und eine "Von" oder eine der anderen Kopfzeilen. Dieses Verhalten

430
00:38:17,559 --> 00:38:22,830
wird tatsächlich durch DMARC behoben, was die Technologie ist, die ich erwähnt habe. Aber

431
00:38:22,830 --> 00:38:27,319
die Mehrheit der SPF-Installationen, Domains, die SPF nutzen, haben kein DMARC. Also sind

432
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

433
00:38:31,329 --> 00:38:36,630
Sie zum Weitergeben von SPF nur den Umschlag-Absender auf etwas anderes setzen.

434
00:38:36,630 --> 00:38:40,430
Zum Beispiel Ihre eigene kontrollierte Adresse, die alle SPF-Prüfungen bestehen wird. Aber

435
00:38:40,430 --> 00:38:49,010
dann können Sie die Kopfzeile innerhalb der "Von"-Adresse sehen, der mit der Organisation

436
00:38:49,010 --> 00:38:56,776
übereinstimmt, die Sie vorgeben wollen zu sein. Okay, Dann gibt es eine andere Technologie, die

437
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.

438
00:39:02,309 --> 00:39:11,450
Sorry für die Abkürzungen. Es heißt: Domainkeys identified mail. Sie müssen sich

439
00:39:11,450 --> 00:39:15,099
den langen Namen nicht Mehrken, nur die Abkürzung. Und was es im Grunde genommen

440
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

441
00:39:20,223 --> 00:39:24,640
schwer zu knacken. Es signiert jede Email, sodass jede E.Mail, die über den DKIM

442
00:39:24,640 --> 00:39:29,870
aktivierten Server versendet wird, eine Signatur erhält, die Sie als Empfänger kryptographisch

443
00:39:29,870 --> 00:39:35,059
verifizieren können. Wie Sie sehen können, ist es eigentlich ziemlich schwierig zu sehen, weil

444
00:39:35,059 --> 00:39:39,940
es nicht dafür gedacht ist, von Menschen verarbeitet zu werden. Es handelt sich um

445
00:39:39,940 --> 00:39:44,160
Kryptographie. Sie ist dafür gedacht, von Computern verarbeitet zu werden. Aber der

446
00:39:44,160 --> 00:39:48,300
wichtige Teil hier ist im Grunde, dass das gelbe Zeug diese kryptische Signatur ist. Aber er

447
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ß

448
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

449
00:40:02,269 --> 00:40:07,160
Organisation haben können, zum Beispiel könnte die Organisation E-Mails von Ihrem

450
00:40:07,160 --> 00:40:12,390
ursprünglichen SMTP-Server senden und dann können Sie einen Backup-Server haben, oder

451
00:40:12,390 --> 00:40:17,650
Sie haben vielleicht einige Nachrichten von Google oder eine Marketingkampagne und

452
00:40:17,650 --> 00:40:21,759
so weiter. Und dann könnte jede von ihnen unterschiedliche "Rot"-Parameter haben. Das

453
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,

454
00:40:26,970 --> 00:40:32,532
bei dem diese Kombination aus grün und rot verwendet wird. Und dann erhalten Sie den

455
00:40:32,532 --> 00:40:36,993
öffentlichen Schlüssel und können diesen verwenden, um die Signatur zu überprüfen.

456
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.

457
00:40:43,799 --> 00:40:48,730
Wie man löst man es? Ich denke, es ist einfach, wenn man die öffentliche Kryptographie.

458
00:40:48,730 --> 00:40:52,440
versteht. Auf der Absenderseite müssen Sie zuerst ein öffentliches und ein privates

459
00:40:52,440 --> 00:40:56,270
Schlüsselpaar generieren. Dann veröffentlichen Sie den öffentlichen Teil im DNS. Dann

460
00:40:56,270 --> 00:41:00,480
verwenden Sie den privaten Schlüssel, um jede Nachricht zu signieren. Der Empfänger macht

461
00:41:00,480 --> 00:41:04,380
jetzt sozusagen das Gegenteil. Sobald er die E-Mail erhalten hat, findet er anhand dieses roten

462
00:41:04,380 --> 00:41:09,000
und grünen Teils den richtigen DNS-Eintrag heraus, führen ihn aus, erhalten den

463
00:41:09,000 --> 00:41:12,526
öffentlichen Schlüssen und vergleichen dann, ob dieser öffentliche Schlüssel mit der Signatur

464
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

465
00:41:19,170 --> 00:41:27,309
Namen aus, Das Problem dabei ist, dass es mehrere Selektoren als DKIM sein können,

466
00:41:27,309 --> 00:41:31,670
wenn Sie die Konfiguration durchführen. Sie können so viele Selektoren auswählen, wie Sie

467
00:41:31,670 --> 00:41:37,170
wollen und der Empfänger weiß nicht, ob Sie tatsächlich einen Selektor hätten verwenden

468
00:41:37,170 --> 00:41:41,599
sollen und welchen Selektor Sie hätten verwenden sollen. Das Problem liegt darin, dass

469
00:41:41,599 --> 00:41:48,690
wenn wir nur über das normale DKIM sprechen, es für einen Penentrationstester oder einen

470
00:41:48,690 --> 00:41:52,630
Angreifer schwierig ist, die vorhandene Signatur zu ändern. Aber es ist einfach, es zu entfernen.

471
00:41:52,630 --> 00:41:57,619
Denn wenn man DKIM aus allen Kopfzeilen entfernt hat, weiß der Empfänger nicht, dass

472
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,

473
00:42:03,550 --> 00:42:08,640
muss ich, statt die Signatur zu überprüfen, diesen grünen Teil kennen. Diese Domain-

474
00:42:08,640 --> 00:42:14,712
Kennung und den Selektor, die Teil dieser Kopfzeile sind. Richtig. Das ist also ein großes

475
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

476
00:42:20,818 --> 00:42:26,700
wir die DKIM einfach abschneiden und die Nachricht ohne sie senden. Und falls die DKIM

477
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,

478
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

479
00:42:37,310 --> 00:42:43,040
ankommen. Eine andere Sache ist dieser Domain-Selektor. Warum müssen wir das

480
00:42:43,040 --> 00:42:48,280
überhabt einstellen? Weil die beste Übung natürlich ist, dass der Umschlag-Absender

481
00:42:48,280 --> 00:42:52,430
gleich der Kopfzeile und gleich diesem DKIM Domain-Sektor ist. Wenn Sie also von Alice

482
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

483
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

484
00:43:04,029 --> 00:43:09,619
so ist? Zum Beispiel gibt es auf der rechten Seite eine echte Domain, die Gmail, Google

485
00:43:09,619 --> 00:43:17,470
Mail, Google Suite verwendet hat. In diesem Fall signiert Google Suite standardmäßig alle

486
00:43:17,470 --> 00:43:22,430
Nachrichten. Wenn Sie jedoch keine eigene Konfiguration vornehmen, wird sie signiert mit

487
00:43:22,430 --> 00:43:28,369
der von ihm kontrollierten Domain "gappssmtp". Und das bedeutet, dass, obwohl

488
00:43:28,369 --> 00:43:32,579
technisch gesehen etwas mit DKIM signiert wurde, es aber nicht so signiert wurde, dass

489
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

490
00:43:36,406 --> 00:43:40,069
sollte der Empfänger in diesem Fall tun? Sollten Sie es einfach ignorieren? Sollten Sie die

491
00:43:40,069 --> 00:43:43,859
Nachricht zurückweisen oder etwas ähnliches? Der richtige Weg wäre also, sie nicht

492
00:43:43,859 --> 00:43:49,380
abzulehnen, sondern sie einfach als ungültig, zumindest nicht als gültige DKIM zu betrachten,

493
00:43:49,380 --> 00:43:53,829
aber es kommt darauf an. Also werden einige Validierer, sobald sie irgendeine DKIM sehen,

494
00:43:53,829 --> 00:44:01,228
diese validieren und sagen, das ist cool, das entspricht dem RFC. Aber nun kommt der

495
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

496
00:44:06,710 --> 00:44:11,339
manchen, nicht in allen Fällen so ist, aber manchmal kann man es tatsächlich ändern.

497
00:44:11,339 --> 00:44:17,190
Der am einfachsten zu ändernde Teil in den Nachrichten sind die Kopfzeilen. Weil DKIM,

498
00:44:17,190 --> 00:44:21,304
da es in den Kopfzeilen selbst platziert ist, nicht automatisch alte Kopfzeilen signiert. Das ist wie

499
00:44:21,304 --> 00:44:26,170
das Henne-Ei-Problem. Es werden standardmäßig nur 1 oder 2 Kopfzeilen signiert

500
00:44:26,170 --> 00:44:30,910
und Sie können weitere Kopfzeilen angeben, die signiert werden sollen, aber das passiert nicht

501
00:44:30,910 --> 00:44:35,569
automatisch. Für den Angreifer ist es eine einfache Sache, eine andere Kopfzeile

502
00:44:35,569 --> 00:44:40,400
hinzuzufügen. Wenn das Ihrem Plan in irgendeiner Weise hilft, dann ist das einfach

503
00:44:40,400 --> 00:44:43,940
zu machen. Sie fügen einfach eine weitere Kopfzeile hinzu. Ein interessante Teil ist, obwohl

504
00:44:43,940 --> 00:44:49,180
obwohl RFC, ist, wie ich vorhin erwähnt habe, dass einige Kopfzeilen wie "Gegenstand" oder

505
00:44:49,180 --> 00:44:53,093
"Von", nur in einer Kopie vorhanden sein sollten. Aktuell könnte man mehr, als eine

506
00:44:53,093 --> 00:44:59,367
"Von" Kopfzeile hinzufügen. Was in diesem Fall passiert ist ziemlich interessant. DKIM wird

507
00:44:59,367 --> 00:45:04,150
einverstanden sein, wenn Sie DKIM mitteilen, dass die Kopfzeile "Von" beispielsweise signiert

508
00:45:04,150 --> 00:45:11,279
werden soll. Dann wird es übereinstimmen und signiert die erste "Von" Kopfzeile von unten.

509
00:45:11,279 --> 00:45:16,807
Aber ziemlich viele Software E-Mail Kunden in einer Software werden dem Benutzer eigentlich

510
00:45:16,807 --> 00:45:23,940
nur zuerst von der anderen Seite, der oberen Seite angezeigt. Das bedeutet also, dass der

511
00:45:23,940 --> 00:45:29,546
Angreifer die Kopfzeilen verfälschen oder überschreiben kann, indem er einfach neue

512
00:45:29,546 --> 00:45:33,089
Kopfzeilen hinzufügt. Und dieses eigentliche Problem wird im DKIM RFC erwähnt und der

513
00:45:33,089 --> 00:45:38,885
Schutz, den sie vorschlagen ist dieser Code Over-Signing, damit Sie den RFC lesen können.

514
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.

515
00:45:44,919 --> 00:45:49,499
Manchmal ist das also gut. Manchmal ist das nicht gut. Ändern des Nachrichtentextes ist

516
00:45:49,499 --> 00:45:54,069
tatsächlich viel schwieriger. Im Grunde genommen ist die naive Art es zu tun durch

517
00:45:54,069 --> 00:45:58,140
Kryptographie, was wir aber nicht tun wollen. Und ein anderer Weg führt über diesen

518
00:45:58,140 --> 00:46:05,118
Parameter, der die Textkörperlänge angibt und das ist eigentlich wie fragwürdig die

519
00:46:05,118 --> 00:46:08,789
Funktionalität ist, die DKIM hat. Manchmal kann man festlegen, dass der Hash für Signierung-

520
00:46:08,789 --> 00:46:13,790
zwecke verwendet werden soll. Wir sollten nicht den ganzen Körper betrachten, sondern nur die

521
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

522
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.

523
00:46:24,500 --> 00:46:28,869
Falls sie es tun, besteht die Gefahr, dass der Textkörper möglicherweise überschrieben wird.

524
00:46:28,869 --> 00:46:34,245
Sie können einen anderen Mime-Typ hinzufügen und dann die Kopfzeilen ändern,

525
00:46:34,245 --> 00:46:37,569
um zu zeigen, dass dieser andere Mime-Typ DKIM passieren wird. In diesem Fall wird zum

526
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

527
00:46:42,634 --> 00:46:47,640
es also die 3. Technologie, die DMARC genannt wird. Und auch hier steht der vollständige

528
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-

529
00:46:52,424 --> 00:46:56,660
wörter: Berichterstattung und Konformität. Berichterstattung ist das Wort, mit dem die

530
00:46:56,660 --> 00:47:01,619
meisten Administratoren vertraut sind, denn das ist es, was DMARC meiner Meinung oft an

531
00:47:01,619 --> 00:47:08,390
sie verkauft. Berichterstattung bedeutet, dass man bei Problemen in diesem Fall, der anderen

532
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

533
00:47:13,309 --> 00:47:16,886
entweder einmal am Tag oder jedes Mal Berichte senden sollen. Für Penetrationstester

534
00:47:16,886 --> 00:47:20,509
ist das nicht sehr nützlich. Möglicherweise könnten wir verwenden, um zu verstehen,

535
00:47:20,509 --> 00:47:25,000
welche Art von Konfiguration auf der anderen Seite läuft. Aber im Moment ist diese Funktion

536
00:47:25,000 --> 00:47:30,309
noch nicht so weit verbreitet. Aber der andere Teil, die Konformität, ist wirklich sehr, sehr

537
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

538
00:47:35,251 --> 00:47:39,381
hatte dieses massive Problem, dass wenn man einfach die Kopfzeilen entfernt, dann hat der

539
00:47:39,381 --> 00:47:43,109
Empfänger keine Möglichkeit zu wissen, ob DKIM an erster Stelle stehen sollte. Wenn Sie

540
00:47:43,109 --> 00:47:49,377
DKIM zusammen mit DMARC verwenden, ist das Problem behoben, denn DMARC gibt nur

541
00:47:49,377 --> 00:47:55,269
an, dass Sie DMARC selbst haben. Das bedeutet, dass Sie automatisch mindestens

542
00:47:55,269 --> 00:47:59,220
eines von SPF oder DKIM passieren sollte. Also hat DKIM als Maßnahme das Problem

543
00:47:59,220 --> 00:48:03,576
automatisch gelöst. Die andere Sache, die sich ändert, ist die Änderung Semantik für SPF.

544
00:48:03,576 --> 00:48:08,599
Falls Sie nun beide, SPF und DMARC haben, könnte SPF gegen die "Von" Kopfzeile sein.

545
00:48:08,599 --> 00:48:13,150
Wie ich schon anmerkte, war das die größte Schwachstelle von SPF, denn wenn Sie selbst

546
00:48:13,150 --> 00:48:17,319
SPF selbst verwenden, war es sogar der Hard-to-Fail-Modus usw. Das bedeutet, dass

547
00:48:17,319 --> 00:48:21,440
Angreifer die "Von" Kopfzeilen immer noch modifizieren können und der Empfänger wird

548
00:48:21,442 --> 00:48:26,710
es nicht besser wissen. Ein minimales Beispiel für DMARC ist also wirklich sehr, sehr klein.

549
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

550
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

551
00:48:36,890 --> 00:48:40,740
diesen einen DNS-Eintrag zu erstellen. Und der Vorteil davon bestseht darin, wenn Sie DKIM

552
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

553
00:48:46,190 --> 00:48:50,680
haben DMARC erstellt. Das bedeutet, dass diese Domain keine E-Mails senden soll.

554
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

555
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

556
00:49:02,279 --> 00:49:07,480
meisten Domains da draußen darüber nachdenken sollten, die DMARC zu aktivieren.

557
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

558
00:49:15,471 --> 00:49:22,019
länger sein, aber es ist für die Penetratrionstester nicht von großem Nutzen.

559
00:49:22,019 --> 00:49:26,009
So, ein wichtiger Teil hier ist wieder die Richtlinie, die diese drei Werte annehmen kann:

560
00:49:26,009 --> 00:49:31,184
"keine", "Quarantäne" und "Ablehnung".Und wenn es "Quarantäne" ist, bedeutet das,

561
00:49:31,184 --> 00:49:39,109
dass die Nachricht im Falle eines Fehlers, im Spam-Ordner landen sollte.

562
00:49:39,109 --> 00:49:42,619
Wenn es "Ablehnung" ist, sollte sie direkt abgewiesen werden. Und wenn es "keine" ist, bedeutet es,

563
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.

564
00:49:47,960 --> 00:49:52,400
Es zeigt dass, obwohl DMARC die wirklich beste Technologie unter diesen 3 Technologien ist.

565
00:49:52,400 --> 00:49:59,655
Sie ist nicht wirklich weit verbreitet. Unglücklicherweise für die Befürworter.

566
00:49:59,655 --> 00:50:05,070
Eine ganz nette Tasche für alle Penetrationstester da draußen. Das bedeutet, dass man

567
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?

568
00:50:14,550 --> 00:50:18,480
Was passiert, wenn jemand DMARC implementiert hat? Können Penetrationstester nun nichts tun?

569
00:50:18,480 --> 00:50:23,526
nichts tun? Sie müssen nicht einmal Nachforschungen anstellen?

570
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

571
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.

572
00:50:33,859 --> 00:50:38,470
DKIM ist sehr leistungsstark und DMARC behebt den Mangel. (???) Das ist cool in der Theorie.

573
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

574
00:50:44,680 --> 00:50:49,751
Empfängerseite sowohl DKIM, als DMARC validieren. Unglücklicherweise tut dies eine

575
00:50:49,751 --> 00:50:53,932
ganze Menge von Software immer noch nicht Eine solche Software ist Microsoft Exchange.

576
00:50:53,932 --> 00:50:57,920
Und selbst wenn Sie nicht mit Microsoft Exchange arbeiten, stehen die Chancen gut, dass

577
00:50:57,920 --> 00:51:02,049
einige der Partner, mit denen Sie kommunizieren, Microsoft Exchange ausführen.

578
00:51:02,049 --> 00:51:05,700
Und standardmäßig gibt es keine Funktion zu DKIM. (???)

579
00:51:05,700 --> 00:51:12,619
Die meisten Systeme müssen tatsächlich SPF immer noch aus praktischen Gründen aktivieren.

580
00:51:12,619 --> 00:51:16,609
Das ist gut für Penetrationstester. Wenn SPF und DMARC standardmäßig zusammen

581
00:51:16,609 --> 00:51:21,502
aktiviert sind, dann behebt das wiederum eines der Hauptprobleme mit SPF, aber

582
00:51:21,502 --> 00:51:25,864
es behebt nich tautomatisch andere Probleme, weil nicht genug Potential für Fehlkonfigurationen

583
00:51:25,864 --> 00:51:32,119
da ist. So. Und die interessante Tatsache ist, dass DMARC nur fordert, dass eine der anderen

584
00:51:32,119 --> 00:51:37,970
Technologien SPF oderDKIM mitgegeben wird, um die E-Mail als gültig zu sehen.

585
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

586
00:51:42,749 --> 00:51:45,680
dem SPF vorgezogen werden soll, obwohl es viele andere Sektoren gibt.

587
00:51:45,680 --> 00:51:50,019
In der Praxis bedeutet dies, dass die meisten Systeme alle drei aktivieren,

588
00:51:50,019 --> 00:51:54,950
was eine gute praktische Lösung von Seiten der Penetrationstester ist.

589
00:51:54,950 --> 00:51:59,849
Wir ignorieren DKIM komplett und konzentrieren uns nur auf SPF, was das schwächste Glied in

590
00:51:59,849 --> 00:52:05,170
dieser Situation ist. Okay. Also nur eine Minute für Rekapitulation.

591
00:52:05,170 --> 00:52:11,559
Ich bin nicht sicher, ob ich noch mehr Zeit habe. Viel Zeit habe ich nicht. Okay.

592
00:52:11,559 --> 00:52:17,140
Okay. Entschuldigung. Yeah. Ein wirklich wichtiger Hinweis ist, wenn man die Systeme testet,

593
00:52:17,140 --> 00:52:22,270
dass beide Szenarien berücksichtigt werden sollen. Konzentrieren Sie sich also nicht

594
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

595
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

596
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

597
00:52:38,670 --> 00:52:43,961
implementieren, denn für beide brauchen Sie nur eine DNS-Konfiguration. Gerade eine für

598
00:52:43,961 --> 00:52:48,779
jede. Aber sie zu testen, sie richtig zu validieren ist schwieriger.

599
00:52:48,779 --> 00:52:52,643
Zunächst benötigen Sie die Software-Unterstützung, die man richtig konfigurieren muss.

600
00:52:52,643 --> 00:52:56,585
In der Praxis könnte es sein, dass viele Organisationen, die DMARC oder SPF auf der

601
00:52:56,585 --> 00:53:01,500
DNS-Seite für ausgehende E-Mailsaktiviert haben, es nicht richtig validieren.

602
00:53:01,500 --> 00:53:07,960
Yeah Okay. Sorry ich habe keine Zeit dafür.

603
00:53:07,960 --> 00:53:16,009
Das wars. Sorry. Vielleicht einige Fragen.

604
00:53:16,009 --> 00:53:24,601
Applaus

605
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.

606
00:53:29,719 --> 00:53:33,839
Ich sehe schon eine Person. Mikrophon Nr.2

607
00:53:33,839 --> 00:53:40,150
M2: Hey, vielen Dank. Kennen Sie einige gute Tools zur Überwachung von DMARC-

608
00:53:40,150 --> 00:53:44,339
Berichten, die ich von meinen Empfängern bekommen habe? A: Yeah. Das ist eine wirklich gute

609
00:53:44,339 --> 00:53:49,940
Frage. Wir als CERT empfehlen jedem, dies zu aktivieren. Aber leider sammeln alle Tools, die im

610
00:53:49,940 --> 00:53:55,190
Internet verbreitet sind, einige Daten über Sie.

611
00:53:55,190 --> 00:53:59,670
Sie verwenden diese für Marketingzwecke.

612
00:53:59,670 --> 00:54:04,412
Das ist nicht gut für Ihre Privatsphäre.

613
00:54:04,412 --> 00:54:07,880
Wenn Sie darüber besorgt sind, müssen Sie selbst etwas implementieren oder

614
00:54:07,880 --> 00:54:12,180
Sie müssen vielleicht ein Open-Source-Projekt starten. Herald: OK, Mikrophone Nr. 1

615
00:54:12,180 --> 00:54:16,428
M1: Danke für das gute Gespräch. Ich würde mich selbst als Administrator bezeichnen.

616
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.

617
00:54:23,609 --> 00:54:28,859
Daher bekomme ich den Rat, den PTR-Eintrag zu löschen.

618
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,

619
00:54:34,930 --> 00:54:39,549
was ich auch auch für nützlich halte.

620
00:54:39,549 --> 00:54:42,920
Wie stehen Sie zu Verkürzung Ihres SPF und zum PTR-Datensatz im Allgemeinen?

621
00:54:42,920 --> 00:54:47,530
A. Das hängt vom jeweiligen Anwendungsfall ab. Es kann sein, dass einige

622
00:54:47,530 --> 00:54:51,230
Organisationen tatsächlich diesen langen SPF benötigen und daran

623
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

624
00:54:55,799 --> 00:55:01,479
Includes, da diese nicht vorhanden sind. Sie sind keine Macros, sie werden nicht erweitert.

625
00:55:01,479 --> 00:55:07,755
Überlegen Sie, ob Sie wirklich so viele Datensätze brauchen, die so lang sind.

626
00:55:07,755 --> 00:55:12,119
Häufige Probleme darin, sofern Sie nicht Google oder etwas Ähnliches verwenden,

627
00:55:12,119 --> 00:55:16,970
benötigen Sie einen so langen SPF nicht wirklich.

628
00:55:16,970 --> 00:55:20,499
Es ist wahrscheinlich ein Problem mit einigen.

629
00:55:20,499 --> 00:55:26,660
Ja genau. Es ist wahrscheinlich ein Fehler bei den meisten Organisationen.

630
00:55:26,660 --> 00:55:36,489
Herald: OK. Nun, sehr. Nur ganz kurz.

631
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

632
00:55:40,496 --> 00:55:43,489
den Standards gelandet ist. Aber sie ist nicht in den Standards enthalten .

633
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.

634
00:55:48,859 --> 00:55:53,599
Ich bin mir nicht bewusst, dass er automatisch irgendwo abgelegt wird. Müsste kein Problem sein.

635
00:55:53,599 --> 00:55:56,380
Herald: Wir haben ein Menge weiterer Fragen hier.

636
00:55:56,380 --> 00:55:59,349
Nummer 6, ganz, ganz hinten.

637
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.

638
00:56:07,420 --> 00:56:13,800
Falls der Mailserver DKIM, DKARC und SPF akzeptiert, ist alles in Ordnung. Aber vor allem bei

639
00:56:13,800 --> 00:56:18,779
Google wird die E-Mail bei vielen Organisationen zugestellt, aber als Spam eingestuft.

640
00:56:18,779 --> 00:56:24,089
Das bedeutet, dass Sie im Posteingang des Empfängers nicht angezeigt wird.

641
00:56:24,089 --> 00:56:28,069
Haben Sie eine Lösung, um diese Problem gegen Google zu lösen?

642
00:56:28,069 --> 00:56:33,630
A. Ja, Ok. Also, ich habe verschiedene Meinungen darüber, denn eine Sache, die tatsächlich

643
00:56:33,630 --> 00:56:38,787
ermöglicht, was wir eigentlich tun sollten, ist, dass Sie so streng sind. Vielen Dank Google.

644
00:56:38,787 --> 00:56:42,859
Denn das ist der einzige Grund, warum wir überhaupt einen hohen Prozentsatz

645
00:56:42,859 --> 00:56:47,879
von SPF haben, der selbst falsch konfiguriert ist. Der einzige Grund, warum 70% Webseiten SPF

646
00:56:47,879 --> 00:56:52,829
verwenden, ist, dass sie mit Google kommunizieren müssen. Und Google wird Ihre E-Mail

647
00:56:52,829 --> 00:56:56,690
nicht akzeptieren, wenn SPF nicht auf der Grundlinie ist. So.

648
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,

649
00:57:04,269 --> 00:57:09,527
was es sagt, Ich verstehe die echten Administratoren, die dieses Problem haben. Google hat das

650
00:57:09,527 --> 00:57:15,239
Werkzeug. Sie kenne es wahrscheinlich. Hier können Sie überprüfen, was es über Ihre

651
00:57:15,239 --> 00:57:19,323
Domain denkt. Sie müssen dieses Problem also von Fall zu Fall prüfen.

652
00:57:19,323 --> 00:57:23,559
Oftmals kommt es vor, dass es trotz DKIM,DMARC etc. nicht richtig konfiguriert ist.

653
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

654
00:57:28,576 --> 00:57:31,259
es richtig konfiguriert haben, aber es bist einige Fehler.

655
00:57:31,259 --> 00:57:35,249
Herald: Okay. Geben wir dem Internet den Vorrang.

656
00:57:35,249 --> 00:57:40,170
Signal Angel: Wir haben eine Frage aus dem Internet. Wenn wir versuchen, eine Adresse zu

657
00:57:40,170 --> 00:57:43,819
überprüfen, wie wird mit E-Mail-Adressen ohne Antwort umgegangen.

658
00:57:43,819 --> 00:57:49,999
A. Keine Antwort, Es tut mir leid. Können Sie es bitte noch einmal vorlesen?

659
00:57:49,999 --> 00:57:55,170
Signal Angel: Wenn ich versuche, eine E-Mail Adresse zu überprüfen, wie geht man

660
00:57:55,170 --> 00:58:04,529
dann mit No-reply-E-Mails um? A: Vielleicht ging es um die No-reply Kopfzeile?

661
00:58:04,529 --> 00:58:10,650
Oder nicht vorhandene IP-Adressen? Signal Angel: Wie geht man mit E-Mails um?

662
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

663
00:58:14,809 --> 00:58:21,532
verstehe. Was also oft passiert ist, dass die E-Mail von nicht existierenden Adressen

664
00:58:21,532 --> 00:58:25,294
gesendet wird. Das war vielleicht die Frage. Die Beispielfrage "keine Antwort"

665
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

666
00:58:29,789 --> 00:58:34,339
Adresse handelt. Es gibt keine solche Adresse. Richtig. Und deshalb habe ich keine Antwort

667
00:58:34,339 --> 00:58:38,816
darauf. Denn laut RFC sollten Sie es praktisch trotzdem akzeptieren.

668
00:58:38,816 --> 00:58:43,627
Ich sagte bereits, dass viele Mailsysteme diese Adressen bereits löschen, wenn sie von

669
00:58:43,627 --> 00:58:46,420
nicht vorhandenen Adressen senden. Es sei denn, Sie sind Google oder etwas Großes.

670
00:58:46,420 --> 00:58:50,150
Dann werden Sie auf die weiße Liste gesetzt. Sie können es einfach nicht tun.

671
00:58:50,150 --> 00:58:54,779
Sie können keine E-Mails von einer nicht existierenden Adresse senden. Falls Sie in einer

672
00:58:54,779 --> 00:59:00,309
erartigen Situation sind, erstellen Sie die Adresse entfernen Sie alle E-Mails, die dort eintreffen, aber

673
00:59:00,309 --> 00:59:03,640
erstellen Sie die echte Adresse, damit Sie akzeptabel sind, wenn Sie auf der anderen Seite sind,

674
00:59:03,640 --> 00:59:08,269
und diese E-Mail erhalten. Das hängt von diesem speziellen Anwendungsfall ab.

675
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.

676
00:59:12,099 --> 00:59:16,220
Wenn Sie sie nicht kontaktieren, dann sollten Sie entscheiden, welches Risiko besteht, wenn Sie

677
00:59:16,220 --> 00:59:23,920
dieselben Adressen weglassen. Sind sie wichtig für Sie? Laut RFC sollten Sie diese Adressen

678
00:59:23,920 --> 00:59:28,660
also erhalten und verarbeiten. Herald: Okay. Mikrophon Nummer 4 bitte.

679
00:59:28,660 --> 00:59:33,040
M4: Hey, danke für diesen Vortrag. Kennen Sie die Bemühungen, Probleme mit großen

680
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

681
00:59:40,630 --> 00:59:47,450
keine eigenen SPF-Datensätze haben, zum Beispiel in der Kontrolle?

682
00:59:47,450 --> 00:59:53,253
A: Ja. In vielen Fällen kann man einfach mit ihnen Kontakt aufnehmen.

683
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

684
00:59:56,711 --> 01:00:01,770
sie tun sollen oder vielleicht wissen sie nicht, wie sie es besser machen sollen. Das stimmt.

685
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

686
01:00:05,249 --> 01:00:10,619
Unternehmen in einem bestimmten Land haben, schlage ich vor, das CERT zu kontaktieren.

687
01:00:10,619 --> 01:00:14,470
Auch wenn es sich nicht um eine Regierungsorganisation handelt, zum Beispiel in Lettland, wenn es

688
01:00:14,470 --> 01:00:18,700
sich um ein lettisches Unternehmen handelt. Wir würden die Trage vornehmen.

689
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

690
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

691
01:00:26,289 --> 01:00:30,060
als Dritte als falsche Konfiguration erscheint, kann ich das in diesem Vortrag nicht erwähnen.

692
01:00:30,060 --> 01:00:34,400
Wenn etwas nicht perfekt ist, heißt das nicht, dass es falsch ist.

693
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,

694
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

695
01:00:42,229 --> 01:00:46,700
getestet haben und wissen, dass sie, wenn sie eine sehr strenge Konfiguration haben, dass dann

696
01:00:46,700 --> 01:00:51,697
ein gewisser Prozentsatz ihrer E-Mails einfach nicht ankommen. Nicht wegen ihrer Problems,

697
01:00:51,697 --> 01:00:55,762
sofern wegen des Problems von jemand anderem. Richtig.

698
01:00:55,762 --> 01:00:59,759


699
01:00:59,759 --> 01:01:04,489


700
01:01:04,489 --> 01:01:08,970


701
01:01:08,970 --> 01:01:13,479


702
01:01:13,479 --> 01:01:17,755


703
01:01:17,755 --> 01:01:21,195


704
01:01:21,195 --> 01:01:25,159


705
01:01:25,159 --> 01:01:40,959


706
01:01:40,959 --> 01:01:53,000