bespioneren van gebruiker

[High Quality king]

Beste tweakers,

Ik heb een gebruiker ssh toegang gegeven tot mijn linux bakje. Nou heb ik sterke vermoedens dat deze gebruiker mij ernstig probeert te fokken dus heb ik een vraagje voor jullie. Is het mogelijk zijn akties bij te houden zonder dat hij zijn sporen kan wissen ?

Alvast bedankt,

[Verwijderd]

Je kan in zijn bash_history kijken. Of bedoel je dat niet? En als je denkt dat hij loopt te "fokken" waarom heeft hij dan access?

[ Voor 38% gewijzigd door Verwijderd op 15-06-2003 11:18 ]

[rvm]

Misschien helpt process accounting:
http://en.tldp.org/HOWTO/mini/Process-Accounting/

Process accounting is the method of recording and summarizing commands executed on Linux. The modern Linux kernel is capable of keeping process accounting records for the commands being run, the user who executed the command, the CPU time, and much more.

Process accounting enables you to keep detailed accounting information for the system resources used, their allocation among users, and system monitoring.

[High Quality king]

Verwijderd schreef op 15 June 2003 @ 11:18:
Je kan in zijn bash_history kijken. Of bedoel je dat niet? En als je denkt dat hij loopt te "fokken" waarom heeft hij dan access?

Ja hij doet ook nog wel nuttige dingen en ik heb nog niet echt bewijs. Alleen heb ik al wel gezien dat ie vanuit computers die niet van hem zijn mijn bak in gaat. En ik weet wat meer over zijn verleden dus ik wil het voor de zekerheid weten.Hij kan zijn bash_history wissen denk ik of niet ? Ik zat zelf al aan ssh logs te denken maar ik weet niet waar dat staat of wat het dan logt.

[moto-moi]

Zoals de waard is vertrouwd hij zijn gasten. Ik zou niemand zomaar root access geven op welke bak van mij dan ook..

Het beste wat je kunt doen, is je root password veranderen, hem een gewone user account geven. Mocht hij toch programma's moeten draaien waarvoor hij rootrechten nodig hebt, dan kun je die hem door middel van sudo geven.

[Verwijderd]

Alleen heb ik al wel gezien dat ie vanuit computers die niet van hem zijn mijn bak in gaat.

Vraag 'm het dan!!
En zeg 'm wel duidelijk dat het NIET de bedoeling is dat ie zijn ssh-account aan andere gaat doorgeven waardoor jij straks misschien in de problemen kan komen.

[blaataaps]

moto-moi schreef op 15 June 2003 @ 11:39:
Zoals de waard is vertrouwd hij zijn gasten. Ik zou niemand zomaar root access geven op welke bak van mij dan ook..

Er staat volgens mij niet dat hij root-toegang heeft, of kijk ik scheef? : )
Maar ook gewone users die je niet vertrouwt zou ik gewoon geen toegang geven.

[Verwijderd]

ttysnoop lijkt me wel wat voor jou

[High Quality king]

moto-moi schreef op 15 June 2003 @ 11:39:
Zoals de waard is vertrouwd hij zijn gasten. Ik zou niemand zomaar root access geven op welke bak van mij dan ook..

Het beste wat je kunt doen, is je root password veranderen, hem een gewone user account geven. Mocht hij toch programma's moeten draaien waarvoor hij rootrechten nodig hebt, dan kun je die hem door middel van sudo geven.

Hij heeft een gewone account en ik heb niks over root gezegt nee dat zou wel erg newbie van me zijn . Maar dat ttysnoop merk je dat als dat draait ? Want het moet wel sneaky zijn. Ik wil hem eigenlijk betrappen.

[Verwijderd]

met ttysnoop merkt de user niets..je kijkt gewoon met hem mee....behalve als je mee gaat typen dan zal hij het merken

[High Quality king]

