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