Starten wir zunächst mit dem Grundsätzlichen:
Welchen Dienst nutze ich und wie finde ich heraus welche Ports dafür freigemacht werden müssen?
Nehmen wir unser schon bekanntes Beispiel, das Protokoll HTTP (HyperTextTransferProtokoll) auf Port 80 tcp (TransmissionControlProtokoll).
Stellen wir uns weiter vor, wir wüssten weder was von HTTP, noch von TCP oder gar 80, einzig Kollege Webbrowser zetert rum, er könne keine Webseite öffnen.
In diesem Fall hilft uns diese schöne Seite
– Liste der standardisierten Ports
auch nicht wirklich weiter.
Schauen wir uns kurz die Datei /etc/shorewall/policy an:
Muss ich weiter mit blauem Hintergrund zeigen wie die Datei zur Bearbeitung geöffnet wird, oder wie man sich den Inhalt anschaut? Nein? Ok.
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
loc net DROP info
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
Tragen wir jetzt unter LOGLEVEL bei loc net ein info ein, speichern und schliessen die Datei wieder, wird ab dem nächsten Neustart von Shorewall jeder DROP von loc nach net ( also ein Zugriff ausserhalb der ACCESS Regeln in der Datei rules vom Heimnetz ins Internet ) im Log vermerkt.
Für diese LOGLEVEL gibt es 8 Zustände von
0 emerg = System läuft nicht mehr
bis
7 debug = zeichne alles auf ( und Dein Log wird ganz schnell ganz groß ! )
Statt info könnte hier auch 6 stehen, womit Du siehst, info loggt auch schonmal eine ganze Menge.
Es bleibt nun jedem selber überlassen welches Loglevel für den Dauerbetrieb angemessen erscheint. Mein Hinweis dazu wäre: Bin ich schwer paranoid und muss obendrein ein paar Staatsgeheimnisse schützen, wähle ich natürlich info und lasse die Logs permanent von weiteren Programmen überwachen.
Bin ich etwas entspannter, würde mir vielleicht ein alert ( 1 ) reichen und ich setze darauf einen swatch.daemon an, der aufpasst und mir bescheid gibt wenn Shorewall einen alert ausspuckt.
Für unseren Beispieltest verbieten wir jetzt in der Datei /etc/shorewall/rules den Zugang HTTP loc net indem wir den Eintrag kommentieren:
# und zuguterletzt immer unser INTERNET # $FW braucht das nur für die Updates # HTTPS(ACCEPT) loc net #HTTP(ACCEPT) loc net HTTPS(ACCEPT) $FW net HTTP(ACCEPT) $FW net HTTPS(ACCEPT) cid net HTTP(ACCEPT) cid net
Speichern, schliessen und Neustart der Firewall mit shrs
gateway: ~ # shrs nochmal in blau, aber eigentlich klar, oder? unser „alias“ für “shorewall restart“
Jetzt rufen wir die Logdatei auf
gateway: ~ # tail -f /var/log/messages | grep DROP
und rufen auf einem beliebigen Rechner im Netz 10.0.0.0 mit einem beliebigen Webbrowser eine ! unverschlüsselte Seite auf, z.B. shorewall.net
Nov 8 17:49:53 gateway kernel: [10563.380205] loc-net DROP IN=eth1 OUT=eth0 MAC=00:1c:42:36:ae:c8:00:1c:42:70:89:4d:08:00 SRC=10.0.0.2 DST=151.139.237.3 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=33964 DF PROTO=TCP SPT=52448 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 Nov 8 17:50:09 gateway kernel: [10579.507575] loc-net DROP IN=eth1 OUT=eth0 MAC=00:1c:42:36:ae:c8:00:1c:42:70:89:4d:08:00 SRC=10.0.0.2 DST=151.139.237.3 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=33965 DF PROTO=TCP SPT=52448 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 Nov 8 17:50:12 gateway kernel: [10582.323550] loc-net DROP IN=eth1 OUT=eth0 MAC=00:1c:42:36:ae:c8:00:1c:42:70:89:4d:08:00 SRC=10.0.0.2 DST=63.135.54.24 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=42659 DF PROTO=TCP SPT=57340 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
Der Browser versucht nun bis zu seinem Timeout ( Zeit bis er aufgibt und meldet, daß das Internet nicht verfügbar ist ) die angegebene Seite zu erreichen.
Zeitgleich loggt Shorewall diese Versuche für uns schön sichtbar als DROP auf.
Wir errinnern uns:
DROP = Paket wird verworfen, Sender erhält keine Antwort
REJECT = Paket wird mit dem Vermerk „ZURÜCK“ an den Sender retourniert
ACCESS = Paket wird wie gewünscht weitergeleitet
Was sehen wir jetzt genau?
Datum und Uhrzeit und wer meldet, hier „gateway kernel“
Warum nicht Shorewall?
Shorewall ist wie gesagt nur die Verwaltungssoftware, ein Assistent der zwischen uns und den Fähigkeiten der Firewall, die in Form von IP-tables bzw. NF-tables bereits fester Bestandteil des Kernels sind, vermittelt.
Die Aufgaben einer Firewall haben direkt nichts mit Shorewall zu tun.
Weiter:
loc-net DROP IN=eth1 OUT=eth0
Verbindung loc ( Heimnetz 10.0.0.0 ) nach net ( nicht wirklich, wir hängen ja tatsächlich hinter unserem Plasterouter, also quasi unser „Zwischennetz“, aber das weiss unser Gateway ja nicht )
wird verworfen DROP.
Paket kommt rein über eth1, unsere Schnittstelle ins Heimnetz 10.0.0.1
Paket will nach eth0, unsere Schnittstelle ins Internet
MAC=00:1c:42:36:ae:c8:00:1c:42:70:89:4d:08:00
Die MAC-Adressen der beteiligten Schnittstellen loc, also eth1 am gateway und die Schnittstelle des anfragenden Rechners.
SRC=10.0.0.2 DST=63.135.54.24
SRC: SOURCE ( Quelle ) der anfragende Rechner
DST: DESTINATION ( Ziel ) des anfragenden Rechners (shorewall.net)
( mit tcpdump könnte man jetzt schauen und sehen, wie SRC vorher beim DNS nach der IP von shorewall.net fragt und die Antwort bekommt )
Und jetzt kommt das Entscheidende!
PROTO=TCP SPT=57340 DPT=80
PROTO: PROTOKOLL = TCP
SPT: SOURCEPORT = 57340
DPT: DESTINATIONPORT = 80
Damit wissen wir alles was wir wissen müssen um den Zugang zu unverschlüsselten Seiten im Web zu erlauben.
Dabei errinnern wir uns nochmal kurz an den Portmapper!
Die Anfrage kommt über Port 57340! Warum?
Der anfragende Rechner schickt die Anfrage auch auf Port 80 an das gateway, und wird dort vom Portmapper empfangen und die zwei handeln nur für diese Anfrage einen anderen Port aus.
Würde das nicht sein, könnte immer nur eine Anfrage ins Netz geleitet werden, da Port 80 immer blockiert wäre.
Musst Du jetzt auch Port 57340 freigeben?
NEIN!
Damit bist Du jetzt gewappnet für alle Hilferufe im Heimnetz.
Ein,
– ey, mein Dings geht nicht mehr
kann jetzt lässig beantwortet werden mit:
Warte kurz
– Terminal aufgemacht
– policy geändert
– shorewall neugestartet
– LOG mit tail -f anwerfen
jetzt mach mal…..
und schauen was kommt.
Ist das Durcheinander zu groß, weil eine Menge anderer Kram geDROPped wird, versuchen wir es mit:
tail -f /var/log/messages | grep ’DROP\|SRC=10.0.0.2′
was die Ausgabe auf DROP und die IP des anfragenden Rechners einschränkt.
Hierbei darauf achten:
– Am Anfang und Ende des „regulären Ausdrucks“ ‘DROP\|SRC=10.0.0.2′ steht jeweils ein ‘
– Am Ende des ersten Suchbegriffs steht ein Backslash \
– Danach wieder die bekannte Pipe |
nicht zu verwechseln mit einem kleinen L oder einem großem i !!!
Nun noch die letzte Kleinigkeit, bevor wir die rules Datei wieder in Ordnung bringen und weitergehen:
Wir sehen mehrfach ein HTTP(ACCESS) oder DNS(ACCESS) in der rules Datei. Einige Dienste, die wirklich Standard sind, kann man Shorewall so mitteilen, Shorewall weiss da selber welche Ports gemeint sind.
Im weiteren Verlauf hört das aber auf, und wir müssen die Regeln anders, ausführlicher eintragen.
Warum? Keine Ahnung, ist halt so.
zurück <