Netzwerkzugriff limitieren

[sanbiber]

Guten Tag,

gibt es unter FreeBSD die Moeglichkeit, ein Programm oder einen Prozess beim Netzwerkzugriff einzuschraenken (bis dahin, ihn komplett zu untersagen)?

Mit rctl kann man ja viele Resourcen limitieren, aber Netzwerk ist nicht darunter. Ein jail oder eine VM waeren natuerlich moeglich, aber ist dafuer zu aufwaendig. Kann MAC (Mandatory-Access-Control) sowas? Damit hab ich noch nie gearbeitet.

Vielen Dank und viele Gruesse
sanbiber

 

[Andy_m4]

gibt es unter FreeBSD die Moeglichkeit, ein Programm oder einen Prozess beim Netzwerkzugriff einzuschraenken (bis dahin, ihn komplett zu untersagen)?

Spontan habe ich dazu zwei Ideen.

Eine Möglichkeit wäre das Programm in einer Jail einzusperren. Das muss ja für den Fall nicht mal ne Full-Jail mit eigenem Verzeichnisbaum/System sein. Es reicht ja, wenn man als Jail-Root quasi normale Root-Directory nimmt.

Die zweite Möglichkeit ist die, über den Paketfilter zu gehen. Zum Beispiel bietet ipfw die Möglichkeit Pakete nach UID und GID zu "matchen". Man könnte also einen User-Account für den Process anlegen und den darunter laufen lassen und dann anhand der UID den Zugriff aufs Netz sperren. Das ermöglicht auch eine etwas differenziertere Reglementierung. So das man sagen kann: 'auf bestimmte Adressen darfst Du dann doch zugreifen'

 

[mr44er]

Ich hätte als absolut sicher auch eine vm oder jail im eigenen vlan vorgeschlagen. Zugang/Block dann sogar mit externer Firewall oder so (falls du mit Bots, Trojanern oder sonst. Giftzeug hantierst)

Was hast du genau vor? Eventuell kann man dann besser das Szenario einschätzen, ob nicht doch eine jail nötig/ratsam ist.

 

[sanbiber]

Danke erstmal. Ja, jail waer eine Loesung, aber ich hatte gehofft, dass es noch weniger aufwaendig geht.

Es geht einfach um ein Programm (auch nur eine Datei / ein binary), was vertrauliche Daten verarbeiten soll und das auf keinen Fall eine Verbindung zum Internet herstellen soll.

 

[Andy_m4]

Naja. Die Jail-Lösung ist ja für diesen Fall gar nicht wirklich kompliziert.
Zum anderen gibts ja noch die Alternative mit der Firewall. Man kann ja einen User-Account anlegen. Zum Beispiel mit dem Namen blockeduser.
Dann definiert man sich per ipfw eine entsprechende Firewallregel:
ipfw add 10000 deny uid blockeduser
(wobei man für 10000 halt die entsprechende Regelnummer einsetzen muss wo man die halt einsortieren will)

Das wäre jetzt ne einfache Maßnahme die aber nicht 100% "wasserdicht" ist. Denn eine uid haben nur ausgehende Pakete. Wenn der Prozess jetzt ein Socket auf macht und da kommen Traffic rein, dann wird der damit nicht erfasst (zumindest für einkommenden Internettraffic ist das in der Praxis meist kein Problem, weil der schon am Home-Router abprallt).

Außerdem hast Du natürlich Probleme mit SUID-Programmen (man kann übrigens relativ einfach heraus finden welche SUID- bzw. GUID-Dateien es gibt, indem man ein find / -type file -perm +6000 macht). Wenn die vom Prozess aufgerufen werden dann laufen die ja effektiv mit den User des SUID-Programms weshalb z.B. ping oder traceroute trotzdem funktioniert.

