Domanda:
Quando un amministratore di sistema lascia, quali precauzioni extra devono essere prese?
Toby
2010-11-12 19:25:48 UTC
view on stackexchange narkive permalink

Se un utente lascia un'organizzazione che conosceva la maggior parte delle credenziali principali, esistono altre precauzioni da prendere oltre alla modifica di tali credenziali?

Ovviamente c'è anche l'utente standard che lascia cose come l'email / Accesso VPN revocato, indirizzi MAC dei loro dispositivi rimossi dalla nostra rete ecc. Ecc., Ma sono più preoccupato per utenti esperti o super.

Questa domanda era IT Domanda di sicurezza della settimana .
Leggi il post di blog del 19 agosto 2011 per ulteriori dettagli o invia la tua domanda della settimana.

Questa domanda riguarda una best practice per evitare questo problema in circostanze normali o stai chiedendo cosa fare ora che hai licenziato un amministratore che aveva accesso a tutto e sospetti che sia incazzato e attaccherà la tua azienda?
Come ha chiesto @Per, poiché esiste un'enorme differenza tra prima / prevenzione e dopo / controllo dei danni. Inoltre, è stato licenziato o se ne è andato da solo? Era generalmente degno di fiducia e vuoi solo andare sul sicuro, o presumi che proverà qualcosa di nefasto?
Era molto affidabile, sto parlando più delle migliori pratiche.
Questo aveva un'altra domanda fusa il 25 marzo 12 che menzionava un caso specifico, tuttavia le domande sono abbastanza simili che le risposte sono pertinenti, a patto che tu le legga in quel senso.
Ho aperto la stessa domanda, ma aggravato dal fatto che i lavoratori sono mobili, nel gruppo degli amministratori di Winfows, utilizzano laptop, alcuni non sono nemmeno dipendenti ma subappaltatori che hanno posti di lavoro in ufficio ma raramente sono presenti [Quali sono i possibili approcci e argomenti per garantire sistemi IT aziendali con la maggior parte dei computer portatili?] (http://security.stackexchange.com/questions/13092/what-are-possible-approaches-and-arguments-for-securing-corporate-it-systems-wit)
Un'azione molto importante, soprattutto se qualcuno deve essere licenziato, è revocare tutte le sue credenziali sensibili _prima_ di notificarlo che il loro rapporto di lavoro è stato risolto.Se la persona ha pianificato di rovinare la tua organizzazione per molto tempo, allora hai praticamente già perso.Questo ti consente solo di prevenire preventivamente il sabotaggio dell'ultimo minuto (che non è raro).
Otto risposte:
#1
+15
Per Wiklander
2010-11-12 20:13:51 UTC
view on stackexchange narkive permalink

Un amministratore non dovrebbe mai avere "credenziali di super utente" che non possono essere rimosse semplicemente rimuovendo il suo account utente o spostando l'account utente in un gruppo che non dispone dell'autorizzazione.

Un esempio: l'amministratore accede a un sistema Linux con il proprio account e utilizza sudo somecommand per fare cose che richiedono il permesso di root. Non si consente a questo utente amministratore di accedere effettivamente come root (e quindi conoscere una singola password di root che dovrebbe essere modificata). NON ESISTE UN ACCOUNT ROOT a cui accedere.

Penso che questo principio possa essere applicato anche ad altre credenziali di accesso.

Ovviamente funziona solo se tutti seguono effettivamente la politica prima di lascia il lavoro o viene licenziato (o viene trasferito in un'altra parte dell'azienda). Non protegge da un amministratore che viola volontariamente la norma e crea una porta di servizio per se stesso.

Un problema è che ha impostato molti dei sistemi.
Sì, ma li ha impostati secondo la politica? Questo è stato convalidato in qualche modo? In genere era degno di fiducia?
+1 per la prevenzione che vale più di mezzo chilo di cura.
spunti di riflessione: 'sudo su' e poi 'passwd'
@seedy: è una politica. Come tale, deve essere seguito. Proprio come una legge. È contro la legge uccidere le persone, ma è ancora possibile (e abbastanza facile).
#2
+10
Mark Davidson
2010-11-12 19:42:19 UTC
view on stackexchange narkive permalink

Dipende molto dal fatto che l'amministratore sia rimasto in buoni rapporti e dalla complessità della tua rete, ma alcuni buoni passi da compiere sono. Ho lavorato con un certo numero di organizzazioni che adottano alcuni di questi passaggi, ma nessuno di loro li prende tutti. Molti di loro revocano solo le credenziali dell'utente e adottano ulteriori misure solo se l'amministratore è andato in cattivi rapporti o stava andando a un concorrente.

  • Revoca le credenziali degli utenti su tutti i server dell'intera rete. Questo dovrebbe includere chiavi e password.
  • Se sono a conoscenza dei dettagli di root che non richiedono prima il login come un altro utente, allora anche questi dettagli dovrebbero essere modificati.
  • Anche altri dettagli dell'account come quelli relativi all'hosting del server dovrebbero essere modificati, poiché c'è sempre la possibilità che ne abbiano una copia o che possano ricordarli.
  • Se la tua rete è chiusa ma consenti il ​​traffico da determinati indirizzi IP come l'indirizzo di casa dell'amministratore, è importante assicurarsi che anche quelli vengano rimossi dall'accesso.
  • Se possibile, monitorare i tentativi di accesso da parte del nome utente che lasciano questo ti darebbe un avviso come il potenziale che stanno cercando di ottenere l'accesso ai tuoi sistemi.
Ottimi consigli qui, aggiungerei per rivedere TUTTI gli account utente (in particolare gli amministratori, ma non solo), vedere se ha impostato degli account orfani; Disattivare l'accesso remoto su macchine sensibili, o meglio ancora TUTTE le macchine; rivedere i registri di controllo di eventuali operazioni sensibili / amministrative che ha fatto, soprattutto nei mesi precedenti (e le prime impostazioni dei sistemi). ** HAI ** i log di controllo dell'amministratore, GIUSTO?
#3
+8
Lucas Kauffman
2012-03-25 03:21:44 UTC
view on stackexchange narkive permalink

Buona fortuna con quello. Normalmente ti assicuri che tutte queste cose siano state fatte prima di licenziare qualcuno. Se qualcuno è un po 'esperto, può diventare molto difficile, se non quasi impossibile vedere se non ha compromesso un sistema.

Se era l'unico dipendente, c'è non si può dire se ha delle backdoor sul posto. Quindi in questo momento potrebbe ancora avere accesso. Quando concedi a un amministratore di sistema l'accesso, guadagni la sua fiducia e devi assicurarti che anche lui sia affidabile.

Quindi le cose da controllare:

  • monitorare tutte le traffico in uscita
  • revoca tutto il suo accesso (dovrebbe essere fatto prima di licenziare qualcuno)

  • Documentazione

Dal mio punto di vista personale:

Sembra che tu non abbia esperienza con questo e può essere piuttosto pericoloso, dovresti rivolgerti a un consulente professionista. Almeno avrei parlato con il ragazzo e gli avrei chiesto cosa ha fatto. Ricorda che aveva accesso a tutto, può rompere qualsiasi cosa. Conosce la sua infrastruttura. Se fa qualcosa di dannoso, puoi iniziare da zero perché nessuno dei tuoi sistemi attuali può essere considerato attendibile.

Se non mi credi, dai un'occhiata a questi casi:

  • Il dipendente scontento di DHL elimina tutti gli ordini di 48 ore
  • Chevron - Sistema di emergenza è stato sabotato da un dipendente scontento in oltre 22 stati (USA 1992)
  • Terry Childs, che ha chiuso FiberWAN

Come ha dichiarato @Joel: La gente pensa che Jurassic Park riguarda i dinosauri che mangiano gente e merda, ma in realtà si tratta di ciò che accade quando non compensi il tuo amministratore di sistema in modo appropriato

aggiorna

L'azienda avrebbe dovuto dirgli che avrebbe assunto qualcuno in una posizione fissa un po 'più in anticipo. Quindi spiegagli che potrebbe ancora aiutare di tanto in tanto se qualcosa è andato storto. Inoltre dovresti avere un periodo di transizione più lungo. Se non sta collaborando, fondamentalmente hai lo scenario di Terry Childs. Quindi, oltre a perseguirlo, c'è poco che puoi fare.

Non era un impiegato. Era una società privata esterna indipendente che serviva l'infrastruttura IT (computer) della mia azienda. Quest'ultimo mi ha assunto costantemente in loco (come dipendente) per lo sviluppo / programmazione dei suoi sistemi contabili e inoltre per sostituirlo
Va bene, aggiornerò la mia risposta
Il top management è ostinato a sbarazzarsi completamente dei servizi del precedente amministratore di sistema esterno. In effetti, ha già causato un downtime di 1 giorno e questo non ha cambiato questo atteggiamento
Quindi è necessario intraprendere un'azione legale :)
Contro chi? Ha accettato la sua colpa ma poteva e può ancora farmi sembrare colpevole. Inoltre, capisco e sono più d'accordo con la logica dell'ex amministratore di sistema che con la leadership della mia azienda. Non ho intenzione di fare la guerra contro l'ex amministratore di sistema, è in una situazione sicura al 100% di dominare la situazione senza la necessità di negoziare.
allora sei fregato irreparabilmente temo: p
#4
+7
tylerl
2012-03-25 04:54:39 UTC
view on stackexchange narkive permalink

A beneficio di tutti gli altri che leggeranno questo articolo, questo è decisamente il momento sbagliato per pensarci.

Ora, ti sei messo in un posizione letteralmente impossibile; semplicemente non puoi dire con certezza che il tuo sistema non è compromesso. Inoltre, più è stato difficile il tuo amministratore di sistema o quanto tempo gli hai dato, più probabile è che avrà installato una sorta di backdoor. Come qualcuno che pulisce questo tipo di pasticcio per vivere, posso dirti che la percentuale di amministratori di sistema che lo fanno è inquietantemente alta e il pericolo è molto reale.

cosa fare ora , il fattore determinante principale è la quantità di tempo di inattività che puoi tollerare e la criticità del tuo sistema IT per la tua azienda. Idealmente, chiudi tutto e ricostruisci tutto da zero. Sì davvero. Sembra estremo, ma ora che ti sei messo in questo pasticcio, è l'unico modo per esserne sicuro. Nessun'altra soluzione funzionerà.

Se non te lo puoi permettere , o se pensi di poter tollerare un serio compromesso, puoi invece setacciare i sistemi uno per volta uno alla ricerca di processi di lunga durata, attività pianificate, token di autenticazione hardcoded, codice back-door di autenticazione, processi di gestione remota, VPN, registratori di tasti o altri strumenti di monitoraggio, qualsiasi altro componente non coerente con la tua politica di sicurezza.

E infine, se non te lo puoi permettere , puoi sempre chiudere gli occhi, coprirti la testa e sperare per il meglio.

Come prevenirlo in futuro

Ancora più importante, ecco alcuni suggerimenti per evitare che ciò accada di nuovo:

  • Avere più amministratori di sistema di primo livello . Le gerarchie sono facili da gestire, ma dannose per la sicurezza. Hai bisogno di qualcuno che possa "guardare l'osservatore"; qualcuno che ha l'abilità e l'autorità per controllare cosa sta facendo il tuo amministratore di sistema e chi può trovare queste backdoor. È molto meno probabile che un amministratore di sistema metta una backdoor se ha paura che qualcuno la trovi.

  • Preferisci l'onestà all'abilità quando assumi un amministratore di sistema . Hai bisogno di qualcuno di cui ti puoi fidare implicitamente, qualcuno che conosci non ti stenderà ad asciugare. Anche se non sono gli amministratori più abili, il loro ruolo principale è quello di essere responsabili delle tue difese: l'onestà conta più di tutte le altre qualifiche messe insieme.

  • Don t tollerare la superiorità condiscendente . Questo va di pari passo con il punto sopra, ma per aggiungere un po 'di chiarezza: non ci si può fidare che qualcuno che non rispetta gli altri agisca nel migliore degli interessi degli altri. A tale persona non dovrebbe essere consentito di lavorare nell'IT nella tua azienda.

  • Rendi felici i tuoi amministratori di sistema , qualunque cosa significhi per loro. Se non sono soddisfatti, risolvi il problema o trova qualcun altro e velocemente.

"allora puoi sempre chiudere gli occhi, coprirti la testa e sperare per il meglio." non dimenticare di chinarti e baciarti il ​​culo :-)
Non posso permettermi niente. Anche 1 min. i tempi di inattività si traducono in una tempesta di lamentele e insulti. C'è una carenza di spazio HD anche per l'attuale funzionamento, quindi non c'è possibilità di montare una nuova infrastruttura in parallelo. Inoltre, l'ex amministratore di sistema dispone ancora dell'accesso remoto dell'amministratore ai sistemi. Non esiste alcuna "politica di sicurezza" eccetto ciò che l'ex amministratore di sistema stava (e sta) facendo senza documentare.
Sono io il nuovo amministratore di sistema e non prendo alcuna decisione né ho influenza finale su di loro. L'errore principale dell'ex amministratore di sistema è stato quello di non rendere trasparente il volume del suo lavoro o di non registrarlo affatto. Gli veniva pagato un importo mensile fisso (che dipendeva dalla quantità di computer mantenuti). Quindi, il top management non riesce a capire perché dovrebbe raddoppiare o triplicare le spese se tutto ha funzionato a meraviglia con meno spese prima
Senza offesa qui ... ma sembri fottuto e stai cercando qualche deus ex machina per salvare la situazione. Ogni volta che qualcuno ti dà consigli su cosa dovrebbe essere fatto, sembra che tu stia contrastando con ragioni che semplicemente non è fattibile. O i tuoi datori di lavoro e tu devi stringere i denti, o continuerai ad essere in gravi difficoltà. Questo è tutto quello che c'è da fare, @WebMAOhist
@WebMAOhist concordato con Bart; puoi o (a) fingere di avere tutto sotto controllo e prendere il fuoco per i fallimenti in futuro, o incontrare mgmt e spiegargli tutto di fronte a loro - fagli conoscere la gravità della situazione e il costo per la riparazione e lascia che siano loro a prendere la decisione. Finché prendono una decisione consapevole e specifica, potrebbe essere più facile convivere con il risultato. Ma tieni presente che a volte scegliere l'insicurezza in cambio di costi iniziali inferiori sarà la decisione aziendale "appropriata" ai loro calcoli. Tutto si riduce a costi e probabilità.
#5
+6
this.josh
2011-08-08 12:39:22 UTC
view on stackexchange narkive permalink

