Mit dem Small Business Server und dem darin enthaltenen Exchange Server hatte man mit ein wenig Konfiguration auch gleich noch einen SMTP-Server welcher zum Versand von Status-Mails, Logfiles oder auch Monitoring-Informationen verwendet werden konnte. Dazu gab’s von mir auch schon einen Beitrag dazu:

https://sbsland.wordpress.com/2010/02/11/sbs2008-meine-hardware-versendet-keine-mails-mehr/

Da aber so nach und nach auch die Mails von kleinen Firmen in die Cloud gehen und Microsoft einen aktuellen Small Business Server auf Basis von Windows Server 2012 R2 und Exchange 2013 gar nicht mehr anbietet, fällt damit auch die Möglichkeit weg über den lokalen Exchange Server die oben beschriebenen Mails zu versenden.

Damit haben wir noch folgende Möglichkeiten:

1. Wir konfigurieren jedes Hardware-Device mit einem externen POP-Account, welchen wir uns bei einem Provider (gmx, web.de, etc.) anlegen. Dann müssen wir aber mit den Unzulänglichkeiten der einzelnen Mail-Clients kämpfen … es gibt RAID-Controller die nur Port 25 und nicht 587 unterstützen, das Lexmark x544 MFC erlaubt keine Authentifizierung mit externen POP-Accounts … usw.
   Real betrachtet ist dieser Ansatz für eine kleine Firma nicht wirklich sinnvoll! 
2. Wir bauen uns einen eigenen, internen SMTP-Server welcher sich mit einem Mail-Account gegenüber einem Provider wie z.B. 1&1 authentifiziert und intern Mails mit einer “loseren” Sicherheit entgegen nimmt …

Ich selbst verwende schon seit meiner eigenen Migration in die Cloud Möglichkeit 2. Dazu müssen folgende Voraussetzungen erfüllt sein:

• Postfach bei einem Provider (und dazu ein entsprechender Mail-Account). Ich habe eine Domain bei 1&1 wo ich für jeden meiner Kunden einen E-Mail Account anlege. Nennen wir die Domain sbs-smtp.net
• Windows Server (in einer von Microsoft unterstützten Version) in diesem Beispiel Windows Server 2012 R2 mit installiertem SMTP-Feature

Die gesamte Konfiguration sieht damit wie folgt aus…

… und wird wie folgt konfiguriert (Windows Server 2012 R2 Englisch):

1. Im Server Manager unter Manage / Add Roles and Features den SMTP Server als Feature hinzufügen, alternativ mit PowerShell:
   

   Install-WindowsFeature "SMTP Server"

2. Nach der Installation wird der SMTP Server über die Internet Information Services (IIS) 6.0 Manager Konsole konfiguriert (Server Manager / Tools / …)
3. Hier mit der rechten Maustaste in die Properties des SMTP Servers gehen
   
4. Im Reiter Access werden nun folgende Einstellungen vorgenommen:
   Access / Authentification / Anonymus access aktivieren
   
   Damit ist es möglich ohne Auth gegenüber dem SMTP Server über diesen Mails zu versenden! Und damit hier Hinz und Kunz das nicht aus dem lokalen Netzwerk machen, tragen wir hier als Erhöhung der Sicherheit die IP-Adressen der Geräte ein welche ohne Auth senden dürfen:
   Access / Connection Control / Connection / Only the list below
   
   SMTP-Relaying ist in kleinen Firmennetzwerken kein Thema, dass heißt das alle Endgeräte unter der internen Domain (sbsland.local) ihre Mails versenden. Der Fall, dass weitere interne Domains den SMTP Server als Relay verwenden sollen beschreibe ich weiter unten als Zusatz.
5. Damit wir mit bekommen, ob Mails nicht versendet werden können wird eine funktionale E-Mail-Adresse mit Postfach unter Messages konfiguriert
   
   Diese Mail-Adresse sollte sinnvoller Weise auch abgerufen werden um ggf. irgendwelche Mails mit NDR auswerten zu können
6. Interessant wird es nun im Reiter Delivery unter diesem wir unter anderem die Auth gegenüber den Provider (hier 1&1) konfigurieren. Die Mail-Adresse und das Passwort wird bei 1&1 im Kundenportal angelegt:
   
   Wichtig dazu ist, dass 1&1 wie viele anderen Provider die Verschlüsselung von Mails mit SSL bzw. TLS unterstützen und auch den Versand über den Standard-Port von SMTP (25) nicht mehr zulassen.
7. Dazu müssen wir wie unter Delivery / Outbound Connections den Port 587 anstatt 25 zusätzlich einstellen
   
8. Abschließend konfigurieren wir die Advanced Delivery Optionen wie folgt
   
   Masquerade domain: sbs-smtp.net
   Full-qualified domain name: sbsland.local
   Smart host: smtp.1und1.de
   Da wir diese Konfiguration auf unserem SBS durch führen welcher die Domain sbsland.local im DNS hostet ist diese auch über Check DNS auflösbar. Als SMART Host, also als Server an den im Internet die Mails gesendet werden tragen wir smtp.1und1.de ein. Dieser muss natürlich auch von unserem Server erreichbar sein – hier einen nslookup smtp.1und1.de und ggf. einen tracert smtp.1und1.de zum Test ausführen
