28
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1067548716
Url: https://administrator.de/contentid/1067548716
Printed on: April 19, 2024 at 06:04 o'clock
28 Comments
Latest comment
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
Danke erstmal für die ersten Hinweise.
@Tezzla: Der Angriffspunkt ist nicht das Mailgateway des Dienstleisters, sondern unser eigener Mailserver. Wir konnten also hinter dem Mailgateway des Dienstleisters angreifen.
Mein primäres Problem ist also erstmal, dass unser Mailserver direkt aus dem Internet angreifbar ist.
Der Port, der vom Gateway zum Mailserver genutzt wird, fordert eine SSL/TLS Verschlüsselung. Die umgekehrte Richtung muss ich noch in Erfahrung bringen. Wenn der Dienstleister was taugt, dann sollte das aber auch gegeben sein.
Was die Aussage des Admins angeht, diese lasse ich einfach so mal stehen. Ich bin anderer Meinung.
Bye
Tanor
@Tezzla: Der Angriffspunkt ist nicht das Mailgateway des Dienstleisters, sondern unser eigener Mailserver. Wir konnten also hinter dem Mailgateway des Dienstleisters angreifen.
Mein primäres Problem ist also erstmal, dass unser Mailserver direkt aus dem Internet angreifbar ist.
Der Port, der vom Gateway zum Mailserver genutzt wird, fordert eine SSL/TLS Verschlüsselung. Die umgekehrte Richtung muss ich noch in Erfahrung bringen. Wenn der Dienstleister was taugt, dann sollte das aber auch gegeben sein.
Was die Aussage des Admins angeht, diese lasse ich einfach so mal stehen. Ich bin anderer Meinung.
Bye
Tanor
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
Ah, ich hatte es anders herum verstanden, dass das Problem beim Gateway liegt.
Wer verwaltet denn euren Mailserver?
Edit: Oder vielleicht besser formuliert: Wer wäre eigentlich zuständig - ihr oder euer Dienstleister?
Wer verwaltet denn euren Mailserver?
Edit: Oder vielleicht besser formuliert: Wer wäre eigentlich zuständig - ihr oder euer Dienstleister?
Geht das mit dem anmelden und Senden auch von Extern?
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)
Die Firewall des Mailservers sollte so konfiguriert werden, dass nur die IP(s) des Mailgateway sich zum Mailserver von außen verbinden dürfen
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
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)
Die Firewall des Mailservers sollte so konfiguriert werden, dass nur die IP(s) des Mailgateway sich zum Mailserver von außen verbinden dürfen
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
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
@Vision2015: Wenn ich jetzt erwähne, dass besagter Admin AV Programme ablehnt, weil die nur Probleme bereiten und ebenfalls Einfallstore sind, fällt er vermutlich endgültig in Ungnade ...
Wir setzen zwar primär Linux ein, aber halt auch Windows (Clients und Server).
Bin jetzt hier auch erst seit 3 Wochen, aber bin im Moment, gelinde gesagt, so etwas wie im Schockzustand.
Bye
Tanor
Wir setzen zwar primär Linux ein, aber halt auch Windows (Clients und Server).
Bin jetzt hier auch erst seit 3 Wochen, aber bin im Moment, gelinde gesagt, so etwas wie im Schockzustand.
Bye
Tanor
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
@icer: In unserem Fall denke ich der Mailserver kann restriktiv die Authentisierung fordern. Denn die Mails von außen werden vom Mailgateway des Dienstleisters empfangen und dann an den Mailserver übertragen.
Der Mailserver kennt also extern nur einen Host, da müsste dann der Dienstleister die Möglichkeit schaffen, dass sich das Mailgateway authentisiert. Und intern können das die Admins administrieren.
Also man hatte ja schon mal vom Ansatz her den Mailserver ins zweite Glied gestellt und nicht direkt für Mail verantwortlich gemacht. MX geht ja auf das Mailgateway des Dienstleisters.
Soweit schon man ein meiner Meinung nach brauchbarer Ansatz.
Daher würde ich schon sagen, man macht den SMTP mit einer Authentisierung dicht. Da kann nix unbekanntes kommen.
Bye
Tanor
Der Mailserver kennt also extern nur einen Host, da müsste dann der Dienstleister die Möglichkeit schaffen, dass sich das Mailgateway authentisiert. Und intern können das die Admins administrieren.
Also man hatte ja schon mal vom Ansatz her den Mailserver ins zweite Glied gestellt und nicht direkt für Mail verantwortlich gemacht. MX geht ja auf das Mailgateway des Dienstleisters.
Soweit schon man ein meiner Meinung nach brauchbarer Ansatz.
Daher würde ich schon sagen, man macht den SMTP mit einer Authentisierung dicht. Da kann nix unbekanntes kommen.
Bye
Tanor
@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.
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.
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.
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?
Bye
Tanor
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.
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.
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?
Bye
Tanor
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
Zitat von @Vision2015:
aha... na dann stell doch das Relay ab!
und glaube mir, ich versende auch mails im Namen deiner Geschäftsleitung, ohne dein Netzwerk zu kennen, und ohne dein Open Relay zu nutzen!
aha... na dann stell doch das Relay ab!
und glaube mir, ich versende auch mails im Namen deiner Geschäftsleitung, ohne dein Netzwerk zu kennen, und ohne dein Open Relay zu nutzen!
Das war ja auch mit der Grund meiner Frage. Ich bin nicht der Admin, ich will nur verstehen, wie man es richtig macht um nicht ein X für ein U vorgemacht zu bekommen und ein paar Wochen später wieder über eine Schwachstelle zu stolpern.
Das ich CEO-Fraud auch ohne Zugriff auf den SMTP machen kann, ist mir auch klar. Aber sieht im Header halt schick aus, wenn in einer internen Mail im Routing nur interne System stehen hat, anstatt diverse externe.
äh... da biste aber auf dem holzweg, das ist client security, und hat nix mit dem mailserver zu tun... und wie schon weiter oben gesagt, wird in der regel von schadsoftware nicht dein mailserver genutzt, sondern das internet geteway... deswgen sollst du ja auch ausgehende internet verbindungen filtern!
also als ISO sollte das wissen aber auch da sein!
also als ISO sollte das wissen aber auch da sein!
Ja ok, da gebe ich Dir recht. Bringt eh nix intern, weil wenn die Dinger mailen, dann i.d.R. über den Mailclient und der kann sich gegen den SMTP authentisieren.
Client security ist noch so ein Thema, das ausdiskutiert werden muss, Internet-Zugang habe ich mir in den 3 Wochen noch nicht vornehmen können. Und natürlich weiß ich, dass auch die Internet Verbindungen überwacht und gefiltert werden müssen
Das mit dem Verzicht auf Fail2ban kann ich nachvollziehen, aber vorher will ich, das wirklich alle anderen noch offenen Ports zugemacht werden. Da schwirren noch zu viele rum, die nichts mit der Mailkommunikation zwischen Mailserver und -gateway zu tun haben. Das steht aber auch schon auf der ToDo-Liste.
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
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.
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 denke ich habe jetzt genug Info bekommen. Vielen Dank an alle Helfer.
Bye
Tanor
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.
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 denke ich habe jetzt genug Info bekommen. Vielen Dank an alle Helfer.
Bye
Tanor
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
1
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
1Zitat 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
Danke
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.
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.
Genau das ist mein Job bzw. der eines ISOs. Ich hab das Wissen um die Prozesse der Informationssicherheit und dem Risikomanagement. Die Admins das Fachwissen der operativen Umsetzung. Der ISO muss im steten Kontakt zu den Fachbereichen Schwachstellen und deren möglichen Risiken für das Unternehmen identifizieren, bewerten, dokumentieren und beheben lassen(!) - ich darf nicht operativ mitwirken -> Interessenskonflikt. Im Rahmen meiner Kompetenzen/Verantwortung liegt es zu entscheiden, was mache ich mit den Admins zusammen aus und wann schalten ich die GF (Kosten, Einfluss auf Geschäftsprozesse, hohe Risiken, etc.) ein.
Natürlich darf ich nicht blind dem vertrauen, was die Admins mir sagen, sondern ggfs. die Sache anschauen, austesten und doofe Fragen stellen.
Viele machen den Fehler und meinen, prima, da ist der ISO, der soll sich die operative Umsetzung kümmern und lehnen sich zurück. Ich habe ein gewisses IT-Grundverständnis, aber da ich nicht nur IT-Themen abdecken muss, kann und muss ich nicht IT-Experte sein.
Ich finde die teils abfällige Behandlung nicht zielführend.
Du, das perlt nach etlichen Jahren Tätigkeit an mir ab. Ich bin auch DSB und BCM-Manager, daher leidgeprüft
Aber nochmals vielen Dank an alle. Ich habe schon das erste konstruktive Gespräch mit den Admins geführt. Ich denke wir sind dabei die erste Baustelle sauber abzuschließen.
Bye
Tanor
