Newsgroup: it.comp.os.linux.sys
Titolo: Reverse engineering del Backup (un po' lungo)

Ciao a tutti!
Il mio Provider mi ha fornito uno script (python compilato! Pork!!) che
effettua un Backup del mio Server su una loro macchina.
Oltre indirizzo, porta, nome utente e password, non so altro.
Se uso FTP vedo che effettivamente i files sono salvati e, sembra, anche
con i giusti permessi e UID/GID.
Pero', se voglio fare un restore, devo settare a manina i permessi. E la
cosa non mi piace... Passi se devo ripristinare UN file, ma gia' una
directory e' una cosa piuttosto laboriosa.
Il Provider NON fornisce (ancora, almeno!) uno script per il Restore.
Dicono che, in caso di problemi, ci pensano loro.
E mi starebbe anche bene nel caso in cui il Server sia da rottamare e
occorre installarne uno nuovo.
Ma sapete tutti che capita ogni tanto di dover ripristinare un file o una
directory dal Backup.
E questo vorrei farlo io, altrimenti devo dare accesso come root al
Provider. E non voglio farlo.
Ora, io so solo che, se apro una connessione SSH con il Server mi risponde:
Linux s13 2.6.39 #1 SMP Tue May 24 20:02:41 CEST 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 19 08:34:21 2011 from 
ns.lucabert.de
Connection to 
server.provider.de
 closed.
Che venga usato rsync ne sono abbastanza sicuro in quanto stanotte ci sono
stati dei problemi (la directory di spool di Exim che e' cambiata giusto
nel momento del Backup) e ho ricevuto questa E-Mail:
file has vanished: "/var/spool/exim/input/1R5SEb-0006CR-P5-D"
file has vanished: "/var/spool/exim/input/1R5SEb-0006CS-QV-D"
file has vanished: "/var/spool/exim/input/1R5SEb-0006CT-TR-D"
file has vanished: "/var/spool/exim/input/1R5SEd-0006Ce-5r-23854-K"
file has vanished: "/var/spool/exim/input/1R5SEd-0006Ce-5r-D"
file has vanished: "/var/spool/exim/input/1R5SEd-0006Ce-5r-H"
file has vanished: "/var/spool/exim/input/1R5SEd-0006Ce-5r-J"
file has vanished: "/var/spool/exim/msglog/1R5SEd-0006Ce-5r"
file has vanished:
"/var/spool/exim/scan/1R5SEb-0006CR-P5/1R5SEb-0006CR-P5.eml"
file has vanished:
"/var/spool/exim/scan/1R5SEb-0006CS-QV/1R5SEb-0006CS-QV.eml"
file has vanished:
"/var/spool/exim/scan/1R5SEb-0006CT-TR/1R5SEb-0006CT-TR.eml"
rsync warning: some files vanished before they could be transferred (code
24) at main.c(1060) [sender=3.0.7]
Pero' se provo a lanciare rsync per, per esempio, ripristinare una
directory, mi risponde picche:
rsync --port 222 -aSHxv
rsync://ute...@server.provider.e:/backup/2011-09-18/backup/ /tmp/b/
rsync: failed to connect to 
s13-basic.ip-projects.de
: Connection refused
(111)
rsync error: error in socket IO (code 10) at clientserver.c(122)
[Receiver=3.0.7]
Ora, volendo non avrei problemi a lasciare uno screen, questa notte, con
ngrep o tcpdump e sniffare i pacchetti.
Pero' mi piacerebbe sapere come procedere... Non ho mai fatto reverse
engineering per queste cose, quindi non saprei neanche cosa sniffare e
come analizzare la cosa dopo.
Qualcuno puo' darmi una dritta? L'alternativa e' cercare di decompilare lo
script python, ma non ho trovato un decompilatore che lavori con python
2.6...
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Scusa, come lo fai il restore?
 
Se leggi poco dopo, lo spiega.
 

 python 2.6...
 
Quando uno capisce che ha a che fare con qualcosa di compilato si 
spaventa e va in palla, pensando subito a tcpdump, tshark e reverse 
engineering del bytecode e robe complicate.
 
Se sei sicuro che usa rsync, allora perchè non sostituisci a rsync un 
wrapper in bash che ti cattura TUTTI i parametri con cui è lanciato e poi 
chiama rsync ?
 

 Scusa, come lo fai il restore?
 
Ecco, e' proprio questo il problema...
Attualmente posso solo prenderlo da FTP oppure dare al Provider i diritti
di root e farmi fare il restore...
 
Per quello sto studiando una soluzione alternativa per prendere questi
dati...
 
Ciao


CtRiX ha scritto:






 chiama rsync ?
 
Sono QUASI certo che usino rsync... Stasera provo a scrivere un wrap che
mi salva i parametri e domani vediamo...
 
Ciao


 restore mentre il backup e' fatto da uno script che -forse- usa rsync.
E dice che il restore o lo fa con FTP o lo fa il provider.

 Mi viene in mente di far andare Rsync via ftp 
E, perchè no, Rsync over IRC o Rsync over SMTP ?
Magari funziona meglio.

Sono QUASI certo che usino rsync...
 
In caso, strace is your friend :-)
 