che conosceva la maggior parte delle credenziali principali

Non sono esattamente certo del tuo significato, ma questo mi spaventa. Sembra che l'individuo avesse un ampio accesso e controllo su molti sistemi critici. L'amministratore di sistema potrebbe anche aver avuto il controllo esclusivo. Alcuni anni fa la città di San Francisco ha perso il controllo della sua rete perché un solo amministratore di sistema si è rifiutato di fornire le sue password ai suoi superiori. Quindi, molto prima che un amministratore di sistema lasci, dovresti assicurarti che ci siano almeno due persone che hanno accesso e controllo sui sistemi critici.

ci sono altre precauzioni che devono essere prese oltre a modificare quelle credenziali?

Revoca l'accesso fisico.

È probabilmente standard raccogliere badge e chiavi dell'ufficio, ma non dimenticare le chiavi degli armadietti, delle aree riservate, dei codici di allarme, dei depositi fuori sede, dei permessi di parcheggio, ecc. Dovresti tenere un registro di ogni chiave fisica fornita, chi le ha ricevute e perché. Inoltre, dovresti essere in grado di reimpostare i punti di accesso critici entro 24 ore. Se il tuo sistema di allarme consente a un utente di chiamare un falso allarme, assicurati che il dipendente uscente sia stato rimosso dall'elenco.

