[Risolto] Creazione script per invio informazioni al forum

[marcomg]

Serve il log "completo" con i difetti. Ovviamente ritoccalo se pensi che quei dati siano sensibili.
Nel farlo ti chiedo gentilmente di: tenerli coerenti (cioè se pippo diventa pluto tutti i pippo falli diventare Pluto) e nel caso di indirizzi IP di rendere comprensibile se sia interno o esterno (cioè se inizia con 192.x oppure 10.x o 172.x o altro).

Sarebbe fantastico anche che indicassi il numero di righe che hai corretto nel log.

Se proprio lo si ritiene utile, occorrerebbe almeno una qualche opzione che attivi il rilevamento dei due history ed un bell' "ATTENZIONE!" che inviti l'utente a controllare il risultato in due sezioni ben definite e facilmente rintracciabili.

S3v è stato particolarmente accorto su questo ambito. Si è discusso molto anche sui dati non necessari da prelevare e sui permessi minimi di esecuzione.
Il problema che riscontri non è stato rilevato nei vari test e prove fatte, servono dei dati da analizzare

Ammesso che quei dati non siano stati raccolti in altro modo.

??

[whitetiger]

Ammesso che quei dati non siano stati raccolti in altro modo.

??

Intendo dire che magari i dati che segnalo non sono prelevati da bash_history, ma da qualche altro comando nello script.

Tornando alla mia segnalazione, se servono anche i due history (comandi e display), suggerivo di inserire una opzione con relativo avviso e spostare poi i risultati in fondo al file mettendo le due sezioni in evidenza così che l'utente possa agevolmente controllare.

Non dubito che in determinati contesti siano informazioni utili, ma non tutto ciò che viene digitato lo è.
Al di là delle considerazioni circa la sicurezza da te riportate nell'altro post, concordo al 100% su ciò che andrebbe fatto e non fatto; però intanto vediamo di non lasciare le credenziali visibili in un file pubblicato in un forum per sua natura pubblico ed accessibile a chiunque abbia un minimo di competenze informatiche.
L'errore è sempre dietro l'angolo: se anziché "adduser pippo" digito "adduset pippo" senza alzare gli occhi dalla tastiera ecco che mi ritrovo a video (e poi sul file) pure le password che pensavo di digitare nel prompt e che invece ho digitato sulla linea di comando.

[marcomg]

Intendo dire che magari i dati che segnalo non sono prelevati da bash_history, ma da qualche altro comando nello script.

Non sono prelevati dal bash history. A meno che tu non abbia digitato e premuto invio durante l'esecuzione dello script non mi viene in mente cosa sia successo, bisogna indagare.

vediamo di non lasciare le credenziali visibili in un file pubblicato in un forum per sua natura pubblico ed accessibile a chiunque abbia un minimo di competenze informatiche

Ma infatti mica ho detto va bene così. Prima di qualsiasi azione eventualmente correttiva devo essere in grado di riprodurre il problema.
Quindi serve un log quanto più identico all'originale e vedere quali righe sono problematiche.
Puoi fornirlo?

[s3v]

Ciao e grazie del feedback.

Ciao.
Come ho scritto in un post a parte, ho ritrovato nel file prodotto dallo script informazioni che non dovrebbero essere presenti.
Credo che siano comandi digitati o il risultato prodotto sullo schermo.

È inutile nascondere gli utenti se poi nel file appare il comando "adduser pippo"
Così come sia inutile nascondere gli IP se mi trovo da qualche parte "user:password@URL/IP".
Io ho dovuto rileggermi quanto prodotto dallo script per andarmi a ripulire tutto ciò che non volevo pubblicare.

Mi spiace che tu sia incappato in questo problema. Inutile ribadire che tale tipo di inconveniente è stato sempre in cima alle cose da evitare.
Ma non sempre ci si riesce, nonostante gli sforzi.