Kommt halt auf den konkreten Fall an ob man mit solchen Löchern leben kann oder nicht.
Wenn man das ganz weg haben will sind wir aber halt wieder bei Jails.
Wobei das - wie gesagt - auch kein größeres Problem ist da wir ja keine vollausgestattete Jail brauchen. Gut, das Setup trotzdem durchaus tricky sein kann je nachdem was das für ein Programm ist. Wenn es ein reines Konsolenprogramm ist, dann geht das easy. Wenn das irgendwie ne GUI hat wird es unter Umständen komplexer.

Müsste man einfach mal probieren und ein bisschen experimentieren. Eventuell reicht ja schon ein simples:
jail -c -u myuser path=/ ip4=disable ip6=disable command=myprogram
und wenn nicht guckt man halt von dort aus weiter wo das Problem liegt und baut das ggf. aus.

Manpages:

ipfw(8)

www.freebsd.org

jail(8)

www.freebsd.org

Mit rctl kann man ja viele Resourcen limitieren, aber Netzwerk ist nicht darunter.

Ja. Damit geht das nicht da solche Art von Ressourcen nicht damit erfasst ist.

Allerdings hat das bei mir noch einen anderen Gedankengang angetriggert. Den Geräte unter FreeBSD kann man ja durchaus mit devd und Co verwalten und denen Rechte zuordnen (zum Beispiel kann man ja auf die Grafikhardware nur direkt zugreifen wenn man in der Benutzergruppe video ist). Dummerweise sind Network-Interfaces nicht sowas wie Gerätedateien unter /dev. Sonst könnte man ja auf der Ebene irgendwas regeln. Ob da trotzdem etwas möglich ist würde ich spontan erst mal verneinen, aber vielleicht hat dazu ja jemand eine Idee.

 

[morromett]

Zum anderen gibts ja noch die Alternative mit der Firewall. Man kann ja einen User-Account anlegen. Zum Beispiel mit dem Namen blockeduser.
Dann definiert man sich per ipfw eine entsprechende Firewallregel:
ipfw add 10000 deny uid blockeduser

Ist es dann aber nicht so, dass das Programm des TE, unter dem user "blockeduser" laufen bzw. aktiv sein müsste?

 

[Andy_m4]

Ist es dann aber nicht so, dass das Programm des TE, unter dem user "blockeduser" laufen bzw. aktiv sein müsste?

Ja logisch. Das hatte ich ja auch im Posting #2 so gesagt. Da hatte ich ja die Idee das via Firewall/ipfw zu realisieren in den Raum geworfen und es dann in Posting #5 konkretisiert.

 

[sanbiber]

...
Eventuell reicht ja schon ein simples:
jail -c -u myuser path=/ ip4=disable ip6=disable command=myprogram
und wenn nicht guckt man halt von dort aus weiter wo das Problem liegt und baut das ggf. aus.
...

Das funktioniert in der Tat und ist ziemlich das, was ich brauche. Sehr schoen! Vielen Dank! Hatte ich nicht gewusst, dass man so adhoc-jails erstellen kann, die auch noch das Haupt-Dateisystem als rootfs haben. Fuer mich hatten jails immer ein eigenes root (mit ezjail gab es dann noch die Moeglichkeit, dass man nicht alle Dateien doppelt haben musste, sondern mit Verlinkungen oder nullfs-mounts arbeiten konnte, mein ich) und liefen (fast) immer - was ja bei service-jails auch Sinn macht ...

kleine Notiz: nach command= steht der Pfad zum Programm UND moegliche Parameter, keine Anfuehrungszeichen noetig.

 

[morromett]

Ja logisch. Das hatte ich ja auch im Posting #2 so gesagt.

D. h. Du gehst davon aus, dass in FreeBSD jedes Programm/Prozess, unter einem x-beliebigem user laufen/aktiv sein kann?
Ich denke, den z. B. bei der Installation (für ein bestimmtes Programm/Software automatisch) angelegten user muss man nicht ändern, aber man kann ihn evtl. Mitglied in einer bestimmten Gruppe machen und dann die gid dieser Gruppe, in einer FW-Regel benutzen.

 

