No banner in farm
iscriviti alla newsletter

ISAserver.it - No. 1 Unofficial European web site on Microsoft ISA Server / Forefront TMG

Home di ISAserver.it
Google
 
Articoli
Autori di ISAserver.it
Forum Tecnico Iscriviti al feed RSS del forum di ISAserver.it
Blog di Luca Conte Iscriviti al feed RSS del blog di ISAserver.it
Software per ISA Server
Soluzioni Hardware per ISA Server
Eventi Tecnici e Formazione
Libreria di ISAserver.it
Contatti
Consigliati da ISAserver.it

No banner in farm
WORKBOOK

No banner in farm
Quale prodotto utilizzi

Quale prodotto utilizzi

VMexperts.org
Community tecnica italiana sulla Virtualizzazione
VOIPexperts.it
Community tecnica italiana sul VOIP
 
 

<< Torna all'elenco degli Articoli
 
Automatizzare le azioni di difesa di ISA Server 2006
in caso di attacchi FTP Brute Force
Autore: Giulio Martino
Data:
18.03.2008
Informazioni sull'Autore:
Creatore e fondatore della Community VOIPexperts.it, opera su sistemi Microsoft fin dai tempi del DOS senza trascurare sistemi Unix, Linux. Le sue competenze spaziano anche nella installazione e configurazione di apparati di rete, firewall e sistemi di posta. Svolge la propria attività a Matera..

Domande sull'articolo? Scrivi sul forum di ISAServer.it >>


Automatizzare le azioni di difesa di ISA Server 2006 in caso di attacchi FTP Brute Force

Introduzione
In questo articolo analizzeremo come mitigare il più possibile ed in maniera automatica, usando come firewall ISA Server, attacchi di tipo Brute Force e/o Dictionary portati al nostro server FTP (IIS).

Questo tipo di approccio non esonera il sistemista dall' implementare policy sulle password e sugli account tali da ridurre al minimo la possibilità che attacchi di questo tipo abbiano successo, ma vuole essere un plug-in utile a ridurre al minimo possibile anche l'occupazione inutile di risorse che questi tipo di attacchi inevitabilmente provoca.
Infatti l'idea è quella di bloccare totalmente l'accesso dei "cattivi" al nostro server FTP direttamente sulla interfaccia External di ISA, impedendone di fatto anche la connessione.


