Die grundsätzlichen Einstellungen sind klar, innerhalb unseres eigenen Subnetzes 10.0.0.0 können wir auf alles zugreifen.
Eine Regel, um auf ein NAS ( Network Attached Storage ), also auf einen Dateiserver 10.0.0.12 von einem Rechner 10.0.0.2 zuzugreifen, brauchen wir nicht.
Ganz im Gegenteil, möchten wir einen Dienst im Subnetz loc vor Zugriffen aus dem gleichen Subnetz schützen, müssen wir entweder
– den Dienst abschalten
– oder auf dem Rechner, auf dem der Dienst läuft, eine eigene Firewall mit eigenen Regeln aufsetzen.
Dabei muss klar sein:
Eine verschlüsselte Verbindung zu einem Zugang mit Nutzername und Passwort und eine Firewall haben erstmal nichts miteinander zu tun.
Der Zugang schützt vor unbefugtem Zugang, solange der Anmelder entweder den Benutzernamen oder das Passwort nicht kennt.
Er schützt aber nicht vor Anmeldeversuchen!
Er ist also nur so sicher, wie es sowohl der Benutzer ( Name / gutes Passwort ) als auch der Dienstbetreiber ( Administrator und/oder Hersteller ) einrichtet.
Sind alle Möglichkeiten korrekt konfiguriert?
Sind alle bekannten Sicherheitslücken mit den neuesten Updates geschlossen?
Hat der Benutzer ein „vernünftiges“ Verhältnis zu seinen Zugangsinformationen?
Oder wissen sowieso alle wo sein „Zettel“ rumliegt, oder das es immer herta/123456 ist?
Eine eigene Firewall auf dem Fileserver kann da helfen.
Und ja, in der Familie sollte man sich vertrauen, aber vielleicht geht es hier ja auch um ein kleines Büronetzwerk, Datenschutz und so wollen beachtet werden….Eine Firewall auf dem Fileserver kann ganze Abteilungen im gleichen Subnetz vom Fileserver fernhalten. Die Firewall auf dem Gateway kann das nicht.
Das ist doch alles klar, aber warum machen wir denn jetzt wieder mit IP-Adressen rum, wir haben doch einen Nameserver?
Gute Frage! IP-tables, NF-tables und damit auch Shorewall interessiert das mal garnicht. Die müssten das ja doch wieder in IP-Adressen umwandeln, das kostet nur Zeit.
Möchten wir hingegen später den Dateiserver 10.0.0.12 = nas.erstes.netz ansprechen, können wir das dank unserem Nameserver einfach mit z.B.
nfs://nas
und schon fragt uns der Server nach Name und Passwort und gibt uns unsere Dateien frei.
Was aber, wenn jetzt KID im Subnetz cid auf die Hörbücher auf dem NAS im Subnetz loc zugreifen möchte?
Schauen wir uns die policy nochmal an:
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT loc net DROP cid net DROP loc cid ACCEPT cid loc DROP net all DROP $LOG_LEVEL # THE FOLLOWING POLICY MUST BE LAST all all REJECT $LOG_LEVEL
Würde das NAS im Subnetz cid stehen, und wir im Subnetz loc sein, hätten wir vollen Zugriff.
Es braucht keine weiteren Regeln.
Andersherum ist alles verboten, kein Gerät im Subnetz cid kann auf irgendwas im Subnetz loc ohne gesonderte Regel zugreifen.
Stellt sich als erstes die Frage, mit welchem Protokoll, oder mit welchen Protokollen werden Dateien zur Verfügung gestellt.
Die häufigsten sind ( nicht unbedingt in dieser Reihenfolge ):
– NFS Network File System; das gängige Protokoll für Unix Dateifreigaben
– AFP Apple File Protokoll; das gängige Protokoll für Apple Dateifreigaben
– SMB Server Message Block; das gängige Protokoll für Windows Datei- und Druckfreigaben
– SAMBA wüsste ich jetzt keine Übersetzung, ist ein Programm, welches auf einem Unixsystem SMB bereitstellt, also Windows ermöglicht auf Unixfreigaben zuzugreifen
– CIFS hab ich auch nix für, auch Windows, nur active Directory, also SMB mit einer vernünftigen Rechteverwaltung
– FTP File Transfer Protokoll; das gängige Protokoll für Internet Dateifreigaben
– SFTP für Secure, also verschlüsselte Übertragung, läuft unter SSH
Sobald ich auf einem Rechner eine Dateifreigabe einrichte, ist das gleichzusetzen mit dem Aufsetzen eines Serverdienstes.
Somit können ohne weiteres in einem Netzwerk alle vier Freigabeprotokolle auftauchen, auch wenn ein Windowsrechner weder mit NFS, noch mit AFP umgehen kann.
Für eine Regel muss ich also immer wissen, welche Freigabe ich erreichen will.
Entsprechend gilt:
– NFS Port 2049 tcp
– AFP Port 548 tcp
– SMB Port 445 tcp ( gilt auch für SAMBA und CIFS )
– FTP Port 21 tcp
– SFTP Port 22 tcp
Schauen wir uns jetzt eine Regel an:
#ACTION SOURCE DEST PROTO DEST # PORT # nfs to loc # ACCEPT cid loc tcp 2049
Die Überschrift #ACTION SOURCE usw lasse ich ab hier weg!
Grundsätzlich gilt die Abfolge:
ACTION = ACCEPT oder anderes – was soll Shorewall mit dieser Zeile machen
SOURCE = MUSS eine eingetragene ZONE sein! Hier also loc,cid,net oder $FW und hier sind wir „case sensitive“ – heisst Fehler in der Groß- und Kleinschreibung werden übel genommen!
DEST = MUSS eine eingetragene ZONE sein!
PROTO = tcp oder udp, kann weggelassen werden, wenn bei ACTION ein bekannter Dienst z.B. DNS(ACCEPT) eingetragen ist.
DEST PORT = Portnummer, mehrere durch Komma getrennt (kein Leerzeichen), Portbereich mit Doppelpunkt (5060:5076)
Die einzelnen Einträge einer Zeile werden durch den Tabulator getrennt.
Dabei ist es egal wie viele Tabulatoren dazwischen sind, der nächste Eintrag bestimmt die Zuordnung. Soll eine Zuordnung keinen Eintrag haben, eine spätere aber sehr wohl, wird die Zuordnung ohne Eintrag mit einem einfachen Bindestrich gesetzt.
ACTION tab SOURCE tab tab DEST tab tab PROTO tab DEST PORT tab usw
Und jedes Gerät im Subnetz cid kann auf jede NFS Freigabe im Subnetz loc zugreifen.
Muss ich erwähnen, daß JEDE Regeländerung erst NACH einem Neustart von Shorewall in Kraft tritt? Das Speichern der Datei rules reicht NICHT!
Das geht aber natürlich auch differenzierter:
Stellen wir uns vor,
KID1 hat einen Rechner 10.0.1.25 im Subnetz cid
KID2 hat einen Rechner 10.0.1.26 im Subnetz cid
PA hat ein NAS 10.0.0.12 im Subnetz loc mit einer Freigabe
KID1 soll zugreifen dürfen, KID2 aber nicht
# nfs von KID1 to loc
#
ACCEPT cid:10.0.1.25 loc tcp 2049
Jetzt darf KID1 zugreifen, KID2 nicht.
KID1 darf jetzt aber auf ALLE (NFS) Freigaben im Subnetz loc zugreifen.
ein:
# nfs to NAS in loc von KID1
#
ACCEPT cid:10.0.1.25 loc:10.0.0.12 tcp 2049
Schränkt KID1 auf das NAS 10.0.0.12 ein. Auf eine Freigabe auf PA’s Rechner 10.0.0.2 hätte es keinen Zugriff.
Das ist jetzt vielleicht nicht das intelligenteste Beispiel, aber es geht ums Prinzip.
Freigaben können und sollten natürlich auch über Rechte abgesichert werden, wie ich oben bereits ausgeführt habe, aber jetzt hätte KID1 auch dann keinen Zugriff auf 10.0.0.2, wenn es Benutzer und Passwort für die Freigabe kennen würde.
Für eine Applefreigabe sähe das analog so aus:
# afp to NAS in loc von KID1
#
ACCEPT cid:10.0.1.25 loc:10.0.0.12 tcp 548
Für eine Windowsfreigabe:
# smb to NAS in loc von KID1
#
ACCEPT cid:10.0.1.25 loc:10.0.0.12 tcp 445
Für FTP, eher selten im Heimnetz, aber auch schon gesehen, wenn z.B. eine Kamera ihre eigene Bewegungserkennung auf einem FTP-Server ablegen möchte, oder ein Netzwerkscanner direkt ins FTP-Verzeichnis für die Buchhaltungsabteilung speichern soll…
# ftp to NAS in loc von KID1
#
ACCEPT cid:10.0.1.25 loc:10.0.0.12 tcp 21
Und jetzt einfach alles zusammen:
# ALLE Dateifreigaben von cid to loc
#
ACCEPT cid loc tcp 21,445,548,2049
Jetzt dürfen alle Geräte im Subnetz cid auf alle Freigaben FTP,SMB,AFP,NFS im Subnetz loc zugreifen.
Ich darf nochmal wärmstens empfehlen, alle Einträge sauber zu kommentieren, in spätestens einem Jahr blickst Du sonst selber nicht mehr durch!
Fasse zusammen in eine Zeile was geht, aber bleibe übersichtlich!
zurück <
em,? und was ist mit den Clouddiensten?
Nextcloud, Owncloud, Dropbox, iCloud und wie die alle heissen?
Jo! Läuft alles über HTTPS, webdav ist der Suchbegriff zum Thema….