Non sei sicuro che tutti gli aggiornamenti di sicurezza vengano applicati? Ricorda, come difensore, devi vincere il 100% delle volte . Un hacker deve vincere solo una volta.

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

2) Inoltre, cos'è una "fonte credibile" per un server web pubblico? L'intera Internet? L'intero Internet, senza Cina / Russia (/ alcuni / altri / paesi)? I sistemi automatizzati possono rilevare molti tipi di attacchi, ma proprio come gli antivirus possono arrivare solo fino a un certo punto.

3) Il monitoraggio dei file locali va bene, ma, ancora una volta, non è una panacea. Cosa succede se l'attaccante riesce a iniettare codice nel server web e quindi utilizza un bug del kernel per ottenere codice nel kernel ... senza mai scrivere un file sul disco? A quel punto, potevano scrivere file sul disco e utilizzare un kit di root per impedire alla maggior parte delle scansioni online (teoricamente tutte ) di rilevare 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 comunque essere tutto ciò a cui l'attaccante era interessato).

4) Dovresti convalida sempre 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, motivo per cui continuiamo a vedere problemi dopo problemi in cui l'input dell'utente non è adeguatamente convalidato. Non sarai mai in grado di garantire che un qualsiasi software reale stia correttamente convalidando 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 potessi (non puoi) assicurarti che ogni vettore di attacco conosciuto sia protetto, non puoi fare altro che dondolarti selvaggiamente nell'oscurità contro e sconosciuto-sconosciuto (beh, educare continuamente te stesso aiuta).

Come esempio in cui le tue difese non avrebbero fatto nulla, stavo prendendo parte a un corso sulla sicurezza in cui stiamo facendo "giochi di guerra". Sono stato in grado di eseguire il root del server di una squadra avversaria riuscendo a ottenere una delle loro password utente da un'altra macchina (una di loro ha sbagliato e l'ha digitata in bash come comando per errore, e non hanno mai pensato per eliminarlo da .bash_history ).

Da lì, ho falsificato l'IP della macchina da cui di solito accedevano e si collegavano in SSH, inserendo il loro nome utente e password. Ho avuto un accesso limitato al sistema. Quindi ho eseguito sudo vim , ho inserito di nuovo la stessa password e ho fatto generare a vim una shell bash. Tada! Accesso root, da una fonte credibile, senza modificare alcun file locale in modo insolito, senza sfruttare una password debole (era cattiva, ma anche la migliore password al mondo non avrebbe aiutato), né fare affidamento su input dell'utente non convalidato.

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

Se potessi alterare la legge di Schneier:

Chiunque, dal dilettante più incapace al miglior amministratore di sistemi, può creare un sistema di sicurezza che lui stesso non può violare.

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

Prendere una pugnalata veloce ai tuoi input ->

Rendi lunga la password dell'account amministratore ...

La semplice navigazione a spalla sconfigge qualsiasi sforzo su password complesse.
Inoltre se i meccanismi di memorizzazione delle password sono deboli (inclini a Iniezioni SQL, o meccanismi di hashing non sicuri o, peggio, archiviazione di password in testo normale), rimani vulnerabile.

Monitora ogni traffico di rete in entrata

Sarai monitoraggio di un'enorme quantità di traffico. Qual è la garanzia che non ti perderai alcune cose importanti? E che dire degli giorni zero?
E del traffico crittografato? Cosa monitorerai su questo?

... e consenti solo fonti credibili.

E se le tue fonti credibili ottengono compromesso / violato? Quindi non sono più credibili ma tu, l'amministratore di sistema, non lo sai!

... monitora le modifiche ai file locali ... Convalida ogni input dell'utente. ..

Di nuovo, quanto puoi monitorare e quanti log puoi analizzare ...

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

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

Ack: Immagine tratta da www.quotesparade.com

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

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

Stando così le cose, i problemi che troverai includono:

• come ti assicuri che tutti gli eseguibili siano sicuri? Di nuovo, non puoi. Puoi decidere quanto sforzo vuoi dedicare al loro controllo ed eseguire vari test, ma le basi di codice sono abbastanza grandi per la maggior parte delle applicazioni in cui si insinuano errori accidentali.
• L'opzione di sicurezza proposta rende il server inutilizzabile per il suo pubblico di destinazione? Scollegarlo dalla rete aumenterà la sicurezza, ma non piacerà ai tuoi utenti.
• Conosci effettivamente tutti i possibili input che i tuoi utenti potrebbero voler utilizzare? Se è così, brillante: inseriscili nella lista bianca. 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 verifica che la lista bianca funzioni per bloccare tutti gli input non approvati. E così via ...
• potrebbe non essere necessario che gli attacchi alterino alcun file sul disco. Ad esempio, il monitoraggio dei file non rileva gli attacchi che prendono di mira direttamente il codice in memoria.
• l'aggiunta di controlli di sicurezza tecnici non tiene conto degli attacchi sociali o fisici. Se un utente malintenzionato desidera davvero accedere a un server ben protetto, potrebbe ritenere che valga la pena darti un bug, registrare le tue battiture per ottenere password, ecc. Oppure potrebbe essere più facile bug un utente - forse è meno consapevole della sicurezza.
• ecc ecc

In poche parole, puoi assicurarti a un livello, a seconda del tuo budget. Decidi quanto sei disposto a spendere in base a ciò che vuoi proteggere. Accetta il fatto che ci sarà qualche rischio residuo.

E poi pianifica che qualcosa vada storto: a un certo punto la tua sicurezza verrà interrotta e dovrai sapere come rispondere. Per un semplice file server questo processo può essere semplicemente cancellato e reinstallato dal backup, ma per qualcosa di più complesso potrebbe essere necessario informare gli utenti, le parti interessate, i regolatori, ecc., Archiviare le prove, fare copie forensi, ricostruire, riconfigurare o in qualche modo riparare l'incidente ... e poi riprendi le esperienze di apprendimento da esso per rivalutare il tuo piano di sicurezza.

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

Supponiamo che tu abbia un server web, che accetta un comando:

GET /helloworld.txt

e che restituisce, molto semplicemente, "Hello, World!"

Questa è la cosa più facile al mondo da programmare, giusto? Supponendo che tu prenda l'input, controlla la stringa "GET /helloworld.txt" e fai la cosa giusta, quindi ignora qualsiasi altra cosa, quali sono le possibilità di hacking? Nessuno?

OK. Qual è la dimensione del buffer dei comandi? 20 byte? Quanto basta per accettare quel comando? E se qualcuno dà un comando più lungo di due byte? E se danno un comando più lungo di 2000 byte? Come ricevi effettivamente il comando? Cosa parla alla scheda di rete? Cosa decodifica il pacchetto? E se i caratteri venissero inviati in due pacchetti, senza terminazione NUL tra i byte?

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

Semplicemente, si tratta di complessità. Ogni volta che viene introdotta una variabile, il numero di POSSIBILI vettori di attacco aumenta in modo esponenziale. Non tutti saranno vettori di attacco, ma POTREBBERO esserlo, quindi devi coprirli tutti, se intendi essere sicuro.

È praticamente impossibile, senza un'unità completamente controllata e completamente testata, sistema 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 sicurezza, presumi sempre il peggio. È MOLTO più intelligente sapere di essere vulnerabile e agire in modo adeguatamente umile, rischiando il meno possibile, piuttosto che presumere 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'hackeraggio è più che un semplice attacco diretto / accesso.

