none
SMB Zugriffe auf eine Server NIC beschränken RRS feed

  • Frage

  • Hallo zusammen,

    folgendes Problem, bei welchem ich aktuell nicht mehr weiter komme:

    Wir haben einen Win 2016 Server mit mehreren NICs, welche in unterschiedlichen Netzen hängen (Intranet, SAN, Backup).

    Der Server fungiert primär als File Server mit installiertem DFS.

    Nun zum eigentlichen Problem.

    Ich habe im Log der Gateway Firewall jede Menge abgelehnte Zugriffe auf Port 445 mit der Ziel IP auf die SAN und Backup NICs des Servers. Da diese in einem anderen Netz Segment hängen, können Rechner welche im "Intranet" Netz hängen diese unabhängig von der Tatsache, dass die Firewall sie sowieso nicht durchlassen würde natürlich nicht erreichen. Auf dem Server ist für die beiden unerwünschten NICs ist die Option "Register this connection's addressesses in DNS" deaktiviert. Im DNS wird auch nur die eine richtige "Intranet" IP gelistet.

    Kann mir jemand sagen, woher die anderen Rechner nun die anderen beiden IPs des Servers kennen und wie man dieses Verhalten abstellen kann?

    Grüße

    Alex

    Dienstag, 16. Oktober 2018 08:03

Antworten

  • Moin,

    ich würde sagen, es ist SMB Multichannel in Aktion. Wenn Du im produktiven Netz nur einen 1GB-Adapter hast, kannst Du auf Multichannel verzichten mit

    Set-SmbServerConfiguration -EnableMultiChannel $false

    Ist die produktive Netzwerkkarte 10 Gig oder sind davon mehrere im Spiel, kann ich das Vorgehen aber nicht empfehlen, denn das geht dann möglicherweise auf die Performance. Dann musst Du von den "falschen" NICs die "Datei- und Druckerfreigabe" abwählen, sofern sie im SAN- und Backup-Netz nicht benötigt wird.

    Wenn alle Stricke reißen, musst Du die Firewall so zumachen, dass noch nicht einmal ein Ping von den Clients zu den falschen Schnittstellen durchgeht. Dann sollte SMB die auch nicht mehr anbieten.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Dienstag, 16. Oktober 2018 08:41

Alle Antworten

  • Moin,

    ich würde sagen, es ist SMB Multichannel in Aktion. Wenn Du im produktiven Netz nur einen 1GB-Adapter hast, kannst Du auf Multichannel verzichten mit

    Set-SmbServerConfiguration -EnableMultiChannel $false

    Ist die produktive Netzwerkkarte 10 Gig oder sind davon mehrere im Spiel, kann ich das Vorgehen aber nicht empfehlen, denn das geht dann möglicherweise auf die Performance. Dann musst Du von den "falschen" NICs die "Datei- und Druckerfreigabe" abwählen, sofern sie im SAN- und Backup-Netz nicht benötigt wird.

    Wenn alle Stricke reißen, musst Du die Firewall so zumachen, dass noch nicht einmal ein Ping von den Clients zu den falschen Schnittstellen durchgeht. Dann sollte SMB die auch nicht mehr anbieten.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Dienstag, 16. Oktober 2018 08:41
  • Hi Evgenij,

    Danke für die schnelle Antwort und einen sehr guten Denkanstoß.

    Das mit der Dateifreigabe guck ich mir mal an. Beim NAS Netz sollte es kein Problem sein. Das läuft über iSCSI.

    Intranet SMB läuft aktuell über eine 1GbE Verbindung. Es soll aber wieder ein Team aus 2 Ports werden...

    Grüße

    Alex

    Dienstag, 16. Oktober 2018 08:57
  • So.. ich habe mal ein wenig rumprobiert.

    MultiChannel ist wohl das worum es sich hier dreht.

    Wenn ich auf dem Client folgende PS Befehle ausführe erhalte ich alle NICs des File Servers zurück:

    Update-SmbMultichannelConnection
    Get-SmbMultichannelConnection
    Server Name        Selected     Client IP       Server IP          Client Interface Index     Server Interface Index
    -----------     --------     ---------       ---------          ----------------------     ------------------
    FILESERVER         True          192.168.10.12     192.168.10.96     5                          14
    FILESERVER         True          192.168.10.12     192.168.11.96     5                          4
    FILESERVER         True          192.168.10.12     192.168.12.96     5                          11


    Wartet man dann einen Moment und führt Get-SmbMultichannelConnection erneut auf dem Client aus, wird nur die eine "richtige" NIC geliefert:

    Server Name        Selected     Client IP       Server IP          Client Interface Index     Server Interface Index
    -----------     --------     ---------       ---------          ----------------------     ------------------
    FILESERVER         True          192.168.10.12     192.168.10.96     5                          14

    Ich habe testweise sowohl die Datei & Druckerfreigabe auf den Server NICs deaktiviert, als auch MultiChannel deaktiviert. Trotzdem bekomme ich nach einem Update-SmbMultichannelConnection immer alle NICs zurück und habe haufenweise Einträge im FW Log.

    Daher stelle ich mir die Frage, ob das ein "by Design" Verhalten ist?!

    Noch zu deiner Anmerkung ICMP zu blockieren. Der Client kann schon jetzt nur die 10er IP pingen, da die anderen Segmente nicht geroutet werden...



    Dienstag, 16. Oktober 2018 13:18
  • Ich habe testweise ... MultiChannel deaktiviert.
    Das deaktivieren alleine hat noch nicht gereicht. Es war noch ein Server Neustart notwendig. Jetzt habe ich keine Zugriffe auf die anderen NICs mehr im Log...
    Dienstag, 30. Oktober 2018 14:21