Come è possibile "hacking" anche se "difendo" correttamente?

Non ci si assicura che tutti gli aggiornamenti di sicurezza siano applicati? Ricorda che, come difensore, devi vincere il 100% delle volte . Un hacker ha solo bisogno di vincere una volta.

I passaggi che hai elencato sono anche molto più facili a dirsi che a farsi (tranne la password ... eppure le persone scelgono ancora password orribili!).

2) Inoltre, qual è una "fonte credibile" per un server Web pubblico? L'intera Internet? L'intera Internet, senza Cina / Russia (/ alcuni / altri / paesi)? I sistemi automatizzati sono in grado di rilevare molti tipi di attacchi, ma proprio come gli antivirus possono solo andare così lontano.

3) Il monitoraggio dei file locali è buono, ma, ancora una volta, non è una panacea. Cosa succede se l'hacker riesce a iniettare il codice nel server web, e quindi usa un bug del kernel per ottenere il codice nel kernel ... senza mai scrivere un file sul disco? A quel punto, potrebbero scrivere file sul disco e usare un root kit per impedire la maggior parte (teoricamente tutti ) delle scansioni online dal notare eventuali modifiche al sistema.

E anche se riescono a sfruttare solo il server web, possono fare tutto ciò che il server web può fare (il che potrebbe essere comunque l'interesse di tutti gli aggressori).

4) Dovresti sempre convalidare l'input dell'utente. La maggior parte degli sviluppatori lo sa (e molti provano a farlo). Purtroppo, è molto più facile a dirsi che a farsi, ed è per questo che continuiamo a vedere un problema dopo l'altro in cui l'input dell'utente non è adeguatamente convalidato. mai essere in grado di garantire che qualsiasi vero software sia correttamente che convalida tutti gli input dell'utente. Leggi alcune domande PHP + MySQL su StackOverflow per vedere quante persone pensano che mysqli_real_escape_string() prevenga tutti gli attacchi SQL injection ( "where ID = " . $val è vulnerabile, anche quando $val è l'output di mysqli_real_escape_string !).

Anche se tu potessi (non puoi) assicurarti che ogni vettore di attacco conosciuto fosse sorvegliato, non puoi fare nulla di più che oscillare selvaggiamente nel buio contro e sconosciuto-sconosciuto (beh, educare te stesso continuamente aiuta).

Come esempio in cui le tue difese non avrebbero fatto nulla, stavo prendendo parte a un corso sulla sicurezza dove stiamo facendo "giochi di guerra". Sono stato in grado di sradicare il server di una squadra avversaria essendo in grado di ottenere una delle loro password utente su un'altra macchina (una di esse si è rovinata e digitata in bash come comando per errore, e non hanno mai pensato per cancellarlo da .bash_history ).

Da lì, ho spoofed l'IP della macchina da cui hanno effettuato l'accesso e SSHed in, inserendo il loro nome utente + password. Ho avuto accesso limitato al sistema. Ho quindi eseguito sudo vim , ho inserito di nuovo la stessa password e ho creato una shell bash. Tada! Accesso root, da una fonte credibile, senza modificare alcun file locale in modo insolito, senza sfruttare una password debole (è stato male, ma anche la migliore password del mondo non avrebbe aiutato), né fare affidamento sull'input dell'utente non convalidato.

A quel punto, essendo malizioso, ho modificato manualmente tutti i file di registro relativi al mio accesso legittimo e ho cancellato il loro IDS (scommetto che non saranno abbastanza osservanti da notare che ho sostituito tutti i suoi binari con copie di /bin/true !). Un hacker "reale" sarebbe probabilmente molto meglio equipaggiato per garantire che la loro attività non venisse rilevata da amministratori più vigili, ma avevo già raggiunto il mio obiettivo, e una piccola parte di me voleva che scoprissero che qualcuno l'ha preso.

Se potessi manipolare la legge di Schneier:

Anyone, from the most clueless amateur to the best systems administrator, can create a security system that he himself can't crack.

In breve, per difendere correttamente non è un compito facile perché ...

Faiunarapidapugnalataaituoiinput->

Makeadminaccountpasswordlong...

Lasemplicenavigazioneconlespallesconfiggeognisforzoconpasswordsicure.
Inoltre,seimeccanismidiarchiviazionedellapasswordsonodeboli(inclinealleiniezioniSQL,ameccanismidihashinginsicurio,peggio,all'archiviazionedipasswordintestonormale),rimanivulnerabile.

Monitoreveryincomingnetworktraffic

Monitoreraiunsaccoditraffico.Qualèlagaranziachenontiperderaialcunecoseimportanti?Echediredi zero-day ?
Che dire del traffico crittato? Che cosa controllerai su questo?

...and only allow credible sources.

Che cosa succede se le tue fonti credibili vengono compromesse / violate? Quindi non sono più credibili ma tu, amministratore di sistema, non lo sai!

...monitor local file changes...Validate every user input...

Ancora, quanto puoi monitorare e quanti registri puoi analizzare ...

Inoltre, supponendo che ci siano almeno alcuni servizi in esecuzione sulla macchina, le vulnerabilità nel servizio potrebbero diventare la causa della compromissione della macchina.

Spero di poterti dare un'idea di come sia l'hacking fattibile:)

Ack: immagine presa da www.quotesparade.com

Se potessi difendere "correttamente", gli hacker non potrebbero mai entrare. Il problema è che cosa significa correttamente in questo tipo di situazione.

Potresti spegnere il server e sigillarlo in cemento a mezzo miglio sotto terra ed è abbastanza sicuro, giusto? Ma è inutilizzabile. E se il valore di ciò che è su di esso è abbastanza alto, un utente malintenzionato può provare a scavare. Quindi puoi già vedere da questo esempio estremo che la sicurezza è un equilibrio. Deve essere appropriato e consentire comunque l'utilizzo del server.

In questo caso, i problemi che troverai includono:

• come ci si assicura che tutti gli eseguibili siano sicuri? Di nuovo, non puoi. Puoi decidere quanti sforzi vuoi spendere per controllarli ed eseguire vari test, ma le basi di codice sono abbastanza grandi per la maggior parte delle applicazioni in cui si verificano errori accidentali.
• la tua opzione di sicurezza proposta rende il server inutilizzabile per il suo pubblico di destinazione? Scollegandolo dalla rete aumenterà la sicurezza, ma non piacerà ai tuoi utenti.
• conosci davvero tutti i possibili input che i tuoi utenti potrebbero voler utilizzare? Se è così, brillante - bianco elencali. Ma ricorda di aggiornare ogni volta che la tua applicazione viene aggiornata o ha nuove funzionalità. E controlla ogni volta che ottieni un nuovo utente. E prova che la lista bianca funzioni per fermare tutti gli input non approvati. E così via ...
Gli attacchi
• potrebbero non avere bisogno di alterare alcun file sul disco. Ad esempio, i file di monitoraggio non rilevano direttamente gli attacchi mirati al codice in memoria.
• l'aggiunta di controlli tecnici di sicurezza non tiene conto di attacchi sociali o fisici. Se un utente malintenzionato vuole davvero l'accesso a un server ben protetto, potrebbe ritenerlo utile bugging, registrare le sequenze di tasti per ottenere password ecc. Oppure potrebbe essere più facile insidiare un utente - forse sono meno consapevoli della sicurezza.
• ecc. ecc.

In parole semplici, puoi raggiungere un livello sicuro, a seconda del budget. Decidi quanto sei disposto a spendere in base a ciò che desideri proteggere. Accetta che ci sarà un rischio residuo.

Quindi pianifica qualcosa che non va, a un certo punto la tua sicurezza sarà rotta e dovrai sapere come rispondere. Per un semplice file server questo processo potrebbe semplicemente essere cancellato e reinstallato dal backup, ma per qualcosa di più complesso potrebbe essere necessario informare utenti, parti interessate, regolatori, ecc., Archiviare prove, fare copie forensi, ricostruire, riconfigurare o in qualche modo rimediare l'incidente ... e poi prendi le esperienze di apprendimento per rivalutare il tuo piano di sicurezza.

... e poi ... Ripeti tutto di nuovo. Rivaluta regolarmente la tua sicurezza e il tuo appetito di sicurezza, visto che è un mondo in rapida evoluzione là fuori!

Diciamo che hai un server web, che accetta un comando:

GET /helloworld.txt

E ciò restituisce, molto semplicemente, "Hello, World!"

Questa è la cosa più semplice del mondo da codificare, giusto? Supponendo che tu prenda l'input, controlla la stringa "GET /helloworld.txt", e fai la cosa giusta, poi ignora qualcos'altro, quali sono le possibilità per l'hacking? Nessuno?

OK. Quale dimensione è il tuo buffer di comando? 20 byte? Quanto basta per accettare quel comando? Cosa succede se qualcuno dà un comando che è più lungo di due byte? Cosa succede se danno un comando che è più di 2000 byte? Come si riceve effettivamente il comando? Cosa parla alla scheda di rete? Cosa decodifica il pacchetto? Cosa succede se i caratteri vengono inviati in due pacchetti, senza terminazione NUL tra byte?

In breve, anche questo "più semplice" dei programmi di rete, che non ha nemmeno bisogno dell'accesso tramite password, potrebbe avere MOLTI difetti di sicurezza.

Semplicemente, si tratta di complessità. Ogni volta che viene introdotta una variabile, il numero di vettori di attacco POSSIBILI aumenta esponenzialmente. Non tutti saranno vettori di attacco, ma potrebbero esserlo e quindi è necessario coprirli tutti, se intendi essere sicuri.

Questo è praticamente impossibile, senza un sistema completamente controllato, completamente collaudato, progettato per contratto e forse anche matematicamente provato. Per quanto ne so, non esiste un tale sistema. OpenBSD potrebbe avvicinarsi, ma dubito che sia tutto lì.

La risposta molto breve è: con la sicurezza, assumete sempre il peggio. È MOLTO più intelligente sapere che sei vulnerabile e agire in modo appropriato, rischiare il meno possibile, piuttosto che pensare di essere al sicuro semplicemente perché non riesci a pensare a un possibile vettore di attacco.

Se fai tutto e lo fai correttamente, puoi prevenire molti attacchi diversi. Sfortunatamente, l'hacking è molto più che un attacco / accesso diretto.

Una grande parte include il bypass della protezione, quindi un utente malintenzionato non deve conoscere la password. L'ingegneria sociale è un'altra grande parte. Le password non proteggono nulla, se sono conosciute dagli aggressori. Inoltre, ci sono più attacchi e obiettivi dannosi rispetto al semplice accesso al pannello di amministrazione. Se qualcuno non vuole che tu gestisca un webshop, perché ha il suo e vuole mantenere i suoi clienti (e tu stesso fuori dal mercato), come vuoi evitare un attacco DDoS, o semplicemente qualcuno che stacca la spina nel tuo server? camera? (La donna delle pulizie, che voleva solo rispolverare la scheda madre?;))