Una parte importante include il bypassare la tua protezione, in modo che un aggressore non debba conoscere la password. L'ingegneria sociale è un'altra grande parte. Le password non proteggono nulla, se sono conosciute dagli aggressori. Inoltre, ci sono attacchi e obiettivi più dannosi rispetto al semplice accesso al pannello di amministrazione. Se qualcuno non vuole che tu gestisca un negozio online, perché ha il suo e vuole mantenere i suoi clienti (e te fuori dal mercato), come vuoi prevenire un attacco DDoS, o semplicemente qualcuno che stacca la spina del tuo server camera? (La donna delle pulizie, che voleva solo spolverare la scheda madre?;))

Inoltre, il monitoraggio non aiuta a prevenire gli attacchi.

Ci sono diversi tipi di protezione, sistemi antimanomissione, antimanomissione e antimanomissione. I sistemi resistenti alle manomissioni vogliono rallentare gli attacchi (ad esempio password lunghe). La risposta alle manomissioni ti dice se è in corso un attacco (ad es. Un allarme che si attiva se il tuo IDS rileva alcune stringhe di SQL injection) e il sistema di verifica delle manomissioni mostra come sono avvenuti gli attacchi effettivi (ad es. File di registro)

Gli hacker cercano di violare o evitare queste protezioni, e il tuo lavoro è essere un passo avanti. Ovviamente questo è molto difficile, poiché puoi a malapena conoscere eventuali falle di sicurezza nel software del tuo 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 punti deboli ed è tuo compito prenderti cura del tuo sistema e rallentare i loro attacchi finché il problema non viene risolto.

Rendi la password dell'account amministratore abbastanza lunga e complicata (cioè, in teoria, la password non può essere decifrata entro un tempo ragionevole).

Crackizzata dalla forza bruta? No. Incrinato 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, comunque, l'accesso fisico può essere ottenuto tramite l'ingegneria sociale. È più difficile da gestire, tuttavia, e devi chiederti se ne vale davvero la pena.

Monitora ogni traffico di rete in entrata ai file amministrativi.

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

Anche se la tua password è lunga, una botnet può entrare. Se hai una sorta di restrizione sul numero di volte in cui puoi fallire un tentativo di password, quindi possono bloccare te .

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