Leonardo
 
-- 
Surstangas via akcipitr', la ceval' fojnumas nur:
Jen vigla damo en brakum', kaj vi pensas pri forkur'?
Do li turnis sin, kaj turnis sin, kaj ekdormis sen singard';
Kaj lin apudis je l' vekigx, soldatoj kaj Barnard'.

 faccia il wget via ftp e restore dei permessin.
 
Mmm... Interessante... Come si fa ad usare RSync via FTP? Ho solo visto
documentazione per usarlo tramite SSH...
Il problema dello script che prenda via FTP e faccia il restore e' che sul
Server remoto (Debian, direi) ci sono degli utenti che usano gli stessi
UID/GID che uso io sul mio Server (niente di strano, direi), ma con FTP
non riesco a vedere i UID/GID numerici, ma solo "tradotti" in stringhe.
E quindi non saprei come rimettere a posto gli utenti...
 
Idee?
 
Grazie


 In caso, strace is your friend :-)
Sicuro?
Ho appena fatto una prova con uno scriptino delle balle che richiama
/bin/echo.
L'ho compilato e l'ho richiamato premettendo strace.
Analizzando il log prodotto NON vedo nessuna chiamata a /bin/echo...
In ogni caso, ho pronto un wrapper per rsync. Vediamo cosa succedera'
stanotte...


 chiama rsync ?
 
Scemo che sono: ho provato ad aprire con less lo script compilato e che ti
vedo? Il richiamo a rsync con un po' di parametri.
Il problema e' che altri, da quel che mi sembra di capire, sono contenuti
in variabili e quindi non visibili da less...
 
In ogni caso, come ho detto prima, ho creato un wrapper per rsync. Domani
vedremo quali sono esattamente i parametri...
 
Ciao


 in variabili e quindi non visibili da less...
 
beh, comunque puoi sempre "disassemblare" per vedere che sta dentro il .pyc
 
(import dis; dis.dis(modulo))
 
-- 
By ZeD

Analizzando il log prodotto NON vedo nessuna chiamata a /bin/echo...
 
Non c'e' versi: sia os.system chiama system(), che comunque va a prendere
execve; popen e :subprocess usano os.execvp() che e' di nuovo execvp e va
a finire su execve (IIRC).
 
Ed execve dovrebbe risultare da strace.
 
Non è che stai usando un loader a due stadi per lo script? Nel qual caso,
devi usare strace -f, in modo da vedere le execve lanciate non dallo stub
dell'"eseguibile", ma dal suo script "figlio".


 chiama rsync ?
 
Ed ecco il risultato:
 