Inoltre, il monitoraggio non aiuta in realtà a impedire attacchi.

Esistono diversi tipi di sistemi di protezione, antisabotaggio, antimanomissione e antimanomissione. I sistemi resistenti alla manomissione vogliono rallentare gli attacchi (ad esempio le password lunghe). La risposta di manomissione indica se si verifica un attacco (ad esempio un allarme che si verifica quando l'IDS rileva alcune stringhe di SQL injection) e il sistema a prova di manomissione mostra come si sono verificati gli attacchi effettivi (ad esempio i file di registro)

Gli hacker tentano di violare o evitare questa protezione, e il tuo compito è di essere un passo avanti. Ovviamente questo è molto difficile, in quanto si possono a malapena conoscere eventuali falle di sicurezza nel software del server, che potrebbero consentire a un utente malintenzionato di accedere alle informazioni di root senza una password. Di solito gli aggressori trovano prima questo tipo di debolezze, ed è compito tuo prendersi cura del tuo sistema e rallentare i loro attacchi fino a quando il problema non viene risolto.

Make admin account password long and complicated enough (i.e. theoretically speaking, password cannot be cracked within reasonable time).

Incrinato dalla forza bruta? No. Cracked dall'ingegneria sociale? Sì. Se molte persone conoscono la password, non è troppo difficile ottenerla tramite l'ingegneria sociale. (ogni volta che più di una persona conosce la password, è possibile utilizzare la rappresentazione in modo efficace per ottenere la password). Se solo tu hai accesso, allora, ancora, l'accesso fisico può essere ottenuto tramite l'ingegneria sociale. È più difficile da gestire, però, e devi chiedertene se valga davvero la pena.

Monitor every incoming network traffic to the administrative files.

Questo non ti protegge da DDoS. E se vuoi proteggere da DDoS, ci saranno troppi falsi positivi di utenti che vengono bloccati ingiustamente.

Anche se la tua password è lunga, una botnet può irrompere. Se hai qualche tipo di restrizione sul numero di volte in cui puoi fallire un tentativo di password, allora possono bloccare tu .

Inoltre, i CAPTCHA non sono più così sicuri, ci sono molte entità che pagano per far sedere la gente tutto il giorno e risolvere i captcha.

To extend the layer of protection from #2 above, monitor local file changes (especially ones that have commands that require sudo privileges.

Non è possibile monitorare completamente tutte le modifiche ai file. Ci sono troppe informazioni. La maggior parte dei programmi fa molto casino con i file mentre vengono eseguiti. Come distinguere tra un aggiornamento del programma e un file dannoso?

Validate every user input, so that all of the user input are guaranteed to be safe.

Assicurati di fare questo lato server.

Infine, gli exploit zero day saranno always un problema. Se qualcuno trova una vulnerabilità di sicurezza nel framework che usi, allora sei affondato. Per evitare ciò, utilizzare strutture ampiamente utilizzate e sperare per il meglio.

Proteggere dall'hacking è come cercare di proteggere un bunker sottomarino pieno di sodio. Ci sono molti posti che ritieni debbano essere rattoppati. Puoi incollarli tutti. Ma questo non significa che tu sia al sicuro: basta una piccola perdita in un luogo che non hai ispezionato perché tutto si fermi.

"difendere correttamente" significa: "il mio codice non ha bug, nessuno degli strumenti che uso". Ma il software ha dei bug; l'hardware ha bug; nessuno sa come garantire l'inesistenza di bug in un software o hardware non banale (quelli che affermano il contrario sono deliranti o bugiardi o entrambi). Vedi questa precedente domanda per alcuni discussione.

Il modo pratico in cui si verificano gli attacchi è quando un utente malintenzionato scopre o impara un bug che può essere sfruttato a suo vantaggio e prima che il proprietario del sistema lo impari e lo risolva.

Dal tuo elenco:

• Una password amministratore grande, grassa, casuale e non gestibile va bene - purché la macchina su cui l'amministratore digita la sua password non sia infetta da alcuni malware keylogger.

• Il monitoraggio aiuta soprattutto l'analisi post mortem; non previene l'attacco, ma ti aiuta a determinare cosa è successo, quale bug è stato sfruttato, in modo che possa essere riparato ... per la prossima volta.

• Non esiste un "input utente sicuro garantito". C'è "input dell'utente che è stato verificato per conformarsi a una serie specifica di regole, il che dovrebbe significare che il suddetto input dell'utente può essere usato in una data costruzione senza incontrare situazioni sconvenienti". Ad esempio, una parte di testo può essere "sicura per l'inclusione in un file HTML" (non contiene alcuni caratteri speciali HTML che attivano l'elaborazione avanzata, come "<" e "&"), ma non è sicura tutto per l'inclusione in una query SQL (i caratteri HTML-safe potrebbero codificare una query SQL totalmente non sicura).

Solo per aggiungere alcuni punti:

Make the admin account password long and complicated enough (i.e. theoretically speaking, password cannot be cracked within reasonable time).

Le password lunghe e complicate sono buone, aumentano le probabilità che vengano scritte. Lo stesso con le password che devono essere cambiate spesso. Soprattutto se più di una persona ha bisogno della password, o è una password che non viene usata spesso.

Monitor all incoming network traffic to the administrative files.

Gli attacchi di escalation di privilegi, lo renderanno inutile, poiché le modifiche sembreranno provenire dal traffico locale, non dalla rete. E troppo monitoraggio aprirà nuove questioni. Overflow del buffer Gli exploit sono comuni. Diamine, alcuni router di consumo ancora soffocano su tentativi di traffico in stallo che intasano le sue tabelle di connessione.

To extend the layer of protection from #2 above, monitor local file changes (especially ones that have commands that require sudo privileges).

Migliori, ma gli attacchi di escalation dei privilegi potrebbero consentire a qualcuno di caricare un file binario e aggiungere ad esso alcuni bit stick suid / sgid. Non sarà presente nell'elenco dei file da controllare.

Validate all user input, so that all of the user input is guaranteed to be safe.

Quanti sforzi ci metti in questo? La disinfezione dell'input dell'utente non è mai efficace al 100%.

Fondamentalmente, il punto è che alcune cose che farai causeranno più problemi che non farle, ci sono sempre dei modi per aggirarla, cerca solo di fare del tuo meglio e spero che tu non faccia un errore da capoccia. Sii come un disinfettante. Puoi solo uccidere il 99% del problema.

"È possibile non commettere errori e perdere ancora. Questa non è una debolezza, è la vita." - Picard

Non hai definito cosa significa per il tuo server essere violato.

Il primo passo è definire quale sia l'ambito dell'accesso legittimo al sistema. Chi sono gli utenti e cosa fornisce il sistema agli utenti che richiedono di essere protetti?

Se il sistema è dedicato a una funzione specifica e limitata (come quella di servire una determinata applicazione distribuita), e gli aggressori possono accedere a quel sistema solo attraverso la rete, quindi praticamente solo quell'applicazione deve essere protetta, più la rete parti esposte del sistema: l'adattatore LAN, il suo driver e lo stack di rete.

La vera sfida per la sicurezza in un sistema operativo come Linux è come rendere il sistema operativo inaccessibile in una situazione multiutente quando le persone hanno quasi pieno utilizzo del sistema, possono accedere agli account del sistema operativo ed eseguire direttamente le applicazioni. p>

Un sistema può avere incidenti di sicurezza senza che l'account superuser venga compromesso. Supponiamo che tu abbia un sistema Linux perfettamente irriconoscibile. Tuttavia, l'utente joe installa un'applicazione non sicura /home/joe/bin . Tale applicazione apre un documento dannoso, che sfrutta un difetto nell'applicazione, mediante il quale il codice dannoso ottiene l'esecuzione di codice arbitrario nel contesto di sicurezza di joe . Il codice dannoso danneggia i dati di joe e inoltre ruba il tempo della CPU dalla macchina. (Prova come potrebbe, però, non può ottenere i privilegi di esecuzione di superutente, perché la macchina è "disabile").

È hackerato? O non violato? Che ne dici dal punto di vista dell'utente joe . joe cura che root non sia mai stato compromesso nell'incidente?

Se le persone (o almeno i tuoi amministratori) non hanno mai commesso errori e i programmi per computer erano tutti al 100% senza errori, quindi in teoria hai ragione. Sfortunatamente, tuttavia, nessuno di questi è mai vero ed è abbastanza facile per un attaccante attaccare in questi punti.

Anche perfettamente configurato, il software non è in grado di agire come è configurato tutto il tempo a causa di bug. Nelle giuste condizioni, potrebbe essere possibile fare in modo che il software faccia qualcosa che non dovrebbe.

Allo stesso modo, l'ingegneria sociale è probabilmente la forma più comune di hacking. Non c'è bisogno di complesse misure tecniche quando puoi semplicemente ingannare il tuo avversario per darti quello che vuoi. Spingendo la password, ottenendo un key-logger su un computer che l'amministratore utilizza o ingannando un amministratore per eseguire il tuo software dannoso sono tutti modi possibili per sgattaiolare da sotto il radar.

Puoi compensare tutto questo bloccando un server in una stanza senza connessione a Internet e consentendo solo agli amministratori di utilizzare il sistema mentre si è nella stanza con una guardia alla porta, e infatti, questo è il numero elevato le reti governative di sicurezza funzionano, ma mette un enorme ostacolo all'usabilità.

In definitiva, la sicurezza consiste nel bilanciare usabilità e rischio. I passaggi da te indicati richiedono troppa riduzione dell'usabilità per essere implementati in modo sicuro e quindi non possono funzionare autonomamente in una situazione reale. La sicurezza è un campo complesso e in continua evoluzione che richiede di essere sempre aggiornato sulle minacce, controllare le difese contro nuove minacce ed essere sicuri di monitorare i compromessi che potrebbero verificarsi con problemi di 0 giorni.

Ho cercato di costruire sistemi antiproiettile per quasi dieci anni. Ho dovuto conoscere tecniche di progettazione ad alta sicurezza (ad es. EAL7), canali segreti, attacchi di sovversione, ecc. Onestamente, la maggior parte dei progettisti di sistemi o amministratori non ha né la conoscenza né le risorse per proteggere totalmente una macchina dagli attacchi noti. È quasi impossibile a causa di vincoli di business. La maggior parte delle decisioni di sicurezza riflette i compromessi tra costi, funzionalità, usabilità, compatibilità legacy, probabili profili degli aggressori, ecc.

Se vuoi sapere, ecco una delle mie interruzioni semplificate sui vari livelli e problemi di sicurezza. (E non è la dimensione di un libro 8). Era indirizzato a un tizio che pensava che i programmatori di prim'ordine potessero fare programmi sicuri, ma si può amministrare l'amministratore per coder e ottenere gli stessi risultati. Divertiti e impara le lezioni meno che ripeti la storia come fa gran parte della comunità INFOSEC. ;)

