5
UniFi USG - CIFS Freigabe
Guten Abend
Ich hätte nochmals eine Frage zur USG von UniFi
Ich versuche die SMB/CIFS Verbindung freizugeben. Ich habe den ganzen Verkehr von einer DMZ Blockiert und nur z.B. die DNS Verbindung erlaubt. Dies klappt auch.
Für CIFS/SMB habe ich schon alle üblichen Ports wie 137-139,445 UDP/TCP versucht. Die Verbindung kann so aber nicht aufgebaut werden. Entferne ich die Block regel geht es.
Gibt es für CIFS/SMB noch andere Ports die ich vergessen habe? Bem. diversen Seiten sind es eigentlich nur die 4 (Verbindung von Linux auf einen Windows Server).
Gruss
Koda
Ich hätte nochmals eine Frage zur USG von UniFi
Ich versuche die SMB/CIFS Verbindung freizugeben. Ich habe den ganzen Verkehr von einer DMZ Blockiert und nur z.B. die DNS Verbindung erlaubt. Dies klappt auch.
Für CIFS/SMB habe ich schon alle üblichen Ports wie 137-139,445 UDP/TCP versucht. Die Verbindung kann so aber nicht aufgebaut werden. Entferne ich die Block regel geht es.
Gibt es für CIFS/SMB noch andere Ports die ich vergessen habe? Bem. diversen Seiten sind es eigentlich nur die 4 (Verbindung von Linux auf einen Windows Server).
Gruss
Koda
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 529911
Url: https://administrator.de/forum/unifi-usg-cifs-freigabe-529911.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
5 Kommentare
Neuester Kommentar
Die Verbindung kann so aber nicht aufgebaut werden. Entferne ich die Block regel geht es.
Der Satz ist logisch irgendwie wirr und führt zur Unverständlichkeit.Wenn du eine Block Regel eingerichtet hast willst du ja explizit 137-139,445 UDP/TCP blocken, sprich also CIFS/SMB verbieten. SMB geht dann also nicht durch, klar.
Wenn du diese Regel dann entfernst ist es doch evident das SMB dann klappt. In sofern widerspricht sich dein Satz diametral und es ist damit dann völlig unklar was du eigentlich willst ?!
Gibt es für CIFS/SMB noch andere Ports die ich vergessen habe?
Nein ! Siehe dazu https://de.wikipedia.org/wiki/Server_Message_BlockMöglicherweise hast du hier die Destination Ports mit den Source Ports verwechselt ?! In einer pfSense Firewall funktioniert dieses Regelwerk fehlerlos !
Hallo
Bitte entschuldige. Bei UniFi ist standardmässig immer alles erlaubt. Zuerst musst du eine Block Regel auf ALLE Ports legen. und danach machst du neue Regeln für die Ports die erlaubt sein sollen und schiebst diese VOR die Block Regel.
Und dies habe ich auch gemacht. Trotzdem funktioniert CIFS/SMB auf der Debian Kiste nicht. Er mountet mir die Laufwerke nicht welche im fstab eingetragen sind.
Wenn ich die REgel z.B. für Port 53 vornehme funktioniert der DNS. Also verwechselt ist ausnahmsweise nichts
PS. Den Test mit der Blockregel zu entfernen habe ich gemacht um zu prüfen ob es sicher an der Firewall scheitert bevor ich hier schreibe
Bitte entschuldige. Bei UniFi ist standardmässig immer alles erlaubt. Zuerst musst du eine Block Regel auf ALLE Ports legen. und danach machst du neue Regeln für die Ports die erlaubt sein sollen und schiebst diese VOR die Block Regel.
Und dies habe ich auch gemacht. Trotzdem funktioniert CIFS/SMB auf der Debian Kiste nicht. Er mountet mir die Laufwerke nicht welche im fstab eingetragen sind.
Wenn ich die REgel z.B. für Port 53 vornehme funktioniert der DNS. Also verwechselt ist ausnahmsweise nichts
PS. Den Test mit der Blockregel zu entfernen habe ich gemacht um zu prüfen ob es sicher an der Firewall scheitert bevor ich hier schreibe
Bei UniFi ist standardmässig immer alles erlaubt.
Uuuhh wie gruselig ! Und sowas nennt sich dann "Firewall" ?!! Ein weiterer Grund von so einem Mist die Finger zu lassen. Das kommt dabei raus wenn WLAN Billigbastler wie Ubuquity sich an Firewalls versuchen...oder diese Produkte von Extern zukaufen was bei denen ja der leider der Fall ist da sie nix eigenes haben.und schiebst diese VOR die Block Regel.
"First match wins" Konzept wie es generell üblich ist... 
Trotzdem funktioniert CIFS/SMB auf der Debian Kiste nicht.
Dann hast du am Regelwerk vermutlich etwas falsch gemacht....?! Einen Bug an einer so zentralen Funktion wollen wir dieser Grusel FW mal nicht unterstellen in der Hoffnung das du die aktuellste Firmware geflasht hast ?!Nur mal ein Beispiel so einer Logik... Bedenke dabei das Filterregeln meist immer nur Inbound greifen also vom Netzwerk Draht in den Firewall Port hinein.
Beispiel:
Dein LAN Firewall Segment ist die 10.1.1.0 /24 und das Firewall Interface hat die 10.1.1.1
Dann lautet eine einfache Regel die nur SMB erlaubt an diesem Interface so:
ALLOW TCP 10.1.1.0 0.0.0.255 port:any any port:445
DENY any any
Regel = Erlaube alles was aus dem 10.1.1.0er Netz kommt mit beliebigen Quellport an beliebige Zieladresse mit Zielport TCP 445.
Das sollte für moderne SMB Versionen schon reichen.
Bedenke aber auch das dann kein DNS durchkommt falls du sowas benötigst. TCP/UDP 53 wäre dann sinnig auch noch freizugeben.
Für die älteren Ports dann noch:
(ALLOW TCP/UDP 10.1.1.0 0.0.0.255 port:any any port:range 53)
ALLOW TCP/UDP 10.1.1.0 0.0.0.255 port:any any port:range 137-139
DENY any any
In einer üblichen (richtigen) Firewall wie pfSense oder OpnSense führt das sofort zum gewünschten Ergebnis.
ALLOW TCP 10.1.1.0 0.0.0.255 port:any any port:445
Sollte man als Netzwerk Admin aber eigentlich wissen das die Source Ports immer Random > 1024 sind !
Es lohnt deshalb immer mit einem Wireshark sich einfach nur mal Pakete im eigenen Netz anzusehen um deren Aufbau und damit dann die ACL/Firewall Logik zu verstehen !
Case closed !
Es lohnt deshalb immer mit einem Wireshark sich einfach nur mal Pakete im eigenen Netz anzusehen um deren Aufbau und damit dann die ACL/Firewall Logik zu verstehen !
Case closed !
