Beiträge von hogi82

POP/IMAP Ports dicht, SMTP ohne Authentifizierung umgestellt, Relay nicht offen, alles läuft

10€ Spende ans Forum, vielen Dank!

Das ist doch schon mal ne Aussage. Danke.

Ich glaube, alle meine externen Benutzer gehen eh mittlerweise über das ActiveSync-Protokoll, und ich kann die POP/IMAP Ports dichtmachen.

Frage: Verwenden Sie ActiveSync Nutzer über den externen SMTP Port 25 unseres Servers die Mail, oder gehen die direkt über das ActiveSync-Protokoll (über HTTP(S)) raus?

Nicht dass nachher jeder quasi als Mueller@kundexy.de an x@y.com Mails _versenden_ kann, weil ja dann die Absender-Adresse legitim ist?

Hallo!

Folgende Ausgangssituation:
Ich betreue nebenbei eine kleine Firma mit 10 Benutzern, die unbedingt einen Exchangeserver (Version 14.3 Build 123.4) haben wollen. Vor kurzem haben wir von 2003 auf 2010 umgestellt.
Wir haben eine Domäne, keine Außenstellen oder weiteren Exchange-Server. Wir haben eine Standleitung mit fester IP, die MX-Einträge der Kunden-Domäne (kundexy.de) verweisen auf Diese. Intern wird überall Outlook 2010 eingesetzt.

Der Router leitet die Ports 25 (SMTP für eingehende Mails), 80+443 für Outlook Webaccess bzw. Handynutzer/ActiveSync und 110/143 für POP/IMAP auf den Exchange-Server weiter.
Alles funktioniert aktuell einwandfrei, Sophos PureMessage schützt uns vor Spam und Viren.

Seit der Umstellung erhalte ich hunderte Warnmeldungen im Sicherheits-Eventlog von Windows (siehe unten), dass eine Anmeldung (mit verschiedenen -nicht in unserer Domäne existierenden- Benutzerkonten) fehlgeschlagen ist.

Meine Vermutung ist, dass hier Spammer versuchen, unseren Server über Port 25 als offenes Relay zu mißbrauchen, und mit den gängigen Standardpasswörtern (12345 etc) alle Standard-Benutzernamen durchprobieren (smith, miller, ...). Unser Server ist kein offenes Relay.

Der Empfangsconnector (Bildlich: Mein Briefkasten an der Haustür, in den jeder etwas einwerfen darf?) ist aktuell mit den Standardeinstellungen konfiguriert:
-Lauschen auf der richtigen IP-Adresse
-Remoteserver: 0.0.0.0-255.255.255.255
-Authentifizierung:
Ja: Transport Layouter Security (TLS)
Nein: Domänensicherheit aktivieren (gegenseitige TLS-Authentifizierung)
Ja: Standardauthentifizierung
Ja: Standardauthentifizierung nur nach dem Starten von TLS anbieten
Nein: Exchange Server-Authentifizierung
Ja: Integrierte Windows-Authentifizierung
Nein: Extern gesichert (zum Beispiel mit IPsec)

-Bereichtigungsgruppen
Ja: Anonyme Benutzer
Ja: Exchange Benutzer
Ja: Exchange-Server
Ja. Vorversionen von Exchange Server
Nein: Partner

Da mir nun von meinem Server-Überwachtungsprogramm (GFI MaxRemote) diese >1000 Meldungen als Hackerversuch angezeigt werden, ist die Frage, wie ich damit umgehen soll?

1) Empfangsconnector umstellen, so dass keine Authenifizierung verwendet wird, und die Spammer damit niemals eine "Erfolgsmeldung" falls sie doch mal das richtige Passwort zu einem Benutzerkonto geraten haben? Wie können dann meine externen POP/SMTP Nutzer "legal" ihre Mail über unseren Server wegschicken, weil wir dann ja eigentlich nur noch wirklich "eingehende" Mails mit Empfänger kundexy.de annehmen?

Muss wirklich der Empfangsconnector die Mails von den Clients im eigenen Netzwerk entgegen nehmen, die nach _draußen_ sollen, und er gibt sie dann an den Sendeconnector weiter? Oder kommen über den Empfangsconnector wirklich nur die Mails aus dem Netz?

2) Warnmeldung einfach ignorieren, weil "das ist halt so, wenn man direkt am Internet hängt? (+regelmäßig bei allen Benutzern Passwörter ändern, ggf. Passwortrichtlinie verschärfen etc.)

3) Kompletter Denkfehler / Andere Lösung?

4) OMG du Vollhorst, wie kann man nur...? Bitte seid gnädig mit mir.

Vielen Dank im Voraus!

Protokollname: Security Quelle: Microsoft-Windows-Security-Auditing Datum: 24.03.2014 22:53:44 Ereignis-ID: 4625 Aufgabenkategorie:Anmelden Ebene: Informationen Schlüsselwörter:Überwachung gescheitert Benutzer: Nicht zutreffend Computer: -ExchangeServer Hostname- Beschreibung: Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: kundexy.dom Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: yyyyy Kontodomäne: Fehlerinformationen: Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort. Status: 0xC000006D Unterstatus:: 0xC0000064 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: SV-MAILCAS Quellnetzwerkadresse: - Quellport: - Detaillierte Authentifizierungsinformationen: Anmeldeprozess: NtLmSsp Authentifizierungspaket: NTLM Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. Ereignis-XML:4625001254400x8010000000000000147138SecurityHostnameS-1-0-0--0x0S-1-0-0yyyyy0xc000006d%%23130xc00000643NtLmSspNTLMSV-MAILCAS--00x0---