[Andy_m4]

Hatte ich nicht gewusst, dass man so adhoc-jails erstellen kann, die auch noch das Haupt-Dateisystem als rootfs haben....

Im Grunde ist ja ne Jail ein recht einfacher Mechanismus. Das wird halt oft dadurch überdeckt, das in der Praxis damit häufig komplexere Setups realisiert werden.

Und ich hatte das ja auch schon in meinem ersten Posting angedeutet, aber eine konkret hingeschriebener Shell-Befehl sagt da ja manchmal mehr als tausend Worte. :-)

D. h. Du gehst davon aus, dass in FreeBSD jedes Programm/Prozess, unter einem x-beliebigem user laufen/aktiv sein kann?

Ähm nein. Ich gehe von gar nichts aus. Ich hatte das halt nur als Lösungsansatz in den Raum geworfen. Wenn das aus irgendeinen Grund nicht passt oder nicht funktioniert, dann muss man halt gucken.

Die andere Möglichkeit wäre gewesen, das man erst mal vom Threadersteller alle möglichen Informationen abfragt, um dann auch möglichst eine passgenaue Lösung präsentieren zu können. Wäre ja auch für mich einfacher gewesen, da ich dann nicht hätte mehrere Lösungen posten zu müssen inkl. deren Vor- und Nachteile zu darzustellen.

Ich muss aber sagen ich fand die Fragestellung a-la "wie blockiert man den Zugriff für ein Prozess aufs Netzwerk" ansich ganz spannend und mal zu überlegen was kann man da grundsätzlich so machen und wo liegen da auch mögliche Grenzen.

Mein Antrieb hier im Forum zu schreiben liegt nicht allein darin Hilfestellung zu geben, sondern auch für mich da was rauszuziehen. Insofern bin ich da stückweit ein fieser Egoist. Aber ich denk mal, solange für die Fragestellung dabei etwas Zählbares raus kommt, geht das auch in Ordnung. :-)

Ich denke, den z. B. bei der Installation (für ein bestimmtes Programm/Software automatisch) angelegten user muss man nicht ändern, aber man kann ihn evtl. Mitglied in einer bestimmten Gruppe machen und dann die gid dieser Gruppe, in einer FW-Regel benutzen.

Ja. Muss man ja auch nicht. Ich hab auch lediglich das als Beispiel genommen um die Vorgehensweise zu illustrieren. Ob man das nun so macht oder ein vorhandenen User dafür nimmt oder man sich gar eine Gruppe definiert oder was auch immer da muss man halt für sich entscheiden, wie es am besten ist. Das ändert aber nix an der Grundidee (Paketfiltern anhand von uid/gid). Und die Grundidee ist das, worum es mir ging. Und nicht das man da unbedingt einen User anlegt.

 

[sanbiber]

Im Grunde ist ja ne Jail ein recht einfacher Mechanismus. Das wird halt häufig dadurch überdeckt, das in der Praxis damit häufig komplexere Setups realisiert werden.

Und ich hatte das ja auch schon in meinem ersten Posting angedeutet, aber eine konkret hingeschriebener Shell-Befehl sagt da ja manchmal mehr als tausend Worte. :-)

Ja, das hatte ich schon gelesen, aber eben direkt an die "kleinen" Jails von ezjail (und iocage kann das meine ich auch) gedacht, die ja im Vergleich zum adhoc-Jail in Deinem Kommando doch noch recht aufwaendig sind.

 

[sanbiber]

Die andere Möglichkeit wäre gewesen, das man erst mal vom Threadersteller alle möglichen Informationen abfragt, um dann auch möglichst eine passgenaue Lösung präsentieren zu können. Wäre ja auch für mich einfacher gewesen, da ich dann nicht hätte mehrere Lösungen posten zu müssen inkl. deren Vor- und Nachteile zu darzustellen.