Per estendere il livello di protezione dal n. 2 sopra, monitora le modifiche ai file locali (specialmente quelli che hanno comandi che richiedono privilegi sudo.

Non è possibile monitorare completamente tutte le modifiche ai file. Ci sono troppe informazioni. La maggior parte dei programmi fa un sacco di confusione con i file durante l'esecuzione. Come distingueresti tra un aggiornamento del programma e un file dannoso?

Convalida ogni input dell'utente, in modo che sia garantito che tutto l'input dell'utente sia sicuro.

Assicurati di fare questo lato server.

Infine , gli exploit zero day saranno sempre un problema. Se qualcuno rileva una vulnerabilità di sicurezza nel framework che utilizzi, sei affondato. Per evitare ciò, utilizza framework ampiamente utilizzati e spera per il meglio.

Proteggersi dall'hacking è come cercare di proteggere un bunker sottomarino pieno di sodio. Ci sono molti posti che ritieni debbano essere riparati. Puoi sistemarli tutti. Ma questo non significa che tu sia al sicuro: basta una piccola perdita in un punto che non hai ispezionato per far crollare tutto.

"Difendersi adeguatamente" significa: "il mio codice non ha bug; nessuno degli strumenti che uso neanche". 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 (chi afferma il contrario è deluso o bugiardo, o entrambi). Vedi questa domanda precedente per qualche discussione.

Il modo pratico in cui avvengono gli attacchi è quando un attaccante scopre o apprende di un bug che può essere sfruttato a suo vantaggio, e prima che il proprietario del sistema lo impara e lo risolve.

Dalla tua lista:

• Una password amministratore grande, grossa, casuale, indovinabile va bene - fintanto che la macchina su cui l'amministratore digita la sua password non è infetta da qualche malware keylogger.

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

• Lì non è qualcosa come "input utente sicuro garantito". C'è "l'input dell'utente che è stato verificato per essere conforme a uno specifico insieme di regole, il che dovrebbe significare che detto input dell'utente può essere utilizzato in una data costruzione senza incontrare situazioni scomode". 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 è affatto sicura per inclusione in una query SQL (i caratteri sicuri per HTML potrebbero codificare una query SQL totalmente non sicura).

Solo per aggiungere alcuni punti:

Rendi la password dell'account amministratore abbastanza lunga e complicata (vale a dire, in teoria, la password non può essere decifrata entro un tempo ragionevole).

Le password lunghe e complicate anche se valide, aumentano la probabilità che vengano scritte. Lo stesso vale per le password che devono essere cambiate spesso. Soprattutto se più di una persona ha bisogno della password, o è una password che non viene utilizzata spesso.

Monitora tutto il traffico di rete in entrata ai file amministrativi.

Gli attacchi di escalation dei privilegi renderanno tutto ciò inutile, poiché i cambiamenti sembreranno provenire dal traffico locale, non dalla rete. E un monitoraggio eccessivo aprirà nuove questioni. Gli exploit di overflow del buffer sono comuni. Diamine, alcuni router consumer continuano a soffocare sui tentativi di traffico bloccato che intasano le tabelle di connessione.

Per estendere il livello di protezione dal n. 2 sopra, monitora le modifiche ai file locali (specialmente quelli che hanno comandi sudo privileges).

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

Convalida tutti gli input dell'utente, in modo che sia garantito che tutto l'input dell'utente sia sicuro.

Quanto impegno ci metti? La disinfezione dell'input dell'utente non è mai efficace al 100%.

Fondamentalmente, il punto è che alcune cose che fai causeranno più problemi che non farle, ci sono sempre modi per aggirarlo, cerca solo di fare del tuo meglio e spero che tu non commetta un errore ossessivo. Sii come un disinfettante. Puoi eliminare solo il 99% del problema.

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

Non hai definito cosa significhi per il tuo server essere hackerato.

Il primo passo è definire qual è 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 molto specifica e limitata (come servire una particolare applicazione distribuita), e gli aggressori possono accedere a quel sistema solo attraverso la rete, quindi praticamente solo quell'applicazione deve essere sicura, più le parti del sistema esposte alla rete: l'adattatore LAN, il suo driver e lo stack di rete.

La vera sfida nella sicurezza in un sistema operativo come Linux è come rendere il sistema operativo inattaccabile in una situazione multiutente quando le persone hanno quasi pieno uso del sistema possono accedere agli account del sistema operativo ed eseguire direttamente le applicazioni.

il sistema può avere incidenti di sicurezza senza che l'account del superutente venga compromesso. Supponi di avere un sistema Linux perfettamente indistruttibile. Tuttavia, l'utente joe installa un'applicazione non sicura / home / joe / bin . Quell'applicazione apre un documento dannoso, che sfrutta un difetto nell'applicazione, per mezzo del 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 ruba anche il tempo della CPU dalla macchina. (Per quanto possa provare, però, non può ottenere i privilegi di esecuzione da superutente, perché la macchina è "unhackable").

È stato violato? O non violato? Che ne dici dal punto di vista dell'utente joe . A joe interessa 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 sempre privi di bug al 100%, in teoria hai ragione. Sfortunatamente, tuttavia, nessuno di questi è mai vero ed è abbastanza facile per un attaccante attaccare in questi punti.

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

Allo stesso modo, l'ingegneria sociale è probabilmente la forma più comune di hacking. Non sono necessarie complesse misure tecniche quando puoi semplicemente ingannare il tuo avversario per darti ciò che desideri. Navigare a spalla la password, ottenere un key-logger su un computer utilizzato dall'amministratore o ingannare un amministratore che esegue il tuo software dannoso sono tutti modi possibili per intrufolarsi sotto il radar.

Puoi compensare un sacco di questo bloccando un server in una stanza senza connessione Internet e consentendo agli amministratori di utilizzare il sistema solo mentre si trova nella stanza con una guardia alla porta, e in effetti, questo è il numero di reti governative ad alta sicurezza che operano, ma mette un enorme barriera all'usabilità.

In ultima analisi, la sicurezza consiste nel bilanciare usabilità e rischio. I passaggi che descrivi richiedono una riduzione eccessiva dell'usabilità per essere implementati in modo sicuro e quindi non possono funzionare da soli in una situazione del mondo reale. La sicurezza è un campo complesso e in continua evoluzione che richiede di rimanere aggiornati sulle minacce, controllare le difese contro nuove minacce ed essere sicuri di monitorare le compromissioni che potrebbero superare come problemi di 0 giorni.

Sto provando a costruire sistemi antiproiettile da quasi dieci anni. Ho dovuto apprendere tecniche di progettazione ad alta garanzia (ad esempio EAL7), canali nascosti, attacchi di sovversione, ecc. Onestamente, la maggior parte dei progettisti di sistemi o degli amministratori non ha né le conoscenze né le risorse per proteggere completamente una macchina da attacchi noti. È quasi impossibile dati i vincoli aziendali. La maggior parte delle decisioni sulla sicurezza riflettono compromessi tra costo, funzionalità, usabilità, compatibilità legacy, probabili profili di aggressore, ecc.

Se vuoi sapere, ecco una delle mie analisi semplificate sui vari livelli e problemi di sicurezza. (E non ha le dimensioni di un libro 8). Era indirizzato a un ragazzo che pensava che i programmatori di prim'ordine potessero creare programmi sicuri, ma puoi sub admin per coder e comunque gli stessi risultati. Divertiti e impara le lezioni meno che ripeti la storia come fa gran parte della comunità INFOSEC. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

Questo segue su commento ha molti collegamenti che tracciano la storia, i fattori governativi, i requisiti di sviluppo, ecc. Ognuno potrebbe avere difetti in agguato ma ispirare più fiducia rispetto al prodotto medio.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

Un sistema è forte quanto il collegamento più debole

Questa è una frase spesso ripetuta e dovresti ricordare che non importa quanto sia forte una password, è un unico punto di fallimento e un bruteforcer sarà in grado di sfondare ad un certo punto.

Inoltre, cosa succederebbe se il tuo amministratore di sistema decidesse di accettare un bel compenso per eliminare accidentalmente un carico di file?

I tedeschi pensavano che l'enigma fosse indecifrabile e si è sostenuto che la loro dipendenza e fiducia in questo unico metodo di crittografia sia costata loro la guerra: la dipendenza da un singolo sistema o risorsa (umana o meno) è la peggiore possibile crimine contro la sicurezza.

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

1. Alcune persone non hanno letteralmente niente di meglio da fare e cercheranno 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 faranno nulla di malevolo.
3. Alcune persone cercheranno di ottenere le password dei tuoi utenti per provarle su altri siti web, come quelli delle carte di credito. Si atteggiano per ottenere un enorme profitto da questa operazione
4. Alcune persone attaccheranno un server per vendetta. "Jane Berman ha detto che sono una testa di cacca? IL SUO SERVER DEVE SCENDERE!"

Le persone, soprattutto in 2-4, tendono ad essere incredibilmente appassionate di entrare nel tuo sistema. A volte il numero 1 diventa 2-4. Le aziende devono pagare qualcuno per proteggere un server e sono necessari molti 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 del software non è a conoscenza della sicurezza in primo luogo. La sicurezza è meticolosa da insegnare, comprendere e anche da aggiornare (notizie, nuovi vettori di attacco, ecc.).

Ecco perché non viene insegnata in modo completo ed estensivo. Ad esempio, non esistono 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 ci si prenderà cura. Un futuro in cui ci saranno qualcosa come 100 o più computer per essere umano.

Se ci pensi davvero, non ci affidiamo abbastanza ai computer per preoccuparci della sicurezza di Internet (almeno penso, o almeno le parti in cui è fondamentale devono essere curate con cura).