Newsgroup: it.comp.os.linux.sys
Titolo: monitorare accesso shell da remoto

Ciao a tutti, ho una domandina da fare...
Devo abilitare l'accesso shell ad un'utente esterno, che dovrà
effettuare delle operazioni sul server.
Senza sapere le sue capacità, vorrei monitorare le sue operazioni,
almeno salvando la sequenza dei comandi di shell... o tutto quello che
mi potrebbe aiutare a capire che sta facendo.
Teoricamente dovrebbe essere un tecnico che manutenziona un suo
applicativo. Ma vorrei evitare casini quindi, vorrei comunicagli che
controllo le sue operazioni.
Grazie
Max

 mi potrebbe aiutare a capire che sta facendo.
http://www.honeynet.org/tools/sebek/
Dai un'occhiata alla sezione "bugs" del readme, se decidi di
usare questo aggeggio.
Puoi anche registrare tutto il traffico di rete generato, se
hai un punto dove poterlo catturare in chiaro.
Fabio

 usare questo aggeggio.
ttysnoop come lo vedresti, invece?
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 ttysnoop come lo vedresti, invece?
Avrei anche una (banalissima) ricettina casalinga per usarlo via
ssh senza ricompilare sshd, nel caso. Il problema di ttysnoop e'
che ttysnoops "parte" da solo, mentre il registratore (ttysnoop)
dev'essere lanciato a manina. Occorrerebbe accrocchiare qualcosa
per farlo partire sul device giusto a ogni inizio di sessione...
non dovrebbe essere tragico, ma non e' una cosa che funziona out
of the box. 
Certo che sebek, in un host su cui, magari, lavorano anche altri
utenti, puo' essere un po' scomodo da usare, in effetti. E i log
di ttysnoop sarebbero piu' comodi da consultare.
Fabio


semplicissimamenti, puoi semplicemente usare bash_logout (o qualiasi 
script di logout della tua shell) per copiare altrove l'history 
(associandogli la data/ora o il numero di processo sul nome).
Se vuoi aumentare un po' la sicurezza puoi fare il 'trap' del CTRL-C o 
cose del genere.
-- 
Massimiliano

 of the box. 
Vero anche questo, ma neanche nulla di particolarmente tragico.

 Vero anche questo, ma neanche nulla di particolarmente tragico.
per ttysnoop se non ho capito male c'è un demone e un client che deve
essere lanciato tramite /etc/inittab praticamente salva tutti i comandi
eseguiti giusto?
ora mi ci metto a fare qualche prova.
Grazie a tutti!!!
Max

 Vero anche questo, ma neanche nulla di particolarmente tragico.
Semplicemente, non ho una soluzione "al volo" per un paio di passi:
trovare il pts giusto [1] ed il modo di passare la passwd al client
[2]. Magari varrebbe la pena di fare un paio di prove per avere una
soluzione pronta all'uso in caso di bisogno.
A questo proposito... MaxTemplar, quando hai fatto 'sto accrocchio,
perche' non posti i dettagli? :-)
Fabio
[1] uhm... l'ultimo creato? Potrebbe esserci una race condition, ma
    per iniziare potrebbe andare. Magari con un check dopo il login
    che faccia il logout se non c'e' il registratore agganciato sul
    pts corrente.
[2] uhm... be', expect, che diamine!

 (associandogli la data/ora o il numero di processo sul nome).
Sono delle soluzioni su cui l'utente monitorato puo' avere un magior
controllo. Se questo approccio fosse compatibile con le sue esigenze
allora potrebbe anche considerare script, che fornisce un log un po'
piu' interessante di history, completo dell'output dei comandi (tipo
ttysnoop) ed e' meno immediato da "manipolare" da parte dell'utente.
Penso che soluzioni alternative siano preferibili, se lo scopo e' il
monitoraggio.
Fabio

 eseguiti giusto?
L'archiettura del tutto dipende da come avranno accesso gli utenti
da monitoare.
Comunque, scrivendo la risposta a MaxAdamo m'e' venuta un'idea per
usare script che forse potrebbe funzionare in modo sicuro, e senza
le complicazioni (neanche troppe, forse) per implementare ttysnoop
(dovrei fare una prova, magari dopo pranzo).
Fabio

Sicuramente appena risco posto tutti i dettagli, comunque l'accesso
avverà tramite ssh. penso mai da consolle, ma non è da escludere.
Appena riesco a installare una macchina mulo ci faccio 2 prove.
Intento se ti viene qualche idea fammi sapere :-)
Grazie
Ciao
Max

 (dovrei fare una prova, magari dopo pranzo).
Non ho avuto tempo per provare :-/ Forse il metodo e' un po' grezzo:
prova a sostituire /bin/login con uno script che ti avvii script(1).
Quest'ultimo deve scrivere il log in una directory non scrivibile da
chi devi monitorare e dovra' avviare (-c) il vero login(1) che avrai
precedentemente rinominato. Il nome del file di log lo puoi creare a
runtime, in base parametri che ti aggradano. Se c'e' possibilita' di
sovrascrittura dei log precedenti, usa -a per appenderlo. E verifica
che script(1), per qualche strano motivo, non sia suid ;-)
Se usi ssh, abilita UseLogin (come si diceva con whip).
E... se ci provi sarebbe gradito un feedback su come funzia, plz :-)
Fabio
esempio:
----
#!/bin/sh
#
# Sostituto di /bin/login
#
# I log di tutte le sessioni di tutti gli utenti andranno nello 
# stesso file, modificare alla bisogna.
/usr/bin/script -af -c /bin/login.vero /non/scrivibile/da/usero.log
----


aldila' della pure questione tecnica, quello che vuoi fare mi sa un po' 
di grande fratello, ma se questo e' quello che devi fare non devo certo 
stare a farti la morale.
-- 
Massimiliano

 di grande fratello
Non hai letto tutto il thread, è evidente.

 controllo le sue operazioni.
Si`, indubbiamente per correttezza, prima di farlo, devi dirglielo.
Andrea

 Si`, indubbiamente per correttezza, prima di farlo, devi dirglielo.
<IANAL>
Per correttezza si' (io lo farei). Ma non penso che ci sia nessun 
obbligo in tal senso, da parte dell'azienda di MaxTemplar. 
</IANAL>
Fabio
[1] a meno di non poter forzare un accesso del tipo "append only" 
    ai log, con LIDS od altri cosi del genere; ma anche in questo
    caso, l'utente avrebbe accesso al processo di tee: per alcuni
    potrebbe essere abbastanza per spippolarci, anche se il gioco
    comincerebbe a farsi molto piu' duro, per chi volesse evadere
    i controlli (e molti degli scenari per un attacco rimarrebero
    validi anche nel caso in cui l'utente non abbia accesso a log
    e/o processo di logging, quindi e' inutile considerarli qui).

 apparterrebbe.
Mi intrometto ora e magari dico una boiata, ma il bsd process accounting non 
va bene?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Preferirei essere negro piuttosto che gay, perche' se sei negro non lo devi
dire a tua madre!
		-- Charles Pierce

 accounting non va bene?
Il dettaglio sulle operazioni che ne ricavi non penso che sia
sufficiente agli scopi di MaxTemplar. Pero', in effetti, puo'
esser d'aiuto, ed anche molto, integrare il log del terminale
con queste info (esempio: ti rendono conto anche di eventuali
comandi lanciati da script che, altrimenti, si perderebbero).
Il problema piu' grosso che vedo sarebbe l'uso delle risorse:
temo che non sarebbe un metodo applicabile su una macchina di
produzione con molti utenti o su cui vengano lanciati un gran
numero di processi (se non per tempi limitati). Certo, magari
si potrebbe attivarlo al login e fermarlo al logoff... magari
i suoi non sono dei server molto carichi... chissa'. 
Mi pare che possa essere un contributo molto interessante per
MaxTemplar, comunque.
Fabio


letto adesso :)
e' una questione mezza politica, mezza tecnica.
Se l'utente sa che ogni sua mossa sara' regitrata puo' anche decidere di 
usare quella cosa che dite voi (che non conosco), altrimenti puo' essere 
sufficiente monitorare i comandi lanciati.
spetta a lui :)
-- 
Massimiliano