Ok dan ga ik dat ttysnoop bekijken. Dat zet je gewoon als programma dat ie opstart als ie inlogt. En zit daar ook een log functie in ofzo. Want ik ga niet 24 uur per dag mee kijken. (hij logt meestal in als ik slaap dus dat is ook sneaky).

Bedankt

[M@rijn]

laat even weten of het goed werkt??

[Verwijderd]

Gebruik bash-bofh. Een patch voor Batch die alles logged dat met Bash getyped wordt. Waar? Google.
GrSecurity heeft een soortgelijke functie. En natuurlijk instellen dat users geen andere shell dan Bash mogen hebben er is overigens ook een tcsh-bofh patch voor tcsh, dus (....)

[moto-moi]

blaataaps schreef op 15 June 2003 @ 12:08:
Er staat volgens mij niet dat hij root-toegang heeft, of kijk ik scheef? : )

worst case senario

Maar ook gewone users die je niet vertrouwt zou ik gewoon geen toegang geven.

Inderdaad.. Of zorgen dat je heel goed oplet wat je users wel en niet mogen, kernel-patches in de gaten houden, bugtrac, etc. etc.

Of chrooten, maar dat is erg veel werk, maar wel heel erg veilig afaik..

[Verwijderd]

moto-moi schreef op 15 June 2003 @ 15:42:

Of chrooten, maar dat is erg veel werk, maar wel heel erg veilig afaik..

Nou... ja en nee. Root in chroot = prijs zonder kernel patch (bijv GrSecurity heeft chroot restricties als je daar ff kijkt dan begrijp je meteen hoeveel methodes een user heeft om uit een chroot te breken op een vanilla Linux)

[High Quality king]

hi

Ik wil deze jongen eigenlijk betrappen dus ben ik nu opzoek naar een goeie sniffer die heel specifiek zijn telnet kan afluisteren. Want wanneer die alles via telnet gaat doen heb ik geen zicht meer op wat ie doet via zijn bash history. Ik had telnet al voor hem dicht gezet maar nu heeft hij via SCP een telnet binary naar me systeem geupload .

Alvast Bedankt,

[Verwijderd]

Dat accountje moet je verwijderen, mensen die dit soort acties uitvoeren zijn nooit te vertrouwen. wie weet wat hij allemaal met jou systeem uitvoerd.

xux

[Wekkel]

Je sterke wens hem ergens mee te betrappen doet vermoeden dat je hem wil betrappen in plaats van preventief ruimen. Waarom moet hij eigenlijk acces hebben?

[miniBSD]

Ik zou eens kijken naar het honeypot project bij de sectie 'Tools'. Daar staat tools voor het bekijken wat een gebruiker uitvoert op je systeem.