Ich muss aber sagen ich fand die Fragestellung a-la "wie blockiert man den Zugriff für ein Prozess aufs Netzwerk" ansich ganz spannend und mal zu überlegen was kann man da grundsätzlich so machen und wo liegen da auch mögliche Grenzen.

Genau. Mir ging es auch nicht nur um die Loesung von "meinem" Problem. Und ich find es immer am Spannensten, wenn Leute direkt aus ihrer Praxis berichten, also erprobtes Wissen teilen ...

Offen ist fuer mich immer noch das "Limitieren" als Ganzes - jetzt kann ich den Zugriff blockieren (das ist auch das, was ich im Moment brauche und ein Teil des Limitierens). Beim Limitieren muesste auch sowas wie "Prozess x darf y% der Bandbreite nutzen" oder "Prozess x darf max. y MB Bandbreite pro Zeiteinheit nutzen" moeglich sein - so wie z.B. rctl fuer memory.
Da kann ich mir vorstellen, dass pf oder ipfw sowas koennen.

 

[Andy_m4]

aber eben direkt an die "kleinen" Jails von ezjail (und iocage kann das meine ich auch) gedacht

Ja genau. Aber das geht ja auch in die Richtung die ich meinte. Diese Tools sind ja ne Abstraktion und das ist auch praktisch weil sie relativ komplexe Jail-Setups einfacher machen. Du kannst halt mit nem simplen Befehl viel erreichen im Gegensatz dazu wenn Du es quasi "zu Fuß" machen musst.
Insofern sind die natürlich rein was die Benutzung angeht "klein" (ich nehme mal an das war das, was Du mit "klein" meintest).

Beim Limitieren muesste auch sowas wie "Prozess x darf y% der Bandbreite nutzen" oder "Prozess x darf max. y MB Bandbreite pro Zeiteinheit nutzen" moeglich sein - so wie z.B. rctl fuer memory.
Da kann ich mir vorstellen, dass pf oder ipfw sowas koennen.

Also was Bandbreite angeht, kannst Du das natürlich entsprechend mit dem Traffic-Shaper von ipfw (hier ist das entsprechende Stichwort dummynet) respektive pf machen. Man definiert Durchgänge (bei ipfw heißen die Pipes bzw. Queues, bei pf Queues - siehe dazu auch die Manpage von pf.conf ) und kann für die definieren was die durchlassen. Und auch hier kannst Du natürlich wieder sagen Pakete die mit einer 'uid' (oder auch Jail) matchen, sollen durch die und die "Pipe" gehen.

Zweite Möglichkeit die mir einfällt ist ein Proxy zu nehmen. Muss man gucken, ob man das dem entsprechenden Programm funktioniert. Wenn man da keine Proxies definieren kann, kann man u.U. tricksen, indem man mit Paket-Forwarding ein Redirect macht und dergleichen.

Dann kannst Du auch noch solche Fälle haben, wie das Dein Prozess selbst gar nicht aufs Netzwerk zugreift, sondern dafür ein anderes Programm benutzt zu dem Du ne Pipe-Verbindung hast (also jetzt keine Pipe im ipfw-Sinne, sondern Shell-Pipes).
Dann kannst Du Programme wie pv einsetzen (in der Manpage von pv wird da als Beispiel das schicken einer Datei via netcat aka nc genannt) und dann mit dem Parameter --rate-limit sagen wieviel KB, MB or whatever es denn pro Sekunde sein dürfen.

Grundsätzlich hast Du bei Traffic-Shaping aber immer folgendes Problem. Du kannst relativ genau definieren wieviel Traffic raus geht. Du hast aber nur limitierten Einfluss auf den Traffic der rein kommt. Die Pakete kommen halt, wie sie gerade kommen.

TCP hat Du eine Flusskontrolle implementiert. Der Gegenüber schickt quasi ein Paket und Du bestätigst das und je nach dem wie schnell Du das machst oder nicht machst wird dann quasi die Übertragungsgeschwindigkeit angepasst und damit hast Du quasi über die ausgehenden Bestätigungspakete eine indirekte Einflussnahmemöglichkeit.