Fallo sapere a tutti.

Non è difficile per un ex amministratore di sistema ingegnere sociale di un dipendente attuale. È praticamente impossibile impedire loro di chiamare un dipendente attuale. Dato l'accesso alle informazioni interne, l'amministratore di sistema probabilmente sa chi chiamare e cosa dire per ottenere un qualche tipo di accesso alla rete. Quindi, annuncia che l'individuo non è più un dipendente. Se possibile mostra una foto (una foto del badge fa bene) dell'ex dipendente. Assicurati che sappiano con chi parlare se l'ex amministratore di sistema crea contatti sospetti. Se l'amministratore di sistema aveva uno stretto rapporto con fornitori, società partner o sussidiarie, informalo anche loro.

Non dimenticare il telefono e il sistema di posta vocale.

Le vulnerabilità qui vanno dallo spionaggio di messaggi vocali casuali all'effettuazione di chiamate interurbane a spese dell'azienda.

Carte di credito, account di addebito, ordini di acquisto

Se l'amministratore di sistema aveva l'autorità di ordinare apparecchiature, assicurarsi che la capacità venga revocata a tutti i fornitori, distributori, ecc. È banale ordinarne alcuni bella attrezzatura utilizzando la procedura standard e modificare l'indirizzo di spedizione.

Rivedere eventuali contratti e accordi firmati dall'ex dipendente.

