Suggerimenti per assumere con garbo un server di produzione (UNIX)

Dopo mesi di abbandono, fiamme via e-mail e battaglie di gestione, il nostro attuale amministratore di sistema è stato licenziato e mi ha consegnato "le credenziali del server". Tali credenziali consistono in una password di root e nient'altro: nessuna procedura, nessuna documentazione, nessun suggerimento, niente.

La mia domanda è: supponendo che abbia lasciato boobytraps, come posso assumere con garbo i server con il minor tempo di inattività possibile?

Ecco i dettagli:

• un server di produzione situato in una server farm nel seminterrato; ubuntu server 9.x probabilmente, con patch grsec (voci che ho sentito l'ultima volta che ho chiesto all'amministratore)
• un server interno che contiene tutta la documentazione interna, il repository di file, i wiki, ecc. Ancora una volta, il server Ubuntu, di pochi anni.

Supponiamo che entrambi i server siano aggiornati e aggiornati, quindi preferirei non tentare di introdurmi a meno che non ci sia una buona ragione (vale a dire che può essere spiegata al top management).

Il server di produzione ha alcuni siti Web ospitati (standard apache-php-mysql), un server LDAP, una suite / server di posta elettronica ZIMBRA e, per quanto ne so, alcune workstation VMware in esecuzione. Non ho idea di cosa stia succedendo lì dentro. Probabilmente uno è il master LDAP, ma questa è un'ipotesi selvaggia.

Il server interno ha un wiki / cms interno, uno slave LDAP che replica le credenziali dal server di produzione, alcune altre stazioni di lavoro VMware e backup in esecuzione.

Potrei semplicemente andare all'amministratore della server farm, puntare sul server, dire loro ' sudochiudi quel server per favore', accedere in modalità utente singolo e fare a modo mio. Lo stesso per il server interno. Tuttavia, ciò significherebbe tempi di inattività, sconvolgimenti della direzione superiore, il vecchio amministratore di sistema mi ha risposto dicendo "Vedi? non puoi fare il mio lavoro 'e altri fastidi, e soprattutto dovrei perdere potenzialmente qualche settimana di tempo non retribuito.

Dall'altra parte dello spettro ho potuto semplicemente accedere come root e pollici attraverso il server per cercare di capire cosa stava succedendo. Con tutti i rischi di innescare sorprese lasciate alle spalle.

Sto cercando una soluzione nel mezzo: cercare di mantenere tutto in esecuzione così com'è, mentre capisco cosa sta succedendo e come, e soprattutto evitando di innescare eventuali trappole esplosive lasciate indietro .

Quali sono i tuoi suggerimenti?

Finora ho pensato di "esercitarmi" con il server interno, disconnettere la rete, riavviare con un cd live, scaricare il file system di root in un'unità USB e caricarlo su una macchina virtuale isolata e disconnessa per comprendere l'ex modo sysadmin di pensare (a-la 'conosci il tuo nemico'). Potrebbe fare la stessa impresa con il server di produzione, ma un dump completo lo farebbe notare a qualcuno. Forse posso semplicemente accedere come root, controllare crontab, controllare il .profile per tutti i comandi che sono stati lanciati, scaricare il lastlog e tutto ciò che mi viene in mente.

Ed è per questo che sono qui. Qualsiasi suggerimento, non importa quanto piccolo, sarebbe molto apprezzato.

Anche il tempo è un problema: potrebbero esserci fattori scatenanti in poche ore o poche settimane. Sembra uno di quei brutti film di Hollywood, vero?

Come altri hanno già detto, sembra una situazione a piede libero.

(A partire dalla fine)

• Distribuzione completamente nuova

Ovviamente non puoi semplicemente smontare i server e lasciare che l'installer faccia la magia.

Processo generale

• Ottieni budget per un server di backup (backup come in memoria per i dati)
• creare istantanee dei dati e posizionarli lì prima di fare qualsiasi cosa
• Ottieni l'approvazione dalla direzione!
• Raccogliere un elenco di requisiti (è necessario il wiki, chi utilizza le istanze VMWare, ...)
  • Dalla direzione e
  • Dagli utenti
