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.
