Di recente (ma è anche una domanda ricorrente) abbiamo visto 3 thread interessanti su hacking e sicurezza:

Come gestisco un server compromesso? .
Individuazione della violazione di un server compromesso
Domanda sui permessi dei file

L'ultimo non è direttamente correlato, ma evidenzia quanto sia facile sbagliare con l'amministrazione di un server web.

Dato che ci sono diverse cose che possono essere fatte, prima che accada qualcosa di brutto, mi piacerebbe avere i tuoi suggerimenti in termini di buone pratiche per limitare gli effetti sul retro di un attacco e come accadrà nel caso triste.

Non si tratta solo di proteggere il server e il codice, ma anche di auditing, registrazione e contromisure.

Hai qualche elenco di buone pratiche o preferisci fare affidamento su software o su esperti che analizzano continuamente i tuoi server web (o niente)?

Se sì, puoi condividere la tua lista e le tue idee / opinioni?

AGGIORNARE

Ho ricevuto diversi feedback positivi e interessanti.

Mi piacerebbe avere un semplice elenco, in modo che possa essere utile per gli amministratori della sicurezza IT ma anche per i master Web factotum .

Anche se tutti hanno dato risposte valide e corrette, al momento preferisco quello di Robert in quanto è il più semplice, chiaro e conciso e quello di sysadmin1138 in quanto è il più completo e preciso.

Ma nessuno considera la prospettiva e la percezione dell'utente, penso che sia il primo da considerare.

Cosa penserà l'utente quando visiterà il mio sito compromesso, molto di più se possiedi dati sensibili su di loro. Non è solo una questione di dove archiviare i dati, ma come calmare gli utenti arrabbiati.

Che dire di dati, media, autorità e concorrenti?

Ci sono due grandi aree su cui concentrarsi:

1. Rendere difficile entrare.
2. Creazione di politiche e procedure per gestire con calma ed efficienza l'evento di qualcuno che passa al punto 1 passato.

Rendere difficile entrare

Questo è un argomento molto complesso, e gran parte si concentra sull'assicurarsi di avere abbastanza informazioni per capire che WTF è successo dopo il fatto. I punti elenco astratti per semplicità:

• Conserva i registri (vedi anche Gestione degli eventi delle informazioni di sicurezza)
  • Qualsiasi tentativo di autorizzazione, sia riuscito che fallito, preferibilmente con informazioni sulla fonte intatte.
  • Log di accesso al firewall (potrebbe essere necessario includere firewall per server, se in uso).
  • Log di accesso al server web
  • Log di autenticazione del server di database
  • Registri di utilizzo specifici dell'applicazione
  • Se possibile, il SIEM può lanciare avvisi su schemi sospetti.
• Applicare controlli di accesso adeguati
  • Assicurati che i diritti siano impostati correttamente ovunque, ed evita i "diritti pigri" ("oh, dai solo lettura a tutti") ove possibile.
  • Controlli periodici degli ACL per accertare che le procedure vengano effettivamente seguite e le fasi temporanee di risoluzione dei problemi ("dare a tutti la lettura, vedere se funziona allora") sono state rimosse correttamente al termine della risoluzione dei problemi.
  • Tutte le regole pass-through del firewall devono essere giustificate e controllate periodicamente.
  • Anche i controlli di accesso al server web devono essere controllati, sia ACL server web che file system ACL.
• Applicare la gestione del cambiamento
  • Qualsiasi modifica all'ambiente di sicurezza deve essere monitorata e rivista centralmente da più di una persona.
  • Le patch dovrebbero essere incluse in questo processo.
  • Avere una build del sistema operativo comune (modello) semplifica l'ambiente e semplifica il monitoraggio e l'applicazione delle modifiche.
• Disabilita gli account ospite.
• Assicurarsi che tutte le password non siano impostate sui valori predefiniti.
  • Le applicazioni standard possono configurare gli utenti con password predefinite. Cambiali.
  • Molte apparecchiature IT vengono fornite con coppie utente / password molto note. Cambia quelli, anche se accedi a quel coso solo una volta all'anno.
• Pratica il privilegio minimo. Offri agli utenti l'accesso di cui hanno effettivamente bisogno.
  • Per gli utenti amministratori, è consigliabile una configurazione a due account. Un account normale utilizzato per le attività di posta elettronica e altre attività d'ufficio e un secondo per il lavoro con privilegi elevati. Le macchine virtuali semplificano la vita.
  • NON incoraggiare l'uso regolare di account amministratore / root generici, è difficile tenere traccia di chi stava facendo cosa quando.

Creazione di politiche e procedure per gestire con calma ed efficienza l'evento di partecipazione di qualcuno