9. Zum Abschluss prüfen wir noch, ob sbsland.local als Domain erscheint
   

Damit wäre die Konfiguration abgeschlossen und unser SBS, der RAID Controller, etc. versenden ihre Mails nun über unseren eigenen internen Mail-Server.

Enjoy it, b!

Seit kurzen habe ich eine MultiSIM und prompt klappte der Empfang von SMS Nachrichten nicht mehr. Die SIM muss dazu erst noch aktiviert werden.

Dazu einfach die *222# anrufen und fertig

Wer Infos über den Status haben will – hier einfach *221# anrufen.

Enjoy it, b!

Neulich musste ich einen SQL Datenbank über einen Port ins Internet exponieren – Ziel war, dass eine Anwendung von Remote auf diese Datenbank zugreifen kann. Um das System möglichst gut gegen Angriffe zu schützen habe ich folgende Maßnahmen ergriffen:

• Alle Microsoft Updates installiert
• Da für den Zugriff über das Internet SQL-Auth notwendig ist, habe ich den SA deaktiviert und einen neuen Login mit SA-Rechten angelegt, um damit Scans auf den SA zu umgehen
• Die Infrastruktur läuft noch vollkommen auf IPv4 und damit wird am Router NAT betrieben. Der Standard-Port auf dem der SQL Server intern läuft (1433) wird am Router auf einen beliebigen externen High-Port gemapped z.B. 47113
• Für den Zugriff auf die Datenbank selbst habe ich einen weiteren Benutzer angelegt und ihm in KeePaas ein hinreichend “scharfes” Passwort erstellen lassen

Der Zugriff von Remote sieht in einem Schaubild wie folgt aus:

Damit nicht von jedem beliebigen Rechner im Internet auf diesen Port zugegriffen werden kann ist es sinnvoll explizit nur die (externe) IP-Adresse des Benutzers in der Firewall des Windows Servers frei zu schalten!

Was aber tun, wenn der Benutzer eine dynamische IP-Adresse verwendet, welche z.B. bei der Telekom jede Nacht wechselt? In diesem Fall ist als Kompromiss zumindest eine Einschränkung auf den Provider möglich – hier z.B. auf 1&1 / Telefonica.

1. Ermittlung der externen IP-Adresse des Benutzers (http://www.wieistmeineip.de) oder alternativ einfach bei einer schon bestehenden Verbindung die externe IP-Adresse aus einem netstat heraus lesen
   
   Anmerkung: Das hier ist eine Verbindung aus dem KabelBW Netz und nicht von 1&1!
2. Ermittlung des vom Provider verwendeten IP-Ranges beim RIP
   
3. Ändern des Firewall Regel des SQL Servers wie folgt:
   
   Damit auf den Datenbankserver noch aus dem lokalen Netzwerk zugegriffen werden kann muss unter Remote IP address am einfachsten das lokale Netzwerk selbst mit z.B. 192.168.1.0/24 hinzugefügt werden.

Wer hierzu noch Verbesserungsvorschläge hat – nur zu, wir lernen immer voneinander.

Update, 2014-11-04-01:
Der Vorschlag ließ nicht lange auf sich warten – klar man kann die Verbindung zur Datenbank noch zusätzlich verschlüsseln. Hier die Anleitung für einen Windows Server 2012 R2 Essentials in Verbindung mit SQL Server 2014 Express (geht auch auf dem “alten” Windows Server 2011 Small Business Essentials mit SQL Server 2008 R2 Express):

1. Im SQL Server Configuration Manager unter Flags, Force Encryption auf Yes stellen
   
2. Unter Certificate muss dann noch das entsprechende zu verwendende Zertifikat ausgewählt werden
   
3. Damit die Einstellungen funktionieren, muss der SQL Server neu gestartet werden
4. Schlägt der Neustart des SQL Servers fehl und wird dazu folgende Meldung im System Eventlog protokolliert, gibt es ein Problem mit den Rechten welche der Service Account zum Zugriff auf das Zertifikat benötigt:
   
   Im Falle von SQL Server 2014 Express handelt es sich hier um
   NT System\MSSQLSERVER – ändert man diesen auf Local System oder einen entsprechend berechtigten Service Account welcher auf folgenden Pfad „C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys“ Zugriff hat, startet der SQL Server auch wieder
5. und damit wäre (entgegen dem verlinkten MSDN Artikel) die Verbindung fertig konfiguriert, auf dem Client muss nichts gemacht werden

Eine Prüfung ob auch wirklich verschlüsselt gearbeitet wird, ist durch folgende Abfrage möglich:

Select protocol_type, encrypt_option from sys.dm_exec_connections

Zusätzlich natürlich auch mit WireShark oder Netmon – was aber einen extra Artikel wert wäre.

Enjoy it, b!