Se l'amministratore di sistema ha firmato contratti o accordi come parte del proprio lavoro , chiedi a qualcuno di rivedere tutti i documenti che ha firmato. Idealmente dovresti avere un database di documenti che i dipendenti hanno firmato ed essere in grado di richiamare immediatamente ogni documento firmato da un determinato dipendente.

Controlla la patch e aggiorna lo stato dei tuoi sistemi critici.

Anche l'ex dipendente non ha agito come amministratore per quei sistemi, potrebbe sapere qual era il loro stato.

#6
+4
laughingman
2012-03-25 08:27:17 UTC
view on stackexchange narkive permalink

Dopo aver letto TUTTO quel + commento ...

Sei fottuto. Iniziare da zero. Rafforzare i sistemi, nuove chiavi / password, VLAN, VPN ...

Fondamentalmente, tutte le nove yard.

Vieni @ it dal punto di vista di un ex amministratore MOLTO scontento. Quindi, difenditi da quei vettori immaginabili. Lavorava in remoto, limitava tutti gli altri accessi remoti eccetto la tua VPN (con chiavi aggiornate).

È una routine di base per la quale la maggior parte delle aziende ha le procedure & scritte con largo anticipo. >

Spero che ce la farai, ma se sei venuto qui per tante informazioni su cosa fare, mi dispiace per l'azienda. :-(

