Absicherung eines SMTP
Hallo,
ich oute mich gleich zu Beginn, ich bin kein Admin, sondern ein ISO (information security officer) und mit Linux hatte ich bisher nur rudimentär zu tun.
Bei unserem Mailserver ist folgendes aufgefallen. Unser MX-Record verweist auf einen Dienstleister, der ein Mailgateway mit Virenscanner, SPAM-Filter, etc. betreibt.
Die Kommunikation zwischen dem Mailgateway und unserem Mailserver erfolgt über einen Nicht-Standard Port. Damit das Mailgateway den Mailserver erreichen kann, steht dieser in der DMZ und hat Zugang zum Internet.
Und hier fängt das Problem an. Wir haben mittels Portscan den Port identifiziert, mit dem der Mailserver mit dem Mailgateway kommuniziert. Dann uns mit
openssl s_client -connect mail.server.de:12345
mit dem SMTP verbunden und waren damit dann in der Lage manuell (das ließe sich sicher auch mittels Scripts automatisiert in Masse bewerkstelligen) Mails über den SMTP im Namen der Geschäftsleitung zu generieren.
Wir sind außer der Kenntnis des Hostnamens des Mailservers ohne jegliche Kenntnis von Zugangsdaten, etc. ohne größeren Probleme - und wir sind jetzt keine Profis - bis zum SMTP durchgedrungen und konnten sowohl Mails nach intern wie auch nach extern erstellen. Einigermaßen versierte Angreifer brauchen wohl auch keinen Hostname, sondern scannen die IP-Bereiche nach Systemen ab und gehen dann wie wir mit einem Portscan weiter in die Tiefe.
Somit sehe ich hier eine kritische Schwachstelle, die viele Angriffsmöglichkeiten von CEO-Fraud, Social Engineering, Einbringen von Schadeprogrammen, aber auch Missbrauch des Mailservers als SPAM-Versender (hier greift eventuell das Mailgateway - hoffe ich).
Ich will unseren Admins nix böses, sondern sie aktiv unterstützen dieses Problem zu lösen.
Ich bin jetzt nicht so weit in der Tiefe, aber meinem technisch begrenzten Verständnis nach, sollte das Problem zu lösen sein, wenn SMTP-Auth aktiviert wird. Flankierend wäre meine Idee auch, mittels einem Tool wie Fail2ban Brute-Force-Angriffe auf den SMTP zu unterbinden.
Hier sträubt sich einer der Admins, der der Meinung ist, solche Tools bieten erst recht Einfallstore, jedoch hätte ich dann keine Ahnung, wie man Brute-Force Angriffe vermeiden will. Vielleicht kennt jemand einen anderen Ansatz.
Wäre das ein entsprechender best practice Ansatz, den ich den Admins so mitteilen kann?
Ich brauche da jetzt auch keine technischen Details, dafür sind die Admins da, sondern nur die Ansätze.
Danke im voraus,
Tanor
ich oute mich gleich zu Beginn, ich bin kein Admin, sondern ein ISO (information security officer) und mit Linux hatte ich bisher nur rudimentär zu tun.
Bei unserem Mailserver ist folgendes aufgefallen. Unser MX-Record verweist auf einen Dienstleister, der ein Mailgateway mit Virenscanner, SPAM-Filter, etc. betreibt.
Die Kommunikation zwischen dem Mailgateway und unserem Mailserver erfolgt über einen Nicht-Standard Port. Damit das Mailgateway den Mailserver erreichen kann, steht dieser in der DMZ und hat Zugang zum Internet.
Und hier fängt das Problem an. Wir haben mittels Portscan den Port identifiziert, mit dem der Mailserver mit dem Mailgateway kommuniziert. Dann uns mit
openssl s_client -connect mail.server.de:12345
mit dem SMTP verbunden und waren damit dann in der Lage manuell (das ließe sich sicher auch mittels Scripts automatisiert in Masse bewerkstelligen) Mails über den SMTP im Namen der Geschäftsleitung zu generieren.
Wir sind außer der Kenntnis des Hostnamens des Mailservers ohne jegliche Kenntnis von Zugangsdaten, etc. ohne größeren Probleme - und wir sind jetzt keine Profis - bis zum SMTP durchgedrungen und konnten sowohl Mails nach intern wie auch nach extern erstellen. Einigermaßen versierte Angreifer brauchen wohl auch keinen Hostname, sondern scannen die IP-Bereiche nach Systemen ab und gehen dann wie wir mit einem Portscan weiter in die Tiefe.
Somit sehe ich hier eine kritische Schwachstelle, die viele Angriffsmöglichkeiten von CEO-Fraud, Social Engineering, Einbringen von Schadeprogrammen, aber auch Missbrauch des Mailservers als SPAM-Versender (hier greift eventuell das Mailgateway - hoffe ich).
Ich will unseren Admins nix böses, sondern sie aktiv unterstützen dieses Problem zu lösen.
Ich bin jetzt nicht so weit in der Tiefe, aber meinem technisch begrenzten Verständnis nach, sollte das Problem zu lösen sein, wenn SMTP-Auth aktiviert wird. Flankierend wäre meine Idee auch, mittels einem Tool wie Fail2ban Brute-Force-Angriffe auf den SMTP zu unterbinden.
Hier sträubt sich einer der Admins, der der Meinung ist, solche Tools bieten erst recht Einfallstore, jedoch hätte ich dann keine Ahnung, wie man Brute-Force Angriffe vermeiden will. Vielleicht kennt jemand einen anderen Ansatz.
Wäre das ein entsprechender best practice Ansatz, den ich den Admins so mitteilen kann?
Ich brauche da jetzt auch keine technischen Details, dafür sind die Admins da, sondern nur die Ansätze.
Danke im voraus,
Tanor
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1067548716
Url: https://administrator.de/forum/absicherung-eines-smtp-1067548716.html
Ausgedruckt am: 03.04.2025 um 03:04 Uhr
28 Kommentare
Neuester Kommentar
Mahlzeit.
Ich sehe das Problem weniger bei euch (außer es wurde genau so beauftragt), sondern eher beim Dienstleister.
Natürlich lässt sich ein Email Gateway so konfigurieren, dass nur mit Auth versendet werden darf. Das sollte auch das Mindeste sein. Die Probleme, die dadurch auftreten können, hast du ja selber schon erkannt.
Zudem wäre es ja durchaus auch möglich die Verbindung von euch zum Dienstleister SMTP abzusichern in Form von VPN oder zumindest IP Whitelisting. Der Nicht-Standardport hilft euch hier überhaupt nicht. Das dauert 30sek, bis man diesen gefunden hat und bietet hierbei nur unzureichende Security. Ja, für automatisierte Scripte hilft das, aber wenn sich das mal jemand anschaut und den Portscan auswertet, hilft das einfach nicht.
Ist die Übertragung denn wenigstens standardmäßig verschlüsselt?
VG
Ich sehe das Problem weniger bei euch (außer es wurde genau so beauftragt), sondern eher beim Dienstleister.
Natürlich lässt sich ein Email Gateway so konfigurieren, dass nur mit Auth versendet werden darf. Das sollte auch das Mindeste sein. Die Probleme, die dadurch auftreten können, hast du ja selber schon erkannt.
Zudem wäre es ja durchaus auch möglich die Verbindung von euch zum Dienstleister SMTP abzusichern in Form von VPN oder zumindest IP Whitelisting. Der Nicht-Standardport hilft euch hier überhaupt nicht. Das dauert 30sek, bis man diesen gefunden hat und bietet hierbei nur unzureichende Security. Ja, für automatisierte Scripte hilft das, aber wenn sich das mal jemand anschaut und den Portscan auswertet, hilft das einfach nicht.
Ist die Übertragung denn wenigstens standardmäßig verschlüsselt?
VG
solche Tools bieten erst recht Einfallstore
Zumindestens für den Klassiker fail2ban ist das barer Unsinn. Bist du dir sicher das du da einen "wirklichen" Admin gefragt hat ?!Gutes Tool zum Testen ist auch: https://github.com/drwetter/testssl.sh
Moin,
Ihr habt also ein exterenes Antispam-Gateway auf das die MX Einträge verweisen.
Dieser sendet die Mails per SMTP an Euren Mail-Server.
Also sollte Euer Mail-Server, oder die Firewall, auch nur SMTP-Verbindungen von den Servern dieses Anbieters annehmen.
Auf Nachfrage bekommt man von denen immer eine Liste mit IP-Adressen.
Nur den Port zu ändern bringt (fast) gar nichts.
Die Kommunikation sollte natürlich über TLS/SSL Verschlüsselt sein.
Stefan
Ihr habt also ein exterenes Antispam-Gateway auf das die MX Einträge verweisen.
Dieser sendet die Mails per SMTP an Euren Mail-Server.
Also sollte Euer Mail-Server, oder die Firewall, auch nur SMTP-Verbindungen von den Servern dieses Anbieters annehmen.
Auf Nachfrage bekommt man von denen immer eine Liste mit IP-Adressen.
Nur den Port zu ändern bringt (fast) gar nichts.
Die Kommunikation sollte natürlich über TLS/SSL Verschlüsselt sein.
Stefan
Hallo,
Zu Eurem Penetrationstest: habt Ihr das aus dem Firmennetzwerk und auch von außerhalb versucht? Wenn das auch von außerhalb möglich war, solltet ihr den Dienstleister wechseln. Zumal ein offenes Gateway früher oder später auf einer Spam-Blacklist landet und Eure Firmenkommunikation nach extern dadurch zusammenbricht.
Grüße
lcer
Zitat von @tanor1969:
mit dem SMTP verbunden und waren damit dann in der Lage manuell (das ließe sich sicher auch mittels Scripts automatisiert in Masse bewerkstelligen) Mails über den SMTP im Namen der Geschäftsleitung zu generieren.
Wir sind außer der Kenntnis des Hostnamens des Mailservers ohne jegliche Kenntnis von Zugangsdaten, etc. ohne größeren Probleme - und wir sind jetzt keine Profis - bis zum SMTP durchgedrungen und konnten sowohl Mails nach intern wie auch nach extern erstellen. Einigermaßen versierte Angreifer brauchen wohl auch keinen Hostname, sondern scannen die IP-Bereiche nach Systemen ab und gehen dann wie wir mit einem Portscan weiter in die Tiefe.
Ich bin jetzt nicht so weit in der Tiefe, aber meinem technisch begrenzten Verständnis nach, sollte das Problem zu lösen sein, wenn SMTP-Auth aktiviert wird. Flankierend wäre meine Idee auch, mittels einem Tool wie Fail2ban Brute-Force-Angriffe auf den SMTP zu unterbinden.
Ihr müsst konsequent fordern, dass sich jeder Absender authentifizieren muss. Das ist Aufgabe des Mailservers - also Eure - wenn Ihr den selbst betreibt. Aufgabe des Dienstleisters ist es, abzusichern, dass das Gateway nur von authorisierten Kommunikationspartnern genutzt werden kann.mit dem SMTP verbunden und waren damit dann in der Lage manuell (das ließe sich sicher auch mittels Scripts automatisiert in Masse bewerkstelligen) Mails über den SMTP im Namen der Geschäftsleitung zu generieren.
Wir sind außer der Kenntnis des Hostnamens des Mailservers ohne jegliche Kenntnis von Zugangsdaten, etc. ohne größeren Probleme - und wir sind jetzt keine Profis - bis zum SMTP durchgedrungen und konnten sowohl Mails nach intern wie auch nach extern erstellen. Einigermaßen versierte Angreifer brauchen wohl auch keinen Hostname, sondern scannen die IP-Bereiche nach Systemen ab und gehen dann wie wir mit einem Portscan weiter in die Tiefe.
Ich bin jetzt nicht so weit in der Tiefe, aber meinem technisch begrenzten Verständnis nach, sollte das Problem zu lösen sein, wenn SMTP-Auth aktiviert wird. Flankierend wäre meine Idee auch, mittels einem Tool wie Fail2ban Brute-Force-Angriffe auf den SMTP zu unterbinden.
Zu Eurem Penetrationstest: habt Ihr das aus dem Firmennetzwerk und auch von außerhalb versucht? Wenn das auch von außerhalb möglich war, solltet ihr den Dienstleister wechseln. Zumal ein offenes Gateway früher oder später auf einer Spam-Blacklist landet und Eure Firmenkommunikation nach extern dadurch zusammenbricht.
Grüße
lcer
Ich bin anderer Meinung.
Der Rest der Welt auch ! Du bist da auf dem richtigen Weg. Der o.a. "Admin" ist dann eher ein Kandidat für den Heise Ticker wenn das Kind in den Brunnen gefallen ist. In jedem Falle erfordert das löchrige Konstrukt eine dringende Überarbeitung. Die Kollegen oben (und unten) haben dazu ja schon alles gesagt.
Hallo,
so wie ich dich verstanden habe, steht euer Mailserver bei euch in der DMZ und kommuniziert ein- und ausgehend mit dem Mailgateway des Providers.
Ist dies richtig so ?
Dann sollte auf eurer Firewall die Kommunikation des Mailservers ein- und ausgehend auf die IP Adresse bzw. Name des Mailgateways eingeschränkt werden, dann ist auch kein Zugriff von außerhalb möglich und es kann kein Mißbrauch über SMPT betrieben werden.
Gr0ß
CH
so wie ich dich verstanden habe, steht euer Mailserver bei euch in der DMZ und kommuniziert ein- und ausgehend mit dem Mailgateway des Providers.
Ist dies richtig so ?
Dann sollte auf eurer Firewall die Kommunikation des Mailservers ein- und ausgehend auf die IP Adresse bzw. Name des Mailgateways eingeschränkt werden, dann ist auch kein Zugriff von außerhalb möglich und es kann kein Mißbrauch über SMPT betrieben werden.
Gr0ß
CH
Moin...
also Fail2Ban ist eigentlich schon fast pflicht
da dein mailserver eh nur mit dem Mailgateway des Dienstleisters redet, kannst du das ja auch auf diesen einen host einschränken!
oder mach ganz dicht, und wenn möglich rede mit dem Mailgateway über ein VPN!
allerdings, verlasse dich nicht aud den Dienstleister, sonder nutze ein eigenes AV Programm...
Frank
also Fail2Ban ist eigentlich schon fast pflicht
da dein mailserver eh nur mit dem Mailgateway des Dienstleisters redet, kannst du das ja auch auf diesen einen host einschränken!
oder mach ganz dicht, und wenn möglich rede mit dem Mailgateway über ein VPN!
allerdings, verlasse dich nicht aud den Dienstleister, sonder nutze ein eigenes AV Programm...
Frank
Hallo,
Für eingehende Emails an den Mailserver die Ihr aus Eurer Domain versenden wollt, sollte aber die Authentifizierung gefordert werden.
Grüße
lcer
Zitat von @tanor1969:
Ich hatte mich da vielleicht nicht deutlich genug ausgedrückt. @ChriBo hat es genau richtig dargestellt.
Mails laufen über das Mailgateway und werden dann an unseren Mailserver gesendet. Unser Problem liegt nicht am Mailgateway, sondern bei unserem eigenen Mailserver.
Unser Angriff auf unseren Mailserver lief über das Internet, also von außen, und nicht gegen das Mailgateway des Dienstleisters.
Deshalb bin ich da auch echt alarmiert, dass das ging und vermutlich schon lange so möglich ist.
Vermutlich war hier bisher mehr Glück als Verstand im Spiel, dass es hier nicht schon geknallt hat.
Also ich fasse mal zusammen:
Generell sollte der SMTP eine Authentisierung verlangen (auch wegen potentieller Schadprogramme die versuchen könnten von intern den SMTP zu nutzen)
nein, nicht unbedingt. SMTP ist das Inter-Mailserver-Transportprotokoll https://de.wikipedia.org/wiki/Mail_Transfer_Agent Mailserver müssen für sie bestimmte Emails beliebiger Empfänger entgegennehmen können. SMTP muss eingehen auch ohne Authentifizierung erlaubt sein. Zumindest gilt das für den öffentlichen "MX-Server". Ihr solltet prüfen, ob Emails wirklich ausschließlich über das Gateway kommen, ober ob da noch irgendetwas anderes "läuft".Ich hatte mich da vielleicht nicht deutlich genug ausgedrückt. @ChriBo hat es genau richtig dargestellt.
Mails laufen über das Mailgateway und werden dann an unseren Mailserver gesendet. Unser Problem liegt nicht am Mailgateway, sondern bei unserem eigenen Mailserver.
Unser Angriff auf unseren Mailserver lief über das Internet, also von außen, und nicht gegen das Mailgateway des Dienstleisters.
Deshalb bin ich da auch echt alarmiert, dass das ging und vermutlich schon lange so möglich ist.
Vermutlich war hier bisher mehr Glück als Verstand im Spiel, dass es hier nicht schon geknallt hat.
Also ich fasse mal zusammen:
Generell sollte der SMTP eine Authentisierung verlangen (auch wegen potentieller Schadprogramme die versuchen könnten von intern den SMTP zu nutzen)
Für eingehende Emails an den Mailserver die Ihr aus Eurer Domain versenden wollt, sollte aber die Authentifizierung gefordert werden.
Die Firewall des Mailservers sollte so konfiguriert werden, dass nur die IP(s) des Mailgateway sich zum Mailserver von außen verbinden dürfen
genau.Grüße
lcer
moin...
Deshalb bin ich da auch echt alarmiert, dass das ging und vermutlich schon lange so möglich ist.
was soll den möglich sein? wo genau sind die schwachstellen?
Vermutlich war hier bisher mehr Glück als Verstand im Spiel, dass es hier nicht schon geknallt hat.
was soll genau knallen?
Also ich fasse mal zusammen:
Generell sollte der SMTP eine Authentisierung verlangen (auch wegen die versuchen könnten von intern den SMTP zu nutzen)
also dein mailserver sollte schon kein SMTP Open Relay sein!
das hat erstmal nix mit potentieller Schadprogrammen zu tun... und wenn die intern am werk sind, nutzen die eh selten dein mailserver, sondern das internet gateway.... also anderes Thema!
Jetzt bitte noch eine realistische Einschätzung - Standardwissen eines Admins?
Wie gesagt ich will denen nix böses, aber ich habe so den Verdacht, dass es hier einen dringenden Schulungsbedarf gibt.
Bye
Tanor
Edit: Für den Mailserver sind übrigens die genannten Admins bzw. wir selbst verantwortlich
Frank
Zitat von @tanor1969:
Ich hatte mich da vielleicht nicht deutlich genug ausgedrückt. @ChriBo hat es genau richtig dargestellt.
Mails laufen über das Mailgateway und werden dann an unseren Mailserver gesendet. Unser Problem liegt nicht am Mailgateway, sondern bei unserem eigenen Mailserver.
Unser Angriff auf unseren Mailserver lief über das Internet, also von außen, und nicht gegen das Mailgateway des Dienstleisters.
was genau hast du denn angegriffen, und womit?Ich hatte mich da vielleicht nicht deutlich genug ausgedrückt. @ChriBo hat es genau richtig dargestellt.
Mails laufen über das Mailgateway und werden dann an unseren Mailserver gesendet. Unser Problem liegt nicht am Mailgateway, sondern bei unserem eigenen Mailserver.
Unser Angriff auf unseren Mailserver lief über das Internet, also von außen, und nicht gegen das Mailgateway des Dienstleisters.
Deshalb bin ich da auch echt alarmiert, dass das ging und vermutlich schon lange so möglich ist.
Vermutlich war hier bisher mehr Glück als Verstand im Spiel, dass es hier nicht schon geknallt hat.
Also ich fasse mal zusammen:
Generell sollte der SMTP eine Authentisierung verlangen (auch wegen die versuchen könnten von intern den SMTP zu nutzen)
das hat erstmal nix mit potentieller Schadprogrammen zu tun... und wenn die intern am werk sind, nutzen die eh selten dein mailserver, sondern das internet gateway.... also anderes Thema!
Die Firewall des Mailservers sollte so konfiguriert werden, dass nur die IP(s) des Mailgateway sich zum Mailserver von außen verbinden dürfen
also die Firewall des mailserver hat da auch nicht viel zu sagen, dein SMTP dienst darf SMTP anfragen eben nur auf die IP deines mailgateways antworten lassen!Jetzt bitte noch eine realistische Einschätzung - Standardwissen eines Admins?
Wie gesagt ich will denen nix böses, aber ich habe so den Verdacht, dass es hier einen dringenden Schulungsbedarf gibt.
Bye
Tanor
Edit: Für den Mailserver sind übrigens die genannten Admins bzw. wir selbst verantwortlich
Frank
Zitat von @tanor1969:
@Vision2015: Wir haben einen Portscan auf unserem von außen erreichbaren Mailserver durchgeführt, danach dann mit openssl s_client verbunden und waren dann schon im SMTP, dort konnten wir im Textmodus Mails erstellen.
ja... so macht man das gewöhnlich auch... der SMTP dienst nimmt erstmal mails an.... das ist noch nicht gefährlich!@Vision2015: Wir haben einen Portscan auf unserem von außen erreichbaren Mailserver durchgeführt, danach dann mit openssl s_client verbunden und waren dann schon im SMTP, dort konnten wir im Textmodus Mails erstellen.
deswegen ist er ja da
Die Schwachstelle ist einfach, dass wir es konnten, weil der SMTP Open Relay spielt. Wir haben Mails nach intern und extern versenden können. Die Mails sahen natürlich sauber aus, auch vom Mailrouting. Wir konnten Mails im Namen der Geschäftsleitung versenden.
und glaube mir, ich versende auch mails im Namen deiner Geschäftsleitung, ohne dein Netzwerk zu kennen, und ohne dein Open Relay zu nutzen!
Was die Schadprogramme angehen, ich habe sehr wohl schon genug gesehen, die versuchen sich über Adressbücher weiter nach außen zu mailen. Sehe ich zwar primär als Aufgabe des Mailgateways und des Virenschutzes, aber meiner Meinung nach eine weitere Schutzmaßnahme.
also als ISO sollte das wissen aber auch da sein!
Wegen dem Zugang des Mailgateways zum Mailserver - ich bin wie gesagt kein Admin, sondern der, der immer die doofen Fragen an die Admins stellt. Ich kann also auch im SMTP selbst konfigurieren, mit wem er Kontakt aufnehmen darf und muss da die Firewall nicht bemühen?
natürlich, wenn dein linux mail server eh nur mit einem host reden darf, brauchst du auch kein Fail2BAN!
Bye
Tanor
Hallo tanor1969,
Warum ist euer Mailserver vom außerhalb erreichbar ?
Aus Sicht des Internets (MX Record) ist das Gateway des Dienstleisters der Mailserver und für den Empfang und das Versenden der Mails zuständig.
Konfiguriert eure Firewall vernünfig: SMTP(s) eingehend und ausgehend nur zu und von dem Gateway und gut ist.
Es besteht keinerlei Notwendigkeit SMTP von any zu erlauben.
Gruß
CH
Warum ist euer Mailserver vom außerhalb erreichbar ?
Aus Sicht des Internets (MX Record) ist das Gateway des Dienstleisters der Mailserver und für den Empfang und das Versenden der Mails zuständig.
Konfiguriert eure Firewall vernünfig: SMTP(s) eingehend und ausgehend nur zu und von dem Gateway und gut ist.
Es besteht keinerlei Notwendigkeit SMTP von any zu erlauben.
Gruß
CH
Hallo
Grüße
lcer
Zitat von @tanor1969:
Für mich aber wiederum ein anderes Thema. Da gehört ein MDM hin, das die PIM-Funktionalitäten über einen Container und VPN-Verbindung zentral abbildet und das MDM intern an den Mailserver geht um die Mails zu synchronisieren.
Du solltest Dich dringend mit Deinen Admins zusammensetzen. Außerdem, wenn Du - wie heißt das - ISO bist, Deine Kenntnis im Bereich Netzwerkprotokolle aufbessern. Sonst kommt das so rüber, als käme da jemand mit schicken neuen Abkürzungen daher, der alles neu erfinden muss, aber leider nicht weiß, wovon er spricht. Im dümmsten Fall suchen sich Deine Admins neue Arbeitgeber, und der Ersatz versucht erst mal Monate lang die gewachsene IT zu verstehen.Für mich aber wiederum ein anderes Thema. Da gehört ein MDM hin, das die PIM-Funktionalitäten über einen Container und VPN-Verbindung zentral abbildet und das MDM intern an den Mailserver geht um die Mails zu synchronisieren.
Grüße
lcer
Jetzt wird mir wieder mal vieles klar.
INFORMATION SECURITY OFFICER
3 Tage 3200€
Voraussetzungen:
Zertifikat Information Security Foundation.
2 Tage Schulung
TEILNEHMERKREIS
z.B. Verantwortliche von KRITIS-Betreibern
4000€ und ne Woche und ich kann mich als Verantwortlicher bei der KRITIS Bewerben
https://www.tuvsud.com/de-de/store/akademie/seminare-management/informat ...
INFORMATION SECURITY OFFICER
3 Tage 3200€
Voraussetzungen:
Zertifikat Information Security Foundation.
2 Tage Schulung
TEILNEHMERKREIS
z.B. Verantwortliche von KRITIS-Betreibern
4000€ und ne Woche und ich kann mich als Verantwortlicher bei der KRITIS Bewerben
https://www.tuvsud.com/de-de/store/akademie/seminare-management/informat ...
moin...
ich sehe auch kein problem, das Mobile Endgeräte direkt auf den Mailserver zugreifen! wo wäre da dein Problem genau?
das Problem ist, du bist ein ISO, zudem kommt dazu, du hast von Tuten und Blasen keine Ahnung- ein ausgewachsener Admin lässt dich im Kreis laufen, und du merkst das nicht einmal.... glaube mir, ich kenne da noch 2 Jungs, die rennen noch
ja... so machen admins das, wenn uns jemand versucht schlau über die schulter zu schauen, und wir merken, außer theorie ist da nix... klar kein Meister ist vom Himmel gefallen, deswgen mein Rat an dich, wenn dein AG schon Geld für eine ISO stelle hat, und du bedenken hast, wie euer netzwerk zustand ist, buche doch einen externen Dinstleister für ein Audit! da wird ja rauskommen was im argen liegt, oder auch nicht!
Ich denke ich habe jetzt genug Info bekommen. Vielen Dank an alle Helfer.
Bye
Tanor
Frank
Zitat von @tanor1969:
Hi CH,
man wirft mir ja Infos zu wie Brotkrumen einem Eichhörnchen. Ich bin gerade über ein Dokument gestolpert, das mir dem Anschein nach den Hinweis gibt, dass wohl mobile Endgeräte direkt auf den Mailserver über das Internet zugreifen. Ich hoffe ich bekomme da auch bald konkrete Antworten, ob dem tatsächlich so ist. Das würde erklären, warum der Mailserver so da steht wie er nun da steht.
aha... also aus meiner sicht spricht da auch nichts gegen! mach das Relay zu, und gut ist (wenn es nicht schon zu ist)Hi CH,
man wirft mir ja Infos zu wie Brotkrumen einem Eichhörnchen. Ich bin gerade über ein Dokument gestolpert, das mir dem Anschein nach den Hinweis gibt, dass wohl mobile Endgeräte direkt auf den Mailserver über das Internet zugreifen. Ich hoffe ich bekomme da auch bald konkrete Antworten, ob dem tatsächlich so ist. Das würde erklären, warum der Mailserver so da steht wie er nun da steht.
ich sehe auch kein problem, das Mobile Endgeräte direkt auf den Mailserver zugreifen! wo wäre da dein Problem genau?
Für mich aber wiederum ein anderes Thema. Da gehört ein MDM hin, das die PIM-Funktionalitäten über einen Container und VPN-Verbindung zentral abbildet und das MDM intern an den Mailserver geht um die Mails zu synchronisieren. Aber das ist ein anderes Thema. Eine weitere Baustelle ...
ich hoffe du weißt auch wovon du sprichst......das Problem ist, du bist ein ISO, zudem kommt dazu, du hast von Tuten und Blasen keine Ahnung- ein ausgewachsener Admin lässt dich im Kreis laufen, und du merkst das nicht einmal.... glaube mir, ich kenne da noch 2 Jungs, die rennen noch
ja... so machen admins das, wenn uns jemand versucht schlau über die schulter zu schauen, und wir merken, außer theorie ist da nix... klar kein Meister ist vom Himmel gefallen, deswgen mein Rat an dich, wenn dein AG schon Geld für eine ISO stelle hat, und du bedenken hast, wie euer netzwerk zustand ist, buche doch einen externen Dinstleister für ein Audit! da wird ja rauskommen was im argen liegt, oder auch nicht!
Ich denke ich habe jetzt genug Info bekommen. Vielen Dank an alle Helfer.
Bye
Tanor
Zitat von @Xerebus:
Jetzt wird mir wieder mal vieles klar.
INFORMATION SECURITY OFFICER
3 Tage 3200€
Voraussetzungen:
Zertifikat Information Security Foundation.
2 Tage Schulung
TEILNEHMERKREIS
z.B. Verantwortliche von KRITIS-Betreibern
4000€ und ne Woche und ich kann mich als Verantwortlicher bei der KRITIS Bewerben
https://www.tuvsud.com/de-de/store/akademie/seminare-management/informat ...
Jetzt wird mir wieder mal vieles klar.
INFORMATION SECURITY OFFICER
3 Tage 3200€
Voraussetzungen:
Zertifikat Information Security Foundation.
2 Tage Schulung
TEILNEHMERKREIS
z.B. Verantwortliche von KRITIS-Betreibern
4000€ und ne Woche und ich kann mich als Verantwortlicher bei der KRITIS Bewerben
https://www.tuvsud.com/de-de/store/akademie/seminare-management/informat ...
na ja... erst war es nach dem Motto, Hurra, wir werden jetzt Datenschutzbeauftragte.....
und jetzt tauchen immer mehr ISO´s auf.... ich finde die lustig und teilweise niedlich
einige haben sogar MS Zertifikate....
Frank
@tanor1969
Für dich zur Zusammenfassung:
- SMTP ohne Authentifizierung für jeden erreichbar --> SCHLECHT! Da hast du völlig recht, das muss verhindert werden.
- Grundsätzliche Erreichbarkeit eures Mailservers von außen: Muss nicht schlecht sein.
Lösung hängt natürlich davon ab, was die Anforderung an die Maschine ist.
- Authentifizierung erzwingen wäre immer gut
- Wenn der Mailserver ausschließlich mit dem Providergateway kommuniziert: Firewall auf die IP festtackern wie schon von einigen vorgeschlagen als quick-fix, da muss der Provider nämlich erstmal nichts machen.
Ich finde übrigens nicht, dass der ISO zwingend Netzwerkprofi sein muss. Ein ISO muss nicht die Lösung diktieren, sondern eigentlich nur erstmal ein potentielles Risiko erkennen (Hat Tanor gemacht), dann prüfen ob das in dem konkreten Fall nicht vll. abgefangen wird (Hat Tanor gemacht) und dann die Verantwortlichen darauf hinweisen, dass man hier ein Risiko sieht.
Dieses muss dann bewertet werden und bei entsprechend hohem Risiko reagiert werden, aber das ist Entscheidung der GF. Sobald Tanor eine Risikoanalyse hat wo drin steht: Die Admins sehen hier kein Risiko, ist seine Arbeit erstmal getan.
Ich finde die teils abfällige Behandlung nicht zielführend.
Für dich zur Zusammenfassung:
- SMTP ohne Authentifizierung für jeden erreichbar --> SCHLECHT! Da hast du völlig recht, das muss verhindert werden.
- Grundsätzliche Erreichbarkeit eures Mailservers von außen: Muss nicht schlecht sein.
Lösung hängt natürlich davon ab, was die Anforderung an die Maschine ist.
- Authentifizierung erzwingen wäre immer gut
- Wenn der Mailserver ausschließlich mit dem Providergateway kommuniziert: Firewall auf die IP festtackern wie schon von einigen vorgeschlagen als quick-fix, da muss der Provider nämlich erstmal nichts machen.
Ich finde übrigens nicht, dass der ISO zwingend Netzwerkprofi sein muss. Ein ISO muss nicht die Lösung diktieren, sondern eigentlich nur erstmal ein potentielles Risiko erkennen (Hat Tanor gemacht), dann prüfen ob das in dem konkreten Fall nicht vll. abgefangen wird (Hat Tanor gemacht) und dann die Verantwortlichen darauf hinweisen, dass man hier ein Risiko sieht.
Dieses muss dann bewertet werden und bei entsprechend hohem Risiko reagiert werden, aber das ist Entscheidung der GF. Sobald Tanor eine Risikoanalyse hat wo drin steht: Die Admins sehen hier kein Risiko, ist seine Arbeit erstmal getan.
Ich finde die teils abfällige Behandlung nicht zielführend.
Moin,
Das ist eine Fehlkonfiguration eures MTAs. Sofern die Mails durch einen Provider "gefiltert" werden sollen, muß bei Eurem MTA eingestellt werden, daß nur von Eurem Provider Mails angenommen werden. Ansonnsten kann Euch Hinz und Kunz Mails schicken.
Und nachdem Ihr Mails vom GF anscheinend vom faken könnte, habt Ihr nciht einmal korrekte Authentifizierung eingestellt. Normalerweise konfiguriert man den MTA so, daß extnerne Mails nach innen ohne Authentifizierung angenommen werden und Absender von mails mit der Internen domains sich athentifizieren müssen.
Ihr solltet dringend mal einen Fachmann an die Kiste lassen.
lks
Das ist eine Fehlkonfiguration eures MTAs. Sofern die Mails durch einen Provider "gefiltert" werden sollen, muß bei Eurem MTA eingestellt werden, daß nur von Eurem Provider Mails angenommen werden. Ansonnsten kann Euch Hinz und Kunz Mails schicken.
Und nachdem Ihr Mails vom GF anscheinend vom faken könnte, habt Ihr nciht einmal korrekte Authentifizierung eingestellt. Normalerweise konfiguriert man den MTA so, daß extnerne Mails nach innen ohne Authentifizierung angenommen werden und Absender von mails mit der Internen domains sich athentifizieren müssen.
Ihr solltet dringend mal einen Fachmann an die Kiste lassen.
lks
Hallo,
https://datatracker.ietf.org/doc/html/rfc4409
Man muss unterscheiden zwischen:
Bei Postfix laufen da zum Beispiel separate Daemons für die beiden Varianten.
Ersteres muss (heute) immer über eine Authenfizierung des Clients abgesichert sein.
Letzteres benötigt normalerweise keine Authentifizierung. In diesem Anwendungsfall (vorgeschaltetes Relay) kann man die Authentifizierung nutzen um das Einliefern auf den Host des Relays zu beschränken. Das gleiche erreicht man aber auch per Firewall-Regel. Die Lösung über eine Authentifizierung ist Robust gegenüber einer Änderung der IP des Relays aber komplexer, die Firewalllösung ist schneller zu implementieren.
Grüße
lcer
Zitat von @Drohnald:
Ich finde übrigens nicht, dass der ISO zwingend Netzwerkprofi sein muss. Ein ISO muss nicht die Lösung diktieren, sondern eigentlich nur erstmal ein potentielles Risiko erkennen (Hat Tanor gemacht), dann prüfen ob das in dem konkreten Fall nicht vll. abgefangen wird (Hat Tanor gemacht) und dann die Verantwortlichen darauf hinweisen, dass man hier ein Risiko sieht.
Dieses muss dann bewertet werden und bei entsprechend hohem Risiko reagiert werden, aber das ist Entscheidung der GF. Sobald Tanor eine Risikoanalyse hat wo drin steht: Die Admins sehen hier kein Risiko, ist seine Arbeit erstmal getan.
Nun ist es so, dass im richtigen Leben kein Unternehmen davon profitiert, dass jemand jedes Risiko das er sieht ungefiltert an die GF meldet. Er meldet ja auch nicht das Risiko eines Meteoriteneinschlags in das Rechenzentrum. Daher etwas Aufklärung zum Thema:Ich finde übrigens nicht, dass der ISO zwingend Netzwerkprofi sein muss. Ein ISO muss nicht die Lösung diktieren, sondern eigentlich nur erstmal ein potentielles Risiko erkennen (Hat Tanor gemacht), dann prüfen ob das in dem konkreten Fall nicht vll. abgefangen wird (Hat Tanor gemacht) und dann die Verantwortlichen darauf hinweisen, dass man hier ein Risiko sieht.
Dieses muss dann bewertet werden und bei entsprechend hohem Risiko reagiert werden, aber das ist Entscheidung der GF. Sobald Tanor eine Risikoanalyse hat wo drin steht: Die Admins sehen hier kein Risiko, ist seine Arbeit erstmal getan.
https://datatracker.ietf.org/doc/html/rfc4409
SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver finished (complete) messages.
However, SMTP is now also widely used as a message *submission*
protocol, that is, a means for Message User Agents (MUAs) to
introduce new messages into the MTA routing network. The process
that accepts message submissions from MUAs is termed a Message
Submission Agent (MSA).
Man muss unterscheiden zwischen:
- SMTP für Message-Submission durch den Client
- SMTP für Mail-Transport zwischen Mailservern
Bei Postfix laufen da zum Beispiel separate Daemons für die beiden Varianten.
Ersteres muss (heute) immer über eine Authenfizierung des Clients abgesichert sein.
Letzteres benötigt normalerweise keine Authentifizierung. In diesem Anwendungsfall (vorgeschaltetes Relay) kann man die Authentifizierung nutzen um das Einliefern auf den Host des Relays zu beschränken. Das gleiche erreicht man aber auch per Firewall-Regel. Die Lösung über eine Authentifizierung ist Robust gegenüber einer Änderung der IP des Relays aber komplexer, die Firewalllösung ist schneller zu implementieren.
Grüße
lcer