Questo è possibile intercettando gli errori di autenticazione portati al server FTP ed alimentando una black list direttamente sulla regola di pubblicazione creata sul nostro ISA server.
Il modo più semplice (e forse l'unico) per intercettare gli errori di autenticazione è quello di leggere ed interpretare i log del server FTP.
Di default i log di IIS sono scritti in file di testo.
Si potrebbero scrivere delle procedure più o meno complesse per leggere ed interpretare i file di testo contenenti i log, ma il nostro scopo è di raggiungere il massimo risultato con il minimo sforzo,
spostando i log del server FTP su di un server SQL e utilizzando i trigger per automatizzare i processi necessari.


…………bene a questo punto possiamo passare alla parte pratica.


Prima di iniziare è importante decidere dove installare il server SQL che ospiterà le tabelle ed i trigger. Nel prendere questa decisione bisogna tener presente che i trigger dovranno eseguire uno script esterno che deve scrivere su ISA server. Questo significa che, qualora si decida di installare il server SQL su un server diverso da ISA, sarà necessario preoccuparsi di avere gli skills per scrivere uno script che possa eseguire comandi da remoto su ISA server.
Per semplicità (poi vedremo che anche qui ci sono delle complicazioni) abbiamo scelto di installare il server SQL sulla stessa macchina dove risiede ISA server.
Come server SQL abbiamo scelto la versione Express che è gratuita e rispetta in pieno tutte le nostre necessità.
L'unica accortezza è di valutare e gestire i limiti che presenta la versione Express (non trattati in questo articolo) ed eventualmente creare e predisporre le misure correttive (es. valutare e gestire il limite sulla dimensione delle tabelle) e/o passare alla versione di SQL a pagamento.

SQL Server
Una volta installato il server SQL è necessario procedere con l'abilitazione del protocollo TCP. Dagli strumenti di amministrazione aprire la MMC Gestione configurazione SQL Server | Configurazione di rete | Protocolli per SQLEXPRESS e abilitare il protocollo TCP/IP dalle Proprietà.


A questo punto, nel caso si sia installato il server SQL sulla stessa macchina di ISA, è necessario verificare che il TCP/IP sia abilitato solo per la scheda di rete internal.
Quindi selezionare il tab Indirizzi IP e verificare che tutti gli IP facenti parte della scheda External di ISA abbiano l'opzione Attivato = NO.


Per terminare l'attivazione e rendere disponibili le modifiche è necessario riavviare il servizio SQL Server.

Ora possiamo procedere con la creazione dell'ambiente dedicato a ricevere e ad elaborare i log dal server FTP. Apriamo la MMC di SQL Server e, come prima operazione, creiamo il database che conterrà le tabelle ed i trigger del progetto.
Esempio di creazione DB :

CREATE DATABASE [FTPLog] ON PRIMARY
( NAME = N'FTPLog', FILENAME = N'C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\FTPLog.mdf' , SIZE = 3072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON
( NAME = N'FTPLog_log', FILENAME = N'C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\FTPLog_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
COLLATE Latin1_General_CI_AS

Creato il DB dobbiamo creare la tabella che conterrà i log del server FTP. Per creare la tabella è disponibile sul server FTP, nella cartella C:\WINDOWS\system32\inetsrv, un file chiamato logtemp.sql.

Esempio di creazione tabella InternetLog:
CREATE TABLE [dbo].[internetlog](
[ClientHost] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[username] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[LogTime] [datetime] NULL,
[service] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[machine] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[serverip] [varchar](50) COLLATE Latin1_General_CI_AS NULL,
[processingtime] [int] NULL,
[bytesrecvd] [int] NULL,
[bytessent] [int] NULL,
[servicestatus] [int] NULL,
[win32status] [int] NULL,
[operation] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[target] [varchar](255) COLLATE Latin1_General_CI_AS NULL,
[parameters] [varchar](255) COLLATE Latin1_General_CI_AS NULL
) ON [PRIMARY]

Creata la tabella dei log è necessario, prima di procedere, fare una piccola considerazione.
Prima di inserire l'indirizzo ip nella blacklist di ISA, vorremmo che l'errore di login si verifichi per un numero determinato di volte. Ad esempio dopo 5 tentativi falliti l'ip deve andare in BlackList.
Per raggiungere questo obiettivo abbiamo creato una tabella di appoggio dove andremo a contare il numero di tentativi falliti.

Esempio di tabella BlackList:
CREATE TABLE [dbo].[BlackList](
[Ipdabloccare] [varchar](255) COLLATE Latin1_General_CI_AS NOT NULL,
[Ntentativi] [int] NULL CONSTRAINT [DF_BlackList_Ntentativi] DEFAULT ((0))
) ON [PRIMARY]

Ipdabloccare = Indirizzo IP dell'host che genera un errore di login
Ntentativi = Contatore dei tentativi falliti

Create le tabelle, dobbiamo preoccuparci di alimentarle. La prima tabella verrà alimentata dal server FTP ed analizzeremo i dettagli più avanti, mentre la tabella di appoggio BlackList verrà alimentata da un trigger creato sulla tabella dei log (InternetLog) che verifichi e conti i tentativi falliti di login.

Esempio di trigger:
declare @RESP1 as int;
declare @RESP2 as int;
declare @BlackIp as varchar(250)
declare @NREC as int;


select @RESP1 = inserted.servicestatus, @RESP2 = inserted.win32status, @BlackIp = inserted.ClientHost from [FTPLog].[DBO].[internetlog], inserted where inserted.ClientHost = internetlog.clienthost

'Verifica Errore di login (APPENDICE B)
if @RESP1 = 530 and @RESP2 = 1326

begin
 select @NREC = count(Ipdabloccare) from  [FTPLog].[dbo].[BlackList] where Ipdabloccare = @BlackIp
 if @NREC = 0
  INSERT INTO [FTPLog].[dbo].[BlackList]
  ([Ipdabloccare],[NTentativi])
  VALUES
  (@BlackIp,1)

 else
  update [FTPLog].[dbo].[BlackList] set Ntentativi =   Ntentativi + 1 where Ipdabloccare = @BlackIp;

 end
END

Questo trigger deve essere creato a livello di tabella InternetLog e deve scatenarsi ad ogni insert. Quando il trigger viene scatenato, va a verificare il campo win32status ed il campo servicestatus e, qualora verifichi un errore di login (APPENDICE B), aggiorna la tabella di appoggio BlackList.
Il secondo trigger deve verificare il numero di tentativi falliti ed eseguire uno script che inserisca l'ip nella blacklist di ISA.

Un esempio del trigger in questione è il seguente:
declare @CMD as varchar(500);
declare @TOT as int;
declare @BlackIp as varchar(255);
select @TOT = inserted.Ntentativi, @BlackIp = inserted.Ipdabloccare from [FTPLog].[dbo].[BlackList], inserted where inserted.ipdabloccare = BlackList.Ipdabloccare

if @TOT > 5
 begin
 set @CMD = 'c:\esegui.bat ' + @blackIp + ' >> C:\test.txt' --+ @BlackIp;

 ' Leggere le note riportate più avanti sugli account
 EXECUTE AS login = 'giulio'
 EXEC master ..xp_cmdshell @CMD;

 ' Va insieme ad EXECUTE AS login e server per ripristinare  l'account originale
 REVERT
 delete from [FTPLog].[dbo].[BlackList] where Ipdabloccare = @BlackIp
end

END

Il comando esegui.bat conterrà la seguente riga:

cscript c:\script\isaipblacklist.vbs %1

Dove :
Isaipblacklist.vbs è lo script che aggiona la black list su ISA e verrà analizzato più avanti
%1 rappresenta l'indirizzo IP passato come parametro

Questo trigger deve essere creato a livello di tabella BlackList e deve scatenarsi ad ogni update. Va a controllare il contatore Ntentativi e, se supera un valore prestabilito - ad es. 5 -, esegue un comando esterno.

Su questo trigger è necessario fare alcune considerazioni importanti e fondamentali per il corretto funzionamento. La funzione xp_cmdshell serve per eseguire dei comandi esterni, funziona in modalità sincrona ed è in grado di restituire un valore.
Questa funzione è disabilitata di default, per cui è necessario abilitarla prima di poterla utilizzare.

Abilitazione funzione xp_cmqshell
-- Abilita la modifica delle opzioni avanzate
EXEC sp_configure 'show advanced options', 1
GO
-- Rende attive le modifiche
RECONFIGURE
GO
-- Abilita l'opzione di esecuzione comandi esterni
EXEC sp_configure 'xp_cmdshell', 1
GO
-- Rende attiva la modifica
RECONFIGURE
GO

Gli account interessati dalla funzione xp_cmdshell sono due :

1) Account di esecuzione funzione xp_cmdshell
2) Account di esecuzione comando esterno


Se ci logghiamo al server con SA o Administrator (quindi sysadmin), la funzione xp_cmdshell verrà eseguita da sysadmin e l'account di windows con cui verrà eseguito il comando sarà l'account con cui viene eseguito il servizio di SQL, che di default non fa parte del gruppo Administrators di Windows.
Questo significa che riusciro' ad eseguire la funzione, ma che l'esecuzione dello script di ISA (comando), fallirà perché l'utente passato non fa parte del gruppo Administrators di Windows. Per risolvere questo problema, dobbiamo fare in modo che il secondo account (account usato per eseguire il comando) sia un utente che faccia parte del gruppo Administrators del server ISA ( o del dominio).
Questa operazione è possibile utilizzando la SP sp_xp_cmdshell_proxy_account che permette di specificare con quale utente di windows deve essere eseguito il comando esterno.


Abilitazione credenziali alternative per xp_cmdshell
EXEC sp_xp_cmdshell_proxy_account <Administrator>,<password>

Sostituire i valori tra < > con un account valido e facente parte del gruppo administrators di windows (usare la notazione DOMINIO\user in caso di utente di domino) e la relativa password.

ATTENZIONE:
L'account specificato nelle credenziali alternative (xp_cmdshell_proxy_account) verrà usato solo ed esclusivamente se l'account con cui si esegue la funzione xp_cmdshell non è un sysadmin.

Gli scenari che si sviluppano a questo punto sono due:
1) Server Login con utente sysadmin
2) Server login con utente non sysadmin