Das geht aber halt nur bei TCP und das klappt halt auch nur bei einem wohlwollenden Gegenüber. Wenn es darum geht mögliche Angriffe abzuwehren wirds schwieriger. Du kannst natürlich einfach den einkommenden Traffic puffern und in in der Geschwindigkeit an Deinen Prozess weiter leiten, den er noch gut verträgt. Allerdings wenn die Traffic-Rate nicht zeitnah wieder zurück geht sind irgendwann Deine Puffer voll.

Oder Du verwirfst dann einkommende Pakete wenn die Rate über ein Limit steigt. Aber da hast Du wieder das Problem, das dann auch Pakete weg sind die Du vielleicht unbedingt haben willst. Deswegen funktionieren auch Denial-of-Service-Attacken immer noch so gut. Denn selbst wenn Du es schafft das die Last auf dem Server-Prozess überschaubar bleibt, kommt dann trotzdem keiner mehr drauf. Da kann man natürlich auch wieder gegensteuern in dem man IP oder IP-Bereiche aussperrt. Was aber auch eher leidlich gut funktioniert, da die Absende-IP-Adresse in einem Paket frei gesetzt werden und ein Angreifer kann da alles mögliche einschreiben kann.

Kurzum: Traffic-Control ist da ein größeres Feld und was und wie man das am besten löst hängt davon ab, was man denn eigentlich erreichen will.

 

[Andy_m4]

Mir ging es auch nicht nur um die Loesung von "meinem" Problem. Und ich find es immer am Spannensten, wenn Leute direkt aus ihrer Praxis berichten, also erprobtes Wissen teilen ...

Ich will dazu auch noch was sagen, weil es mich noch umtreibt.

Es kommt ja durchaus vor das auch ich mal eine Frage oder Problemstellung hab. Und was ich dann als erstes mache ist im Internet zu suchen ob jemand schon so ein Problem hatte.
Und dann kommen natürlich auch so Suchtreffer von Foren etc. wo man sich dann schon immer freut wenn der Fragesteller im Prinzip die Frage stellt, die man selbst auch stellen würde. Und was dann aber häufig passiert ist, das jemand nachfragt was genau erreicht werden soll. Das ja auch eine total nachvollziehbare und legitime Frage ist. Aber das führt dann halt nicht selten dafür, das der Thread dann in eine andere Richtung läuft und für den Threadersteller ist das ja oft auch ok, aber für mich als Suchenden nicht. :-)
Da würde ich mir wünschen das da jemand mal ein raushaut so nach dem Motto: Wir nehmen einfach mal die Frage so wie sie ist und sagen was dazu.

Wie gesagt. Für die dort Beteiligten ist das ja auch alles völlig ok und nachvollziehbar und logisch das man das so macht und ich würde daraus keinen Vorwurf konstruieren. Aber für jemanden der über ne Suche da rein stolpert ist das oft doof.

Der zweite Aspekt der geht so in die Richtung was Du sagtest. Es gibt ja so Fragestellungen die schreien so ein bisschen danach, das man hier gar nicht irgendwie eine fix und fertige Lösung haben will, sondern es (zumindest im ersten Schritt) darum geht so sondieren, was es überhaupt für prinzipielle Möglichkeiten gibt. Insbesondere weil dann auch Aspekte zu tragen kommen an die man vorher vielleicht gar nicht so gedacht hat.
Das kriegt man auch teilweise abgefangen in dem man nachfragt und spezifiziert und das es zu einem "mach es lieber nicht so sondern soundso" kommt aber was dann immer etwas auf der Strecke bleibt ist die Begründung, warum eine bestimmte Lösung am besten ist.
Und das ist mir häufig wichtiger als wenn mit irgendwer ne mundgerecht aufbereitete Fertig-Lösung schreibt, die ich dann am besten noch per "copy-pasten" übernehmen kann.