rsync --rsh=ssh -i
/root/Backup/.OAE4AIY8LCQ71QT0DNRV354WOPZ09CNX2CCW9JODKFASQPGIR7JSUUIF7FSGKJ8AGLCTVZHMEZ26SX8ACK1WMPK3FQ04AMUE2Z2NVQP0G1A8BTSJ7PQ7XFSKN8SZJ46M
-p 222 -arv --progress --delete
--exclude=/root/Backup/.OAE4AIY8LCQ71QT0DNRV354WOPZ09CNX2CCW9JODKFASQPGIR7JSUUIF7FSGKJ8AGLCTVZHMEZ26SX8ACK1WMPK3FQ04AMUE2Z2NVQP0G1A8BTSJ7PQ7XFSKN8SZJ46M
--exclude=/dev --exclude=/sys --exclude=/proc --force --backup
--backup-dir=../2011-09-19 --log-file=/root/Backup/rsync.log /
ro...@server.provider.de:/home/backup_atom60/backup/full
 
E cosi' a naso, direi che mi hanno fregato...
Loro hanno la chiave RSA di root all'interno del programma, la salvano su
disco e accedono alla macchina come root...
E poi cancellano (giustamente!) la chiave.
 
Visto che poi lo script stanotte e' fallito, a causa di qualche problema
nel mio wrapper, l'ho rilanciato adesso a manina.
Risultato: funziona, ma non riesco a prendere la directory dove mettono le
chiavi (manco la riesco a vedere...).
 
Altre idee?


 E poi cancellano (giustamente!) la chiave.
 
Ho capito male o mi stai dicendo che costoro hanno cablato la chiave per accedere come root a un server remoto,
al quale tu non avresti accesso, all'interno di un programma che risiede sul tuo server?

whiplash ha scritto:

Se guardo il comando passato a rsync, direi proprio di si...
E questo spiega sicuramente il motivo per cui NON distribuiscono il
sorgente dello script...
 
Sinceramente la cosa mi piace poco e sto meditando veramente di mandare a
quel paese lo script e di fare i Backup con ReoBack o similari (tar.gz).
 
Sinceramente, che LORO siano tanto stupidi da creare un programma del
genere mi lascia abbastanza indiferente, ma IO **DEVO** essere in grado di
fare un restore dei miei dati senza coinvolgere altre persone...
 
Ciao


 genere mi lascia abbastanza indiferente,
 
Io invece qualche problema me lo porrei.

 Io invece qualche problema me lo porrei.
 
Bah, alla fine mi basta disattivare il loro script e morta li...


 Bah, alla fine mi basta disattivare il loro script e morta li...
 
La domanda che mi porrei io è: il serve di backup è condiviso con altri clienti?
Ammesso che con il trucco di cui sopra io riesca effettivamente a ricavare la chiave per accedere
come root al server di backup e  che la prima domanda abbia risposta positiva, è possibile che anche
qualcun altro si sia accorto della cosa e possa accedere ai backup di chiunque, compreso il mio?

 Non capisco cosa intendi con quel comando...
 
http://en.wikipedia.org/wiki/Inotify
 
 
Basta aspettare che venga scritta la chiave nella dir /root/Backup e
te ne fai una copia da qualche parte.
Maccheffurboni.
 
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
 
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 
 
 

Altre idee?
 
cp is your friend :-D


 qualcun altro si sia accorto della cosa e possa accedere ai backup di
chiunque, compreso il mio?
 
Tutto e' possibile... E' per quello che dicevo che sto pensando di usare
ReoBack (che fa un bel TAR.GZ, eventualmente anche criptato) al posto del
loro script.
Cosi' IO ho accesso totale ai miei dati e NESSUN altro puo' averlo...


 documentazione per usarlo tramite SSH... 
 
Se riesce a rispondere gli offro una cena a base di bistecca fiorentina 
originale in un posticino qui vicino.

 ro...@server.provider.de:/home/backup_atom60/backup/full
 