In entrambi gli scenari saremo costretti a creare un account non sysadmin che abbia i permessi di esecuzione sulla funzione xp_cmdshell.

Creazione account
CREATE LOGIN giulio WITH PASSWORD = '1234' CREATE USER giulio FROM LOGIN giulio

In questo esempio ho creato un account chiamato "giulio" abilitato anche al login.
Nel nostro scenario specifico, "giulio" dovrà essere creato a livello di database master e anche di database FTPlog.
Ora è necessario abilitarlo alla esecuzione della funzione xp_cmdshell come da esempio qui riportato :
GRANT EXECUTE ON xp_cmdshell TO giulio

A questo punto, se ci connettiamo al DB come sysadmin, nella esecuzione del trigger, prima della esecuzione del comando xp_cmdshell, dovremo inserire la seguente riga (vedi esempio trigger sopra riportato) :
' Impersono l'utente non sysadmin chiamato giulio
EXECUTE AS login = 'giulio'

' Eseguo il comando. Verranno usate le credenziali alternative
EXEC master ..xp_cmdshell @CMD;

' Ripristino l'account originale di connessione
REVERT

In questo modo impersoniamo per un attimo l'utente giulio che non essendo un sysadmin permetterà alla funzione xp_cmdshell di usare le credenziali alternative specificate in precedenza, in modo da eseguire con successo lo script su Isa Server. Se invece ci connettiamo al DB (scelta consigliata in un ambiente di produzione) usando un account non sysadmin (Es. giulio), la riga:
EXECUTE AS login = 'giulio'

