Security through stupidity

E cosi stamani sono ritornato in server farm, a parte il caos da "the day after tomorrow" per le strade, è andato tutto liscio, verificata la raggiungibilità anche da console chiudo tutto e vado in ufficio.

Mi metto quindi al lavoro per reimportare i backup, le impostazioni, le procedure, ecc ecc tutto questo per quasi tutta la giornata fino a quando non inizia il delirio post-pranzo, credo dovuto al caldo unito allo stomaco pieno.

Vedo cascare quindi una mail, nella mia inbox, del boss che molto eloquacemente mi quota una sua richiesta di ieri, come per dire "non mi hai più risposto". Io convinto di averlo fatto ieri stesso controllo e, si, avevo risposto;

From: me
To: Boss
CC: me(viva la doppie mail); altrocollega
Subject: Re: [Fwd: Re: Test Sito cliente in cluster su 4 macchine]

ti avevo risposto…mo te la rigiro

recupero la mail, rimando e mi rimetto al lavoro, dopo 5 minuti ecco il boss alla riscossa:

From: boss
To: me
Subject: Re: [Fwd: Re: Test Sito cliente in cluster su 4 macchine]
???

ma sta mail l’avevi già mandata o sbaglio?

"??!!"

Al che in tempo zero il mio collega risponde cercando di mettere in chiaro un paio di punti oscuri, e quindi decido che possono benissimo vedersela tra loro ed io posso continuare, nel frattempo noto che la discussione si evolve su alcuni stress test che si dovrebbero fare su tale cluster, allora aguzzo un occhio e cerco di seguire la discussione con più attenzione fino a che Boss non decide di pianificare per prima un piano d’azione e poi parlare con gli sviluppatori, e chiede che tipo di test fare:

From: me
To: Boss
CC: altrocollega, me (sempre per la storia delle doppie mail)
Subject: Re: [Fwd: Re: Test Sito cliente in cluster su 4 macchine]

ab a manetta da due/tre macchine in disuso e nessus/nikto dalle nostre
postazioni?

puntuale come le tasse nel frattempo arriva la mail dagli sviluppatori che dicono che i test sono ultimati, bla, bla, bugfix, ecc, ecc, rilasci, bla, bla, si va in produzione.

"Cosa dicevamo riguardo agli stress test??"

Boss: Io gli direi che il rilascio lo potremo fare lunedi mattina, però gli stress test li dobbiamo fare prima, e dovremmo quantificare anche il tempo di disservizio.

(Nel frattempo concludo i lavoro sulla macchina e annuncio al mondo il lieto evento…)

Rispondo dicendo che il disservizio sarà al massimo di pochi minuti, salvo disastri, che si deve fare questo, quello, cazzi e mazzi.

Ecco quindi la mail del Boss che ripete ciò che gli ho detto io tranne la faccenda degli stress test…

IO: Sbaglio o hai dimenticato la roba degli stress test?

Boss: No, l’ho fatto a posta, appena abbiamo uno schema lo proponiamo, e poi tanto è di collaudo quindi potremmo anche evitare di dirlo

IO: Ok domanda bomba: metti che si scassa tutto durante i test e non riusciamo ad entrare in produzione chi glielo dice poi ai gringos di là?

Boss: Ok allora fammi 1/2 paginetta spiegando la rava e la fava e poi ne parleremo con loro.

Nel frattempo parte un parallelo giro di mail, sempre su questo maledetto cluster, iniziato dagli sviluppatori che dicevano cosa si doveva fare e come prima della messa in produzione, tra le cose da fare c’era il rilascio di un bugfix.

Qui bisogna chiarire un paio di cose, attualmente il sito di cui si parla gira su una sola macchina, a causa di problemi vari, finalmente dopo un mese si sono decisi a fare i testi di collaudo del cluster ocfs su 4 macchine, durante questo mese però sulla macchina di produzione è spuntato un problema abbastanza anomalo: tutto ad un tratto la merdavigliosa applicazione java con cui è fatto il sito inizia a staccarsi dal database per motivi a noi sconosciuti, fino ad oggi abbiamo brillantemente risolto con un riavvio notturno dell’applicazione stessa, workaround che sembra tenere abbastanza tenacemente. Due giorni fa però ci è stato chiesto di modificare un opzione sul cluster di collaudo, per verificare che questo problema non si presenti più. Tale opzione non fa altro che alzare il timeout delle connessioni al db fino a 7 ore!!

Adesso si potrebbe aprire un dibattito sulla scelta di rilasciare un bugfix di livello critico su un cluster di macchine che sostanzialmente è in disuso, a parte quelle 4 visite quotidiane che ci facciamo noi, soprattutto conoscendo che mmitticco bugfix che è; però dato che era in programma l’entrata in produzione per ieri, si era deciso di rilasciare i bugfix direttamente in collaudo, dato che da li a breve sarebbe stato trasformato in produzione. Caso volle che lo switch ieri non fu fatto (che novità) e quindi si discuteva sul fatto che tale bugfix andava rilasciato anche nell’attuale unica macchina che sta servendo il sito.

Siccome conosco murphy, e siccome sono convinto che questo bugfix non risolverà una beneamata fava ho risposto dicendo che, se le cose funzionano, bisogna lasciarle cosi come sono, e concentrarci nel testare il più possibile e tutto quanto il possibile sull’attuale cluster di collaudo.

Parole al vento, gli sviluppatori hanno assicurato che questo bugfix è stato ampiamente certificato prima nell’ambiente di sviluppo (che altro non è che una misera macchina virtuale CentOS), e poi sull’ambiente di collaudo (che altri non è che il famoso cluster in disuso, e quindi non ha mai conosciuto stress da carico); morale della favola domani rilasceremo il bugfix nella macchina di produzione…speriamo che tenga.