Una politica di eventi di sicurezza è un must per tutte le organizzazioni. Riduce notevolmente la fase di risposta "correre in giro con le nostre teste tagliate", poiché le persone tendono a diventare irrazionali di fronte a eventi come questi. Le intrusioni sono grandi affari spaventosi. La vergogna a subire un'intrusione può far sì che amministratori di sistema diversamente abili inizino a reagire in modo errato.

Tutti i livelli dell'organizzazione devono essere consapevoli delle politiche. Più grande è l'incidente, maggiore è la probabilità che il management superiore venga coinvolto in qualche modo, e aver impostato le procedure per gestire le cose contribuirà notevolmente a respingere "l'aiuto" dall'alto. Fornisce inoltre un livello di copertura per i tecnici direttamente coinvolti nella risposta agli incidenti, sotto forma di procedure per il middle management per interfacciarsi con il resto dell'organizzazione.

Idealmente, la tua politica di Disaster Recovery ha già definito per quanto tempo determinati servizi potrebbero non essere disponibili prima che la politica di DR entri in gioco. Ciò aiuterà la risposta agli incidenti, poiché questi tipi di eventi sono disastri. Se l'evento è di un tipo in cui NON verrà soddisfatta la finestra di ripristino (esempio: un sito DR di backup a caldo ottiene un feed in tempo reale di dati modificati e gli intrusi hanno eliminato un mucchio di dati che sono stati replicati sul sito DR prima che fossero Pertanto, dovranno essere utilizzate procedure di recupero del freddo), quindi i vertici dovranno essere coinvolti per i colloqui sulla valutazione del rischio.

Alcuni componenti di qualsiasi piano di risposta agli incidenti:

• Identificare i sistemi compromessi e i dati esposti.
• Stabilire in anticipo se è necessario conservare o meno le prove legali per eventuali procedimenti giudiziari.
  • Se le prove devono essere conservate , non toccare nulla di quel sistema a meno che non sia assolutamente necessario . Non accedere ad esso. Non setacciare i file di registro. Fare. Non. Toccare.
  • Se le prove devono essere conservate, i sistemi compromessi devono essere lasciati online ma disconnessi fino a quando un esperto di informatica forense certificato non sarà in grado di analizzare il sistema in modo compatibile con le regole di gestione delle prove.
    • Lo spegnimento di un sistema compromesso può contaminare i dati.
    • Se il sistema di archiviazione consente questo (dispositivo SAN discreto), eseguire l'istantanea dei LUN interessati prima della disconnessione e contrassegnarli di sola lettura.
  • Le regole di gestione delle prove sono complesse e oh così facili da rovinare. Non farlo a meno che tu non abbia ricevuto formazione su di essi. Gli amministratori di sistema più generali NON hanno questo tipo di addestramento.
  • Se vengono conservate prove, trattare la perdita del servizio come un disastro di perdita dell'hardware e avviare le procedure di ripristino con nuovo hardware.
• Regole predefinite per quali tipi di catastrofi richiedono quali tipi di preavviso. Le leggi e le normative variano in base alla località.
  • Le regole relative all '"esposizione" e al "comprovato compromesso" variano.
  • Le regole di notifica richiederanno il coinvolgimento del dipartimento Comunicazioni.
  • Se l'avviso richiesto è abbastanza grande, dovrà essere coinvolta la gestione di alto livello.
• Utilizzando i dati DR, determinare quanto tempo "WTF è appena trascorso" può essere impiegato prima che il servizio in linea diventi una priorità più alta.
  • I tempi di recupero del servizio possono richiedere il lavoro di capire cosa è successo essere subordinato. In tal caso, quindi prendere un'immagine dell'unità del dispositivo interessato per la dissezione dopo che i servizi sono stati ripristinati (questa non è una copia probatoria, è per i tecnici fare il reverse engineering).
  • Pianifica le attività di ripristino del servizio in modo da includere una ricostruzione completa del sistema interessato, non solo la pulizia del pasticcio.
  • In alcuni casi i tempi di ripristino del servizio sono abbastanza brevi che le immagini del disco devono essere acquisite immediatamente dopo aver identificato un compromesso e non devono essere conservate prove legali. Una volta ricostruito il servizio, può iniziare il lavoro per capire cosa è successo.
• Scorri i file di log per ottenere informazioni su come è arrivato l'attaccante e cosa potrebbe aver fatto una volta dentro.
• Scorri i file modificati per ottenere informazioni su come sono entrati e cosa hanno fatto una volta entrati.
• Scorri i registri del firewall per informazioni su da dove provengono, dove potrebbero aver inviato i dati e in che misura potrebbero essere stati inviati.

