ubuntuusers.de

Ich möchte hier einfach mal eine Firewall-Konfiguration thematisieren, die in Zukunft sicher einige benötigen werden oder gern nutzen wollen. Denn im Zuge der Entwicklung werden immer mehr Geräte in Handel erscheinen, die einen Zugang per WLAN ins Netzwerk haben, die aber keinerlei Konfiguration und Kontrolle auf Zugriff zum Internet bereitstellen werden. Wer hier die Kontrolle behalten möchte, muss dann schon etwas mehr Aufwand betreiben. Und da ich das grundsätzlich nicht ändern kann, musste ich mir etwas einfallen lassen.

Eigentlich handelt es sich hierbei nur um meine (private) Dokumentation zur Firewall, Routing und Netzwerk, die evtl. auch mal ein anderer verstehen muss, warum so und nicht anders und was die einzelnen Dinge zu bedeuten haben. Vielleicht kann ja der ein oder andere etwas damit anfangen oder freut sich einfach. ;o)
(im übrigen, so sehen meine Dokus immer aus)

Für evtl. auftauchende Schäden ist jeder selbst verantwortlich!

Teil 1

Konkret geht es hier um einen Netzwerkfähigen Fernseher, der im Netzwerk sein "muss", weil man per UPNP/DLNA seine Videos vom Server sehen möchte. Ab und an darf dann eben auch mal ein Update der Software stattfinden und das Ding auch das ein oder andere neue Feature installieren. Ich wollte das Ding in seinen Funktionen halt beschneiden, aber eben nicht völlig funktionslos zum Internet machen.

Mein konkretes Beispiel ist durch die Kinder öfter mal in Benutzung gewesen, da Dortmund in Europa Fußball gespielt hat und die Übertragung nur per Sky zu sehen war. Hier gibt es immer mal wieder Webseiten, die dann eben den Live-Stream ins Internet stellen. Jedoch meist mit sehr viel Werbung gespickt. Und das kann man sich dann eben auch am Fernseher ansehen. (Is schon cool, wenn die ganze Familie dann doch guggen kann)

Diese Werbung galt es nun heraus zu filtern. Zudem sollte der Fernseher nur das tun was tatsächlich erlaubt war. Man weiß ja nicht was in die Dinger so alles eingebaut ist. Denn die Möhre telefoniert bei jedem Start nach Hause. Und da ich damit sowieso alles neu machen musste, warum nicht gleich total neu.

Das ganze Szenario lässt sich so erweitern, dass mehrere Firewall-Regeln ein "umbiegen" der Routen zulässt. So können dann eben auch die Rechner der Kinder unter Kontrolle gebracht werden, während man selbst ohne Beschränkungen im Internet unterwegs sein kann.

Ok, was wird benötigt? Als erstes natürlich ein funktionierender Linux-Router. Auf diesem dann VirtualBox, um einen virtuellen und externen Proxy installieren zu können. So spart man sich den transparenten Proxy und dessen umfangreiche Einstellungsmöglichkeiten auf dem Server/Router und kann sich auf das konzentrieren, was man letzten Endes benötigt. Der Proxy-Server selbst erhält dann Squid und SquidGuard, letzteres zum ausfiltern der Werbung und anderer Dinge, die man blockieren möchte.

VirtualBox benötigt für diesen Zweck dringend die entsprechenden Erweiterungen, da der Proxy-Server in einem anderen Netz stehen soll. Das erschwert zwar etwas das Routing, trennt aber die Netzwerke voneinander, so dass Firewall-Regeln auf dem Router "einfacher" und übersichtlicher erstellt werden können.

In den Globalen Einstellungen zu VirtualBox sollten dann unter Netzwerk zwei neue "Host-only Netzwerke" erstellt werden. Jede Schnittstelle von vboxnet+ bekommt dann eine eigene IP-Adresse. Damit die Netze nicht zu groß werden, kann man etwas Subneting machen und die Anzahl der Hosts verkleinern. In meinem Fall hat das Netz dann die Netzmaske 255.255.255.192, was dem Netzwerk 192.168.120.0/26 entspricht. Nutzbare Adressen dann von xxx.1 bis xxx.62, Broadcastadresse xxx.63 und demnach 62 IP-Adressen zur Verfügung stehen. Wer wissen will wie man am einfachsten Subnetze sich erstellen kann, der sollte hier mal vorbei sehen. Da gibt es einen Netzwerk-Rechner.

Die Verteilung der IP-Adressen für die VirtualBox nun so:
* vboxnet0 = 192.168.120.15 netmask 255.255.255.192
* vboxnet1 = 192.168.120.75 netmask 255.255.255.192

Das ergibt nun folgendes Routing-Bild auf dem Host-Server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
18.16.16.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.2.0     192.168.103.10  255.255.255.0   UG    0      0        0 wlan0
192.168.103.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.104.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.120.0   0.0.0.0         255.255.255.192 U     0      0        0 vboxnet0
192.168.120.64  0.0.0.0         255.255.255.192 U     0      0        0 vboxnet1

Versteckt und nicht konfiguriert, das ist wichtig, ist eth1. eth1 steckt, per Kabel natürlich, direkt im DSL-Router und öffnet die pppoe Verbindung per ppp0! So gibt es im Netzwerk keinerlei Möglichkeit eine eigene Verbindung, von einem anderen PC aus, in das Internet aufzubauen!

Zur Veranschaulichung lasse ich die Route in das (entfernte) Netz 192.168.2.0 mit drin, damit evtl. klar wird, wie Routing funktioniert. Denn auf dem Proxy wird dieser Eintrag auch wieder auftauchen.

Ist der Server auf der VirtualBox installiert, bekommt dieser, also der Proxy-Server in der Box, zwei verschiedene IP-Adressen.
* eth0 = 192.168.120.10 Netmask 255.255.255.192
* eth1 = 192.168.120.70 Netmask 255.255.255.192