• Ottieni l'approvazione dalla direzione!
• Chiudi i servizi non elencati per una settimana (un servizio alla volta - iptables potrebbe essere tuo amico se vuoi semplicemente chiudere i servizi esterni ma sospetti che possa ancora essere utilizzato da un'applicazione sullo stesso host)
  • Nessuna reazione? -> backup finale, rimuovere dal server
  • Reazione? -> Parla con gli utenti del servizio
  • Raccogli nuovi requisiti e Geet approvati dalla direzione!
• tutti i servizi non elencati in giù per un mese e nessuna reazione? -> rm -rf $service(suona duro ma ciò che intendo è smantellare il servizio)
• ottenere il budget per un server di riserva
• migrare un servizio alla volta al ricambio
• farlo firmare dalla direzione!
• spegnere il server migrato (spegnere)
• scopri altre persone che ti urlano -> yay, hai appena trovato gli avanzi
• raccogliere nuovi requisiti
• riavviare e migrare i servizi
• ripeti gli ultimi 4 passaggi fino a quando non ci sono persone che ti seguono per un mese
• ridistribuire il server (e farlo firmare dalla direzione!)
• risciacquare e ripetere l'intero processo.
  • il server ridistribuito è il tuo nuovo ricambio

Cosa hai guadagnato?

• Inventario di tutti i servizi (per te e la direzione)
• Documentazione (dopo tutto è necessario scrivere qualcosa per la gestione, perché non farlo correttamente e creare qualcosa per te e la gestione)

Ci sono stato, non è affatto divertente :(

Perché hai bisogno di farlo firmare dalla direzione ?

• Rendi visibili i problemi
• Assicurati di non essere licenziato
• Opportunità per spiegare i rischi
  • Va bene se non vogliono che tu lo faccia, ma dopo tutto è la loro decisione da prendere dopo che hanno avuto abbastanza input per giudicare se vale la pena investire.

Oh, e presenta loro il piano generale prima di iniziare , con alcune stime su cosa accadrà nel caso peggiore e migliore.

Si avrà un costo di un sacco di tempo a prescindere dalla ridistribuzione, se non si dispone di documentazione. Non c'è bisogno di pensare alle backdoor, IMHO se non si dispone di documentazione, una migrazione continua è l'unico modo per raggiungere uno stato sano che fornirà valore per l'azienda.

Hai motivo di credere che l'amministratore precedente abbia lasciato qualcosa di brutto alle spalle o guardi solo molti film?

Non sto chiedendo di essere faceto, sto cercando di farmi un'idea del tipo di minaccia che pensi ci sia e di quanto sia probabile. Se pensi che le possibilità che ci sia davvero una sorta di problema seriamente distruttivo, suggerisco di trattarlo come se si trattasse di un'intrusione di rete riuscita .

In ogni caso, i tuoi capi non vogliono interrompere i tempi di inattività mentre ti occupi di questo: qual è il loro atteggiamento nei confronti dei tempi di inattività pianificati per riordinare i sistemi rispetto ai tempi di inattività non pianificati se c'è un guasto nel sistema (che si tratti di un guasto reale o di un rogue admin) e se il loro atteggiamento è realistico rispetto alla tua valutazione della probabilità che tu abbia davvero un problema qui.

Qualunque cosa tu faccia, considera quanto segue:

Prendete l'immagine dei sistemi di r ight ora . Prima di fare qualsiasi altra cosa. In effetti, prendine due e mettine uno da parte e non toccarlo di nuovo fino a quando non sai cosa sta succedendo nel tuo sistema, questo è il tuo record di come era il sistema quando lo hai preso in consegna.

Ripristina il "secondo" set di immagini su alcune macchine virtuali e usale per sondare cosa sta succedendo. Se sei preoccupato che le cose vengano attivate dopo una certa data, imposta la data in avanti di circa un anno nella macchina virtuale.

Prima di tutto, se hai intenzione di investire tempo extra in questo ti consiglio di essere effettivamente pagato per questo. Sembra che tu abbia accettato gli straordinari non retribuiti come un fatto, a giudicare dalle tue parole - non dovrebbe essere così, secondo me, e specialmente non quando sei così pizzicato a causa di qualcun altro (sia esso la gestione, il vecchio amministratore di sistema o probabilmente una combinazione di entrambi).

Abbassa i server e avvia in modalità utente singolo (init = / bin / sh o 1 su grub) per verificare la presenza di comandi eseguiti sul login di root. Qui sono necessari tempi di inattività, chiarire al management che non c'è altra scelta se non i tempi di inattività se vogliono essere sicuri di riuscire a conservare i propri dati.

Successivamente, controlla tutti i cronjob, anche se sembrano legittimi. Esegui anche backup completi il ​​più presto possibile, anche se ciò significa tempi di inattività. Se lo desideri, puoi trasformare i tuoi backup completi in VM in esecuzione.

Quindi, se riesci a mettere le mani su nuovi server o VM capaci, migrerei i servizi in ambienti nuovi e puliti uno per uno. Puoi farlo in più fasi per ridurre al minimo i tempi di fermo percepiti. Acquisirai la necessaria conoscenza approfondita dei servizi ripristinando al contempo la fiducia nei sistemi di base.

Nel frattempo puoi controllare i rootkit usando gli strumenti come chkrootkit . Esegui nessus sui server per cercare falle di sicurezza che il vecchio amministratore potrebbe usare.

Modifica: immagino di non aver affrontato la parte "con grazia" della tua domanda nel miglior modo possibile. Il primo passo (andare in modalità utente singolo per verificare le trap di accesso) può essere probabilmente saltato: il vecchio sysadmin che ti dà la password di root e imposta il login per fare rm -rf /sarebbe praticamente lo stesso che eliminare tutti i file da solo, quindi c'è probabilmente non ha senso farlo. Come per la parte di backup: prova a utilizzare una rsyncsoluzione basata in modo da poter eseguire la maggior parte del backup iniziale online e ridurre al minimo i tempi di inattività.

Investirò tempo nell'apprendere quali app girano su quei server. Dopo aver saputo di cosa si tratta in qualsiasi momento è possibile installare un nuovo server. Nel caso in cui ritieni che possa trattarsi di una backdoor, sarà una buona idea avviare solo in modalità singola o avere un firewall tra i server e la rete esterna.

Stai diventando paranoico sulla sicurezza. Non è necessario diventare paranoici. (perché parli di trappole esplosive). Passare attraverso l'elenco dei software installati. Scopri quali sono i servizi in esecuzione (netstat, ps, ecc.), Vedi cron jobs. Disabilita l'account utente amministratore di sistema precedente senza eliminare l'account (facilmente eseguendo il puntamento della shell su nologin). Vedere attraverso i file di registro. Penso che con questi passaggi e dalla tua conoscenza delle esigenze dell'azienda da cui puoi indovinare l'uso dei server, penso che dovresti essere in grado di mantenerli senza grossi problemi.