REVERT
non sarà necessaria.

ISA Server 2006
Per prima cosa è necessario creare un computer set che conterrà tutti gli IP bloccati.
Il nome del computer set deve rispecchiare il nome inserito all'interno dello script preposto ad aggiungere gli indirizzi ip bloccati. Nel nostro esempio si chiamerà FTPBlackList.

Fatto questo, è necessario informare ISA che deve bloccare l'accesso a tutti gli indirizzi IP contenuti in questo computer set.
Per farlo andremo ad inserire il computer set appena creato nelle Exceptions della regola di pubblicazione del server FTP.


In questo modo, l'accesso sarà consentito a tutti (Anywhere) tranne agli IP inseriti nelle Exceptions (FTPBlackList).

Script che alimenta il computer set con un ip passato a riga comando
Sub InserisciComputer(sNomeIpDaBloccare , sIpDaBloccare)
On Error Resume Next

 Dim cComputers
 Dim oComputer
 Dim cComputerSet
 Dim cComputerSets


 Set cComputerSets = oIsaArray.RuleElements.ComputerSets

  '--------------------------------------------------------
 ' Il nome inserito in ComputerSets.Item deve corrispondere  ' al computer set creato su ISA
 Set cComputerSet = cComputerSets.Item("FTPBlackList")
 Set cComputers = cComputerSet.Computers

 Set oComputer = cComputers.Add(sNomeIpDaBloccare, sIpDaBloccare)

 cComputers.Save
 Call KillTcp(sIpDaBloccare)
 End Sub


Una attenzione particolare va riservata alla sub KillTCP e al motivo della sua esistenza. Come ben sa chi usa ISA Server, alcune modifiche alle access rule e/o publisher rule diventano operative solo per le nuove connessioni e non per le connessioni attive al momento della modifica.
Nel nostro scenario questa considerazione riveste un' importanza fondamentale perché fino a che la sessione cattiva non verrà chiusa, il nostro utente, potrà continuare ad inviare UserName e Password praticamente all'infinito anche se inserito nella blacklist.
Con stupore mi sono accorto che ISA non visualizza da nessuna parte (tranne che nei log) la connessione attiva , questo significa che non è "killabile" via script usando gli oggetti disponibili nella mmc di ISA | Monitoring | Connection.
Purtroppo mi sono anche accorto che non esiste un comando di OS che permetta di "killare" una sessione TCP/UDP attiva.
In realtà esistono delle utility che sono in grado di recuperare l'id del processo che mantiene attiva la connessione e di "killarlo", ma questo comporterebbe la morte definitiva (fino ad successivo riavvio) del servizio incriminato, nel nostro caso la pubblicazione del server FTP.
Quindi, usando questa tecnica, otterremmo che il notro server FTP non sarebbe più raggiungibile da nessuno attraverso internet dato che andremmo a "killare" il processo che mantiene attivo il listner sul protocollo FTP usato dalla regola di pubblicazione.
Cercando un po' in giro per la rete, ho verificato che non esiste (o per lo meno non l'ho trovato) un tool per windows che sia in grado di "killare" una connessione TCP/UDP a riga comando.
Esiste un tool della sysinternals (ora Microsoft) chiamato TCPView che è in grado di "killare" una connessione TCP/UDP, ma non funziona a riga comando.
A questo punto l'unica alternativa era scriversi un tool che facesse al nostro caso. Il tool in questione si chiama KillTcpConn.exe ed stato scritto sia in VB6 che in .NET; funziona a riga comando, passando come parametro l'ip remoto della sessione TCP da "killare". Nell'appendice a questo articolo alcuni dettagli sul codice sorgente (APPENDICE A)

E qui arriviamo alla nostra SUB KillTCP che non fa altro che eseguire il programma sopra descritto utile a "killare" la connessione attiva.


Sub KillTCP(IpAddress)
 Set obj = WScript.CreateObject("WScript.Shell")
 obj.Run "C:\script\KillTcpconn.exe " & IpAddress
end sub


