Monitor SSH terminal activity

[Verwijderd]

Door tijdsgebrek heb ik via VWorker (oude rentacoder) een sysadmin aangetrokken die wat klusjes op m'n Debian servers gaat verrichten, waarvoor hij ook root-access nodig heeft.

Zijn er tools waarmee ik zijn terminal in real time kan monitoren? Het liefst in real time omdat logging naar een file ook makkelijk aan te passen is met root-access lijkt me.

Bij voorkeur te installeren via aptitude op een Debian Lenny systeem, want ik ben niet een Linux held (packages uit de default Lenny repository installeren lukt nog wel).

[u_nix_we_all]

Als je hem root-rechten geeft, kan alles wat je aanzet/installeert net zo makkelijk weer uitgezet worden natuurlijk.

Maar het probleem zit hem meer in het feit dat je iemand óf moet vertrouwen, of je geeft hem geen root-rechten.
Alles daartussenin is suboptimaal.Ik denk dat je gewoon de shell history moet nalopen, ja, dat is makkelijk te omzeilen, maar dat geldt eigenlijk voor alles.

Nog een optie is: Backup maken, en als die admin klaar is, vergelijken om te zien welke files er veranderd zijn.

[lordgandalf]

realtime kun je via een tweede term fixen maar je kunt hem ook iets geven als sudosh shell die kan ook loggen geloof ik

[Verwijderd]

Daarvoor heb je SUDO. Daarmee kan je een gebruiker aanmaken die alleen datgene kan en mag doen wat jij wilt en ook dit kan gelogd worden.

[benoni]

u_nix_we_all schreef op dinsdag 11 januari 2011 @ 11:20:
Nog een optie is: Backup maken, en als die admin klaar is, vergelijken om te zien welke files er veranderd zijn.

Of iets met Tripwire.

Verwijderd schreef op dinsdag 11 januari 2011 @ 11:13:
Zijn er tools waarmee ik zijn terminal in real time kan monitoren? Het liefst in real time omdat logging naar een file ook makkelijk aan te passen is met root-access lijkt me.

Lijkt mij wel ergens wel een beetje een sneaky attitude worden zo, je overlegt hopelijk wel wat je doet, waarom je dat wilt?

edit:
Niet goed de topicstart gelezen, bij het volgende ging ik er van uit dat het werk op locatie betrof:

Vraag hem gewoon een dump van zijn terminalvensters als afronding voor de werkzaamheden, dat is een mooie basis voor je documentatie en nacalculatie. En kom af en toe even binnenvallen en vraag of het gaat. Of kijk gewoon de hele sessie mee als je de tijd er voor hebt, dan steek je er ook nog wat van op.

Als het om vertrouwlijkheidsredenen echt nodig is om de sessie integraal te monitoren (ik kan me dat voor bepaalde gewichtige zaken wel voorstellen), laat hem dan alleen op een geprepareerde laptop werken met een remote access protocol aan. Of zet een videokamera voor zijn snufferd.

[ Voor 4% gewijzigd door benoni op 11-01-2011 12:15 ]

[Wolfboy]

Of gewoon geen root geven maar via een gedeelde screen sessie hem toegang verstrekken zodat je ook mee kan kijken.

[Rainmaker]

auditd anyone?

Dit logt desnoods alle syscalls die uitgevoerd worden. Laat het naar een remote syslog host gaan en klaar.

Met "script" kun je ook simpelweg recorden wat ie aan het doen is. En als je iemand inhuurt en je vraagt of ie alles vast wil leggen in een script sessie, waarom niet? script -f zorgt ervoor dat het realtime gaat.

Misschien een hardware keylogger op het toetsenbord?

En nee, dit zijn geen waterdichte methodes.
Uiteindelijk zul je iemand toch tot op zekere hoogte moeten vertrouwen voor je deze root access geeft.

[Verwijderd]

bedankt voor tips allemaal.

Zitten heel bruikbare dingen bij.

Over wat nddeleeuw zegt; een tweede terminal, heeft iemand daar misschien nog wat tips voor? Dit is namelijk volgens mij wat ik zoek. Dat je net als in Windows Server 2008 Taskmgr>Remote Control gewoon de hele sessie kan meekijken.

Over zo'n terminal dump, hoe werkt dat?

Daarnaast heb ik sudo geinstalleerd, maar dat biedt volgens mij ook weinig bescherming.
Ik heb sudo su, sudo -s en sudo bash nou geblocked, maar sudo nano /etc/sudoers lukt me niet om te voorkomen. Althans, kan wel die edit commands blocken, maarja, met een apt-get install editorx is dat ook zo te omzeilen.

Ik ga nou naar autitd en script kijken.

[Wolfboy]

Verwijderd schreef op dinsdag 11 januari 2011 @ 13:56:
bedankt voor tips allemaal.

Zitten heel bruikbare dingen bij.

Over wat nddeleeuw zegt; een tweede terminal, heeft iemand daar misschien nog wat tips voor? Dit is namelijk volgens mij wat ik zoek. Dat je net als in Windows Server 2008 Taskmgr>Remote Control gewoon de hele sessie kan meekijken.

Screen of ttysnoop

[benoni]

Verwijderd schreef op dinsdag 11 januari 2011 @ 13:56:
Over zo'n terminal dump, hoe werkt dat?

Als je vanuit een lokale tekstterminal inlogt op de server kun je de hele sessie naar een bestand laten wegschrijven. Hetzelfde kan vanuit de sessie op de server zelf, oa. met script zoals hierboven vermeld.