Avere politiche e procedure in atto prima di un compromesso, e ben noto alle persone che le attueranno in caso di compromesso, è qualcosa che deve solo fare. Fornisce a tutti un quadro di risposta in un momento in cui le persone non penseranno in modo corretto. La direzione superiore può tuonare e esplodere per azioni legali e accuse penali, ma in realtà riunire un caso è un processo costoso e sapere che in anticipo può aiutare a smorzare la furia.

Noto anche che questo tipo di eventi devono essere presi in considerazione nel piano generale di risposta alle catastrofi. È molto probabile che un compromesso scateni la politica di risposta "perdita dell'hardware" e anche la risposta "perdita di dati". Conoscere i tempi di recupero del servizio aiuta a stabilire le aspettative per quanto tempo il team di risposta alla sicurezza può avere per riversare il sistema effettivo compromesso (se non conservare prove legali) prima che sia necessario per il recupero del servizio.

Come possono essere d'aiuto le procedure adeguate di helpdesk

Dobbiamo considerare come vengono trattati i clienti qui (questo vale sia per i clienti interni che per quelli esterni che contattano un helpdesk).

Innanzitutto, la comunicazione è importante ; gli utenti saranno arrabbiati per l'interruzione dell'attività e potrebbero anche preoccuparsi dell'entità / conseguenze di eventuali violazioni delle informazioni che potrebbero aver avuto luogo nell'ambito di un'intrusione. Tenere informate queste persone aiuterà a gestire la loro rabbia e preoccupazione, sia dal punto di vista della condivisione della conoscenza sia dal punto di vista forse un po 'meno ovvio che una cosa che dovranno sentire è che hai il controllo della situazione.

L'helpdesk e la gestione IT devono fungere da "ombrello" a questo punto, proteggendo le persone che fanno il lavoro per determinare l'entità dell'intrusione e ripristinare i servizi da innumerevoli indagini che interrompono quel lavoro.

1. Prova e pubblica aggiornamenti realistici per i clienti e collabora con loro per determinare l'urgenza di riportare un servizio online. Essere consapevoli delle esigenze dei clienti è importante, ma allo stesso tempo non consentire loro di dettare un programma impraticabile per te.
2. Assicurati che il tuo team di helpdesk sappia quali informazioni possono o non possono essere divulgate e che non dovrebbero incoraggiare voci e speculazioni (e assolutamente non dovrebbero discutere di tutto ciò che potrebbe pregiudicare qualsiasi azione legale che la tua organizzazione potrebbe intraprendere o affrontare).
3. Una cosa positiva che l'helpdesk dovrebbe fare è registrare tutte le chiamate relative all'intrusione - questo può aiutare a misurare l'interruzione causata sia dall'intrusione stessa sia dai processi che ne sono seguiti. Mettere sia un tempo che un costo finanziario per l'intrusione e l'attenuazione può essere molto utile sia per affinare le strategie future, sia ovviamente potrebbe rivelarsi utile con qualsiasi azione legale. In questo caso può essere utile la registrazione degli incidenti ITIL e dei problemi : sia l'intrusione stessa che la mitigazione possono essere registrate come problemi separati e ogni chiamante tracciato come incidente di uno o entrambi i problemi.

Come possono aiutare gli standard di implementazione

Anche la distribuzione in un modello impostato (o almeno in un elenco di controllo) aiuta, oltre a esercitarsi nel controllo / gestione delle modifiche su eventuali personalizzazioni / aggiornamenti al modello di distribuzione. È possibile disporre di diversi modelli per tenere conto dei server che svolgono diversi lavori (ad esempio un modello di server di posta, un modello di server Web, ecc.).

Un modello dovrebbe funzionare sia per il sistema operativo che per le app e includere non solo la sicurezza ma tutte le impostazioni utilizzate e dovrebbe essere idealmente sottoposto a script (ad esempio un modello) anziché applicato manualmente (ad esempio un elenco di controllo) per eliminare il più possibile l'errore umano.

Questo aiuta in diversi modi:

• Consente di ripristinare / ricostruire più rapidamente nel caso in cui si verifichi un'intrusione (tenere presente che non è necessario distribuire da questo modello "così com'è" perché si sa che è vulnerabile, ma consente di tornare alla "ultima configurazione valida nota " che deve subire un ulteriore rafforzamento prima della distribuzione live ... e non dimenticare di aggiornare il modello di distribuzione una volta che sei sicuro che sia bloccato correttamente)
• Ti dà una "base" per confrontare un server compromesso
• Riduce gli errori non necessari che potrebbero portare a un'intrusione in primo luogo
• Aiuta con la gestione delle modifiche e delle patch perché quando diventa evidente che hai bisogno di una patch / aggiornamento o di una modifica procedurale per la sicurezza (o qualsiasi altra ragione per quella materia), rende più facile vedere quali sistemi hanno bisogno della modifica, rende più facile scrivere test per vedere se la modifica è stata applicata correttamente, ecc.).
• Se tutto è il più coerente possibile e sensato, aiuta a far sì che eventi insoliti e sospetti sporgano ulteriormente.