FTP Server
Bene, a questo punto non ci resta che alimentare la tabella InternetLog con i LOG del server FTP. Sul server FTP, per prima cosa, dobbiamo crearci un DSN di connessione al nostro server SQL.
Da strumenti di amministrazione, apriamo la MMC Origine Dati (ODBC) , selezioniamo il TAB DSN di sistema | Aggiungi, assegnamo un nome al nostro DSN - es. FTPSQLLOG - e selezioniamo il server SQL precedentemente installato.


La parte dell'autenticazione è fondamentale per il corretto funzionamento degli script, così come descritto nella parte dedicata alla funzione xp_cmdshell


Selezioniamo il DB che contiene le tabelle sopra descritte

Eseguiamo un test per verificare la connettività

Verificato il corretto funzionamento del nostro DSN possiamo procedere con lo spostare i LOG del notro server FTP dal file di testo a ODBC.
Apriamo IIS e andiamo nelle proprietà del notro server FTP. Verifichiamo che il check Consenti registrazione attività sia selezionato e che in formato registro attivo ci sia ODBC.

Nelle proprietà è necessario specificare il nome del DB - es. FTPSQLLOG -, la tabella - es. internetLog - e le credenziali di connessione al server SQL.

Terminata questa operazione, il nostro sistema è operativo e non ci resta che testarlo per verificarne la corretta funzionalità.

Test di funzionamento
Il primo test da eseguire è la corretta alimentazione della tabella InternetLog.
Questa operazione è possibile dalla MMC di SQL Server con una query (select) sulla tabella.

A questo punto possiamo provare il primo trigger, quello inserito a livello di tabella InternetLog dedicato ad alimentare la tabella BlackList con l'ip ed il numero di tentativi di login falliti. A questo scopo, andiamo in riga comandi e colleghiamoci al sito ftp :

Iniziamo ora inserire user name e password errati così da raggiungere i tentativi di login errati impostati in maniera da innescare il secondo trigger - es. 5 tentativi -.

A questo punto, sempre dalla MMC di SQL Server andiamo a verificare con una query sulla tabella BlackList che sia stato inserito l'ip del nostro client ed il numero di tentativi falliti.
Questo indica che il primo trigger funziona correttamente. Ora dobbiamo verificare anche il secondo trigger e per farlo facciamo un altro tentativo di login errato - superando cosi' il valore limite di 5 impostato -.

Come possiamo vedere dall'immagine, il server ci ha chiuso la connessione. Questo significa che il secondo trigger ha funzionato e che è stata seguita la SUB che "killa" la connessione TCP.
Ora se proviamo a ricollegarci al server FTP, il nostro tentativo verrà inesorabilemte rifiutato da ISA server.

Il nostro obiettivo è stato raggiunto ed il nostro cattivo è stato buttato fuori ed inserito nella BlackList di ISA server che ne impedirà connessioni future.

Di seguito le Appendici A e B scaricabili in formato PDF.
Appendice A e B

Buon Lavoro con ISAserver.it

Giulio Martino

Riferimenti
http://www.isaserver.it/articoli
http://www.isaserver.it/forum
http://www.voipexperts.it
http://www.isascripts.org

Codici di stato IIS

Codici di stato del campo Win32Status

IIS/FTP

Microsoft Technet
http://www.isaserver.it/articoli/20061128-GM04.asp

SQL Server

http://msdn2.microsoft.com/it-it/express/bb410792(en-us).aspx
http://msdn2.microsoft.com/it-it/library/ms165636.aspx
http://msdn2.microsoft.com/en-us/library/ms189799.aspx

Commenti sull'articolo
E' aperta una sezione sul forum di ISAserver.it chiamata "Caffè con gli Autori", dove è possibile discutere sugli articoli pubblicati.


ISAServer.it ed i suoi Autori non sono responsabili per danni di qualsiasi tipo - inclusi danni per perdita o mancato guadagno, interruzione dell'attivita', perdita di informazioni commerciali o altre perdite pecuniarie - derivanti o correlati all'utilizzo o all'incapacita' di utilizzo delle informazioni e degli esempi riportati - per quanto testati e funzionanti -. Le informazioni e gli script sono "cosi' come sono", senza garanzia di nessun tipo. L'intero rischio derivante dall'uso delle informazioni e degli script di esempio e' interamente a proprio carico. L'utilizzo è consentito solo accettando le presenti condizioni.
No banner in farm


ISAserver.it - No. 1 Unofficial European web site on Microsoft ISA Server / Forefront TMG

Pubblicità su ISAserver.it - Note d'uso - Privacy
Copyright© 2004-2008 Luca Conte Tutti i diritti riservati.