Iniziare da zero non è un'opzione praticabile nel prossimo futuro perché i dipendenti usano laptop e alcuni lavoratori non sono nemmeno dipendenti ma subappaltatori indipendenti che e di cui vedo raramente i laptop. Inoltre c'è una mancanza di spazio su disco sui server anche per le operazioni correnti
#7
+4
Brad
2012-03-27 03:51:38 UTC
view on stackexchange narkive permalink

Ho avuto la sfortunata esperienza di quasi lo stesso problema. Ho perso diverse notti di sonno per questo, spero che questo ti aiuti.

Risposta breve: inizia dall'esterno se le tue applicazioni / operazioni interne consentono di cambiare gli indirizzi IP (se sai che attaccheranno) potrebbe essere un punto di svolta. Nel mio caso non ho potuto farlo poiché le applicazioni eseguite dai siti remoti stavano colpendo direttamente un IP esterno.

In secondo luogo ho disabilitato il WiFi dell'ufficio che lui (l'amministratore precedente) ha configurato. Ho fatto questo secondo poiché sapevo che sarei stato in grado di vederlo sulla proprietà se avesse tentato di accedere. Cerca anche di vedere quali segnali wireless vedi girovagare per cercare di eliminare la possibilità di un punto di accesso nascosto installato all'insaputa di nessuno.

La prossima cosa che ho fatto è stata controllare OGNI REGOLA nel mio firewall. Ho trovato alcuni IP statici (aircard e Internet via cavo) che erano "consentiti" e ho semplicemente negato l'accesso da qualsiasi luogo per cui non potevo verificare l'accesso necessario.

Successivamente ho esaminato ogni file di registro su ogni server cercare tentativi di accesso non riusciti. Se trovi qualcosa che lo documenti.

Quindi costringerei TUTTI GLI UTENTI a cambiare le loro password e imporre un criterio che non consente le parole da un dizionario come password. Ho dovuto convincere la direzione di questo, ma quando ho mostrato un attacco utilizzando un file di dizionario VS bruteforce e hanno approvato la modifica dell'azienda in quel momento.

Il prossimo (almeno nel mio caso) è stato il sistema telefonico. Cambia tutti i codici di accesso per tutti e costringili a usare qualcos'altro (o fallo per loro se si rifiutano di cambiare il PIN della segreteria)