Per la maggior parte dei nostri server facciamo affidamento su firewall di rete e host, software antivirus / spyware, ID di rete e ID host per la maggior parte della nostra prevenzione. Questo insieme a tutte le linee guida generali come i privilegi minimi, i programmi non essenziali disinstallati, gli aggiornamenti, ecc. Da lì usiamo prodotti come Nagios, Cacti e una soluzione SIEM per vari rivestimenti di base e notifiche di eventi. Il nostro HIDS (OSSEC) esegue anche molti tipi di registrazione SIEM, il che è carino. Fondamentalmente proviamo a bloccare le cose il più possibile, ma poi registriamo a livello centrale, quindi se succede qualcosa possiamo analizzarlo e correlarlo.

Quello che vuoi davvero può cadere in 3 aree di base:

1. Configurazione di sistema standard
2. Monitoraggio sistema / applicazione
3. Risposta agli incidenti

Se hai a disposizione personale informativo (assicurazione | sicurezza), dovresti assolutamente parlare con loro. Mentre la risposta agli incidenti è spesso di esclusiva competenza di tale ufficio, il resto dovrebbe essere uno sforzo congiunto di sviluppo in tutte le parti interessate.

A rischio di auto-sfruttamento, questa risposta a una domanda correlata dovrebbe indicizzare molte risorse utili: Suggerimenti per la protezione di un server LAMP.

Idealmente, dovresti avere il minor numero di sistemi operativi supportati e crearne uno utilizzando un'immagine di base. È necessario deviare dalla base solo quanto è necessario per fornire qualsiasi servizio fornito dal server. Le deviazioni devono essere documentate o possono essere richieste se si devono soddisfare PCI / HIPAA / ecc. o altre conformità. L'utilizzo di sistemi di gestione della distribuzione e della configurazione può essere di grande aiuto in questo senso. Le specifiche dipenderanno molto dal tuo sistema operativo, calzolaio / burattino / Altiris / DeployStudio / SCCM, ecc.

Dovresti assolutamente eseguire una sorta di revisione periodica del registro. Data l'opzione, un SIEM può essere molto utile, ma ha anche il rovescio della medaglia sia nel prezzo di acquisto che nei costi di costruzione. Dai un'occhiata a questa domanda dal sito IT Security SE per alcuni commenti sull'analisi dei log: Come gestisci l'analisi dei log? Se questo è ancora troppo pesante, anche strumenti comuni come LogWatch possono fornire un buon contesto per quello che sta succedendo. Il pezzo importante, tuttavia, sta solo prendendo il tempo di esaminare i registri. Questo ti aiuterà a conoscere ciò che costituisce un comportamento normale, in modo da poter riconoscere anormale.

Oltre alla revisione del registro, è importante anche il monitoraggio dello stato del server. Sapere quando si verificano cambiamenti, pianificati o meno, è cruciale. L'utilizzo di uno strumento di monitoraggio locale come Tripwire può avvisare l'amministratore delle modifiche. Sfortunatamente, proprio come i SIEM e gli IDS hanno il rovescio della medaglia di essere costosi da mettere a punto e / o acquistare. Inoltre, senza una buona sintonizzazione, le soglie di avviso saranno così alte che tutti i messaggi validi andranno persi nel rumore e diventeranno inutili.

Una corretta Security Information and Event gestione politica (SIEM) al posto andrà un lungo modi per rendere la vita più facile di sicurezza.

Non sono un esperto di sicurezza, quindi mi rimando principalmente a loro; ma a partire dal principio del privilegio minimo quasi sempre il loro lavoro è notevolmente più semplice. Applicarlo come un salve di guarigione funziona bene per molti aspetti della sicurezza: permessi dei file, utenti di runtime, regole del firewall, ecc. Nemmeno KISS fa male.

La maggior parte della soluzione menzionata qui è applicabile a livello di host e di rete, ma spesso dimentichiamo applicazioni Web non sicure. Le applicazioni Web sono le falle di sicurezza più comuni. Tramite un'applicazione Web un utente malintenzionato può ottenere l'accesso al database o all'host. Nessun firewall, IDS, firewall può proteggerti da questi. OWASP mantiene un elenco delle 10 vulnerabilità più importanti e offre loro correzioni.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide