userbased trafficaccounting

[mutombo]

ich verwende ipac-ng zum trafficlogging und bin damit auch eigentlich ganz zufrieden.
nur das lgging ausgehender clientverbindungen (wget etc) gestaltet sich damit schwierig. Sobald der z.b. ftp auf der gegenseite nicht auf port 21 liegt, schlüpft der transfer einfach durch meine chains. Deshalb würde ich hier lieber userbasierendes logging verwenden. Dazu konnte ich leider nur das tool UserIpAcct finden, leider ist der download hierzu nichtmehr erreichbar.
Meine überlegung war jetzt jedem user eine gewissen portrange zuzuweisen, dann bräuchte ich auch keine zusätzliche loggingsoft.
perfekt wäre diese lösung:
http://www.ex-parrot.com/~pdw/user-port-hack/
leider nur für kernel 2.4.9 zu haben :(

mit grsecurity1.9 hab ich keine möglichkeit gefunden das userbasierend einzuschränken.
für grsec 2 soll es ja sogenannte rolebased acl geben.

Weiß jemand ob mein vorhaben mit grsec2 möglich ist, oder hat jemand vielleicht eine andere idee das problem zu lösen ?

danke schonmal

[mutombo]

sorry das ich den alten thread nochmal nach oben hole,
aber ich finde einfach keine lösung.
nachdem ich ein wenig mit iptables match owner rumexpermimentiert habe und feststellen mußte das das auch nicht das gelbe vom ei ist, bin ich wieder ganz am anfang.
FreeBSD's ipfw scheint das zu können.
Allerdings würde ich den schritt noch ein neues os zu erlernen gerne erstmal vermeiden :)

also wenn doch noch jemand irgend einen tip hat, wäre ich sehr dankbar.

[alexander newald]

Das Problem bei der Geschichte ist, dass es ohne Patch nicht geht (Linux), da man bei eingehenden Paketen ja noch nicht ohne weiteres weiss, welcher Prozess und somit welcher User dafür zuständig ist. Bis auf ssh lässt sich alles aus den Logfiles fummeln und für ssh gibt es meht oder weniger gute Patches, die den Traffic ebenfalls in ein Logfile schreiben. (url entfallen)

[captaincrunch]

Ich werde im Laufe des Tages mal probieren, ob sich der Patch auch in aktuelle Kernel integrieren lässt. Falls er das nicht tut, könntest du mal den Autor des Patches anschreiben, ob er da vielleicht etwas drehen kann. Im Normalfall machen die Leute so etwas, wenn sie gerade mal zeit und Langeweile haben ... ;)

[captaincrunch]

So, hier also der aktuelle Stand :
für den Patch ist Handarbeit angesagt, ohne weiteres lässt er sich auf dem aktuellen 2.4.21er nicht nutzen. Ich würde daher (wie schon gesagt) den Autor mal direkt anschreiben, vielleicht portiert der den ja mal kurz.

[mutombo]

Ich werde im Laufe des Tages mal probieren, ob sich der Patch auch in aktuelle Kernel integrieren lässt. Falls er das nicht tut, könntest du mal den Autor des Patches anschreiben, ob er da vielleicht etwas drehen kann. Im Normalfall machen die Leute so etwas, wenn sie gerade mal zeit und Langeweile haben ... ;)

oh sorry, das hab ich ganz vergessen.
habe den patch mal spaßeshalber auf kernel 2.4.21-grsec applied.
funzt soweit auch, bis auf die tatsache das die ephermal portrange für alle clients weiterhin die gleiche bleibt. binds lassen sich nur in der für den user vorgesehene portrange vornehmen(soweit wunderbar). connects gehen aber immer in die unrestricted area. hab auch mal ne mail an den author losgeschickt, aber das schon einige tage her. möglicherweise ist da die emailaddresse nichtmehr aktuell.


vielleicht findest du da ja den fehler oder hast ne lösung.