
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
Archivio: Giugno 2002 ml@sikurezza.org Soggetto: Re: Bloccare l'accesso ad un server W2000 (livello anche di File System) Mittente: Rp progetti di Pasquale Ruocco Data: 17 Jun 2002 11:07:51 -0000
hai pensato alla distruzione fisica dell'hd; ossia alimentarlo normalmente(il cavo da 12 e 5.5 v) ma con in parallelo una alimentazione sezionatata da attuatore comandatato da relè antisimico o roba simile (i relè degli anti furti...non centrano niente con i terremoti)...all'azione di scardinamento o frequenza di taglio del metallo (sono tarabili per gamma di vibrazione e sonora) si attua una bella alimentazione a 220 volts ed i poveri compomnenti dalla limitatissima suscettanza elettrica si trasferiscono nel mondo dei più.. con ottime probabilità di guasto o cancellazione elettromagnetica della superfice interna del panino di discoidi che lo costituisce fisicamente. Sul piano dell'incendio l'impossibilità di fuoco dovrebbe essere garantità dall'impossibilità di afflusso di aria comburente dovuto alla chiusura della cassetta; sul piano elettrico ci vorrebbe almeno una protezione a fusibile diciamo di 5a abbastanza sensibile da evitare guai seri.. non troppo sensibile da salvare l'hd... volendo un relè differenziale ritardato per non sentirsi in colpa dopo. Salvo che non si tratti di applicazioni dal misterioso interesse, che motivino persone di altissima specializzazione, direi che hai attuato in questo modo una soluzione talmente distruttiva sul piano dati e talmente imprevedibile che sei al sicuro. direi che l'effetto massimo ottenibile dall'eventuale birbante è aprire in tempo per vedere una bella fumata di componenti Pasquale RUocco ----- Original Message ----- From: "Andrea Rizzi" <andrea.rizzi@integra-europe.it> To: <ml@sikurezza.org> Sent: Monday, June 10, 2002 9:53 AM Subject: Re: Bloccare l'accesso ad un server W2000 (livello anche di File System) > Enrico, > grazie per la tua esaustiva risposta. > Cerco di dettagliare meglio lo scenario, > - il server è unico ed è riposto in una casetta blindata. > - dalla cassetta blindata può essere inserita solamente il cavo di rete e di > alimentazione. > - il server è configurato per fornire solamente il servizio web. > Nessun'altro servizio è attivo. > - il server non ha utenti registrati, solamente un'utente con permessi di > administrator. > - il server è costantemente monitorato da un watchdog che verifica le > seguenti variabili/stati, in caso di errore vengono eliminati tutti i file > sorgenti (FILE ASP) e parte dei dati del database (non tutte le tabelle, > solo alcune, una tabella viene esportata sul file system e criptata da una > chiave con lunghezza ancora da definire): > - tipologia di piattaforma hardware > - checksum file > - esecuzione programma analisi log di sistema (application,security) > - log accessi > - stato del cavo di rete > - il server dovrebbe rimanere sempre accesso, ad ogni avvio della macchina > viene incrementato un contatore. quando il contatore è pari a X viene > lanciata la routine di pulizia (routine descritta sopra) > - Il server risiede sulla LAN interna del cliente. Ovviamente non esiste > nessun accesso alla macchina dal punto di vista terminale (ripeto solamente > il servizio WEB è attivo) > > La mia paura è che venga scardinata la cassetta blindata, a quel punto è > chiaro che il sistema non deve più funzionare. > > quello che chiedevo era se secondo voi ci sono altre contromisure da attuare > per rendere difficile la vita a chi vuole appropriarsi dell'applicazione > contenuta sull'harddisk. > Per questo motivo ho pensato anche di fare delle modifiche hardware sul > server, in modo tale che qualora l'hard disk fosse estratto dal cabinet, non > fosse possibile installarlo su un'altro computer così facilmente. > > Il cripting del file system mi sembrava una buona idea, sempre per lo stesso > motivo. > > Ora se avete qualche altra idea, bhe fatevi avanti :) > > Buon lavoro, > Andrea. > > PS> mi sono dimenticato di dirvi che la cassetta blindata ha una serie di > sensori che verranno collegati tramite circuito elettrico e PIC 16CXX alla > porta parallela del server. (devo ancora sviluppare entrambi i codici PIC e > server, cmq sarà un'altro watchdog) > > > > ----- Original Message ----- > From: "Enrico Branca" <stu1015@libero.it> > To: <ml@sikurezza.org> > Sent: Friday, June 07, 2002 5:03 PM > Subject: Re: Bloccare l'accesso ad un server W2000 (livello anche di File > System) > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > Ciao a tutti, > > > ho bisogno di alcune idee su come proteggere questa soluzione: > > Cerco di darti il mio punto di vista, per quel poco che conosco. > > > INTRODUZIONE: > > > la soluzione è basata su un'applicazione web sviluppata in ASP. Essa > > risiede > > > per ovvie ragioni > > Beh ovvie non lo sono poi tanto, ma fa lo stesso, visto che volendo > > potresti anche usare Apache 2.0 visto che è stato rilaciato da poco > > :-) > > > su un web/application Server IIS 5.0, sistema operativo > > > Microsoft Windows 2000 Professional/Server. > > su sistema operativo windows 2000...ma su professiona o su server ? > > Fare l'hardening di una macchina server è diverso che di una macchina > > client. Ipotizziamo che tu voglia usare un 2k server. > > > L'applicazione, tramite ODBC, fa uso di un database Access. Il file > > Access > > > risiede sempre sulla stessa macchina, non è visibile via web. > > Cosa intendi che non è visibile via web ? via web dall'interno, o via > > web passando per internet ? > > > Il server verrà inserito all'interno di una LAN, offrirà dei > > contenuti agli > > > utenti appartenenti a questa LAN. > > Mi sembra una lan abbastanza problematica, se stai studiando un modo > > per blindare la macchina. Ma se la macchina corre così tanti rischi, > > non ti conviene metterla in una zona separata dagli altri > > computer, magari in un settore compartimentato accessibile solo > > passando un firewall ? > > > Il database access contiene dati di valore, e non devono essere > > modificati > > > dall'esterno per nessun motivo. > > Vuoi dire che per accedere si deve essere fisicamente > > davanti alla macchina, o che gli utenti normali da remoto non possono > > accedere, mentre un utente con diritti di amministratore ( o diritti > > che gli consentano di svolgere il lavoro che gli è stato assegnato) > > può accedere alla macchina da remoto ? > > > Inoltre, data la natura dell'applicazione, non si vuole dare accesso > > in > > > nessun modo al file system per ottenere il codice sorgente del > > database e > > > dell'applicazione. > > ok...qui va abbastanza bene, anche se non farebbe male dire cosa > > intendi per "ottenere il codice sorgente". Non ci si deve arrivare via > > web o via condivisione di rete ? > > > SOLUZIONI: > > > Ho pensato le seguenti soluzioni: > > > - invertire fili del controller dell'hard drive (solamente i D0... > > DN no gli > > > Address ovviamente) > > a che ti serve se poi non hai controllo pieno della macchina ? devi > > evitare l'accesso "a chi vuoi tu" non anche a te stesso, altrimenti > > parti svantaggiato. > > > - Criptare il file system > > sarebbe una cosa carina, ma forse inutile. In windows 2000 l'efs > > funziona, ma non come molti credono. > > faccio un piccolo esempio per spiegarmi meglio: > > l'utente pippo ha un file che vuole leggere solo lui, per cui attiva > > la criptazione sul file. L'utente quindi crede che il file non sia > > leggibile da nessuno. > > SBAGLIATO, L'AMMINISTRATORE LO PUO LEGGERE. > > l'utente pippo, col tempo, viene considerato superfluo per la ditta, > > per cui viene licenziato, e il suo account cancellato. > > La sua cartella viene assegnata ad un altro utente (mettiamo che sia > > paperino) per lavorare sui file. > > Paperino non vede nulla, ma l'amministratore, che controllava tutto > > fin da prima, viene contattato. Vede che l'account di pippo è stato > > cancellato, quindi per recuperare i file, usa il suo certificato > > digitale speciale, che gli permette di decriptare i dati, e recupera > > il file. > > MORALE: l'efs funziona, ma se una persona no autorizzata accede alla > > macchina si presume che abbia diritti di amministratore, per cui sarà > > sempre in grado di decriptare i file che sono stati criptati. > > Per evitare questo, dopo ogni criptazione si dovrebbero rimuovere i > > certificati digitali dalla macchina, e ad ogni de-criptazione > > sarabbero da reimportare. > > Per quel che so io, l'efs aiuta, ma non ti risolve il > > problema. Ovviamente è una buona cosa abilitarlo. > > > - Creare un filtro DLL per IIS che effettui la codifica delle chiavi > > a > > > livello di server tramite 3DES > > windows 2000 può anche usare come metodo di accesso NTLMv2, che è > > decisamente più sicuro di quello normale, come credo tutti sappiano. > > L'unico problema è che impedisce totalmente l'accesso VIA RETE alla > > macchina da parte di client che non abbiano lo stesso protocollo. > > Comunque per le macchine windows basta usare dsclient.exe dal cd di > > installazione di win2k server. > > Via web potresti sempre usare SSL che aiuta anche lui a mantenere la > > riservatezza. > > > Qualcun'altro a qualche idea migliore? > > beh....ci sarebbero alcune cose che credo sia buona cosa prendere in > > considerazione. > > Dovresti usare almeno TRE hard disk diversi. > > 1 per la system partition (partizione di boot) e per la boot > > partition (partizione di sistema) > > 1 per l'installazione di IIS 5 > > 1 per lo storage dei file del database > > > > Mettiamo caso che uno riesca ad accedere al sistema, se hai tutto su > > un disco, riuscirebbe contemporaneamente a rubarti i file del > > database, a rubarti tutto il sito, e a formattarti la macchina ( se è > > cattivo potrebbe anche farti un wipe) > > Per cui fai dei compartimenti, in modo tale che chi accede al sistema > > non sia in grado di interagire sul sito > > che chi accede al disco che contiene iis non sia in grado di accedere > > al disco con il database > > che chi accede al database non sia in grado di portarsi via i file > > suppongo sempre che la macchina non sia stata compromessa a tal punto > > da restituire una shell di dos o una condivisione di rete a chi la > > attacca > > > Vi ricordo che è di vitale importanza non dare accesso ai sorgenti e > > al > > > database, per nessun motivo (in caso estremo va bene perdere > > l'intero > > > contenuto del disco). > > Poi direi che dovresti mettere un HOST-IDS sulla macchina, e potresti > > ad esempio usare snort che è gratis. > > Poi dovresti togliere le condivisione di rete, togliere almeno una > > ventina di chiavi di registro per disabilitare amenità varie che win2k > > si porta da NT 4 > > Poi dovresti cambiare le permission di tutte le cartelle della > > macchina rimuovendo EVERYONE e mettendo solo AUTHENTICATED USER, e > > quindi assegnare alle cartelle delle permission che siano il più > > restrittive possibile > > ma non è finita. > > poi devi rimuovere tutti i servizi che non sono ASSOLUTAMENTE > > NECESSARI, e rendere inutilizzabili i file che venivano usati > > poi disabilitare gli account di base, rinominarli e al loro posto > > usare account creati ad hoc. > > ovviemente usare password MOLTO COMPLESSE per gli account chedovranno > > accedere alla macchina. > > La data delle password deve essere inferiore a 32 giorni, che sono i > > gliorni che occorrono a LC3 per decriptare una password alfanumerica > > di 12 caratteri con maiuscole, minuscole, numeri e simboli normali( il > > tempo che impiega l'ho testato sul campo). Puoi considerare di mettere > > caratteri ASCII estesi. > > Poi puoi fare il test con LC3 di @stake. se non te le trova in 18 ore > > di > > cracking allora sei va abbastanza bene. > > Poi direi che dovresti abilitare l'auditing su tutte le parti della > > macchina e salvare i log in un posto sicuro, per poi analizzarli. > > Come metodo di accesso da remoto escludi VNC, che è craccabile. > > Escludi anche i terminal service, che aprono porte di comunicazione > > standard e possono essere facili bersagli di attacchi. > > Puoi provare con OpenSSH usando SSHv2. > > Poi rimuovi i banner dei servizi web e rinominali. > > E alla fine abilita i filtri di IPSec per filtrare le porte che > > possono essere usate sulla macchina. > > > Inoltre sono costretto ad utilizzare le suddette tecnologie (OS W2K, > > > IIS,ASP,MS Access) :( (se fosse stato per me l'avrei scritto > > totalmente in > > > ASM, purtroppo non posso farci niente) > > Beh...tutti i sistemi operativi sono vulnerabili, chi più chi meno. Ma > > quello che fa diventare sicuro un sistema non sono i wizard di > > configurazione ma la mano di chi configura il sistema. > > Quindi volendo la tua macchina potrebbe essere un bersaglio molto poco > > "hacker-friendly". > > > > Spero di non aver detto cose troppo ovvie. Nel caso avessi detto cose > > sbagliate, fatemelo sapere grazie :-)) > > > > Se ti può servire puoi contattarmi personalmente che non ci sono > > problemi. > > > > Enrico Branca > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 6.0.2i > > > > iQA/AwUBPQC9RkVqSmXe/tZ/EQKBNgCgte4fKkmYAuHBRgkXZBZKiZcqnDwAoLxC > > dHtAnwkJTrTZzPCNcbt/Kk13 > > =lmTU > > -----END PGP SIGNATURE----- > > > > > > ________________________________________________________ > > http://www.sikurezza.org - Italian Security Mailing List > > > > > > > ________________________________________________________ > http://www.sikurezza.org - Italian Security Mailing List > > > ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005