La giornata volge al termine ed io inizio a sentire lo stress fare sempre più parte della storia, e puntualmente torna il boss con un altra richiesta:

Boss: ale?

IO: Eccolo

Boss: mi fai un piacere? dovresti farmi un archivio con tutte le pagine jsp del sito di altrocliente

IO: Momento…(ssh….ls…tar…scp) ecco lo trovi nella cartella condivisa

Boss: Thx

Passano dieci minuti…

Boss: ale?

IO: arieccolo

Boss: mi chiedono anche il dump del db del sito di altrocliente

IO: azz…ok

…scopri che il db è un fententissimo postgreslq di cui io non ricordo assolutamente come si usa….googlando trovo il comando

"Ok quindi pg_dump  -U utente nomedb > file….dunque….ssh….pg_dump -U…..eh  -U cosa??!!"

Si non mi ricordavo le credenziali…

IO: Senti ti ricordi le credenziali del db di sto catorcio?

Boss: No non le ricordo…ma cmq ci abbiamo lavorato un mese e mezzo fa su quel db

IO: Me ne rendo conto ma se non me le ricordo…non me le ricordo…

Boss: Vedi nei vari file del catorcio o chiedi a altrocollega l’aveva completata lui la migrazione

Salto la prima parte e vado dal collega direttamente (discorso non adatto ai deboli di cuore):

IO: chiedo umilmente perdono
IO: ma siccome hai completato tu
IO: forse sai
IO: ti ricordi mica dove recuperare utente e pass per psql?
IO: sempre per nomecliente
LUI: ossignur
LUI: boh
LUI: sul keeppassx non ci sono?
IO: £$%&%£ che palle
IO: tutte cose fatte con la punta del £$%$%&
LUI: tutte cose fatte adesso per ieri
LUI: adesso aspetta un secoindo che stavo facendo pulizia nella casella di velvet
LUI: e ho thunderbird piantato
LUI: che due £$%&

LUI: ma spè
LUI: controlla nei file di conf di quel cesso di tomcazz
LUI: che da qualche parte devono esserci scritte per forza
IO: infatti ho lanciato un fgrep assassino
LUI: lol
LUI: fermo il mio allora
IO: auahuah

Ok ravaniamo dentro quest’altra merdavigliosa applicazione java per scardinare il db, per motivi sempre a me oscuri dentro la cartella "conf" non c’è una beneamata mazza della configurazione del db, con l’ "fgrep" selvaggio le trovo però dentro una cartella "xml"

"Utile mettere una cartella conf e le configurazioni dentro un’ altra cartella che non centra un cazzo…forse l’hanno fatto per depistare le indagini…"

Con mia amara sorpresa scopro che le credenziali sono nomecliente/nomecliente (Scemo io che non ci ho pensato subito dovevo aspettarmelo), ed il DB si chiama, con molta fantasia, nomecliente;

 
IO: certo che però anche io sono un gran coglione
IO: si vede che non ce la faccio più
IO: secondo te quali potevano essere id e pass per nomecliente?
LUI: nomecliente/nomecliente?
IO: cos’altro se no…
LUI: auahuauaujajiajhuauhahuahaha
LUI: security through stupidity

 quindi mi lancio nel dump del db:

:~# pg_dump -U nomecliente nomeDB > dumpone.sql
:~#

"mmm perchè non mi da output??!!" 

chatto quindi il collega che mi sta accanto:

LUI: come fare il dump l’hai trovato?
IO: pg_dump
IO: ma non dumpa UNA STRACA$$O DI FAVA
IO: AAAAAAAAAAAAAAARRRRRRRRRRRGHHH
LUI: euuiua!
IO: ma ma….
IO: ma….
IO: non mi chiede la password
IO: …
LUI: e il dump è vuoto?
IO: no O_o
LUI: metti -W
LUI: dovrebbe chiedertela
IO: non cambia un $%&@
IO: security through stupidity
IO: o meglio
IO: me la chiede
IO: ma il risultato è uguale
LUI: prova senza pass e senza username
IO: LOL
LUI: vai vai
IO: pg_dump: fatal error: se striscia fulmina se svolazza l’ammazza!
IO: questo si che è un sistema sicuro
LUI: minchia davvero
LUI: i dati non sono recuperabili!
LUI: huahuah
IO: ti bucano la macchina e ti scardinano il db con una scorreggia

Alla fine della delicata discussione salvo il dump nella cartella condivisa e notifico il capo. Ritorno a cazzeggiare in attesa della fine della giornata…

Passa mezz’ora e skype mi si illumina è di nuovo Boss:

Boss: Ale?
IO: cosa c’è sta volta
Boss: senza che ti arrabbi…
Boss: ma l’amico tuo qui mi ha chiesto
Boss: se si potrebbe avere un altro archivio di tutta la document root del sito
IO: ….
IO: Si ma mi pare di avere a che fare con degli scimpanzè (Si ho scritto proprio cosi)
IO: chiederlo prima al posto delle jsp no eh?
Boss: Guarda non sto ad incollarti la discussione che c’è stata qui..
IO: Va beh momento…

…ssh…cd…ls….tar…scp..

IO: Indovina un pò dove ti ritroverai il pacchetto?
Boss: Grazie^3
IO: Prego

Guardo l’ora, 18:03…niente male per una giornata di normale routine, la mia Inbox sta chiedendo pietà…decido che è il caso che me ne vado a casa, saluto tutti e mi avvio…