Persoonlijk zou ik ook kiezen voor een chroot omgeving (http://www.tjw.org/chroot-login-HOWTO/) met daarin alleen de commando's die wil toestaan, en de kernel patchen.

[Verwijderd]

gewoon omdat ik het raar vind hoor.
maar als hij gewoon met ssh kan inloggen waarom wil hij dan telnet gebruiken?

zo i zo is telnet niet al te veilig.

[active2]

Wat ik zou doen?

grsecurity patch installeren om te voorkomen dat die jou bak gaat exploiten (als het zo'n l4m3 scriptkiddie is) vervolgens alles maar dan ook alles wat die user uitvreet loggen. En eventueel nog wat tools halen van het honey pot project. Die hebben echt hele leuke tools voor zoiets. Eventueel kun je daar ook nog wat leuke dingen mee doen zoals je eigen ssh process hiden en hem vervolgens in de gaten houden. Dan heeft ie niet in de gaten dat er iemand in zit en mee zit te kijken.

En even over die telnet client --> zolang het een telnet client is is het niet zo erg dan kun je hem met een sniffer netjes afluisteren. Zodra hij een telnetd binary installeerd en deze op een hoge poort gebruikt meteen telnetd verwijderen en zorgen dat hij nooit weer op jou bak kan.

Hij denkt nu namelijk ha ik zit mooi in iemand anders zijn bak hier kan ik allerlei leuke dingen vandaan doen zoals andere bakken cracken en dat soort zaken. Kijk eens of je nmap en dat soort tools op je systeem hebt staan. Als dat zo is dan kun je in zijn .bash_history waarschijnlijk ook zien of ie bepaalde ip's scant dan is het ook verstandig dat je die lui van wie dat ip is effe mailed en zegt dat je een scriptkiddo aan de lijn hebt en even wil bekijken wat die gast nou precies aan het uitvreten is.

Veel succes.

[Guru Evi]

Leuk. Een goede firewall zou in ieder geval helpen (dat hij enkel kan verbinden op bepaalde poorten en de rest moet gesloten zijn - kan hij in ieder geval geen andere deamons installeren)
Dan heb je natuurlijk RSBAC of zoiets.
http://www.cauniversity.o...itle=Dutch%20Class%20Logs
Daar bij Linux 301 kun je daar meer info over vinden ;-)

[High Quality king]

Er is weer een nieuwe ontwikkeling maar weet niet of het er mee te maken heeft,

Vannacht werd ik wakker gemaakt om 3 uur door me ouders omdat mijn bak aan het flippen was. Het bleek dat mijn raid configuratie op volledige load aan het laden was en dat al een kwartier lang. Hij was zo van slag dat ik niet eens meer in kon loggen en ik heb uit eindelijk de bak uit moeten zetten met de power knop. Toen hij gereset was heb ik de netwerk kabels eruit getrokken voor de bonding kaartjes. En last -15 getypt maar ik zie niks ook in de bash historie van de verdachte persoon was niks te zien. De pc had al een uptime van 15 dagen ofzo en dit was nog niet eerder gebeurt. Dus dacht ik dat het wel een user aktiviteit moest zijn. Maar ik heb ook wel is iets gehoord over vage schijven onder de 2.4.20 kernel (ik heb 2.4.20-8 (redhat 9 standaard kernel)). Weet iemand hoe ik kan achterhalen wat er nou aan de hand was ? Ik heb geen wijzigen op me schijf gedaan na dit voorval dus misschien kan ik het nog na kijken maar hoe ? Ik heb een EXT 3 filesystem.

Alvast bedankt.

[miniBSD]

Uiteraard je logbestanden op je gemak doornemen. De .bash_history wordt pas weggeschreven na het uitloggen dus dat zou wel iets verklaren. Door het resetten is die informatie dus weg.

Om een gebruiker process en disk toegang te beperken staat op http://www.linuxdocs.org/HOWTOs/Security-HOWTO.htm een hoop nuttige informatie.


En als je hem echt wil betrappen, patch dan bash en zorg ervoor dat iedere toetsaanslag wordt opgenomen op een andere machine. Verder: installeer tripwire. Geweldig goed voor het opsporen van bestanden welke geplaatst zijn op je systeem.

Bedenk dat bij de installatie van SSH ook sftp en scp meekomen.

Bij iptables kun je ook op userid opgeven

code:

owner

    Loaded explicitly with the -m option. 
    The owner extensions match a local packet's creator's user, 
    group process, and session IDs. This makes sense only as a 
    part of the OUTPUT chain.

    --uid-owner userid

        Match packets created by a process owned by userid.
    --gid-owner groupid

        Match packets created by a process owned by groupid.
    --pid-owner processid

        Match packets created by process ID processid.
    --sid-owner sessionid

        Match packets created by a process in the session sessionid.

[Verwijderd]

NOS policy - updated 01/04/03

Ik tel nu al 3 verschillende vragen, in dezelfde thread. Verder blijkt ook niet echt dat je zelf eea probeerd. Ik stel voor dat je a) die gebruiker per direct van het systeem aftrapt, b) je systeem opnieuw installed (met andere wachtwoorden) en c) dat je je eens gaat verdiepen in unix security. Dit topic gaat dus op slot. Succes