link

Questo commento di follow-up ha molti link che tracciano la cronologia, i fattori governativi, i requisiti di sviluppo, ecc. Elencho anche una tonnellata di sistemi e processi esemplificativi. Ognuno potrebbe avere dei difetti in agguato ma ispirare più fiducia del prodotto medio.

link

A system is only as strong as the weakest link

Questa è una frase ripetuta spesso e dovresti ricordare che non importa quanto sia strong una password: è un singolo punto di errore e un bruteforcer sarà in grado di sfondare a un certo punto.

Inoltre, cosa accadrebbe se il tuo sysadmin decidesse di accettare un pagamento abbastanza vantaggioso per cancellare accidentalmente un carico di file?

I tedeschi pensavano che l'enigma non fosse incrinato e si è sostenuto che la fiducia e la fiducia in questo unico metodo di crittografia li costasse la guerra: affidarsi a un singolo sistema o risorsa (umana o meno) è il peggior crimine possibile contro la sicurezza .

Ci sono alcuni aspetti umani che di solito non vengono presentati quando viene chiesto qualcosa di simile.

1. Alcune persone non hanno letteralmente niente di meglio da fare e tenteranno di hackerare il tuo sistema per pura noia.
2. Alcune persone lo fanno per divertimento (come alcuni cappelli bianchi). I cappelli bianchi di solito non sono male perché molti di loro ti contatteranno e diranno "amico, sono entrato nel tuo sistema" e non fare nulla di malvagio.
3. Alcune persone là fuori cercheranno di ottenere le password dei tuoi utenti per provarle su altri siti web, come quelli di carte di credito. Posano per ottenere un enorme profitto dal fare questo
4. Alcune persone attaccheranno un server per vendetta. "Jane Berman ha detto che sono un po 'testa? IL SUO SERVER ANDRÀ!"

Le persone specialmente in 2-4 tendono ad essere incredibilmente appassionate di entrare nel tuo sistema. A volte il # 1 diventa 2-4. Le aziende devono pagare qualcuno per proteggere un server, e ci vuole un sacco di soldi, ricerche e ore di lavoro per impedire a un esercito di questo tipo di persone di attaccarlo

Forse perché la maggior parte dei sistemi e dei software non sono al primo posto in termini di sicurezza. La sicurezza è meticolosa nell'insegnare, capire e anche essere aggiornata (notizie, nuovi vettori di attacco, ecc.).

Ecco perché non viene fatto interamente ed ampiamente insegnato. Ad esempio, non ci sono norme di sicurezza come le norme ISO. Anche perché è un potenziale mercato per la sicurezza domestica (antivirus).

Quando i computer saranno più comuni, forse un giorno diventerà qualcosa di cui si prenderà cura. Un futuro in cui esistono qualcosa come 100 o più computer per persona.

Se ci pensi davvero, non facciamo abbastanza affidamento sui computer per preoccuparci della sicurezza di Internet (almeno credo, o almeno le parti in cui è fondamentale prendersi cura di).