Wichtig hier jetzt die Anpassungen in der /etc/network/interfaces!

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
        address 192.168.120.10
        netmask 255.255.255.192
        network 192.168.120.0
        broadcast 192.168.120.63
        dns-nameservers 192.168.104.10
        dns-search home
        up route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.120.15
        up route add -net 192.168.104.0 netmask 255.255.255.0 gw 192.168.120.15
        up route add -net 192.168.103.0 netmask 255.255.255.0 gw 192.168.120.15

auto eth1
iface eth1 inet static
        address 192.168.120.70
        netmask 255.255.255.192
        network 192.168.120.64
        broadcast 192.168.120.127
        dns-nameservers 192.168.104.10
        dns-search home
        gateway 192.168.120.75

Hinweis!
Ganz wichtig, sonst wird der Proxy nicht funktionieren, ist das Standard-Gateway, welches auf die "Tür" zum Server verweist! Also die IP-Adresse die der Router als auch der Proxy kennt. Hier 192.168.120.75!

Das heisst, alle Traffic die ankommt, wird automatisch nach dahin weiter geroutet. Außer den Netzwerken, die mit "up route add -net" an eth0 gebunden sind. Diese Netzwerke werden automatisch an 192.168.120.15 gesendet, in dem Fall vboxnet0 auf dem Router. Und der wiederum weiß, wo die entsprechenden Netzwerke zu finden sind. (Ich weiß das Routing logisch nicht einfach zu verstehen ist, obwohl es doch äußerst simpel ist ;o))

Wenn das Routing nun so auf dem Proxy aussieht, ist die halbe Miete drin.

1
2
3
4
5
6
7
8
9

$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.120.64  0.0.0.0         255.255.255.192 U     0      0        0 eth1
192.168.120.0   0.0.0.0         255.255.255.192 U     0      0        0 eth0
192.168.103.0   192.168.120.15  255.255.255.0   UG    0      0        0 eth0
192.168.2.0     192.168.120.15  255.255.255.0   UG    0      0        0 eth0
192.168.104.0   192.168.120.15  255.255.255.0   UG    0      0        0 eth0
0.0.0.0         192.168.120.75  0.0.0.0         UG    100    0        0 eth1

Zum testen jetzt am besten von allen Hosts im Netzwerk aus einfach mal ein ping in alle Richtungen versuchen. Bekommt man Antworten, ist alles in Ordnung und man kann sich nun der Firewall widmen.

Teil 2 - Firewall

Zuerst sollte man sich Gedanken darüber machen, welche verschiedenen Netzwerke man selbst in Benutzung hat. Ok, bei mir zu Hause ist es tatsächlich etwas viel, hängt aber damit zusammen, dass eben die unterschiedlichsten Geräte und Betriebssysteme existieren, die alle irgendwie mit dem zentralen Server kommunizieren können sollen. Auch Internet ist eben wichtig.

Bei den meisten wird es in der Regel ein Netzwerk (auf eth0) geben, welches oft 192.168.0.0/24 ist. Also 254 verfügbare IP-Adressen. Da drin stecken dann alle Hosts, die sich gegenseitig "sehen" können und alle miteinander Brotkiste um Brotkiste versenden. (Brotkiste = Umgangssprachlich für Broadcast)
Um nun aber ein vernünftiges Routing mit Firewall zu erhalten, wird man um ein zweites Netzwerk, mit zweiter Netzwerkkarte (eth1 oder wlan0) auf dem Router/Server, nicht wirklich herum kommen. Das dritte/vierte Netzwerk sind dann die vboxnet0/1 für den Proxy.

Man kann nun fragen, wozu dieser Unfug und dieser Aufwand? Ich antworte dann immer, "Zum einen, weiß ich was noch alles an Geräten kommt? Zum anderen, so kommt man nicht aus der Übung und trennt von vornherein Gut von Böse. (hier Linux von Windows ;o))". Zudem fallen Fehler im Netzwerk viel eher auf.

Genug gequasselt, jetzt zur Firewall.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

## Debugging der Firewall ein/aus schalten
## damit das Logging nicht begrenzt wird sondern alle Ausgaben zeigt
DEBUG_FW=1

case $DEBUG_FW in
        0) LOG_LIMITER="-m limit" ;;
        1) LOG_LIMITER=""
                echo "\n\033[0;31mFirewall Script Debug ON\033[0;37m" ;;
esac



echo "\nsetze Firewall-Regeln"

DEV_INTERN="eth0"
DEV_EXTERN="ppp0"
DEV_WLAN="wlan0"
DEV_VBOX="vboxnet+"

Grundsätzlich sollte man sich auch beim kleinsten Firewallscript angewöhnen, von Anfang an mit Variablen zu arbeiten. Denn wird die eigene Erfahrung größer, wird sich auch das Script vergrößern. Dann möchte man das erlernte eben auch umsetzen und die eigene Firewall so gut als möglich machen.

Die ersten Zeilen verändern das Log-Verhalten der Firewall. Ist der Begrenzer nämlich an, werden nicht alle verworfenen Pakete mehr geloggt. Das verhindert ein überlaufen der Log-Dateien mit unnötigen Informationen.

Als nächstes dann werden die entsprechenden Schnittstellen definiert, die die Firewall bearbeiten soll. Besonderheit hier, vboxnet+. Das Plus steht hier als Platzhalter für alle Zahlen, die dahinter stehen können. Wer mehrere ppp Schnittstellen besitzt, schreibt dann hier eben ppp+, wenn alle Ausgänge ins Internet sind. Die Virtuellen Schnittstellen, vom OpenVPN, tun/tap kann man so nicht nutzen! Dazu aber später.

Als nächstes definiert man die verwendeten Netzwerke:

1
2
3

LAN_INTERN="192.168.104.0/24"
LAN_WLAN="192.168.103.0/24"
ALL_LAN="192.168.96.0/20"

Als Besonderheit hier, ALL_LAN besitzt den Suffix /20, was nichts anderes bedeutet, als dass alle Netzwerke/Adressen von 192.168.96.0 bis 192.168.111.255 erreicht werden. Also auch die Adressen xxx.103.0 und xxx.104.0 mit nur einer einzigen Angabe in der Firewall eine Regel bekommen können. Korrektes Subneting vorausgesetzt.

Extern braucht man nicht zu definieren, da alle Pakete dahin auf 0.0.0.0 gesendet werden und dann vom Provider entsprechend weitergeleitet oder eben zurückgewiesen werden.

Eine weitere, hier noch nicht aufgeführte, Besonderheit sind die Broadcast-, Multicast- oder Unicast-Adressen. Diese werden dann wichtig, wenn man im internen Netzwerk UPNP/DLNA nutzen will oder angewiesen ist auf andere Dienste, wie DHCP oder ähnlichem. Dieses Firewall-Script lässt momentan alles zu was sich im internen Netzwerk dazu bewegen soll.

Wir starten jetzt die Firewall.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

FW="iptables"

## per Default alles offen oder alles zu?!
DEFAULT_STATUS="DROP"

## als erstes alle Regeln löschen
$FW -F
$FW -X
$FW -t nat -F

# nun neu aufbauen
# Initialisierung der Firewall mit dem Standard-Status der weiter oben definiert ist
$FW -P INPUT $DEFAULT_STATUS
$FW -P FORWARD $DEFAULT_STATUS
$FW -P OUTPUT $DEFAULT_STATUS

Wer dieses Script nun so benutzt, der Router ist sicher! Kein Zugriff aber auch keine Kommunikation mehr nach außen. Das ist dann wie; Netzwerkkabel aus der Dose gezogen. Nur noch lokal kann man sich anmelden. Und auch hier werden dann nicht alle Dienste funktionieren! Möchte man sich anmelden und hat evtl. die Anmeldung per LDAP eingestellt und damit kein lokales Konto mehr, wird auch der lokale LDAP keine Antwort geben! Anmeldung unmöglich!

Ich denke die Kommentare im Script sind so weit verständlich und bedürfen keiner weiteren Erläuterung.

Teil 3 - Die Zwangs-Umleitung

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Umleitung für einzelne IP
# Hier für das Gerät, welches den Proxy nutzen muss
SRC_IP="192.168.103.31"
 ## der Fernseher
DST_IP="192.168.120.10"
 ## der Proxy
DST_PT=":8080"
 ## Proxy Port
$FW -t nat -I PREROUTING -p tcp -s $SRC_IP --dport 80 -j DNAT --to $DST_IP
$FW -I FORWARD -s $SRC_IP -d $DST_IP -j ACCEPT

Hinweis, weil es im Text öfter vorkommen wird:
^ = Gleichbedeutend für "entspricht" oder "bedeutet"

Die letzten beiden Zeilen sind eigentlich doppelt gemoppelt. Die erste Zeile besagt nämlich nichts anderes, als dass alles was als Zielport (--dport) die 80 hat und das Protokoll tcp (-p tcp) benutzt, soll zum Proxy geleitet werden.
Die zweite Zeile jagt dann von der Source (-s) ^ dem Fernseher, alles zur Ziel-IP (-d ^ Destination). Da der Proxy transparent ist, stört es ihn nicht und alle Pakete erreichen ihr Ziel. Bis auf die die gefiltert werden!

Man kann das so lassen, man kann sich aber auch für eine Variante entscheiden. Auf jeden Fall ist hier sicher gestellt, das alles was Internet und Web betrifft, über den Proxy gejagt wird.

Teil 3 - Firewall: Regeln für die Netzwerke definieren

Noch mal einige Variablen, die als erstes definiert werden. Damit spart man sich am Ende viel Schreibarbeit und vor allem Fehler.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

## die eingetragenen DNS-Forwarder aus dem DNS-Server, sonst geht gar nix
DNS1="213.73.91.35"
DNS2="85.214.20.141"

##### Firewall Regeln für gesamten anderen Traffic #####
## alle bewilligten Ports nach EXTERN oder INTERN zulassen und hier eintragen
TCP_P_EXT="20,21,25,43,80,110,443,8080"
TCP_P_INT=$TCP_P_EXT",3128,5900,6000:6003"
UDP_P_EXT="53,123"
UDP_P_INT=$UDP_P_EXT

Am Beispiel TCP_P_EXT, werden alle Ports eingetragen, die Standardmäßig ins Internet dürfen. Alles was dann sowieso ins Internet darf, wird meist auch im Intranet werkeln dürfen. Daher setzt sich TCP_P_INT eben aus TCP_P_EXT und den nachfolgend definierten Ports zusammen. Selbiges wird für UDP zusammen gebaut. 53 für DNS und 123 für NNTP, also das Timeprotokoll.

Der wohl größte Block der Firewallkommunikation wird wohl der werden, der die Verbindungen aus den internen Netzwerken nach draußen definieren soll. Also das was die Nutzer im Netzwerk dürfen und was nicht.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