PS: Ok, jetzt hab ich was gemacht was für Foren auch nicht so gut ist. Nämlich zu viel Offtopic-Text. Etwaige Ermahnungen werde ich daher klaglos erdulden :-)

 

[GrandDixence]

Grundsätzlich hast Du bei Traffic-Shaping aber immer folgendes Problem. Du kannst relativ genau definieren wieviel Traffic raus geht. Du hast aber nur limitierten Einfluss auf den Traffic der rein kommt.

Faires Traffic-Shaping mit CAKE (unter Linux) funktioniert erfahrungsgemäss im Praxiseinsatz auch im Downstream/Downlink (Download-Richtung) gut bis sehr gut, wenn:

a) alle über den WAN-Port ankommenden IP-Datenpakete über ein Dummy-Device (z.B. FreeBSD: DummyNet) geführt werden und als simulierter, "ausgehender Datenverkehr" in einer Warteschlange vor einem "künstlichen Flaschenhals" landen.

b) UND per Firewallregeln dafür gesorgt wird, dass über den WAN-Port nur UDP-Datenpakete von zeitkritischen Diensten (z.B. NTP, VoIP-Telefonie, Gaming) und Grunddiensten (DNS, DHCP) übertragen werden. Alle anderen über den WAN-Port laufenden Dienste müssen zwingend TCP verwenden.

c) UND die Gesamtdatenübertragungsrate des Downstream/Downlink per Traffic-Shaper auf rund 50 % der tatsächlichen maximalen Datenübertragungsrate des WAN-Ports gedrosselt wird (z.B. 50 MBit/s statt 100 MBit/s) => "Künstlicher Flaschenhals"

CAKE (mit ECN => Explicit Congestion Notification) ist die aktuelle Deluxe-Lösung für Traffic-Shaping.

https://www.bufferbloat.net/projects/attachments/150817135028_cake-battlemesh-v8.pdf

Eine Anleitung zur Realisierung von Traffic-Shaping mit CAKE unter Linux auf einem Raspberry Pi findet man unter:

Bandbreite zum Surfen zur Außenstelle begrenzen - LANCOM-Forum.de

Hallo zusammen, ich dachte, ich wäre der Lancom Firewall mächtig, aber ich komme an dieser Stelle gerade nicht weiter bzw. sehe ich den Wald vor lauter Bäumen nicht mehr... Involviert sind zwei Router Lancom 1781EF , 10.12.0612RU11. Einer ist das zen..

www.lancom-forum.de

FreeBSD unterstützt meines Wissens nur fq_codel.

fq_codel or CAKE implementation

groups.google.com

IPFW - IPFW + dummynet with fq_codel halves download speed?

I've recently(ish) switched from PF to IPFW because I wanted to use dummynet with fq_codel to fix some rather massive bufferbloat issues I'm seeing on my cable Internet connection with one of the US Cable Monsters. Cable modem is set to pass-through, so the only firewall between me an the...

forums.freebsd.org

Die auf FreeBSD basierenden Firewalllösungen pfSense und OPNsense unterstützen fq_codel:

Improve your BufferBloat with Traffic Shaping in Opnsense with IPv6

How to configure Traffic Shaping also under IPv6 and additionally improve BufferBloat

maltechx.de

pfSense® software Configuration Recipes — Configuring CoDel Limiters for Bufferbloat | pfSense Documentation

docs.netgate.com

Einen guten Einstieg in das Thema "Faires Traffic-Shaping" bietet das Youtube-Video:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

ab 14:00 min.

 

[Andy_m4]

funktioniert erfahrungsgemäss im Praxiseinsatz auch im Downstream/Downlink (Download-Richtung) gut bis sehr gut, wenn

Ich weiß jetzt nicht, ob Du mir mit Deinem Posting widersprechen oder mich ergänzen wolltest. In beiden Fällen hätte ich etwas unterschiedliches zu sagen. Deshalb frag ich an der Stelle lieber noch mal nach.