Lo script non raccoglie alcuna cronologia dei comandi e non nasconde IP siano essi pubblici o privati.
Nel caso venga visualizzato da qualche parte il tuo IP pubblico, ovviamente va nascosto.
Puoi indicare la sezione del file di log sotto cui riscontri il problema?
Inizia con una riga di asterischi.

Se proprio lo si ritiene utile, occorrerebbe almeno una qualche opzione che attivi il rilevamento dei due history ed un bell' "ATTENZIONE!" che inviti l'utente a controllare il risultato in due sezioni ben definite e facilmente rintracciabili.

Ammesso che quei dati non siano stati raccolti in altro modo.

L'indicazione di controllare il file prima di allegarlo sul forum è sicuramente qualcosa da inserire.
Comunque non capisco a quali history fai riferimento. A quelle di apt?

Puoi indicare come hai prelevato lo script?

Grazie ancora.

[marcomg]

Puoi indicare come hai prelevato lo script?

La discussione di interesse è questa viewtopic.php?p=223122#p223122 quindi presuppongo sia stato prelevato direttamente dal wiki.

@S3v grazie per essere intervenuto, anche perché in scripting bash non sono proprio una spada

[whitetiger]

Oddio...
È già grazia se mi ricordo cosa ho mangiato a colazione
Se non ricordo male l'ho preso usando il link nella firma e di averlo lanciato con l'opzione "-generico" come da consiglio di Marco.
E non mi ricordo di avere rimosso delle righe, ma solo oscurato le cose che non volevo pubblicare.

Poi non vorrei aver creato una tempesta in un bicchiere d'acqua; magari ho semplicemente valutato male ciò che ho trovato.
Ad esempio alla riga 3614, più che un history sembrerebbe un servizio, dove però c'è l'URL.

È chiaro che se ho preso lucciole per lanterne, interpretando per history quello che non è, le mie preoccupazioni vengono a mancare e mi riprometto in futuro di allacciare meglio la spina prima di dire ancora qualche castroneria.

Più tardi lo rigenero e sarò semmai più preciso.

==== Update
Che vi devo dire? Visto che sono mezzo astemio non posso neppure accampare la scusa di un bicchierino di troppo.
Però nel file di ieri c'erano delle cose che non mi garbavano più di tanto e l'ho corretto prima di inviarlo.
In quello generato oggi non c'è nulla di tutto ciò; però ormai il file originale di ieri l'ho rimosso.
Quindi... chiedo venia e la chiudo qui.
Allego il file nuovo nell'altro post visto che comunque ci sono state delle nuove installazioni.

[marcomg]

come da consiglio di Marco

consiglio di Aki

ma solo oscurato le cose che non volevo pubblicare

Ok meglio, così riusciamo a confrontare

Ad esempio alla riga 3614, più che un history sembrerebbe un servizio, dove però c'è l'URL.

Sono i log di systemd relativi all'autenticazione. Quindi sì, appare il nome utente, ma nessuna password.

Non mi sembra comunque ci siano dati sensibili, magari S3v può dare un parere più esperto al riguardo

[whitetiger]

...
Non mi sembra comunque ci siano dati sensibili, magari S3v può dare un parere più esperto al riguardo

Per quanto mi riguarda discorso chiuso. Ho segnalato una cosa, l'avete raccolta ed avete verificato che è tutto OK.
Tra l'altro confermo che con il secondo script non ci sono neppure le cose che mi preoccupavano.

[marcomg]

Hai fatto bene a segnalarla

avete raccolta ed avete verificato che è tutto OK.

Diciamo che lo penso anche io, ma sarei voluto essere più sicuro.

confermo che con il secondo script non ci sono neppure le cose che mi preoccupavano.

Sisi, ma il punto è che vorremo non accadesse, anche se le condizioni da essere verificate siano remote

Chi esegue lo script ripone in noi fiducia che vogliamo meritare

[marcomg]

Non so se si fosse già trattato, ma lo script utilizza aptitude (viewtopic.php?f=1&t=56395) log di esempio che non è più installato di default a opzionale da Stretch... Forse è il caso di sostituirlo?

[HAL 9000]