## alles was raus darf wird auf "TRANSPORT" definiert
$FW -N TRANSPORT
## hier die Regeln
$FW -A TRANSPORT -i $DEV_INTERN -o $DEV_EXTERN -s 192.168.104.21 -j ACCEPT
$FW -A TRANSPORT -i $DEV_INTERN -o $DEV_WLAN -j ACCEPT ## von LAN zum WLAN alles zulassen
$FW -A TRANSPORT -i $DEV_WLAN -o $DEV_INTERN -j ACCEPT ## vom WLAN zum LAN alles zulassen
$FW -A TRANSPORT -i $DEV_INTERN -o $DEV_VBOX -j ACCEPT ## LAN zu VBOXen
$FW -A TRANSPORT -i $DEV_WLAN -o $DEV_VBOX -j ACCEPT ## WLAN zu VBOXen
$FW -A TRANSPORT -p tcp -i $DEV_VBOX -o $DEV_EXTERN -m multiport --dport $TCP_P_EXT -j ACCEPT ## tcp VBOXen nach extern
$FW -A TRANSPORT -p udp -i $DEV_VBOX -o $DEV_EXTERN -m multiport --dport $UDP_P_EXT -j ACCEPT ## udp VBOXen nach extern
$FW -A TRANSPORT -i $DEV_VBOX -o $DEV_WLAN -j ACCEPT   ## VBOXen zum WLAN (Proxy geht sonst nicht)
$FW -A TRANSPORT -i $DEV_VBOX -o $DEV_INTERN -j ACCEPT   ## VBOXen zum LAN
$FW -A TRANSPORT -p tcp -i $DEV_INTERN -o $DEV_EXTERN -m multiport --dport $TCP_P_EXT -j ACCEPT
$FW -A TRANSPORT -p udp -i $DEV_INTERN -o $DEV_EXTERN -m multiport --dport $UDP_P_EXT -j ACCEPT
$FW -A TRANSPORT -p tcp -i $DEV_WLAN -o $DEV_EXTERN -m multiport --dport $TCP_P_EXT -j ACCEPT
$FW -A TRANSPORT -p udp -i $DEV_WLAN -o $DEV_EXTERN -m multiport --dport $UDP_P_EXT -j ACCEPT

#$FW -A TRANSPORT -p tcp -i $DEV_WLAN -o $DEV_EXTERN -m multiport --dport $TCP_P_EXT -j ACCEPT
#$FW -A TRANSPORT -p tcp -i $DEV_WLAN -o $DEV_VBOX -m multiport --dport $TCP_P_EXT -j ACCEPT
#$FW -A TRANSPORT -p udp -i $DEV_WLAN -m multiport --dport $UDP_P_EXT -j ACCEPT
$FW -A TRANSPORT -p icmp -j ACCEPT
$FW -A TRANSPORT -p udp --dport 33434:33523 -j ACCEPT # traceroute -- Windows nutzt icmp dazu

###### ANWENDUNGEN ######
# mit der nächsten Zeile (skype) ist zwar nun alles offen, aber das Ziel entscheidet, was zurück antworten darf ... nun mal sehen
$FW -A TRANSPORT -p udp -i $DEV_WLAN -o $DEV_EXTERN --sport 1024:65535 -j ACCEPT ## skype
$FW -A TRANSPORT -p udp -i $DEV_INTERN -o $DEV_EXTERN --sport 1024:65535 -j ACCEPT ## skype
$FW -A TRANSPORT -p tcp -o $DEV_EXTERN --dport 26000 -j ACCEPT ## eve-online
$FW -A TRANSPORT -p udp -o $DEV_EXTERN --dport 9987 -j ACCEPT ## TS3 Standard Sprache
$FW -A TRANSPORT -p tcp -o $DEV_EXTERN --dport 30033 -j ACCEPT ## TS3 Filetransfer Standard
$FW -A TRANSPORT -p tcp -o $DEV_EXTERN --dport 8883 -j ACCEPT ## Facebook Chat
$FW -A TRANSPORT -p tcp -o $DEV_EXTERN -m multiport --dport 25,110 -j ACCEPT ## Mailprogramme
$FW -A TRANSPORT -p udp -o $DEV_EXTERN --dport 2010 -j DROP
$FW -A TRANSPORT -s 10.8.0.0/24 -j ACCEPT


## Alles was einmal rausgelassen wurde, darf auch zurück antworten
$FW -A TRANSPORT -m state --state RELATED,ESTABLISHED -j ACCEPT
## Alles was falsch läuft loggen
$FW -A TRANSPORT $LOG_LIMITER -j LOG --log-prefix "[FW] DENY-TRANSPORT-ACCESS "
## und dann komplett verwerfen
$FW -A TRANSPORT -j DROP

Ich habe absichtlich mal alles drin gelassen, auch Regeln die nicht benutzt werden. Insbesondere Zeile 34 ist interessant! Wie vorhin schon gesagt, OpenVPN benutzt virtuelle Schnittstellen. Soll man aus dieser Richtung Verbindungen auf den Server und die Netze haben, muss man ein Netzwerkrouting auf der Firewall zulassen!

Ihr erinnert Euch? Routing und Subneting? 10.8.0.0/8 ist eigentlich korrekt. (^ Netmask 255.0.0.0) 16.777.214 Hosts kann man damit versorgen. Der Suffix /24 (^ Netmask 255.255.255.0) beschränkt das ganze wieder auf nur 254 Hosts, also von 10.8.0.0 bis 10.8.0.255 (minus 2, Broadcast und Hostadresse)

Zeile 4 ist auch so ein Spezialfall. Admins wollen meist gar keine Beschränkungen, stimmts? ,o)
Diese Zeile bedeutet im Grunde nichts anderes als: "Lass durch was kommt". Aber eben nur aus diesem Netzwerk über diese Schnittstelle und nur von dieser IP-Adresse.

Interessant sicher auch die Zeilen 21 + 22. Zeile 21 besagt, dass alles was ping(en) will, auch ping machen darf. Egal wohin. Das -p icmp steht dann stellvertretend für einen der Ports, die in iptables fest einprogrammiert sind. Auch hier besteht eine Besonderheit. Das traceroute vom Linux nutzt die Ports aus Zeile 22. Windows mit tracert nutzt hier hingegen ICMP.