Ik gebruik het als best practice methode voor het configureren van onze Linux servers (ong. 5 stuks). Ik kopieer de gebruikte opdrachten, scriptjes en aangepaste config files naar een tekstbestand, en voorzie dat van commentaar. Dit kost wel ongeveer een uur extra, maar heeft het voordeel dat iemand anders aan de hand van mijn tekstbestandje de configuratie makkelijk kan nalopen, of desnoods de server helemaal overnieuw zou kunnen opbouwen als dat nodig is. Zelf maak ik er ook gebruik van als ik een andere server moet installeren, dan kan ik de commando's en config files vaak op het rijtje af kopiëren van een ouder documentatiebestand.

[Verwijderd]

Klinkt goed.

Misschien domme vraag, maar hoe doe je dat? Dat wegschrijven? Met wat voor commando ofzo.


ik heb onderhand sudo geinstalleerd en de volgende dingen geblocked:
/bin/sh
/bin/bash
/bin/su
/usr/sbin/visudo

Daarnaast ben ik via webmin File Change monitors aan het opzetten voor /etc/sudoers en een aantal andere belangrijke bestanden, waarbij ik een shellscriptje run die mij het bestand mailt en de bash_history voor de user.

weer hobbywerk allemaal


Maargoed, als ik door heb hoe zo'n terminal dump werkt, dan vraag ik daar gewoon naar.

[DiedX]

Verwijderd schreef op dinsdag 11 januari 2011 @ 16:16:

/bin/sh
/bin/bash
/bin/su
/usr/sbin/visudo

Tuurlijk!

vi hackje.txt
:shell

bingo.

[Verwijderd]

Verwijderd schreef op dinsdag 11 januari 2011 @ 16:16:
via webmin

Gewoon een tip: gooi webmin aan de kant totdat je weet hoe je het zonder webmin moet doen. Daar leer je nog iets van.

[benoni]

Verwijderd schreef op dinsdag 11 januari 2011 @ 16:16:
Maargoed, als ik door heb hoe zo'n terminal dump werkt, dan vraag ik daar gewoon naar.

Hoe werk je zelf met de server? Ik werk meestal vanuit een lokaal terminalprogramma (onder Windows zou dat Putty zijn) waarmee ik met SSH inlog op de server. In de meeste terminal clients zit een menu-optie om je sessie te loggen naar een tekstbestand. En je kunt natuurlijk gewoon kopiëren en plakken in het venster.

Het gaat alleen minder handig als je met 'menu-gestuurde' selectieschermen werkt binnen je terminal (alle pakketten die werken met de ncurses interface). Maar in Linux moet je in principe alles direct vanaf de command line kunnen instellen.

[ Voor 5% gewijzigd door benoni op 11-01-2011 16:44 ]

[Rainmaker]

Je blocked de shell (/bin/bash)?

Hoe moet je sysadmin dan inloggen?

En hoe block je het? Verwijderen van /bin/sh is niet echt slim...

Zoals gezegd, vraag de sysadmin even in een script sessie te werken, kun je daarna op je gemak alles nalopen.

Je kunt wel wat dingen blocken, maar (zoals hierboven al gezegd), via vi een shell escape pakken ontwijkt verrassend veel beveiliging...

Ook al naar auditd gekeken? Staan in /usr/share/doc/audit-1.7.17/capp.rules een aantal voorbeelden die me echt van pas lijken te komen:

Bijvoorbeeld:

code:

## Changes in ownership and permissions
#-a entry,always -F arch=b32 -S chmod -S fchmod -S fchmodat 
#-a entry,always -F arch=b64 -S chmod -S fchmod -S fchmodat 
#-a entry,always -F arch=b32 -S chown -S fchown -S fchownat -S lchown
#-a entry,always -F arch=b64 -S chown -S fchown -S fchownat -S lchown
## File content modification. Permissions are checked at open time,
## monitoring individual read/write calls is not useful.
#-a entry,always -F arch=b32 -S creat -S open -S openat -S truncate -S ftruncate
#-a entry,always -F arch=b64 -S creat -S open -S openat -S truncate -S ftruncate

Daarnaast ook nog -S unlink om deletes af te vangen, en je bent al een heel eind.

Maar, misschien een stomme vraag, waarom zet je er niet iemand langs die je wel vertrouwd met een root shell? Hoeft de sysadmin niet eens het root wachtwoord te hebben...

[Verwijderd]

block het door "!/bin/sh" etc. achter ALL in /etc/sudoers te zetten.
weet dat dat met een editor inderdaad heel erg makkelijk te omzeilen is, maarja, "sudo bash" toelaten is ook zo...

Ik heb auditd geinstalleerd en sta te kijken hoeveel er wel niet gelogd wordt voor het handjevol bestanden dat ik monitor. Ik ben momenteel aan het googelen over die rules, dus mocht iemand hier nog voorbeelden hebben hoe je voor /etc/ppp/chap-secrets slechts voor een specifieke user read access monitort, graag.

Over dat 'in een script werken', daar wist ik dus niets van en is precies wat ik zoek. Ik vraag de sysadmin inderdaad vanuit script te werken. Ideaal.

Voor degenen die hier ook niet van op de hoogte waren, ik heb uiteindelijk deze gevolgd:
http://linux.byexamples.c...session-and-replay-later/

Bedankt voor tips!