BRRR Scappa scappa!
Pialla tutti i dati che hai su quel server e non usare più quel sistema 
di backup.

 
 
Anche direttamente dal wrapper.
 
-- 
In God we trust. All others must bring data
W. E. Deming

 accesso, all'interno di un programma che risiede sul tuo server?
 
Sono un pelino superficiali. In linea di principio il metodo e` buono ma
invece di usare root avrebbero dovuto crearsi un utente dedicato per
ogni account con relativa chiave personalizzata.
 
-- 
Vincenzo

 ogni account con relativa chiave personalizzata.
 
Anche tu sei supercifiale se definisci quella cazzata come "superficiale".
 
Questi ti consentono con pochissimo sforzo di:
 
1) ottenere accesso root alla macchina dei backups
2) ottenere i backup degli altri clienti non avendone (ovviamente) i 
diritti.
 
Capisco che se vuoi salvare gli uid/gid ed i permessi dei files con rsync 
devi essere root, ma ciò non significa che tu *debba* usare rsync per far 
fare dei backup da gente "untrusted".
 
Semplicemente, rsync non è lo strumento giusto per fare quei backup e chi 
ha ideato il metodo è un incompetente e te che lo definisci superficiale 
sei, probabilmente, un kamikaze informatico che non parla a ragion veduta 
(perchè, al contrario di quello che hai scritto, con rsync che gira come 
utente normale non ce li salvi altri UID se non quello con cui sta 
girando).

 al quale tu non avresti accesso, all'interno di un programma che risiede sul tuo server?
 
Vacca miseria, questi son persino peggio di me.
 
Non mi sento più solo ora.
 
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 al quale tu non avresti accesso, all'interno di un programma che risiede sul tuo server?
 
Neanche dire che non ci abbiano proprio pensato, visto che i Cialtroni hanno 
pure perso tempo a randomizzare e nascondere il file.
 
 
Fabio

 UID se non quello con cui sta girando).
 
Nello specifico non mi ero concentrato sulla questione rsync/uid/guid.
rsync sicuramente non va bene. Il discorso si riferiva all'accesso ssh
con chiave.
 
E comunque stai calmino, il "pelino superficiale" era ironico.
Probabilmente ti sevono altre tonnellate di vacanze.
 
-- 
Vincenzo

 diritti.
 
Prima di partire in quarta e di dare degli incompetenti agli altri,
verificherei che quella macchina di backup non sia dedicata al cliente.


 verificherei che quella macchina di backup non sia dedicata al cliente.
 
"superficiale" != "incompetente"
 
Mi stupirei se fosse dedicata al cliente, allocheresti il doppio di 
risorse con un certo aggravio di costi.
E se fosse dedicata non ci sarebbero problemi, a quel punto, a fornire 
l'accesso di root all'OP nel caso dovesse recuperare i dati.
 
 
 
 

 Probabilmente ti sevono altre tonnellate di vacanze.
 
Uh magari.

 l'accesso di root all'OP nel caso dovesse recuperare i dati.
 
Mah, io non mi stupisco più, ho visto cose anche più strane giustificate
da ragioni ""commerciali""".
Sulle risorse non è detto che ci siano aggravi significativi, una vm con
un sistema minimale, un ip privato e lo spazio che allocheresti comunque
non è che chissà quanto costi. E non sappiamo Luca che servizio ha,
potrebbe essere un ultra-mega-maxi-iper-housing che 160Gb di spazio
per il backup te li regalo volentieri.
 
Ovviamente sparo un po' a caso pensando a mie esperienze passate.


 Ovviamente sparo un po' a caso pensando a mie esperienze passate.
 
Bisognerebbe aprire un NG dedicato per raccontare le chicche che 
quotidianamente accadono qui.
 

 per il backup te li regalo volentieri.
 
Bah, niente di che... Un Server Atom 1.80 GHz, 2GB RAM e 250GB SW-RAID1.
Per il Backup dicono che forniscono un sistema con RAID6, ma senza
specificarne la dimensione. Immagino che, ogni tanto, quando lo spazio
libero si riduce troppo, aggiungano un altro disco al NAS.
 
Per quanto riguarda lo script: da quel che mi ha detto il Provider ieri,
pare che sia stato creato per fare il Backup dei Server MANAGED (quindi
dove il cliente NON ha accesso root e NON si occupa dell'amministrazione).
In questo caso, pur con le dovute considerazioni di sicurezza del caso, lo
script lavora egregiamente e, essendo messo in una directory completamente
invisibile al cliente, non gli consente di vedere come funziona e dov'e'
e, conseguentemente, di poter crackare il sistema.
Inoltre consente, con un singolo colpo di rsync, di rimettere in piedi una
macchina della quale i dischi hanno reso l'anima partendo da un Live-CD.
Il fatto che il cliente non sia in grado di fare autonomamente il restore
non e' un problema, in quanto il Server e' MANAGED e, per definizione,
queste cose le fa il Provider.
 
Ora, pare che, a richiesta, offrano questo script anche ai clienti di
Server "ROOT" (quindi dove e' il Cliente che ha l'accesso amministrativo e
non il Provider).
In effetti, al tempo, mi dissero di aver gia' pronto uno script che mi
avrebbero dato volentieri, ma avrei potuto tranquillamente usare altri
programmi a mio piacimento.
 
Visto che, secondo il Provider, quello script e' ottimizzato per il
consumo di banda (rsync in effetti trasferisce SOLO le differenze), prima
di cercare altro, ho deciso di provarlo.
 
Ora, dopo averne visto i problemi (e, sopratutto, dopo aver realizzato che
NON posso fare un restore automatico da solo), ho deciso di dismettere lo
script e di sostituirlo con duplicity che e' anch'esso ottimizzato per il
consumo di banda (funziona come rsync) e in piu' mi consente di criptare e
firmare i Backup con GPG.
 
Tutto qui!
 
Ciao


 fare dei backup da gente "untrusted".
 
Ecco, questo e` un ottimo spunto di discussione, tu come salveresti questi 
attributi (ACL e xattr compresi) non utilizzando rsync via root? Al volo, 
l'unico modo che mi viene in mente e` impostando i comandi getfacl, lsattr e 
stat via sudo su di un utente
 
Enrico

 dell'OP.
 
Ma io mi sono agganciato molto piu` sotto dove si discuteva di accesso
ssh con chiave. A questo mi riferivo quando ho scritto "In linea di
principio il metodo e` buono", non certo a rsync che non era nemmeno
presente nel post che ho quotato.
 
-- 
Vincenzo

 non è che chissà quanto costi.
 
Non ci sarebbero particolari motivi per cablare una chiave privata
nel codice, a quel punto.

 ha scritto nel messaggio
news:j5epff$6ia$
1...@posted-at.bofh.it
 

Come dicevo dopo, 'boh'.
Potrebbe essere una situazione ereditata da un'altra gestione...


 getfacl, lsattr e stat via sudo su di un utente
 
tar.
 


Allora si, in questi giorni sono acido e rompicoglioni.
Sarà la vecchiaia ma tant'è, puntualizzo un pò di cose.
 
 
10/15 anni fa su questo newsgroup c'erano tre tipi di persone:
a) quelli che facevano domande in tema e coerenti
b) quelli che davano risposte competenti e corrette
c) quelli che non ricadendo nella categoria a) e b), stavano zitti 
(lurkavano) ed imparavano.
 
Queste distinzioni erano molto utili perchè quando qualcuno aveva 
problemi (leggasi, cercava soluzioni ai suoi problemi) prima leggeva il/i 
manuali e poi eventualmente chiedeva sul NG. 
Google non esisteva ma quando ha cominciato ad esistere, i newsgroups si 
sono rivelati una fonte importantissima di informazioni e di manualistica 
puntuale e precisa.
 
