3.2 MODALITA' OPERATIVE
Come
già detto, Portsentry può essere eseguito in tre modalità operative(sia UDP che TCP): Classic mode, Stealth mode e
Advanced Stealth mode. A seconda della modalità di esecuzione e delle opzioni
configurate nel file portsentry.conf, il comportamento di Portsentry in
relazione alle scansioni sarà differente.
È importante notare che Stealth e Advanced Stealth Mode sono supportati solo sui sistemi Linux.
3.2.1 RILEVAZIONE DEI PORT SCAN
Il modo in cui Portsentry effettua la rilevazione
dei port scan dipende della modalità operativa utilizzata, consentendo così
all'utente di specificare la sensibilità con la quale reagire:
|
|
|
Quindi la principale
differenza tra la modalità classica e quelle nascoste sta nel fatto che nelle
ultime non viene effettuato il bind vero e proprio delle porte protette.
Un'ulteriore differenza a questo livello consiste
nel numero di porte che possono essere monitorizzate. Infatti nel Classic
Mode possono essere protette al più 64 porte, mentre l'ampiezza del range delle
porte protette in Advanced Stealth Mode è per default di 1024 porte e può
essere portato fino a 65535, che è il numero di porta più alta del sistema,
permettendoo così di monitorizzare tutte le porte dell'host protetto, anche se
questo non è consigliato.
Questo implica che le modalità nascoste sono le più
sensibili, ma, proprio per questo, anche le più soggette a falsi allarmi. Più
in dettaglio nelle modalità nascoste Portsentry è in grado di rilevare i
seguenti tipi di scansioni:
|
|
full
connect scan – Completa un three-handshake. |
|
|
SYN/Half open scan – Verifica solo se la porta è
in listening, poi manda un RST. |
|
|
FIN scan – Manda un FIN alla porta da attaccare,
se riceve in risposta un RST allora la porta è chiusa. |
|
|
NULL scan – Manda un pacchetto con tutti i flag
disabilitati alla porta da attaccare: l’output è uguale a quello del FIN scan. |
|
|
XMAS scan – Come il FIN scan, solo che manda un
pacchetto con FIN, URG e PUSH impostati. |
|
|
UDP scan (non è realmente uno scanning nascosto)
– Manda un pacchetto UDP alla porta da attaccare. Se riceve in risposta un
ICMP Port Unreacheable allora la porta è aperta. |
|
|
Qualsiasi altro pacchetto strano i cui flag non
corrispondano ai precedenti. |
Altra differenza importante è che le modalità nascoste
sono supportate solo da sistemi Linux.
La lista delle porte da proteggere è specificata
all'interno del file portsentry.conf, in particolare:
|
|
In
Classic Mode o Stealth Mode è necessario specificare la lista all'interno
della variabile TCP_PORTS per TCP (e rispettivamente UDP_PORTS per UDP) . I
numeri di porta devono essere separati da virgola e la lista non deve
contenere spazi. È possibile specificare quante porte si vogliono, ma
verranno monitorate solo le prime 64 che il programma è riuscito ad aprire. |
|
|
In
Advanced Stealth Mode bisogna specificare il più alto numero di porta da
monitorare nella variabile ADVANCED_PORTS_TCP ( ADVANCED_PORTS_UDP). Verranno
controllate tutte le porte al di sotto di questo valore tranne quelle presenti
nelle lista delle porte escluse associata alla variabile ADVANCED_EXCLUDE_TCP
(ADVANCED_EXCLUDE_UDP) e quelle che il sistema ha già legato a demoni di rete
quando il programma è lanciato. |
3.2.2 OPZIONI CONFIGURABILI
Come abbiamo detto in precedenza, Portsentry non è
soltanto un software per la rilevazione dei port scan, ma anche un software di
difesa attiva da questi ultimi. Questo significa che è in grado di reagire ai
port scan intraprendendo le azioni configurate nel suo file di configurazione
portsentry.conf. Anche in questo caso a modalità operative diverse
corrisponderanno comportamenti (e problemi) differenti.
Per ognuna delle modalità operative
(sia TCP che UDP) di Portsentry sono possibili due opzioni:
|
|
Opzione non
bloccante
|
|||
|
|
Opzione bloccante
|
In questo paragrafo analizzeremo
più in dettaglio queste opzioni e mostreremo degli esempi sul loro utilizzo.
3.2.2.1 OPZIONE NON BLOCCANTE
Il comportamento di Portsentry nell' opzione non
bloccante è lo stesso indipendentemente dalla modalità operativa utilizzata. In
questo caso infatti, quando è rilevato un tentativo di connessione ad una delle
porte protette, la connessione viene immediatamente
bloccata e viene registrato l'accaduto
nel file di log. Inoltre l’indirizzo IP dell’aggressore è registrato nel file
portsentry.blocked.
Il file portsentry.blocked contiene gli
indirizzi IP di tutti gli host bloccati durante l'attuale sessione di Portsentry.
Per riabilitare un host bloccato basterà quindi far ripartire PortSentry oppure
cancellare la sua entry nel file portsentry.blocked.
Tutti gli host inseriti in
portsentry.blocked sono memorizzati anche nel file portsentry.history, che a
differenza del primo, tiene memoria di tutti gli host che sono stati
bloccati nel tempo.
Per default i percorso dei file
portsentry.blocked e portsentry.history è /usr/local/psionic/portsentry.
È possibile indicare un percorso alternativo modificando
il valore delle variabili BLOCKED_FILE e HISTORY_FILE, contenute in
portsentry.conf.
3.2.2.1.1 ESEMPIO: CLASSIC MODE NON BLOCCANTE
In questo paragrafo descriveremo un
esempio di utilizzo di Portsentry in Classic Mode TCP non bloccante. Come già detto
precedentemente, il comportamento dello scan detector con l’opzione non
bloccante è indipendente dalla modalità operativa utilizzata, quindi sarà
simile anche nelle altre modalità.
Per vedere come Portsentry reagisce ad
un tentativo di connessione ad una porta protetta lanciamolo in modalità
classica tcp:
|
altafini:~
# /urs/local/psionic/portsentry/portsentry –tcp |
Andiamo adesso ad eseguire un telnet ad
una porta protetta da un host remoto, ad esempio:
|
tancredi:~
# telnet 193.205.161.191 11 Trying 193.205.161.191... Connected
to altafini.diareti.diaedu.unisa.it (193.205.161.191). Escape character is '^]'. ***
ACCESSO NON AUTORIZZATO!!! *** Connection closed by foreign host. |
La prima cosa da notare è che
Portsentry ha chiuso la connessione. Inoltre bisogna notare che Portsentry da
la possibilità di specificare un banner da visualizzare all'aggressore durante
i tentativi di connessione. Nel nostro caso il banner utilizzato è stata la
stringa: "*** ACCESSO NON AUTORIZZATO!!! ***"
Il contenuto del file di log in questo
caso sarà:
|
Sep 6 11:44:36 altafini
portsentry[1330]: attackalert: Connect from host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 11 Sep 6 11:44:36 altafini portsentry[1330]: attackalert:
Ignoring TCP response per configuration file
setting. |
Se adesso riproviamo a connetterci
all’host protetto da quello bloccato otteniamo lo stesso output di prima:
|
tancredi:~
# telnet 193.205.161.191 Trying 193.205.161.191... Connected
to altafini.diareti.diaedu.unisa.it (193.205.161.191). Escape character is '^]'. ***
ACCESSO NON AUTORIZZATO!!! *** Connection closed by foreign host. |
I messaggi inseriti nel file di log per
ogni tentativo di connessione successivo al primo saranno invece i seguenti:
|
Sep 6 11:54:55 altafini
portsentry[1370]: attackalert: Connect from host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 11 Sep 6 11:54:55 altafini
portsentry[1370]: attackalert: Host: 193.205.161.192 is already blocked. Ignoring Sep 6 11:54:57 altafini
portsentry[1370]: attackalert: Connect from host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 11 Sep 6 11:54:57 altafini
portsentry[1370]: attackalert: Host: 193.205.161.192 is already blocked. Ignorino
|
Per configurare il banner, cioè il
messaggio visualizzato all’aggressore durante i tentativi di connessione alle
porte del nostro sistema, basta modificare come desiderato la variabile PORT_BANNER,
contenuta nel file portsentry.conf. Se non si desidera questa caratteristica
basta lasciare questa opzione commentata. Non è possibile utilizzare questa
opzione con le modalità nascoste.
È possibile ottenere questa funzionalità andando a
porre nel file portsentry.conf :
|
|
BLOCK_TCP = 0 per TCP e BLOCK_UDP = 0 nel caso di UDP
|
3.2.2.2 OPZIONE BLOCCANTE
La caratteristica che rende Portsentry
uno strumento davvero potente contro i port scan è la possibilità di eseguirlo
in modalità bloccante. In questo modo infatti è possibile non soltanto rilevare
i tentativi di connessione alle porte messe sotto controllo, ma anche bloccare
i port scan sul sistema protetto rendendolo irraggiungibile all’host
aggressore.
Schematicamente Portsentry, configurato
in modo da utilizzare l'opzione bloccante, opera nel seguente modo:
|
|
rileva i tentativi di connessione alle porte
messe sotto controllo |
|
|
li registra in un file
di log |
|
|
registra l'indirizzo IP dal quale
proviene il port scan nei file portsentry.blocked e host.deny |
|
|
impedisce agli host
"incriminati" di ricevere pacchetti in risposta alla loro scansione |
.
Il file host.deny è utilizzato dai TCP
wrapper (programmi che forniscono sicurezza aggiuntiva alle applicazioni che utilizzano TCP/IP) per registrare gli
indirizzi IP degli host a cui inibire l'accesso ai servizi di rete.
Disabilitare le risposte alle scansioni
ha un duplice effetto. In primo luogo, durante uno scan TCP l'host bloccato non
riceverà nessuna risposta alla sua scansione. Conseguenza di questo è che
l'host protetto diventerà irraggiungibile da qualsiasi host bloccato. In
secondo luogo, durante uno scan UDP tutte le porte del sistema protetto
sembreranno aperte. Infatti poiché i messaggi dall'host protetto all'host
bloccato sono disabilitati, neanche i messaggi ICMP port unreacheable che
indicano che una porta è chiusa arriveranno all'aggressore, facendogli credere
che siano tutte aperte.
È possibile disabilitare le risposte ai
port scan in due modi:
|
|
Introducendo una nuova regola di routing
per indirizzare tutti i pacchetti provenienti dall’IP dell’aggressore verso
un indirizzo fasullo o all’indirizzo di localhost. |
|
|
Utilizzando un packet filter (come
ipfwadm/ipchains per Linux o ipfw per *BSD). |
La modifica alla tabella di routing
dell'host protetto è realizzata configurando correttamente la varialile
KILL_ROUTE contenuta in portsentry.conf. In pratica la nuova regola di routing
è creata utilizzando il comando di sistema route e, nei sistemi più moderni,
l’opzione ‘-reject’.
Bisogna essere a conoscenza del fatto
che configurando il parametro KILL_ROUTE viene creata una "asynchronous
route", cioè i pacchetti arrivano all'host tramite una strada e ne escono
tramite un’altra. Sebbene non ci siano problemi nel caso di richieste di tipo
full TCP connect, ce ne potrebbero essere nel caso di UDP e nel caso di
utilizzo delle modalità nascoste. Infatti potrebbero essere generati una serie
di allarmi "already blocked" e questo potrebbe essere all'origine di un
attacco di tipo Denial of Service. Ad esempio nel caso di UDP scan, sebbene
un’aggressore non ottiene nessun messaggio ICMP in risposta agli scan, potrebbe
continuare ad inviare un flusso pacchetti che, raggiungendo il nostro host,
farebbero attivare Portsentry in continuazione.
Il metodo più pulito per disabilitare
le risposte ai port scan è quello di uilizzare un packet filter. Questo metodo
peraltro è quello raccomandato.
Questa opzione è possibile ponendo nel
file portsentry.conf:
|
|
BLOCK_TCP = 1 per
TCP e BLOCK_UDP = 1 per UDP |
|
|
Settando
adeguatamente il valore di KILL_ROUTE o il racket filter
utilizzato |
3.2.2.2.1 ESEMPIO: CLASSIC MODE BLOCCANTE
In questo paragrafo descriveremo un
esempio di utilizzo di Portsentry in Classic Mode TCP bloccante effettuato
abilitando il parametro KILL_ROUTE.
Per vedere come Portsentry reagisce ad
un tentativo di connessione ad una porta protetta lanciamolo in modalità
classica tcp:
|
altafini:~
# /urs/local/psionic/portsentry/portsentry –tcp |
Andiamo adesso ad eseguire un telnet ad
una porta protetta da un host remoto, ad esempio:
|
tancredi:~
# telnet 193.205.161.191 11 Trying 193.205.161.191... Connected to altafini.diareti.diaedu.unisa.it
(193.205.161.191). Escape character is '^]'. ***
ACCESSO NON AUTORIZZATO!!! *** Connection closed by foreign host. |
Il contenuto del file di log in questo
caso sarà:
|
Jul
4 13:43:06 altafini portsentry[839]: attackalert: Connect from host:
tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 11 Jul 4 13:43:06 altafini portsentry[839]:
attackalert: Host 193.205.161.192 has been blocked via wrappers with string:
"ALL: 193.205.161.192" Jul 4 13:43:06 altafini portsentry[839]:
attackalert: Host 193.205.161.192 has been blocked
via dropped route using command: "/sbin/route add -host 193.205.161.192
reject" |
Controllando i cambiamenti avvenuti
nella tabella di routing dell’host protetto possiamo notare la presenza di una
riga aggiuntiva con flag !H che indica un reject dei pacchetti provenienti
dall’host a cui essa si riferisce. Nel nostro caso avremo:
|
altafini:~
# netstat –rn |
|||||||
|
Destination |
Gateway |
Genmask |
Flags |
MSS |
Window |
irtt |
Iface |
|
193.205.161.192 |
- |
255.255.255.255 |
!H |
- |
- |
- |
- |
|
193.205.161.0 |
0.0.0.0 |
255.255.255.0 |
U |
0 |
0 |
0 |
eth0 |
|
127.0.0.0 |
0.0.0.0 |
255.0.0.0 |
U |
0 |
0 |
0 |
Lo |
|
0.0.0.0 |
193.205.161.184 |
0.0.0.0 |
UG |
0 |
0 |
0 |
eth0 |
Se adesso riproviamo a connetterci
all’host protetto da quello bloccato otteniamo:
|
tancredi:~
# telnet 193.205.161.191 Trying 193.205.161.191... |
L’host protetto è diventato quindi
irraggiungibile e Portsentry non si attiverà più in risposta ai pacchetti
inviatigli dall’attaccante.
3.2.2.2.2 ESEMPIO: ADVANCED STEALTH MODE BLOCCANTE
Descriveremo adesso un esempio di
utilizzo di Portsentry in Advances Stealth Mode TCP bloccante, sempre
abilitando il parametro KILL_ROUTE.
A questo scopo lanciamo Portsentry in
modalità avanzata tcp:
|
altafini:~
# /urs/local/psionic/portsentry/portsentry –atcp |
Eseguendo adesso un telnet ad una porta
protetta da un host remoto, otteniamo:
|
tancredi:~
# telnet 193.205.161.191 143 Trying 193.205.161.191... telnet: Unable to connect
to remote host: Connection refused |
Il contenuto del file di log sarà molto
simile a quello dell'esempio precedente:
|
Jul
4 12:54:00 altafini portsentry[1826]: attackalert: SYN/Normal scan from host:
tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 143 Jul 4 12:54:00 altafini
portsentry[1826]: attackalert: Host 193.205.161.192 has been blocked via
wrappers with string: "ALL: 193.205.161.192" Jul 5 12:12:22 altafini
portsentry[9183]:attackalert:Host 193.205.161.192 has been blocked via
dropped route using command: "/sbin/route add -host 193.205.161.192
reject" |
Anche questa volta l’host protetto
risulterà irraggiungibile all’aggressore. Tuttavia i pacchetti provenienti
dall'host attaccante continueranno ad arrivare all'host protetto (anche se non
otterranno risposta) e, a differenza della modalità classica, Portsentry
continuerà ad attivarsi.
Quindi, ad esempio, continuando ad
eseguire il telnet sulla porta 143 dall'host bloccato, Portsentry genererà una
serie di messaggi di questo tipo:
|
Jul 5 12:12:26 altafini portsentry[9183]: attackalert: SYN/Normal scan
from host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 143 Jul 5 12:12:26 altafini portsentry[9183]:
attackalert: Host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 is
already blocked Ignoring Jul 5 12:12:29 altafini portsentry[9183]:
attackalert: SYN/Normal scan from host:
tancredi.diareti.diaedu.unisa.it/193.205.161.192 to TCP port: 143 Jul 5 12:12:29 altafini portsentry[9183]:
attackalert: Host: tancredi.diareti.diaedu.unisa.it/193.205.161.192 is
already blocked Ignoring . . . |
Questo modo di reagire alle
scansioni può essere alla base di un attacco di tipo Deniall of System. Per
approfondire questo punto vedere il paragrafo 5.