Erweiterte Firewall-Techniken

Alles rund um sicherheitsrelevante Fragen und Probleme.
Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Re: Erweiterte Firewall-Techniken

Beitrag von DynaBlaster » 06.03.2014 19:24:32

Code: Alles auswählen

http://www.iptables.info/en/iptables-matches.html#OWNERMATCH
Das dürfte allerdings wohl nur funktionieren, wenn man die Anwendung auf dem Host ausführt, der auch per iptables "abgesichert" ist. Auf einem Gateway/Router kommt dann wohl nur ein Proxy wie Squid in Frage.

Code: Alles auswählen

http://gaugusch.at/squid.shtml
Das hilft aber vermutlich auch nur bedingt, weil es sicher einige Schadprogramme gibt, die die Proxyeinstellungen aus dem(n) installierten Browser(n) auslesen und ggf. als eben solcher Browser ausgeben. Immerhin kann man dann wenigstens in den Squid-Logs ohne Probleme nachvollziehen, welcher Rechner (oder IP) bzw. User über den Proxy raus- und vor allem wohin gegangen ist.

Gefährliches Halbwissen :-)

Benutzeravatar
router
Beiträge: 153
Registriert: 29.01.2004 19:27:43
Wohnort: Wuppertal

Re: Erweiterte Firewall-Techniken

Beitrag von router » 06.03.2014 20:20:53

"Owner Match" ist genau das, was ich suchte. Vielen Dank!

bumer
Beiträge: 238
Registriert: 02.07.2014 12:29:15

Re: Erweiterte Firewall-Techniken

Beitrag von bumer » 20.07.2015 10:12:13

DynaBlaster hat geschrieben:

Code: Alles auswählen

http://www.iptables.info/en/iptables-matches.html#OWNERMATCH
Das dürfte allerdings wohl nur funktionieren, wenn man die Anwendung auf dem Host ausführt, der auch per iptables "abgesichert" ist.
Ich roll das mal hier ein Bisschen auf: "Owner-Match" ist ja für ältere Kernel und wird heutzutage ja nicht mehr unterstützt. Gibt es da Alternativen? Suche nämlich auch nach einer Möglichkeit nur bestimmten Programmen (sprich Whitelist) den Zugang zum Net zu erlauben.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Erweiterte Firewall-Techniken

Beitrag von catdog2 » 20.07.2015 11:38:59

Nein, die Erklärung impliziert ziemlich deutlich, wie weiter abgesichert werden kann: Auf dem Client.
Auch wenn das keiner wahr haben will, aber die Idee mit der Externen Firewall ist eine Sackgasse. Das einzige wozu das führt ist, dass die ganzen legitimen Anwendungen sich mittlerweile selbst wie Schadsoftwre verhalten muss, um den immer kaputteren Fangmechanismen zu entkommen. Das fängt im übrigen bei den SNAT-Regeln an, die alles aufhalten (Zu aller erst sichere und private kommunikation) nur keine Schadsoftware. Weil die ist drauf ausgelegt sich zu tarnen.
:THX: Sehr richtig.
Aber bedeutet dass, dass ihr alle keine Firewalls oder NATs einsetzt?
Um NAT kommt man kaum rum dank latentem ipv4 Adressmangel. NAT ist aber auch nur genau dazu da und es ist auch explizit kein Sicherheitsfeature!
NAT kommt da zum Einsatz, wo es gebraucht wird. (IP Mangel) Im übrigen ist eine reine Firewall wesentlich flexibler und braucht für das gleiche weniger weniger resourcen, als ein NAT. Genau deswegen ist es völliger Unsinn NAT mit IPv6 einzusetzen.
NAT (vor allem SNAT) sollte man immer vermeiden wo es nur geht das ist ein übler hack mit vielen Nachteilen.
Bzw. sie einfach so konfiguriert, dass sie rausgehenden Traffic komplett durchlassen und "nur" reinkommenden filtern?
Wenn dann nur gezieltes blacklisten von Diensten, die nur in deinem LAN erreichbar sein sollen. Dieser Mist hat zusammen mit NAT das Ende zu Ende Prinzip kaputt gemacht.
Ich schließe mich da Wanne an, aber es bietet in gewisser Weise zusätzliche Sicherheit, nämlich vor'm Benutzer, der z.B. "mal eben" oder "zum Ausprobieren" einen neuen Dienst installiert, welchen er vielleicht nur lokal benötigt, aber aus Versehen oder Unkenntnis falsch konfiguriert.
Das ist ein Gewinn, aber eben nur ein marginaler.
Wie gesagt ist es eben nicht zwangsläufig Fehlverhalten des Benutzers sondern vielleicht auch gewollt. Das sollte man bedenken bevor man so etwas Konfiguriert.
Fuer diesen speziellen Fall macht iptables wirklich Sinn. Danke fuer das Beispiel; ich hatte schon befuerchtet, dass es fuer iptables ueberhaupt keinen Anwendungsfall gibt.
Es gibt sehr viele nur sollte man die Konsequenzen und den Sinn gewisser Regeln im Auge behalten und nicht irgendwas einstellen weil der Freund eines Freundes mal gehört hat … wäre gut.
Ich roll das mal hier ein Bisschen auf: "Owner-Match" ist ja für ältere Kernel und wird heutzutage ja nicht mehr unterstützt. Gibt es da Alternativen? Suche nämlich auch nach einer Möglichkeit nur bestimmten Programmen (sprich Whitelist) den Zugang zum Net zu erlauben.
Nein das owner Modul wird weiter unterstützt. Das was nicht mehr funktioniert ist das matchen auf prozess ids (war wohl eh kaputt) aber du kannst durchaus noch auf user ids matchen und Prozesse, die unter einem bestimmten Nutzer laufen reglementieren.
Eine andere nette Möglichkeit solche Dinge zu erreichen sind Network Namespaces, einfach mal googlen. Wenn du Prozesse mit systemd startest musst du nicht mal viel tun http://www.freedesktop.org/software/sys ... teNetwork= wobei es für einen Whitelist Ansatz wohl besser wäre das physikalische Interface in einen neuen Namespace zu verschieben und im default namespace nur lo zu haben.
Unix is user-friendly; it's just picky about who its friends are.

