Non so se infastidirvi ancora con la storia di Prism e dello spionaggio, ma visto che qui e’ campagna elettorale e la Merkel e’ sotto stress per questo (SPD e’ diventata la cavalleria della privacy, sfruttando anche il fatto che i tedeschi hanno un retaggio storico – La Stasi – che li terrorizza e produce pregiudizi verso i politici originari della Germania Est) , ma c’e’ una cosa che vorrei chiarire, ovvero il ruolo – quasi mai esaminato – degli amministratori di sistema.
Un amministratore di sistema – a meno che voi non criptiate la posta – e’ la persona piu’ indicata da corrompere per spiare una grossa corporation.
Prendiamo per esempio una classica installazione di Windows per ambienti corporate. Avere una batteria di server Exchange, che contengono anche la vostra mailbox, piu’ un controllore di dominio che decide quale sia il vostro DNS, a sua volta amministrato – insieme al server DHCP – dallo stesso controllore di dominio , e un server LDAP (i cui schemi vengono chiamati “Active Directory”) che controlla i vostri diritti di connessione per lettura e scrittura.
A seconda dell’implementazione, avete un agente che puo’ distribuire software sui vostri computer, in alcune configurazioni anche “svegliando” il PC durante la notte per eseguire l’installazione, usando alcune features di alcune schede di rete, di solito MII. L’agente puo’ distribuire sul vostro computer i certificati , il software, rimuovere software non desiderato, e quant’altro.
Inoltre vengono distribuiti i cosiddetti login scripts, che vengono eseguiti ogni volta che accendete il computer ed accedete al dominio. Tutta questa centralizzazione ovviamente giova ai costi, alle politiche di licenza (potete centralizzare la licenza e spostarla da un PC all’altro, come le floating licenses di FlexLM) , eccetera. Ma adesso potete chiedervi “quanto potere ha un amministratore di sistema, o un semplice operatore?”.
La risposta che ottengo quando pongo questa domanda e’ terrificante: “gli amministratori di sistema sono controllati e monitorati, quindi possono accedere ai vostri dati solo dietro un valido motivo”. Il “valido motivo” e’ un guasto, che sia documentato dall’apertura del ticket.
Lo schema normalmente seguito e’ il seguente:
- L’utente si accorge del problema. Chiama quindi il customer care o l’helpdesk.
- Il customer care apre un ticket indipendente, nel senso che se siete utenti VIP c’e’ un customer care apposito.
- Il ticket raggiunge gli operatori, che hanno accesso ai sistemi e riportano le condizioni operative precedenti.
- Il ticket viene chiuso, dopo che l’operatore ha descritto l’accaduto.
L’operatore , per fissare i problemi , occupa sullo schema ISO la posizione di supporto 3 o 4. Se e’ un operatore di supporto a livello 3 ISO, si occupa di configurazioni, reset dello stato dell’utente, ed eventuali analisi dei problemi di infrastruttura che portano il problema, la root cause analisys. Se il problema e’ un baco o generalmente puo’ essere risolto solo modificando il software, si passa al livello 4 ISO di supporto, che sviluppa la hotfix, la patch, quel che e’, che viene poi installata dagli operatori di livello 3 o, a seconda del tipo di patch, da quelli di livello 2.
Adesso, voi vi riterrete soddisfatti: siete nelle condizioni in cui OGNI accesso , diciamo alla vostra mailbox, DEVE essere giustificato con un ticket. Tutto questo e’ ottimo, ma avete dimenticato una cosa: che l’utente apre il ticket quando c’e’ un problema. Il succo e’: chi causa il problema?
Allora, vi spiego UN trucco con cui il BOFH spia la posta del manager. Non deve fare altro che causare un problema che prevenga il manager dal , diciamo, scaricare la sua posta. Chi si occupa dei sistemi ogni giorno avra’ di sicuro conoscenza di un problema che produce questo effetto. Se fate la manutenzione di un server che serve posta, sapete bene quali siano i problemi degli utenti.
Quindi, prima causate il problema. Fate in modo che ad eseguire la causa del problema sia un evento automatico, che so io schedulando l’esecuzione con cron, mentre siete a casa.
Diciamo che dieci minuti prima che siate in ufficio per iniziare il turno l’email del manager si blocca. Il manager apre subito un ticket, ed essendo il manager un VIP , il ticket e’ urgente ed arriva a voi. Siccome il collega cui date il cambio se ne sta andando, prendete voi il ticket. Fatto questo, accedete alla casella del manager per riprodurre il problema. A seconda dei vostri diritti , potete gia’ leggere la posta. Poi applicate la soluzione, e accedete di nuovo per vedere che funzioni. Se siete zelanti, simulate lo scaricamento da un computer di test che usate ad hoc. Seconda occasione per leggere la posta. E i computer di test, essendo macchine riconfigurate decine di volte al giorno per fare test, normalmente consentono quasi tutto, compresa la copia su file.
Morale: per entrare nella casella vi serve una scusa , cioe’ che il cliente vi apra il ticket. Ma l’utente apre il ticket quando c’e’ il problema. Ma chi puo’ risolvere problemi puo’ anche causarne. Rifacciamo allora la scala:
- Nasce un problema sul vostro account.
- L’utente si accorge del problema. Chiama quindi il customer care o l’helpdesk.
- Il customer care apre un ticket indipendente, nel senso che se siete utenti VIP c’e’ un customer care apposito.
- Il ticket raggiunge gli operatori, che hanno accesso ai sistemi e riportano le condizioni operative precedenti.
- Il ticket viene chiuso, dopo che l’operatore ha descritto l’accaduto.
Il punto 1 e’ il punto debole di tutta la catena di controllo. Il vostro sistema di controlli, che ritenevate infallibile perche’ richiede che si documenti la effettiva necessita’ di lavorare su un account, e’ debole perche’ chi interviene sull’account puo’ anche generare artificialmente la “effettiva necessita’”.
Se anche mandaste in tribunale il nostro operatore, lui vi direbbe: “ehi, e’ vero che ho scaricato la sua posta, ma c’era un ticket, il ticket #PRB002759372 , e’ tutto documentato. E nella risoluzione del ticket ho anche scritto che avevo testato la casella leggendo la posta. E’ il mio lavoro”.
Iniziate adesso ad intuire il problema: non solo il sysadmin o l’operatore sono corruttibili perche’ non guadagnano quanto un manager, ma spesso avete anche dato in outsourcing il settore operations, livelli 1 e 2 del livello di supporto ISO. Per applicativi legacy, addirittura 3 e 4.
Adesso vi racconto un’altra storia. In questi giorni ho richiesto un accesso ad un HLR , che mi serviva per sapere se un dato utente sia abilitato o meno agli SMS. Mi serve per impedire che sia usato se puo’ ricevere SMS. In definitiva, si tratta di un servizio di domotica da qualche parte nel mondo che permette di controllare una stufa di casa, che deve ricevere solo alcuni segnali da una precisa piattaforma. Se e’ abilitato in genere agli SMS NON consento (=il servizio che gestisco insieme alla mia squadra non consente) che la stufa sia integrata , dal momento che un malintenzionato potrebbe mandarvi a fuoco la casa. Solo una precisa chiamata ad un preciso APN dedicato e’ possibile. Ma siccome la stufa implementa GSM, e’ teoricamente sensibile ad SMS, e quindi per proteggerla controlliamo.
Detto questo, ho chiesto che ci consentissero di verificare che quella SIM dentro la stufa non consenta SMS. Niente di che.
Ci hanno dato accesso. Anche questo e’ ok. Ma ci hanno dato accesso in lettura per OGNI dato dell’ HLR: se voglio sapere dove si trovi un individuo di una certa nazione, devo solo fare una query cercando le celle, a patto di conoscere la sua utenza.
Alle mie proteste hanno risposto che il vendor dell’ HLR non ha implementato una feature capace di limitare l’accesso in lettura ad alcuni dati, e non intendono spendere tanto per chiedere al vendor una patch. Tuttavia, mi dicono, stanno consentento l’accesso solo alla mia associazione SCTP/IP, e solo in lettura. Che problema c’e’?
C’e’ il problema che qualcuno potrebbe corrompere ME. Ovviamente io sono un monaco kamikaze del Dio Onestus, quindi il deal non si fa. Ma ogni tanto in squadra mi si avvicendano consulenti junior. Uhm. Sono tutti seguaci della stessa chiesa?(1)
Adesso iniziate a intuire maggiormente il succo del problema. Sensato o meno, legale o meno, esiste un layer di accesso, consentito e/o impedito con procedure discutibili, che permette ad un gruppo di persone eterogeneo, culturalmente “idealista” per usare un eufemismo, ed esteticamente discutibile, di avere un potere gigantesco. Non esiste, su questo pianeta, un uomo politico la cui email non possa venire letta da ALMENO un sysadmin.
Certo, suppongo che il sysadmin che puo’ accedere alla email di Obama sia ultracertificato, un militare nato da una donna marines durante il bombardamento di Hanoi, che ha partorito mentre strangolava vietkong, nutrito a sandwitch di bandiere americane e napalm, che soffre di anemia perche’ i globuli rossi li ha uccisi sospettandoli di comunismo, e tutto quanto. Ma anche in questi casi c’e’ un piccolo problema.
Ho lavorato per infrastrutture con regole di accesso molto strette. Il guaio di queste regole e’ che piu’ sono strette e piu’ eccezioni si fanno.
Allora, quando Obama ha un problema sulla mail, lo dice ad un collaboratore cosi’ patriottico che al suo passaggio le bandiere americane si agitano anche senza vento. Uno che lo guardi e sa di aquila e smith&wesson. Il nostro cowboy prende la richiesta, e la porta di persona nell’ufficio apposito , pronto a morire per difendere la patria se dietro la felce si nascondesse un terrorista lesbocomunista islamico. Normalmente le felci della casa bianca sono controllate , per cui John DropTable(2) arriva sano e salvo nell’ufficio e consegna il ticket al sysadmin. Il Sysadmin esamina il ticket, controlla che non lo abbiano scritto o russinesi comunazisti , verifica l’integrita’ patriottica di John facendogli cantare l’ Inno americano di fronte ad un sensore di comunismo, e lo passa a Burt Kentucky, il vero sysadmin nonche’ campione di Lancio del Cubano Sgozzato.
Il quale ha dimenticato a casa il generatore di PIN #17 sui 26 che gli servono per accedere al sistema. Nel mondo reale, questo succede. Ma il presidente e’ in Cipango , ha bisogno della email per l’altro ieri, si incazzera’ come una pantera se non accede, e quindi si attiva per escalation la procedura numero #8943, ovvero cosa fare se un operatore di livello BaldMaverick non riesce ad accedere al sistema coi diritti di PBSFP ( PeaceBySuperiorFirePower)(3). Si fa una escalation e un generale con piu’ stelle di Messier31 autorizza che Burt Kentucky potra’ entrare nel sistema anche se ha dimenticato il PIN numero 17.
Adesso, torniamo nel mondo reale. Consideriamo un numero di operatori attorno al migliaio. Considerate un centinaio di procedure, due centinaia di escalation (una per aprire la procedura ed una per chiuderla) , e una quantita’ di problemi da mondo reale moltiplicati per il numero di operatori. Sapete cosa succedera’ al vostro sistema? Che lavorera’ al 100% del tempo con qualche eccezione alla regola in corso.
I militari lo chiamano “problema della guardiola davanti al cesso”. Mettete il cesso della caserma fuori da una guardiola, chiedendo alla guardiola di controllare chi entra ed esce da una certa zona. Poiche’ il cesso produce una quantita’ enorme di casi di “fretta urgente” nell’uscire, la guardiola iniziera’ a gestire eccezioni: gente che ha il sangue al naso e deve trovare un lavandino, e blablabla. Se sono commilitoni, in caso di urgenza li si lascia passare in fretta. Il numero di eccezioni cresce, sinche’ la guardiola diventa inutile.
Ho avuto a che fare con banche ed assicurazioni. Ho avuto a che fare con telco e con sistemi MIMD classificati dal ministero della difesa. Posso avere buone o cattive opinioni della sicurezza implementata, ma una cosa posso garantirvela: tutti, e ripeto tutti, e ripeto tutti i sistemi, anche quelli che considero i piu’ sicuri, hanno il problema del sysadmin. Non ho MAI visto UN SOLO sistema ove il sysadmin sia davvero impossibilitato a fare qualcosa o spiare qualcuno. In alcuni e’ ostacolato, certo, ma col tempo si producono eccezioni sempre piu’ giustificate e numerose per permettere al sysadmin di risolvere un problema piu’ o meno grave. E’ il problema della guardiola davanti al cesso: c’e’ sempre qualcuno col sangue al naso che deve passare subito e raggiungere il lavandino, anche se dovrebbe andare in infermeria, con tutto quel sangue si fa lo strappo alla regola.
A volte mi sorprendo a chiedermi che potere avrebbe una massoneria mondiale di Sysadmin. Immaginiamo di formare una massoneria cui si acceda solo dimostrando di avere i diritti di root, di Administrator, di enable, su sistemi con piu’ di 20.000 utenti. Quanto potente sarebbe una simile massoneria? Piu’ o meno, potrebbe farselo puppare dall’ NSA prima e dopo i pasti. Gli Illuminati sarebbero i loro camerieri. Il BildBerg club sarebbe la loro bocciofila. Userebbero il G8 come asilo nido per i figli.
Si tratterebbe di una massoneria strana, perche’ i sysadmin si dividono in due categorie, (Star Trek e Star Wars (4) ) , e questo rende piu’ interessanti i loro complotti. Cioe’, immaginate che esista un linguaggio iniziatico livello Jedi tipo “Noi Riuniti oggi siamo per la elezione di Putin decidere”(5) , e al livello superiore tutti usino il Klingon, e cosi’ via. E il cesso non e’ altro che un Tardis, cosi’ potete leggere il giornale e tornare alla riunione dopo cinque ore, pur essendo rimasti assenti 5 minuti. Se continuo a pensarci mettero’ su davvero il Grande Complotto di Root Enable Administrator, il REA. “Come la SPECTRE, ma noi usiamo TACACS e non LDAP”.
A questo punto mi direte che criptando tutto si risolve ogni problema. Aha. Ma se lo fate in una grande organizzazione, avrete bisogno di un sistema di key management. E il sistema di key management contiene server. E i server hanno bisogno di sysadmin. Siete punto a capo.
Insomma, dove voglio arrivare?
Sto cercando di spiegare che, sebbene esistano tecniche di gestione degli accessi, si parli di sicurezza euristica, si implementino sistemi di sicurezza sempre piu’ sofisticati, c’e’ un punto che non si riesce ad aggirare: il disperato bisogno di affidabilita’ dei sysadmin. Non avete modo, nessun modo, di aggirare una congiura dei sysadmin aziendali.
Qual’e’ quindi il requisito di sicurezza minimo per QUALSIASI sistema che vogliate rendere sicuro? Semplice: che i sysadmin siano pagati MOLTO bene.(6)
Se venite a sapere che la vostra telco o un qualsiasi ente che vi offra trasporto dati o servizi ha dato operations in outsourcing – per risparmiare -, potete essere CERTI sin da ora di essere spiati. Basta una ricerca su google alla ricerca di notizie su aziende che avviano piani di tagli.
Uriel
(1) btw uno dei miei colleghi e’ un ex ufficiale riservista dell’esercito israeliano , molto abile su HP-UX. AAArrrgh, israele controlla le vostre stufe! Il MOSSAD vi fa sudare! Il complotto ebraico dei piedi freddi! In realta’ e’ una bravissima persona, IMHO. Dovreste vedere come mi punta il fucile alla testa quando scrivo di lui in un post , davvero.
(2) Ogni volta che la polizia lo fermava e scriveva il suo nome nel sistema, andava tutto in malora. Accusato di portare sfiga ai sistemi IT, sviluppo’ sin da piccolo una passione per i computer. Sono storie.
(3) Gli statunitensi inventano acronimi di continuo. Del resto, vivono in U.S.A. : gli statunitensi hanno SEMPRE inventato acronimi.
(4) Vi aspettavate qualcosa tipo Unix e Windows, ingenui? In realta’ esiste anche la categoria Doctor Who, ma in genere lavorano su AS400. E hanno sangue alieno coi globuli verdi.
(5) Il modo di parlare di Yoda e’ semplicemente tedesco tradotto parola per parola. La grammatica e’ identica.
(6) Penserete che io stia parlando “pro domo mea”. Assolutamente no: sono del tutto disinteressato, e le due signorine in topless che mi fanno aria con un ventaglio sono parte della strategia “green” dell’azienda: i condizionatori d’aria consumano energia. Sul serio.
