[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Giugno 2002 ml@sikurezza.org
Soggetto: Re: Bloccare l'accesso ad un server W2000 (livello anche di File System)
Mittente: Enrico Branca
Data: 7 Jun 2002 18:05:49 -0000
-----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




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005