La tendenza del 2011, invece, è suddividere le persone in:
 
a) faccio domande stupide e dopo 2 minuti mi autorispondo da solo. Potrei 
mettere in piedi un blog ma non me ne fotte, inquino i NG.
 
b) faccio domande senza aver letto i manuali o la documentazione. Male 
non fa. Sono pigro, così faccio prima. Questi sono generatori di entropia.
 
c) io comunque rispondo, non ho letto tutto ma rispondo, un pò ad 
minchiam, in base al sentimento che nutro. 
 
RISULTATO:
 
i tizi a) inquinano il newsgroup e google e quando cerchi risposte, trovi 
rumenta
 
i tizi b) sono quelli che gli risolvi un problema oggi, copiano la 
soluzione e fra una settimana tornano a farti la stessa domanda. Sono 
pigri e stupidi.
 
i tizi c) questi sono quelli come te o come quell'altro furbo che voleva 
usare Rsync over FTP. Sono superficiali o incompetenti a seconda del tipo 
di risposte.
 
 
Il risultato di questa tendenza semplificante e superficializzante è che 
quando poi vai a cercare se rsync over FTP esiste trovi qualcuno che lo 
suggerisce e perdi giorni a capire come si fa.
 
 
Bisogna mettersi in testa che se non si legge un thread e se non si 
conosce la risposta, SI STA ZITTI.
 
Risposte del tipo "eh io ho risposto così perchè non avevo letto prima" 
vorrei che tu le avessi date al professore di storia "eh, ma io ero 
assente alla lezione". STICAZZI!
 
 
Se devi fornire un contributo lo fornisci corretto. 
Se devi sparare cazzate è bene lurkare.
 
 
Ebbasta, ho a che fare con scarpari tutto il giorno.
Almeno it.comp.os.linux.sys ripristiniamolo a certi livelli di 
competenza, non assimiliamo tutto al forum di aiuto di ubuntu.
 

 consente di criptare e firmare i Backup con GPG.
 
Fai in modo di piallare tutti i dati in LORO possesso perchè il loro 
backup contiene anche le TUE chiavi private e le tue password.

 prima"
 
Va bene, non capisci e/o non sai leggere.
In compenso hai parecchio tempo da perdere e vomiti in pubblico.
Fatti vedere da uno bravo.
 
-- 
Vincenzo


Capisco che il messaggio ti è arrivato.
 

 che quando poi vai a cercare se rsync over FTP esiste
 
...rischi di trovare cose tipo
http://www.rainbowbreeze.it/backup-via-ftp-con-rsync-e-curlftpfs/
 
 
Per il resto, pur condividendo alcuni punti del tuo post, credo che
il dare dell'incompetente / superficiale / stupido / cretino a chiunque
da' semplicemente l'idea che ci si sta ponendo su un piedistallo.


 semplicemente l'idea che ci si sta ponendo su un piedistallo.
 
No o meglio ni.
Me ne scuso ma mi sarei anche stufato di leggere castronerie.

 tar.
 
Eh, magari :)
A seconda della distribuzione (e quindi agli scazzi del mantainer), tar puo` 
non supportare ACL e xattrs, facendo perdere quindi queste informazioni per 
strada (giusto per fare nomi, in Debian e` cosi`: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254615
 ), senza contare che 
tar e` un sistema locale, ovvero non mi permette di centralizzare i backup 
su di un server se non dopo aver scritto una mole di script
 
Enrico

 E quindi non saprei come rimettere a posto gli utenti...
 
Posso immaginare un backup in 2 fasi: crei i tgz delle directory di cui
vuoi fare il backup e poi trasferisci i tgz con il loro script 
 
Jey
-- 
Non prendere la vita troppo sul serio... non ne uscirai mai vivo
http://www.joram.it/servizi/consulente.htm