La penultima cosa da fare sarebbe rilevare tutto il tuo traffico. Acquista o costruisci un rubinetto LAN economico (ho comprato un rubinetto lan stella da lancio) per circa $ 20 e lo metto tra il firewall e l'interruttore principale in cui entra tutto. Ho prestato particolare attenzione al traffico al di fuori dell'orario di lavoro. Questo dovrebbe aiutarti a identificare cosa succede sulla tua rete durante l'orario non lavorativo.

Infine, a seconda della situazione nel suo insieme (il tuo datore di lavoro li ha licenziati per risparmiare denaro?) Potresti dover dare loro (advin precedente) una chiamata a seconda della complessità della situazione. Ho scoperto chi era amico dell'amministratore precedente e sono diventato subito amico di loro, nel caso avessi bisogno di chiamare il vecchio amministratore per un favore (password per l'hosting web di un dominio separato che l'azienda ha acquistato come regalo per un'organizzazione no-profit gruppo) La società senza scopo di lucro per cui il vecchio amministratore aveva scritto un sito era ancora persa poiché non l'hanno pagato (amministratore precedente) per un altro anno per rinnovare il dominio, ma almeno ho riavuto il dominio per il non profit. / p>

Se l'amministratore precedente fa minacce verbali o addirittura scritte (stupide), conserva più copie di tutto. Puoi anche affermare che i problemi legali che potrebbero derivarne non valgono lo sforzo (cosa che non sono mai). Spero che questo ti aiuti un po '.

Grazie. Non sono sicuro a chi ti rivolgi come "loro" e "loro" in "(li hanno licenziati per risparmiare denaro?) Potresti doverli chiamare a seconda della complessità della situazione. Ho scoperto chi erano i loro amici e sono diventato subito amico di loro, nel caso avessi bisogno di chiamarli ". Puoi modificarlo in frasi più esplicite / descrittive?
#8
+2
Yoav Aner
2012-03-25 12:00:58 UTC
view on stackexchange narkive permalink

NOTA: questa risposta è stata migrata da un'altra domanda e quindi fusa in questa. Pertanto non si applica perfettamente a questa domanda (l'altra domanda descriveva una situazione in cui erano già stati commessi molti errori e l'accesso era ancora disponibile per un amministratore di sistema che avrebbe lasciato presto). Forse dovrebbe essere rimosso, ma ho lasciato una versione non modificata di seguito


Penso che le altre risposte (in particolare @tylerl, @lucaskauffman) siano assolutamente corrette, ma allo stesso tempo forse sono finite- allarmante.

Sì, non puoi sapere con certezza cosa potrebbe fare questo insoddisfatto amministratore di sistema. Tuttavia, ci vuole un po 'di malcontento per far entrare qualcuno nel sistema e causare danni. Questo tipo di azione è molto probabilmente sia in violazione del loro contratto di lavoro che in illegale (come se si fosse scoperti si può andare in prigione).

Da come la vedo io, il punto cruciale che altre risposte mancano, o trattano come un ripensamento, è come risolvere la causa principale o il rischio più elevato, che è quanto questa persona sia turbata potrebbe essere .

Penso quindi che la prima e migliore linea d'azione sia cercare di rendere questa persona la meno scontenta , possibilmente anche felice . Offri loro denaro extra per consegnare le cose, documentare ciò che stavano facendo e assicurarti che il successore abbia un lavoro facile. Offri anche un compenso extra in "standby" quando vengono pagati ma non devono svolgere alcun lavoro. Spiega perché per l'azienda ha senso che un dipendente interno svolga questo lavoro anziché un appaltatore esterno.

Allo stesso tempo chiarisci che sono le uniche persone in grado e che hanno pieno accesso a il sistema e, in caso di violazioni, sarà il principale sospettato e che non esiterà a segnalare e indagare anche il più piccolo incidente.

l'intero IT down e costruirlo da zero risolverà anche il problema, ma non vedo quanto sia realistica questa soluzione.

Bene, costruire l'intera struttura da zero non è un'opzione praticabile nel prossimo futuro perché i dipendenti usano laptop e alcuni lavoratori non sono nemmeno dipendenti ma subappaltatori indipendenti che e di cui raramente vedo i laptop
questo è esattamente il motivo per cui ho sentito che non è una soluzione realistica.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...