Ein "Notfall", die Zeilen 26 + 27. Laut Dokumentation von Skype nutzt das Programm ab Port 1024 bis zum Ende alle Ports zur Kommunikation. Zumeist die Chats. Damit ist nun auch die Kommunikation zu anderen Programmen aus dem Internen Netzwerk zu, z.B. ... ... ... Verdammt, mir fällt grad nicht der Name dieses blöden Spiele-Anmelde-Verkaufs-Programms ein ....

Also alles was hier aus dem Netzwerk (-i ^ Input/Von) $DEV_WLAN oder $DEV_INTERN kommt, darf weitergeleitet werden nach draußen (-o ^ Output) auf $DEV_EXTERN. Zudem muss es der Protokoll-Familie udp (-p udp) angehören und als Source-Port (--sport) besagte Ports 1024:65535 nutzen.

Ich denke zu Hause ist das auch kein schwerwiegendes Problem. Und in einer Firma werden eher weniger Skype nutzen (dürfen), würde ich mal so behaupten.

Doppelt ist im Grunde dann auch eingetragen, Zeile 29, der Standard-Port für die Sprache des Teamspeak 3. Denn eigentlich ist das schon, aus Zeile 7, erlaubte Kommunikation. Gibt es aber irgendwann mal eine neue Erkenntnis für Skype, kann man getrost da ändern und TS3 wird wie gewohnt funktionieren.

Problematisch dann, zumindest hier im Beispiel TS3, möchte man sich mit einem TS3-Server verbinden der andere Ports benutzt, muss man die Firewall entsprechend anpassen.

Die wichtigste Zeile vielleicht ist dann die mit der Nummer 38. Denn diese besagt, das alles was von Intern erlaubt ist und eine Verbindung ins Internet aufgebaut hat, ohne weiteres zurück antworten darf. Ohne Beschränkungen! Das hat dann aber auch den Nachteil, dass in Skype ein einmal geöffneter Chat, der die udp-Ports (z.B.) 34005 eingehend und 33456 ausgehend nutzt, nicht von außen neu aufgebaut werden kann, wenn die Firewall neu gestartet wird. Sprich, Antworten vom Partner werden erst dann angezeigt, wenn man selbst diesen (als erstes) angeschrieben hat. Die Transport-Regel blockt dann alles.

In Zeile 42 wird dann alles das was nicht transportiert werden durfte ins Log geschrieben, am Ende alles verworfen (Zeile 44).

Teil 4 - Die Regeln werden gesetzt

Alles was zuvor in die selbst definierte Regel TRANSPORT gepackt wurde, wird an dieser Stelle gesetzt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

###########################################################
## Die vorher gesetzten Regeln aus TRANSPORT             ##
## alles aus FORWARD löschen, dann neue Regeln einfügen  ##
$FW -P FORWARD DROP
$FW -A FORWARD -j TRANSPORT
## Flooding Regeln
$FW -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
$FW -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
$FW -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
# Mache mal NAT
$FW -t nat -A POSTROUTING -o $DEV_EXTERN -j MASQUERADE
## und alles was nicht mehr passt ab ins Log damit
$FW -A FORWARD $LOG_LIMITER -j LOG --log-prefix "[FW] DENY-FWD-ACCESS "

## mach mal Terz und zeige das du durch bist
beep -f 900 500
beep -f 1000 500

Damit ist nun beschrieben, wie ihr _über_ den Proxy kommt. Zugriff auf irgend einen Dienst auf dem Router/Server selbst, habt ihr damit noch nicht. Die Firewall ist hier noch nicht fertig. Das sind dann zwei weitere Regelwerke mit den Namen INPUT und OUTPUT. Die werden hier noch folgen.

Zeile 13 wäre hier noch bemerkenswert. Die Variable $LOG_LIMITER ist weiter oben definiert. Die Firewall Debuggen, damit die Logs nicht abgeschnitten werden und wirklich jeder Fehler zu sehen ist. Wird das Debuggen ausgeschaltet, wird hier "nur" der entsprechende Wert gesetzt.

Mit

1

tail -f /var/los/syslog | grep FW

sieht man dann nur noch die entsprechenden Einträge und kann los legen Fehler zu eleminieren.

Teil 5 - Auf welche Fragen darf der Server antworten?

Jetzt wird es etwas "komplizierter". Die Regeln um die Netzwerke zu "schützen" sind ja noch relativ einfach. Um aber den Server selbst zu schützen, muss man noch etwas feiner arbeiten.

Hier gibt es erst mal drei verschiedene Zustände, über die man sich Gedanken machen muss. Zugriff vom internen Netzwerk, erlaubter Zugriff auf Dienste von draußen aus dem Internet und das was der Server mit sich selbst veranstalten darf.
Diese Regeln hier sind ganz sicher noch nicht der Weisheit letzter Schluß, sollen und können aber durchaus eine Anregung sein hier weiter zu spielen.

Das einfachste zuserst:

1

$FW -A INPUT -i lo -j ACCEPT ## localhost darf alles mit sich selbst tun *lol*

Wenn nur alles so einfach wäre! Denn alles was rein kommt über die Schnittstelle (-i) und localhost (lo) ist, wird akzeptiert. ,o)

1
2
3
4
5
6
7
8

TCP_P_INT="0:65535"
UDP_P_INT="0:65535"

$FW -A INPUT -s 10.8.0.0/24 -j ACCEPT
$FW -A INPUT -p tcp --dport $TCP_P_INT -i $DEV_INTERN -j ACCEPT
$FW -A INPUT -p udp --dport $UDP_P_INT -i $DEV_INTERN -j ACCEPT
$FW -A INPUT -p tcp --dport $TCP_P_INT -i $DEV_WLAN -j ACCEPT
$FW -A INPUT -p udp --dport $UDP_P_INT -i $DEV_WLAN -j ACCEPT