Se non ricordo male, lo script utilizza anche comandi non presenti di default per cercare di fornire quante più informazioni possibili nel caso siano presenti.

In effetti però è ormai molto improbabile che aptitude sia presente, essendo opzionale da Debian 8 (jessie). Specialmente nel caso degli utilizzatori di questo script, e bisognerebbe cercare un'alternativa, se possibile.

Non penso sia l'unico, e potrei approfittarne per controllare tutti i comandi rispetto a quelli presenti in un'installazione standard di bullseye.

[s3v]

Non penso sia l'unico, e potrei approfittarne per controllare tutti i comandi rispetto a quelli presenti in un'installazione standard di bullseye.

Qui se ne è scritto
viewtopic.php?p=221538#p221538

Provai fin dall'inizio a sostituire aptitude (come provai a sostituire qualunque comando non essenziale con comandi essenziali) ma ne veniva fuori praticamente un altro script che era pure lentissimo.
Se si trova una soluzione, comunque ben venga.

[HAL 9000]

Mi limiterei allora a segnalare come raccomandata l'installazione di aptitude, come si fa per pastebinit, per raccogliere informazioni più precise.

Si potrebbe però includere la lista dei pacchetti installati manualmente:

Codice: Seleziona tutto

apt-mark showmanual

(E già che ci siamo anche quelli eventuali in stato di "hold" con showhold.)

E anche l'elenco totale, con numero di versione:

Codice: Seleziona tutto

dpkg -l

Così almeno si raccoglie l'informazione, anche se non è evidenziata.


EDIT: ho notato inoltre che il controllo sull'assenza di aptitude avviene troppo presto nella funzione "_extpack", mentre si potrebbe spostare dopo, così che ci sia comunque un qualche controllo sui repository e venga restituito quanti ne sono stati trovati.
Inoltre si potrebbe integrare una verifica anche per il repository di sicurezza, tenendo conto del cambiamento di sintassi con bullseye.

Altra cosa: bisognerebbe controllare su una nuova installazione come si comporta lo script ora che sono unificate (?) /usr/bin e /bin (così come /usr/sbin e /sbin). Avendo sempre fatto aggiornamenti, non ne ho idea, ma immagino dovrebbe ancora esserci un link simbolico da /bin a /usr/bin.
E si potrebbero rimuovere i comandi ifconfig/route, tanto più che le alternative sono già presenti.

E anche column non è più presente di default, spostato dal pacchetto bsdutils a bsdextrautils. Ignoro francamente se ci sia un'alternativa presente di default che permette la formattazione dell'output in colonne. Comunque serviva solo per rendere più leggibile l'output di aptitude.(vedi nota successiva)


EDIT2: è cambiata la policy di gestione delle priorità delle dipendenze dei pacchetti. Ora un pacchetto ha una priorità sua, a prescindere dall'essere o meno dipendenza di un altro, mentre prima nessun pacchetto poteva dipendere da uno con priorità inferiore. Per esempio libc6 è ora (almeno su bullseye) "optional", per quanto non si possa effettivamente rimuovere.
Il seguente comando (è richiesto aptitude installato) dovrebbe restituire tutti i pacchetti (librerie comprese) presenti in un'installazione standard di Debian (tra <> ci sono quelli virtuali):

Codice: Seleziona tutto

apt-cache --recurse -i depends $(aptitude -F %p search '!~pextra !~poptional !~v')|awk '$1~/(^|[^|])Depends:/{print $2}'|sort -u

Il comando column quindi è ancora presente, essendo bsdextrautils una nuova dipendenza di man-db (con priorità standard).

[s3v]

Mi limiterei allora a segnalare come raccomandata l'installazione di aptitude, come si fa per pastebinit, per raccogliere informazioni più precise.

Ok

Si potrebbe però includere la lista dei pacchetti installati manualmente:

Codice: Seleziona tutto

apt-mark showmanual

(E già che ci siamo anche quelli eventuali in stato di "hold" con showhold.)

Ok

E anche l'elenco totale, con numero di versione:

Codice: Seleziona tutto

dpkg -l

Così almeno si raccoglie l'informazione, anche se non è evidenziata.

Risulterebbe un output chilometrico e scarsamente leggibile...
Inoltre la versione visualizzata, non avendo indicazione del repo da cui proviene, potrebbe essere anche uguale ad una versione presente in un repo canonico di Debian.

EDIT: ho notato inoltre che il controllo sull'assenza di aptitude avviene troppo presto nella funzione "_extpack", mentre si potrebbe spostare dopo, così che ci sia comunque un qualche controllo sui repository e venga restituito quanti ne sono stati trovati.

Forse non ho capito bene cosa intendi, ma questa informazione non è presente anche in "sources.list"?

Inoltre si potrebbe integrare una verifica anche per il repository di sicurezza, tenendo conto del cambiamento di sintassi con bullseye.

Sì, va verificato.

Altra cosa: bisognerebbe controllare su una nuova installazione come si comporta lo script ora che sono unificate (?) /usr/bin e /bin (così come /usr/sbin e /sbin). Avendo sempre fatto aggiornamenti, non ne ho idea, ma immagino dovrebbe ancora esserci un link simbolico da /bin a /usr/bin.

Anche questo.

E si potrebbero rimuovere i comandi ifconfig/route, tanto più che le alternative sono già presenti.

Lo script è compatibile fino a oldoldstable, non so se in Jessie le alternative sono già presenti.
Inoltre c'è un typo: "OLDOLDSTABLE"->"$OLDOLDSTABLE".

EDIT2: è cambiata la policy di gestione delle priorità delle dipendenze dei pacchetti. Ora un pacchetto ha una priorità sua, a prescindere dall'essere o meno dipendenza di un altro, mentre prima nessun pacchetto poteva dipendere da uno con priorità inferiore. Per esempio libc6 è ora (almeno su bullseye) "optional", per quanto non si possa effettivamente rimuovere.
Il seguente comando (è richiesto aptitude installato) dovrebbe restituire tutti i pacchetti (librerie comprese) presenti in un'installazione standard di Debian (tra <> ci sono quelli virtuali):

Codice: Seleziona tutto

apt-cache --recurse -i depends $(aptitude -F %p search '!~pextra !~poptional !~v')|awk '$1~/(^|[^|])Depends:/{print $2}'|sort -u

Il comando column quindi è ancora presente, essendo bsdextrautils una nuova dipendenza di man-db (con priorità standard).

Meno male, grazie di esserti accorto di "column", mi era totalmente sfuggito.
Si può anche togliere (insieme a --disable-columns) ma l'output non è tanto bello.

[HAL 9000]

Va bene, cercavo di raccogliere più informazioni possibili, ma effettivamente dpkg è troppo verboso e comunque informeremo sulla necessità di installare aptitude per un log più dettagliato.

Per non rimuovere completamente dpkg, si potrebbero rimuovere tutti i pacchetti installati/disinstallati correttamente:

Codice: Seleziona tutto

dpkg -l | grep -Ev '^(ii|un|rc)'

Perderemmo la versione degli altri, ma ma almeno manterremmo la possibilità di controllare eventuali pacchetti in uno stato non corretto. Non so però se le informazioni sarebbero le stesse che con le simulazioni di apt-get, in tal caso ovviamente non servirebbe.

Per il controllo di aptitude, non so perché, pensavo quelle informazioni fossero solo nella funzione _apt, mentre invece sono comuni a tutti i casi. E apt-cache policy e i sources.list forniscono già quelle informazioni, quindi non serve spostare niente.
Preferirei comunque rimuovere column, se non altro per evitare possibili problemi più avanti, e cambiare leggermente il formato dell'output (per quelli con una sola versione, la versione ha la stessa larghezza e così almeno il nome del pacchetto resterebbe sempre allineato):

Codice: Seleziona tutto

aptitude --disable-columns -F '%t: %p %v' search ...

"--disable-columns" forse non serve a niente con le redirezioni? Se è così, si può anche togliere.