Domanda:
Quali lezioni sul Denial of Service possiamo imparare dall '"esperimento" egiziano?
nealmcb
2011-01-31 00:53:02 UTC
view on stackexchange narkive permalink

Il servizio Internet è stato ampiamente interrotto in Egitto a partire dal 27 gennaio alle 22:15 circa UTC, nello spazio di circa 20 minuti: How Egypt Killed the Internet. Il servizio è stato in gran parte ripristinato 5 giorni e mezzo dopo, il 2 febbraio, alle 9:30 UTC circa: Panoramica dell'attività di instradamento in Egitto - RIPE

Come descritto in Sul terreno in mezzo alle proteste degli egiziani Ha interrotto molto di più della semplice navigazione e messaggistica:

La manciata di fattorini che lavoravano allo Sheraton Hotel vicino all'aeroporto internazionale del Cairo ha dovuto affrettarsi da una stanza all'altra, usando le loro chiavi principali per aiutare gli ospiti nelle loro stanze perché il sistema di chiavi magnetiche dell'hotel non funzionava: si basa sull'accesso a Internet per aggiornare le chiavi degli ospiti.

Quali altre lezioni forse sorprendenti si possono imparare qui sulle ramificazioni di un attacco DoS?

Alcune domande. Perché dici "Esperimento" egiziano? Cos'è l '"esperimento"? E perché lo descrivi come un Denial of Service? Non è stato apposta? Non il gov. ha ordinato agli ISP di chiudere? Dov'è il DoS su questo?
@labmice: Il governo egiziano ha negato il servizio ai clienti degli ISP egiziani. Potrebbe essere un _de jure_ DoS piuttosto che un SYN flood, ma è comunque un DoS.
@labmice - Stavo cercando di essere un po 'satirico sulle azioni del governo egiziano. Ma volevo richiamare l'attenzione sugli effetti di quelle azioni, che sono degne di studio per informare gli altri sui risultati di un'improvvisa e massiccia mancanza di disponibilità del servizio di rete.
Sembra spaventosamente che alcune persone negli Stati Uniti non abbiano imparato affatto dall'Egitto - http://www.networkworld.com/news/2011/013111-egypt-kill-switch.html
Quattro risposte:
Alex Holst
2011-01-31 03:36:56 UTC
view on stackexchange narkive permalink

Ci viene ricordato che testare un'infrastruttura 24 ore su 24, 7 giorni su 7 è un problema molto difficile.

I test aiutano

Serrature che dipendono dall'accesso a Internet, prodotti di grandi imprese che dipendono da una rete non identificata risorse. Se non puoi disabilitare parte del tuo ambiente per vedere cos'altro si rompe, non ne hai davvero idea.

Ovviamente, le serrature delle porte non dovrebbero dipendere dall'accesso a Internet e se hai deciso che dovrebbero dipendere da un LAN, faresti meglio ad assicurarti che sia completamente sotto il tuo controllo.

Ho lavorato in ambienti in cui i sistemi NetApp e i sistemi DNS erano reciprocamente dipendenti e questo è stato scoperto solo riportando in linea un intero datacenter dopo un'interruzione di corrente.

Ho lavorato in ambienti in cui processi di compilazione presumibilmente autonomi e della durata di un'ora dipendevano dalle risorse di rete. Questo è stato scoperto solo quando la rete si è guastata in un momento critico del rilascio del software.

Altre discipline ingegneristiche (acqua, energia, ecc.) Hanno avuto questo problema per secoli.

Almeno in Ambienti IT, hai la possibilità di ricreare automaticamente il tuo ambiente da qualche parte isolato e vedere cosa succede quando parti della configurazione di test ricreata muoiono.

Progettare per funzionalità offline

Questo è in realtà la mia più grande preoccupazione con "il cloud".

Tutto diventa dipendente da reti affidabili e ad alta velocità. Personalmente cerco di evitare di dover dipendere da reti affidabili: invece di un CMS basato sul Web che richiede l'accesso alla rete per modificare i contenuti sul posto, ho un sito Web statico che modifico offline e carico quando sono su una rete veloce .

Sincronizzo il mio account IMAP sul disco locale, quindi non devo aspettare la latenza di rete o la disponibilità del servizio.

La maggior parte del mio lavoro in questi giorni è archiviato in git, così posso lavorare completamente offline rendendo facile il backup e la condivisione del mio lavoro ogni volta che sono su una rete veloce.

Google Reader recupera i contenuti da Internet e memorizza tutti i miei feed fino a quando il mio client offline si connette a Google Reader e scarica una copia completa. Posso accedere ai contenuti desiderati indipendentemente da quanto questi siti siano danneggiati, perché deve funzionare solo il percorso tra il mio computer e Google.

So che questi sono esempi molto semplici (e alcuni, come Google Reader, hanno implicazioni sulla privacy) ma ogni volta che puoi progettare un sistema che consenta la modalità offline completa, mentre ottieni il meglio da una rete quando è disponibile, penso che sia un design d'oro per cui puntare.

Solo come suggerimento : Forse le serrature dovrebbero essere in grado di memorizzare nella cache una sorta di credenziali per X ore o giorni per evitare che i problemi di rete rendano inutilizzabile un intero hotel.

Steve
2011-01-31 02:08:42 UTC
view on stackexchange narkive permalink

Per ogni intenzione ci sono conseguenze indesiderate.

Disponi sempre di opzioni di backup o non eseguire sistemi mission-critical esclusivamente in un ambiente che può essere attaccato tramite DoS.

Ottima domanda .

nealmcb
2011-02-03 20:25:27 UTC
view on stackexchange narkive permalink

I costi di un DoS possono essere notevoli.



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...