tomi89
Beiträge: 269
Registriert: 21.08.2014 00:21:52

Re: Erweiterte Firewall-Techniken

Beitrag von tomi89 » 21.07.2015 15:37:42

Automatisierte Sicherheitsupdates, richtige und sichere Konfiguration des Servers, Debian Abhärtung inkl. Iptables, sysctl.conf.

Und ggf. den Server z.B. via LXC oder Firejail sandboxen oder gleich in eine VM packen und immer eine Sicherheitskopie vorhalten.

Alles andere halte ich für Zwecklos.

Die Anzahl der Sicherheitslücken hält sich bei Debian sowieso in Grenzen und Profihacker interessieren sich wahrscheinlich für ganz andere Server.

bumer
Beiträge: 238
Registriert: 02.07.2014 12:29:15

Re: Erweiterte Firewall-Techniken

Beitrag von bumer » 22.07.2015 14:38:09

catdog2 hat geschrieben:
Ich roll das mal hier ein Bisschen auf: "Owner-Match" ist ja für ältere Kernel und wird heutzutage ja nicht mehr unterstützt. Gibt es da Alternativen? Suche nämlich auch nach einer Möglichkeit nur bestimmten Programmen (sprich Whitelist) den Zugang zum Net zu erlauben.
Nein das owner Modul wird weiter unterstützt. Das was nicht mehr funktioniert ist das matchen auf prozess ids (war wohl eh kaputt) aber du kannst durchaus noch auf user ids matchen und Prozesse, die unter einem bestimmten Nutzer laufen reglementieren.

Code: Alles auswählen

$iptables -A OUTPUT -m owner --cmd-owner PROGRAMMNAME
$iptables -A OUTPUT -m owner --uid-owner USERID
$iptables -A OUTPUT -m owner --gid-owner GROUPID
Alle nur bis Kernel 2.6 unterstützt.

Habs trotzdem gerade mal ausprobiert:cmd-owner gibt 'ne Fehlermeldung aus und die anderen beiden funktionieren nicht.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Erweiterte Firewall-Techniken

Beitrag von catdog2 » 22.07.2015 14:41:07

Nein cmd-owner geht nicht, die anderen Beiden schon, (man iptables-extentions). Das mit der uid geht auf jeden Fall, das hab vor sehr kurzer Zeit erst das letzete mal benutzt.
Unix is user-friendly; it's just picky about who its friends are.

bumer
Beiträge: 238
Registriert: 02.07.2014 12:29:15

Re: Erweiterte Firewall-Techniken

Beitrag von bumer » 22.07.2015 16:21:13

catdog2 hat geschrieben:Eine andere nette Möglichkeit solche Dinge zu erreichen sind Network Namespaces, einfach mal googlen. Wenn du Prozesse mit systemd startest musst du nicht mal viel tun http://www.freedesktop.org/software/sys ... teNetwork= wobei es für einen Whitelist Ansatz wohl besser wäre das physikalische Interface in einen neuen Namespace zu verschieben und im default namespace nur lo zu haben.
:THX: Nach langem Suchen wird mir aber einfach nicht klar wo ich die configuration-option PrivateNetwork= einzutragen habe?
The execution specific configuration options are configured in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.
Wo befinden sich diese sections?
Könntest du bitte mit einem weiteren Hinweis behilflich sein? Danke.

tomi89
Beiträge: 269
Registriert: 21.08.2014 00:21:52

Re: Erweiterte Firewall-Techniken

Beitrag von tomi89 » 22.07.2015 20:25:46

Das Modul ipt_owner und/oder xt_owner muss geladen werden, falls es nicht automatisch passiert.

Auf jeden Fall funktioniert bei mir folgendes (Jessie):

Code: Alles auswählen

/sbin/iptables -A OUTPUT -p tcp --sport 1024:65535 -m owner --uid-owner privoxy -j ACCEPT
Und für Privoxy habe ich einen eigenes Konto angelegt.

Antworten