Von den internen Schnittstellen darf erst mal auf alles zugegriffen werden. Hier fehlt jetzt nur noch alles das was von den vboxen kommen darf

1

$FW -A INPUT -i $DEV_VBOX -j ACCEPT

Diese Zeile ist nun wirklich auf das notwendigste zusammen geschrumpft. Alles was über $DEV_VBOX rein kommt ist erlaubt. Vorher wurde zumindest noch tcp und udp als Protokoll mit den erlaubten Ports definiert. Beides ist im Grunde die selbe Regel. Letzteres jedoch gekürzt auf ein Minimum.

Bis hier hin darf das interne Netzwerk alles, das externe hat immer noch keinen Zugriff. Das wird nun damit definiert:

1
2
3
4

$FW -A INPUT -p tcp -i $DEV_EXTERN --dport 80 -j ACCEPT    # Apache
$FW -A INPUT -p udp -i $DEV_EXTERN --dport 1194 -j ACCEPT  # VPN
$FW -A INPUT -p udp -i $DEV_EXTERN --dport 9987 -j ACCEPT  # TS3
$FW -A INPUT -p tcp -i $DEV_EXTERN --dport 30033 -j ACCEPT # TS3

Und hier wird dann tatsächlich für jeden Dienst eine eigene Regel angelegt. Und diese sollte so genau wie möglich sein. Also anhand von Zeile 1 beschrieben, etwas darf rein, welches das Protokoll tcp spricht, als Input-Schnittstelle $DEV_EXTERN besitzt und als Zielport 80, den Apache interviewen möchte. Das wird akzeptiert, der Rest komplett verworfen.

1
2
3
4
5
6
7

## Alles was einmal rein gelassen wurde, darf auch zurück antworten
$FW -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

## Alles was bis hier her nicht auf INPUT definiert worden ist, wird geloggt, geblockt und dann verworfen
$FW -A INPUT $LOG_LIMITER -j LOG --log-prefix "[FW] LOCAL-INPUT-DENY "
$FW -A INPUT -j DROP
$FW -P INPUT DROP

Damit könnte der Apache nun antworten. Denn alles was zu ihm durfte, darf er ja auch beantworten. (Zeile 2)

Die OUPTUT-Regeln

Also diese sind fast noch wichtiger als das was rein darf. Denn hier entscheidet sich, was man als Administrator des Servers nach außen hin tun darf. Nicht mal ein Update der Server-Software, würde jetzt funktionieren.

Als erstes wieder das einfachste, localhost darf auf sich selbst alles

1
2

## Allen lokalen Diensten erlauben irgend wo hin zu gehen (Updates z.B.)
$FW -A OUTPUT -o lo -j ACCEPT

Alles andere sähe in etwa so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

$FW -A OUTPUT -p icmp -j ACCEPT                                         # ping
$FW -A OUTPUT -p udp -o $DEV_EXTERN --dport 33434:33523 -j ACCEPT       # traceroute Linux, Win nutzt icmp
$FW -A OUTPUT -p udp -o $DEV_INTERN --dport $UDP_P_INT -j ACCEPT
$FW -A OUTPUT -p udp -o $DEV_EXTERN -m multiport --dport 53,123 -j ACCEPT ## DNS, NNTP
$FW -A OUTPUT -p udp -o $DEV_VBOX --dport $UDP_P_INT -j ACCEPT
$FW -A OUTPUT -p udp -o $DEV_WLAN --dport $UDP_P_INT -j ACCEPT
$FW -A OUTPUT -p udp -o $DEV_INTERN --dport 631 -j ACCEPT ## CUPS
$FW -A OUTPUT -p udp -s 127.0.0.1 --dport 1024:65535 -d $DNS1 -j ACCEPT ## externe DNS Serverabfrage zulassen
$FW -A OUTPUT -p udp -s 127.0.0.1 --dport 1024:65535 -d $DNS2 -j ACCEPT ## externe DNS Serverabfrage zulassen
$FW -A OUTPUT -p tcp --dport 80 -j ACCEPT                               # Apache
$FW -A OUTPUT -p udp -o $DEV_EXTERN --dport 9987 -j ACCEPT              # TS3
$FW -A OUTPUT -p tcp -o $DEV_EXTERN --dport 30033 -j ACCEPT             # TS3
$FW -A OUTPUT -p tcp -o $DEV_EXTERN -m multiport --dport 80,443 -j ACCEPT

## Alles was ne Verbindung über INPUT aufgebaut hat, darf natürlich auch antworten 
$FW -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#$FW -A OUTPUT -j LOG --log-prefix "[FW] LOCAL-OUTPUT-DENY "
$FW -A OUTPUT $LOG_LIMITER -j LOG --log-prefix "[FW] LOCAL-OUTPUT-DENY "
$FW -P OUTPUT DROP                                                         # und Sperren

Zeile 1 besagt, dass man von local aus einen ping nach überall hin tätigen kann. Zeile 2 erlaubt dann einen traceroute.

Zeile 4 erlaubt dem Admin auf dem Server Port 53 (DNS) und Port 123 (NNTP) zu nutzen, der in Richtung $DEV_EXTERN gehen darf.

Im Gegensatz dazu wird localhost in Zeile 8 + 9 erlaubt selbst etwas zu tun. Der DNS darf die von Intern gestellten Fragen nach außen weiterleiten. Hier besonders restriktiv, weil nur die Protokollfamilie udp erlaubt ist, mit der Source localhost (oder 127.0.0.1), die Zielports (--dport ^ Destination-Port) irgendwo zwischen 1024:65535 sind und als Zieladresse (-d) die IP-Adresse des anzufragenden DNS-Servers hinterlegt sind. Alle anderen Adressen werden verworfen, nur DNS wird darüber antworten.

