[Linux 2.4.20] Per user ip accounting

[Gerco]

Ik ben al een tijdje op zoek naar een programma om per user ip accounting te doen, voor het beperken van de traffic van shell accounts van mijn users. Nu heb ik UserIpAcc gevonden, maar die houdt op bij kernel 2.4.6 en vertoont over het algemeen weinig activiteit.

In de search vond ik [rml][ MRTG] ook per IP?[/rml] , dat deed ook niet veel goeds.

Weet iemand misschien of er aan deze of aan andere package nog gewerkt wordt? Ik heb geprobeerd om de 2.4.6 patch te converteren naar 2.4.20, dat gaat beter dan ik dacht, maar het is nog een aardig eind van werkend vandaan en ik verwacht eigenlijk niet dat ik het voor elkaar ga krijgen.

[jep]

Ik heb ook wel eens een shell-usertje . Persoonlijk gebruik ik voor ip-monitoring iptables (en wat van m'n scripts) en voor metingen op user-niveau ook. Het meten op OWNER is wel expirimenteel en werkt alleen op uitgaand verkeer. Op OWNER support in iptables zou ik nog niet teveel vertrouwen.

[Gerco]

Ik heb inderdaad ook ipag-ng staan en die heb ik geprobeerd met OWNER support in iptables, werkt best leuk, maar als iemand 100GB gaat zitten wgetten betaal ik me blauw aan het einde van de maand en weet ik nog niet wie het was...

Wat voor scripts gebruik je dan en zijn die geschikt voor dit doel?

[ Voor 18% gewijzigd door Gerco op 26-03-2003 21:55 ]

[jep]

Ze lezen iptables data uit en laat de user de gebruikte datatraffic zien, inkomend + dataverkeer over 't ip dat bij 't accountje hoort. Maar inderdaad, wgetten = pech hebben . Ik meen dat 't niet of nauwelijks mogelijk is om inkomende data op user-niveau te monitoren en of te filteren.

[Gerco]

jep schreef op 26 March 2003 @ 22:43:
Ik meen dat 't niet of nauwelijks mogelijk is om inkomende data op user-niveau te monitoren en of te filteren.

Met UserIPAcc kan het dus wel "screenshot" uit de README:

code:

        User       Sent       Received     Flags
        root       401364     401421
        news       2143       2210
        lf         221462     348287
        joe        1036475    2793743      N
        guest      65432734   43462382     N
        nobody     34323      23791

Dit kan alleen omdat het een kernel patch is, hij trekt die data gewoon direct uit je netwerk subsystem (ipv4 protocol eigenlijk), waar 'ie wat patches aan doet. Helaas is er geen patch voor 2.4.20 en ik ga geen 2.4.6 draaien

Is het mogelijk om die 2.4.6 patch te gebruiken en toch op de 1 of andere manier een 2.4.20 kernel te gebruiken, zonder UserIpAcc te herschrijven dan?

[DGTL_Magician]

Gerco schreef op 27 March 2003 @ 07:33:
[...]

Met UserIPAcc kan het dus wel "screenshot" uit de README:

code:

        User       Sent       Received     Flags
        root       401364     401421
        news       2143       2210
        lf         221462     348287
        joe        1036475    2793743      N
        guest      65432734   43462382     N
        nobody     34323      23791

Dit kan alleen omdat het een kernel patch is, hij trekt die data gewoon direct uit je netwerk subsystem (ipv4 protocol eigenlijk), waar 'ie wat patches aan doet. Helaas is er geen patch voor 2.4.20 en ik ga geen 2.4.6 draaien

Is het mogelijk om die 2.4.6 patch te gebruiken en toch op de 1 of andere manier een 2.4.20 kernel te gebruiken, zonder UserIpAcc te herschrijven dan?

Heb je niks aan gewoon bandwith limiting? http://www.tldp.org/HOWTO...Limiting-HOWTO/index.html

[jep]

Gerco schreef op 27 maart 2003 @ 07:33:
[...]
Is het mogelijk om die 2.4.6 patch te gebruiken en toch op de 1 of andere manier een 2.4.20 kernel te gebruiken, zonder UserIpAcc te herschrijven dan?

Hm, dat schept perspectieven. Wellicht kan ik wel iemand vinden die dat voor niet zoveel voor me om kan bouwen . Ik ga informeren.

[Gerco]

DGTL_Magician schreef op 27 maart 2003 @ 08:44:
Heb je niks aan gewoon bandwith limiting? http://www.tldp.org/HOWTO...Limiting-HOWTO/index.html

Ziet er leuk uit en zou ook werken voor bijvoorbeeld UT server verhuur. Dan limit je gewoon de bandbreedte op poort 7777 tot xGB per maand en je bent klaar. Waar ik echter ook mee zit is een user die shell toegang heeft. Die kan wgetten, ftp'en, vanalles. Die mogelijkheden wil ik ze niet afnemen omdat dan shell toegang nogal zinloos wordt, maar ik wil wel graag een limiet aan het dataverkeer stellen.

[jep]

Ik ga achter die patch aan iig, ik laat 't hier wel weten als ik 'm heb. Waarom limiting en niet laten betalen eigenlijk? Heb je meer aan, toch?

[Verwijderd]

Ik heb ook naar ip accounting gezocht, er is idd heel weinig voor gemaakt. Waarschijnlijk als je ziets nodig hebt dat je dan eigenlijk zowieso geen shells moet vrijgeven. je zou eerder per service moeten kijken naar traffic logs. misschien dat sshd iets heeft?

[Infern0]

Misschien is dit wel geen nette oplossing maar kun je elke user niet een virtueel IP geven en dan accoounting doen over dat virtuele IP?
IPFW heeft wel de mogelijkheid voor per user accounting, maar ja das FreeBSD, dus is hier niet van toepassing.

[jep]

Verwijderd schreef op 27 maart 2003 @ 12:46:
Ik heb ook naar ip accounting gezocht, er is idd heel weinig voor gemaakt. Waarschijnlijk als je ziets nodig hebt dat je dan eigenlijk zowieso geen shells moet vrijgeven. je zou eerder per service moeten kijken naar traffic logs. misschien dat sshd iets heeft?

SSHD zal dan alleen de data meten over SSH, da's tekst dus. Hoe bedoel je geen shells vrij geven? Hij kan ook offline gaan, heeft hij helemaal geen traffic .

Betreft ip's, het is erg lastig een user (vooral voor inkomende data) te forceren een bepaald ip te gebruiken.

[Gerco]

jep schreef op 27 maart 2003 @ 12:39:
Ik ga achter die patch aan iig, ik laat 't hier wel weten als ik 'm heb. Waarom
limiting en niet laten betalen eigenlijk? Heb je meer aan, toch?

Laten betalen is ook prima, maakt mij niet zoveel uit, zo lang ik mn geld maar krijg. Maar ook om te laten betalen moet ik de traffic kunnen meten

[0siris]

als wget een probleem vormt, zorg je toch dat alleen root mag wgetten? Is weliswaar symptoombestreiding, maar ik zou daar eens mee beginnen terwijl je op onderzoek uitgaat...

[JoostBaksteen]

0siris schreef op 27 March 2003 @ 14:18:
als wget een probleem vormt, zorg je toch dat alleen root mag wgetten? Is weliswaar symptoombestreiding, maar ik zou daar eens mee beginnen terwijl je op onderzoek uitgaat...

Dan kunnen users alsnog een wget (OID) zelf compilen... heb je weer _VEEL_ verkeer.

Degene die veel willen wgetten, en dus misbruiken, zullen er dan wel moeite voor doen om toch wel te kunnen wgetten.

[DGTL_Magician]

Gerco schreef op 27 March 2003 @ 12:35:
[...]

Ziet er leuk uit en zou ook werken voor bijvoorbeeld UT server verhuur. Dan limit je gewoon de bandbreedte op poort 7777 tot xGB per maand en je bent klaar. Waar ik echter ook mee zit is een user die shell toegang heeft. Die kan wgetten, ftp'en, vanalles. Die mogelijkheden wil ik ze niet afnemen omdat dan shell toegang nogal zinloos wordt, maar ik wil wel graag een limiet aan het dataverkeer stellen.

Mjah, maar dan limiteer je dat toch gewoon? Je kan een transfer dan gewoon cappen op 512kbit/sec ofzo?

[JoostBaksteen]

DGTL_Magician schreef op 27 maart 2003 @ 14:24:
[...]

Mjah, maar dan limiteer je dat toch gewoon? Je kan een transfer dan gewoon cappen op 512kbit/sec ofzo?

Dan kom ik op 163.476562 GB theoretisch per maand.

Dat is best veel...

[jep]

joostbaksteen schreef op 27 March 2003 @ 15:11:
[...]


Dan kom ik op 163.476562 GB theoretisch per maand.

Dat is best veel...

Normaliter monitor je een server.

[Verwijderd]

jep schreef op 27 March 2003 @ 18:59:
[...]

Normaliter monitor je een server.

ja, de domme sysadmins die houden elk dingetje zelf in de gaten en kijken niet of het misschien geautomatiseerd kan worden.Dan komt het ongeveer neer dat per 5 servers 1 sysadmin nodig is.

mijn advies is eerder, probeer zoveel mogenlijk automatisch te laten verlopen, programmeer status reports die alles in 1 keer weergeven. probeer foutdetectie foutdectie systemen te gebruiken om zoveel mogenlijk redundancy te creeeren.

[jep]

Verwijderd schreef op 27 maart 2003 @ 19:08:
[...]


ja, de domme sysadmins die houden elk dingetje zelf in de gaten en kijken niet of het misschien geautomatiseerd kan worden.Dan komt het ongeveer neer dat per 5 servers 1 sysadmin nodig is.

De domme systeembeheerders zijn binnen een dag arm en gehacked. De iets slimmere beheerders houden er een oogje op en merken excessief dataverkeer binnen 24 uur op. Ook geautomatiseerde processen moet je monitoren.

[Gerco]

En dan nog heeft een slimme systeembeheerder een probleem als 'ie na 10 uur een datastroom van 5MB per seconde ontdekt en hij heeft betaalt voor 20GB per maand... mensen moeten ook slapen.

Je KAN gewoon niet 24/7 monitoren en met de snelheden van vandaag en de hoeveelheden bandbreedte die ze verkopen, heb je je maandquota er in een paar uur doorheengepompt. Erg jammer voor admins die eens een keertje van een goede nachtrust willen genieten.

[Gerco]

Even een subtiel schopje, weet iemand hier al meer over?