Reverse Firewall mit Live-Parametrierung

[peterLSN]

Hallo,

ich habe mir für mein lokales Netzwerk einen kleinen Firewall-Rechner mit Debian gebastelt. Das
Ziel ist, Geräte denen ich nicht vertrauen kann (wie mein Fernsehr) in ein eigenes Netz zu verbannen
und den Internet-Zugriff entsprechend zu "sanktionieren". Zwar bin ich mit dem Umgang mit iptables
durchaus vertraut und die Weiterleitung zwischen den Interfaces ist im Grunde kein Problem, was
ich jedoch gern hätte wäre ein Tool, welches mir Verbindungsversuche grafisch darstellt (z.B. Web-basiert
im internen, d.h. nicht sanktionierten Netz) und ich diese explizit bestätigen kann.

Im Grunde genommen müsste das Tool ja lediglich die Log-Meldungen von iptables analysieren und
grafisch aufbereiten sowie eine entsprechende accept-rule generieren, wenn ich den Zugriff erlauben
möchte.

Kennt ihr hier irgendeine fertige Lösung, die ich einsetzen könnte?

Vielen Dank schonmal!
Peter

[rendegast]

ntop?
Analysiert aber den Netzwerkverkehr, nicht die (evtl. separaten) iptables-Logs.
Sollte an einer zentralen Stelle, also zBsp. auf die firewall.
Sehr viel einfacher gehaltene Alternative darkstat,
zeigt aber zBsp., wieviel Pakete vom/zum Port eines Host kommen/gehen.


"log" ist ein blöder Suchbegriff, daher ein wenig Filter:

Code: Alles auswählen

apt-cache search anal | sed 's@logic@LGC@g;s@technolog@TCHNLG@g' | grep -i log | sort | less -i

apt-cache search log | sed 's@logic@LGC@g;s@technolog@TCHNLG@g' | grep -i anal | sort | less -i

Für die komplexer gehaltenen Netzwerkanalyse- oder Überwachungs-Frameworks lassen sich wohl passende Module erstellen/finden.

[r4pt0r]

Wenns dir primär darum geht zu schauen ob die iptables-regeln greifen bzw die config etwas "verständlicher" werden soll schau dir die shorewall an. Das ist im Grunde eine abstraktionsschicht für iptables die die Konfigurationslogik näher an die Netzwerktopologie rückt: Man konfiguriert Zonen und interfaces und weist diesen entsprechende Regeln zu. Damit lassen sich auch kompliziertere Konfigurationen (Mehrere Subnetze auf einem Interface z.B.) deutlich einfacher erfassen/verwalten.
Viele vorgefertigte macros erleichtern die Konfiguration ohne dass das ganze undurchsichtig wird (wie z.B. bei Firestarter).
Die generierten logs orientieren sich am selben Modell und man kann damit schnell neue Regeln anlegen wenn ein Programm/Dienst nicht funktioniert - ein Eintrag schaut z.B. so aus:

Code: Alles auswählen

Jul 13 03:05:05 loc2dsl:REJECT:IN=eth0 OUT=ppp0 SRC=5.4.3.2 DST=1.2.3.4 LEN=65 TOS=0x00 PREC=0x00 TTL=63 ID=45339 DF PROTO=UDP SPT=39053 DPT=53 LEN=45 

Man gibt dann einfach von "loc" nach "dsl" udp 53 frei bzw per macro: DNS(ACCEPT)

Das lässt sich auch sehr leicht per fail2ban auswerten bzw mit perl-scripten bzw mit praktisch allem was annähernd regexp versteht. So lassen sich einfach statistiken sammeln und ggf grafisch aufbereiten. Kann mir auch gut vorstellen dass es da schon was gibt.


Mit "live-parametrierung" meinst du anscheinend Programmbasierte regeln wie sie die Windows-Firewall nutzt. Für lokale Firewall-Konfiguration kenne ich da nur Firestarter - der war mir persönlich aber zu undurchsichtig, daher nutze ich auch auf Clients die in fremden Netzen unterwegs sind (Notebooks) shorewall.
Die Firewall am Gateway von Clients aus zu Konfigurieren ist zumindest bedenklich - dann nutze lieber UPnP. Die Firewall sollte aber eigentlich keinesfalls von kompromittierten Clients aus Konfiguriert werden können. UPnP ist da auch schon eher die Büchse der Pandora...

Wenn die Firewall einmal eingerichtet ist rührt man die Konfiguration sowieso nur noch selten an - Anfangs vll noch etwas öfter, ich hab an meiner Firewall zuhause sicher seit mehreren Monaten nichts mehr geändert....

[peterLSN]

Nun, shorewall habe ich mir auch bereits angesehen und dies werde ich wohl zur grundsätzlichen Konfiguration auch einsetzen, da dies natürlich deutlich einfacher geht, als die Regeln "zu Fuß" aufzuschreiben.

Von der Windows-Firewall hab ich leider keine Ahnung, meine letzte Windows-Installation ist mehr als 15 Jahre her Vielleicht sollte ich das Ziel meiner Anwendung noch etwas mehr verdeutlichen: Ich hab im Heimnetz Geräte, über die ich leider keine Kontrolle habe, wie z.B. mein TV. Da ich z.B. die Mediathek nutzen möchte, ist die Verbindung zum Internet erstmal unabdingbar. Hier möchte ich jedoch den Zugriff beschränken, d.h. ich möchte vermeiden, dass der TV irgendwelche anderen Daten sendet, sondern tatsächlich nur mit den Mediatheken kommuniziert, für die er freigegeben ist. Ich brauche also keine generelle Port-Freigabe, sondern direkt die Freigabe "Client X -> Server Y".

Die Parametrierung der FW soll natürlich nicht vom TV aus möglich sein. Der FW-Rechner hat zu diesem Zweck mehrere Netzwerk-Schnittstellen und auch mein internes Netz wird von der Firwall geschützt. Aus dem internen Netz ist der Zugriff über ssh und somit jede beliebige Konfiguration möglich. Die Web-Schnittstelle könnte also durchaus via ssh getunnelt werden, um dort nicht noch weitere Ports zu öffnen.

Ich kenne derartige Reverse-Firewalls lediglich auf dem Host selbst, d.h. das eine Kontrolle des ein- und ausgehenden Datenverkehrs auf einer Per-Programm-Ebene möglich ist. Dies nützt mir jedoch nichts, wenn ich dem Endpunkt nicht vertrauen bzw. diesen nicht modifizieren kann. Daher bin ich auf eine Analyse des Datenstromes im Netzwerk angewiesen...

[r4pt0r]

Das Sinnvollste wäre, unvertraute Geräte in eine eigene FW-Zone zu verbannen. Sei es via VLAN, Subnetz oder komplett getrenntes Netz an einer eigenen NIC am gateway. Das vertrauenswürdige Netz kann dann ggf sogar UPnP nutzen wenn man will/"muss".

Habe bei mir im Netz die Fritzbox ebenfalls in eine eigene Zone verbannt - ausschließlich Voip-Traffic wird hier für die ip der FB zugelassen. Die WLAN-Clients landen in einer "untrusted wireless" Zone (-> eigenes subnetz via dhcp) die nur rudimentären Zugriff aufs WAN haben (mail + port 80/443 via eigenem, restriktivem privoxy), ausser sie sind explizit als Host am dhcp konfiguriert, dann landen sie im "trusted subnet" mit deutlich mehr berechtigungen und Zugriff auf die lokalen Dienste.

Durch das subnetting lassen sich auch die lokalen Dienste sehr einfach einschränken -> subnetz whitelisten / listen-address / bind to interface usw...

[debianoli]

apt-cache search anal | sed 's@logic@LGC@g;s@technolog@TCHNLG@g' | grep -i log | sort | less -i

Bisschen zweideutig, oder? Wenn du das bei google eingibst, landest du manchmal auf sehr eigenartigen Seiten...

[Six]

Was r4pt0r vorschlägt ist die richtige Idee: trenne deine Verbraucher, damit du sie besser kontrollieren kannst. Dazu musst du nicht unbedingt im Netzwerk Änderungen vornehmen, du kannst in deinem speziellen Fall auch verschiedene iptables chains benutzen. Über die chains kannst du auch leicht den traffic loggen und über die Zeit deine Firewall so verfeinern, dass du tatsächlich nur noch erwünschten outbound traffic hast.

ABER: GNU/Linux' iptables sind "nur" stateful. Was du eigentlich möchtest, nennt sich application level filtering (z. B. wie unterscheide ich zwei Applikationen, die beide auf ein Ziel a.b.c.d:80 zugreifen) und liegt außerhalb des scopes von iptables. Alf lässt sich sinnvoll sowieso nur auf den application host durchführen (z. B. mit AppArmor, RSBAC oder SELinux), danach ist das network traffic und meistens nicht erkennbar, welche Applikation den Ursprung darstellt -- nur das Ursprungssocket ist noch klar. Ist der traffic unverschlüsselt, kann ein proxy bzw. content filter helfen, der deep packet inspection (dpi) durchführt und sich den payload deiner Pakete angucken kann. Mir sind da L7 und ndpi bekannt. Letzteres kommt streckenweise sogar mit verschlüsselten Paketen zu einem Ergebnis.*


* Tangente: Ich denke, nun wird auch klar, warum sich SysAdmins von großen Infrastrukturen häufig gegen Verschlüsselung wehren.

[r4pt0r]

DPI ist _sehr_ Hardwareintensiv wenn man nicht reihenweise Anwendungen in timeouts rennen lassen will!
Eine Snort-VM z.B. gönnt sich in einem Netz mit ~15 Windowsclients locker mal 2 CPUs vom Host (2x quadcore Xeon L5506) + 6-8GB RAM (gerne auch mal mehr).
Will man DPI am gateway einsetzen darf dieses praktisch kein I/O-wait haben, sonst sind Anwendungen schon spürbar verzögert bzw schlechte Clientsoftware reißt ständig die Hufe hoch... (verbindungsabbrüche etc). Videostreaming ist auch oft kritisch und muss eigentlich ausgenommen werden wenn es wirklich genutzt werden soll/darf.

Es gibt auch DPI das nur den Header des ersten Pakets inspiziert und darüber den gesamten folgenden Stream blockiert oder passieren lässt. Fast alle kommerziellen border-gateways mit angepriesenem "high performance DPI" o.ä. machen das so - bringt aber nix wenn die igentliche payload z.B. hinter einem html/xml header verpackt wird.

Um aber auf dem Teppich zu bleiben: Fürs Heimnetz ist DPI IMHO völliger overkill - fürs reine Firewalling reicht ein eher konservativ konfiguriertes gateway und an den clients SELinux installieren (+ Setroubleshoot für einfachere Verwaltung) und ggf noch via Firestarter o.ä. rudimentäre FW-Regeln definieren (oder ebenfalls shorewall)