Ohne Zeile 13 würde man vom localhost keine Updates machen können. Alles andere dann wie zuvor gehabt.

Vielleicht eine kleine Eselsbrücke. Die Option -i (Input-Device) kann nur in der Regel INPUT vorkommen. Selbiges gilt dann auch für die Regel -o (Output-Device), die nur bei OUTPUT einen Sinn macht. -s (Source-IP) ist immer das woher etwas kommen kann, -d (Destination-Device) wohin etwas gehen soll. --dport (wohin) und --sport (woher) sind dann immer nur die "verlängerten" Optionen für -d oder -s.

Ich denke das dürfte es fürs erste gewesen sein. Vielleicht kann der ein oder andere etwas damit anfangen. Und eine Firewall ist niemals fertig. Hier gibt es immer etwas zu basteln.

Wer hier nun durch ist, kann sich sicher sein, dass er eine Firewall besitzt die sagt, alles was nicht explizit erlaubt ist, wird blockiert. Die meisten (gefühlte 95%) widmen sich meist dem umgekehrten Fall. Lass alles durch und blockiere nur das nicht erlaubte. Nur sei Dir versichert, Du wirst manches mal fluchen und bei jeder Gelegenheit die Firewall im Verdacht haben. ;o)

(vorläufiges) Ente

Wutze schrieb:

Verdammt, mir fällt grad nicht der Name dieses blöden Spiele-Anmelde-Verkaufs-Programms ein ....

Steam, vllt?

Eine Menge Arbeit! *lob*

Vielleicht magst du dein Netzwerk noch mit jNetMap illustrieren?

Ryu

Jaa, Steam .. Danke. Ich nutze es halt nicht. Mein Spielzeug sind Netzwerke *gg*

Aber gut, nen kleines Netzwerkschema ist fix gemacht. (Ich hoffe das funzt)

Teil 6 - lesen der Logs

Ich bin gefragt worden, wie das nun mit dem lesen der Logs ist und dem verändern der Firewall-Regeln. Ich versuche das mal anhand von aktuellen Beispielen etwas zu erläutern.

Beispiel 1:
Kind installiert neues (!) Spiel, World of Warcraft 3, und hupt mächtig herum, dass das Spiel nicht funktioniert. Es könne sich nicht verbinden. Bevor das Kind nun Maikäfer spielt, es wirft sich theatralisch auf den Rücken und strampelt mit den Beinen, müssen wir einschreiten.

Meistens wissen wir die dafür zugrunde liegenden Ports nicht, über die dieses Spiel sich mit dem Internet verbinden möchte. Ich vertraue hier auch selten auf Forenbeiträge, da diese meist von Usern erstellt sind, die von Firewall wenig bis gar keine Ahnung haben.

Um nun den entsprechenden Port heraus zu finden, benötigt man dringend den Eintrag des eigenen Firewall-Debug auf 1. Jetzt wird alles angezeigt.

Die Log Einträge sehen nun so aus:

Feb 14 19:49:38 tv kernel: [464253.226925] [FW] DENY-TRANSPORT-ACCESS IN=wlan0 OUT=ppp0 MAC=70:71:bc:af:08:27:00:16:38:e7:28:f1:08:00 SRC=192.168.103.55 DST=213.248.106.66 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=1779 DF PROTO=TCP SPT=49245 DPT=6112 WINDOW=8192 RES=0x00 SYN URGP=0

Hier ist nun wirklich alles zu finden was man benötigt, um den entsprechenden Port auf der Firewall freigeben zu können.

* Die Firewall "erzählt", dass etwas blockiert wird in der Regel "DENY-TRANSPORT-ACCESS".
* IN=wlan0 → also kommt aus dem WLAN, wo auch das Kind mit dem Computer sitzt.
* OUT=ppp0 → es soll etwas nach draußen transportiert werden

Das muss es sein!

Die MAC-Adressen sind hier uninteressant

* SRC=192.168.103.55 → die Herkunft des Paketes, welches nach draußen möchte. Jetzt muss man sein Netzwerk kennen! Denn diese IP-Adresse ist ja eigentlich nicht die IP-Adresse des PCs, der diese Verbindung aufbauen will. Diese IP-Adresse ist jedoch das eine "Bein" des WLAN-Routers im Netzwerk 192.168.103.0/24 vom Netzwerk 192.168.2.0/24. Also kommt die Anfrage tatsächlich auch aus der richtigen Richtung!
* DST=213.248.106.66 → Mit diesem Server/Host, dahin will sich der Computer verbinden

HINWEIS
Die Pakete zurück, werden dann als DST=192.168.2.33 angezeigt. Auch das ist korrekt, da ja der WLAN-Router nun nicht wirklich viel damit anfangen kann, die Routen auf dem Server aber wissen wo das Netzwerk zu finden ist und die Pakete dahin weiter leiten. Und der WLAN-Router seinerseits kennt den Client.

Die nachfolgenden Einträge sind hier auch nicht wichtig. Erst ab
* PROTO=TCP → das verwendete Protokoll ist der Familie TCP zuzuordnen
* SPT=49245 (SourcePort) ist wichtig für die Rückantwort zum PC, muss aber nicht bearbeitet werden
* DPT=6112 → (ZielPort oder DestinationPort) da will sich der PC hin verbinden

Den Rest benötigen wir nicht mehr.

Wir haben nun auf jeden Fall den Port herausgefunden. Fix noch mal Google befragt ob "Port 6112" in irgend einer Weise bekannt ist. Taucht Warcraft 3 dann auf, müsste es zu 99% der richtige Port sein. Wir können dann weiter machen.

Zusammengefasst kann man nun die Regel eigentlich schon "sehen".

* "DENY-TRANSPORT-ACCESS" → $FW -A TRANSPORT
* IN=wlan0 → -i $DEV_WLAN
* OUT=ppp0 → -o $DEV_EXTERN
* SRC=192.168.103.55 → nicht benötigt
* PROTO=TCP → -p tcp
* DPT=6112 → --dport 6112
zum Schluß nur noch akzeptieren → -j ACCEPT
einen Kommentar dazu, damit man nicht vergisst was das soll → ## Warcraft 3
Fertig ;o)

Jetzt ergibt sich damit folgende neue Regel:

1

$FW -A TRANSPORT -p tcp -i $DEV_WLAN -o $DEV_EXTERN --dport 6112 -j ACCEPT ## Warcraft 3

Diese neue Regel jetzt einfach in das Firewall-Script eintragen, fertig. Im Grunde genügt es das Script nur neu ausführen zu lassen.

Wer jetzt aber ganz genau sein möchte, der kann zusätzlich noch den entsprechenden Host im Internet angeben. Damit kann dann über diesen einen Port nur zu dieser einen IP-Adresse verbinden. Blöd nur, wenn die IP sich verändert. Dann funktioniert die Verbindung auch nicht mehr. Hierzu müsste man dann zusätzlich noch DNS befragen bzw. mit Wireshark die Traffic analysieren um den FQDN zu finden, zu welchem DNS-Host verbunden werden soll.

Beispiel 2
Im LAN 1 hat einer der Clients einen Bit-Torrent-Client laufen. Wir erinnern uns, Teil 3 - zweiter Codeblock, die Zeilen 26 + 27. Eigentlich für Skype gedacht, BitTorrent nutzt die selben Ports per UDP. Zielport der Abfragen aus dem Internet ist hier immer 51413. Der Client hat selbst eine Verbindung geöffnet, es läuft also die Anfrage nach draußen und darf Retour/Zurück auch beantwortet werden. Alle anderen Abfrager, was denn sonst noch evtl. so bei mir zu finden wäre, laufen ins leere. Die Logs dazu sehen dann so aus:

Feb 14 23:18:38 tv kernel: [476779.061126] [FW] LOCAL-INPUT-DENY IN=ppp0 OUT= MAC= SRC=178.214.150.209 DST=14.51.69.128 LEN=129 TOS=0x00 PREC=0x00 TTL=113 ID=20989 PROTO=UDP SPT=17079 DPT=51413 LEN=109

Die Regel die hier greift ist nun aber "LOCAL-INPUT-DENY" und nicht TRANSPORT? Ganz einfach erklärt, wir haben keinen Kontakt zur Gegenstelle aufgebaut, daher weiß unser Router/Firewall nicht, wohin diese Fragen zu senden wären. Der Server nimmt daher an, der Kontakt soll direkt zu ihm gehen. Da hier aber weder ein Dienst seine Pforten geöffnet hat noch eine Weiterleitung dieses Ports DPT=51413 besteht, wird dieser Kontaktversuch abgebrochen.

Mit anderen Worten, es bekommt immer nur die Person etwas von uns, wenn wir auch etwas von ihr bekommen. Die "Fehlermeldung" ist also erwünscht, die Firewall arbeitet korrekt.

Da dieser Thread ziemlich schnell in der Versenkung verschwinden wird, warum trägst du das ganze nicht ins Wiki ein?

TheDarkRose schrieb:

Da dieser Thread ziemlich schnell in der Versenkung verschwinden wird, warum trägst du das ganze nicht ins Wiki ein?

Weil es in erster Linie nicht Wiki-konform ist. Es ist auch keine Vorstellung oder Installationshilfe eines Programms. Es ist lediglich ne Art von FAQ: "Wie kann ich etwas nutzen".
Weiterhin ist mir im Moment kein Beitrag im Wiki bekannt, der die Handhabung von etwas beschreibt, woran man sich im Wiki etwa annähernd orientieren könnte. Zudem habe ich keine Lust auf irgend welchen "Stress", nur weil etwas vom Verfasser anders bedacht wurde als das was man hier gerne sieht. Ich mag in solchen Texten keine Kästchen und Böxchen ...

Hmn, also ich hab den Thread abonniert 😉

Und wie bei manchen anderen häufig referenzierten Seiten wird das schon nicht in Vergessenheit geraten, denke ich ...

Wutze schrieb:

Zudem habe ich keine Lust auf irgend welchen "Stress", nur weil etwas vom Verfasser anders bedacht wurde als das was man hier gerne sieht. Ich mag in solchen Texten keine Kästchen und Böxchen ...

Andere Idee!

Verlink es doch auf deiner Benutzerseite (nach Überschriften sortiert?).

Von einigen Usern wie elektronenblitz63 kenne ich dieses Vorgehen auch schon 😉

Und der wird auch oft zitiert!

Ryu

Gestern Abend ist der Router das erste mal neu gestartet worden und sagte danach keinen Piep mehr. Also er war da, hatte alle Regeln die er so besitzen sollte. Jeder Dienst der laufen sollte tat auch das seinige. Also eigentlich alles korrekt. ;o)

Trotzdem kam keiner mehr ins Internet. Auch in die internen anderen Netzwerke ging nichts mehr. Im Teil 4 im ersten Scriptblock, fehlte noch ein ganz wesentlicher Eintrag in Zeile 14

1

sysctl -w net.ipv4.ip_forward=1

Wenn man das nicht vergisst, funktioniert dann tatsächlich alles wie versprochen. ;o)
Unglaublich was so eine kleine Zeile alles bewirken kann ,o)

PS:
@Ryuno, hab ich gemacht ;o)

Wutze schrieb:

PS:
@Ryuno, hab ich gemacht ;o)

Ach, DU warst derjenige mit dem Bookmarkserver! Hab ich mir zumindest abonniert ... will ich mir anschauen, wenn meine alte Kiste soweit ausrangiert wird (~2 Jahre?). ☺