Impostiamo nel NUM nella sezione Policy voce Filtering lo slot di filtraggio creato in modo wizard da NETASQ chiamato Low. L’output ottenuto risulterà essere:

Filter
0  :0  : skip 5 proto tcp from any to any port 113
0  :0  : reset on Dialup3 proto tcp from any to dynamic 0.0.0.0 port 113
0  :0  : reset on Dialup2 proto tcp from any to dynamic 0.0.0.0 port 113
0  :0  : reset on Dialup1 proto tcp from any to dynamic 0.0.0.0 port 113
0  :0  : reset on Dialup0 proto tcp from any to dynamic 0.0.0.0 port 113
0  :0  : reset on Out proto tcp from any to 151.8.xx.xxx port 113
0  :0  : pass on Out proto tcp from any to 151.8.xx.xxx port 1723
0  :0  : pass on Out proto gre from any to 151.8.xx.xxx
0  :0  : skip 3 on In proto tcp from any to any
0  :0  : pass attach stream on In proto tcp from any to dynamic 0.0.0.0 port 1300
0  :0  : pass attach stream on In proto tcp from any to dynamic 0.0.0.0 port 22
0  :0  : pass on In proto tcp from any to 127.0.0.1 port 8080
0  :0  : pass on loopback from any to any
0  :0  : pass asq noprobe on loopback5 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on loopback4 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on loopback3 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on loopback2 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on loopback dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP15 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP14 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP13 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP12 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP11 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP10 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP9 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP8 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP7 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP6 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP5 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP4 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP3 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP2 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP1 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on PPTP0 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Dialup3 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Dialup2 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Dialup1 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Dialup0 dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Dmz dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on Out dynamic from 0.0.0.0 to any
0  :0  : pass asq noprobe on In dynamic from 0.0.0.0 to any
2  :1  : skip 19 from 10.0.0.0:10.0.0.255 to any
2  :1  : pass attach dns proto udp from 10.0.0.0:10.0.0.255 to any port 53
2  :1  : pass attach edonkey proto tcp from 10.0.0.0:10.0.0.255 to any port 4662
2  :1  : pass attach ftp proto tcp from 10.0.0.0:10.0.0.255 to any port 21
2  :1  : pass attach h323 proto tcp from 10.0.0.0:10.0.0.255 to any port 1720
2  :1  : pass attach http proto tcp from 10.0.0.0:10.0.0.255 to any port 80
2  :1  : pass attach http proto tcp from 10.0.0.0:10.0.0.255 to any port 8080
2  :1  : pass attach ssl proto tcp from 10.0.0.0:10.0.0.255 to any port 443
2  :1  : pass attach imap4 proto tcp from 10.0.0.0:10.0.0.255 to any port 143
2  :1  : pass attach ssl proto tcp from 10.0.0.0:10.0.0.255 to any port 993
2  :1  : pass attach ssl proto tcp from 10.0.0.0:10.0.0.255 to any port 5223
2  :1  : pass attach ssl proto tcp from 10.0.0.0:10.0.0.255 to any port 636
2  :1  : pass attach nntp proto tcp from 10.0.0.0:10.0.0.255 to any port 119
2  :1  : pass attach pop3 proto tcp from 10.0.0.0:10.0.0.255 to any port 110
2  :1  : pass attach ssl proto tcp from 10.0.0.0:10.0.0.255 to any port 995
2  :1  : pass attach rip proto udp from 10.0.0.0:10.0.0.255 to any port 520
2  :1  : pass attach smtp proto tcp from 10.0.0.0:10.0.0.255 to any port 25
2  :1  : pass attach smtp proto tcp from 10.0.0.0:10.0.0.255 to any port 8081
2  :1  : pass attach ssh proto tcp from 10.0.0.0:10.0.0.255 to any port 22
2  :1  : pass attach telnet proto tcp from 10.0.0.0:10.0.0.255 to any port 23
2  :2  : pass from 10.0.0.0:10.0.0.255 to any

Analizziamo la sintassi delle regole impostate all’interno di NETASQ. Genericamente vengono strutturate in questo modo:

Riportiamo ora i dati precedenti in formato strutturato seguendo la struttura appena definita e numerando le righe in modo tale da semplificare i commenti:

Le possibili azioni di una regola sono: SKIP, PASS, RESET, BLOCK, LOG

SKIP
Nel caso in cui la regola venga matchata salta il numero di regole successive specificato nell’argomento della regola ad esempio la regola numero 1 dice:
skip 5 proto tcp from any to any port 113
Nel caso in cui un pacchetto TCP proveniente da chiunque e destinato a chiunque sulla porta 113 salta le 5 regole successive e quindi l’analisi delle regole procede alla riga 7.

PASS
Nel caso in cui la regola venga matchata il pacchetto passa senza ulteriori analisi. Questa è una differenza sostanziale rispetto alla tecnologia di filtering BSD dove in realtà il pass ed il block applicano un flag al pacchetto, ma l’analisi delle regole procede fino al termine. Nel caso di NETASQ la prima regola valida viene eseguita indipendentemente da quello che segue.

RESET/BLOCK
Nel caso in cui la regola venga matchata il pacchetto viene bloccato senza ulteriori analisi.
La differenza tra le due è la reazione ovvero nel caso di BLOCK il pacchetto viene sostanzialmente scartato, mentre nel caso di reset viene inviato un pacchetto di tipo RST in risposta. In modo molto banale nel caso in cui vi sia un BLOCK il chiamante otterrà dopo un certo lasso di tempo un “connection timeout” mentre nel caso di reset il chiamante otterrà istantaneamente un “connect reset by peer”.

LOG
Nel caso in cui la regola venga matchata il pacchetto viene tracciato nei log. Non verrà eseguita nessuna operazione ne di pass ne di block, ma semplicemente tracciato. All’interno di NUM viene definita come azione “None” ovvero nessuna azione. In realtà nessuna azione significa LOG.

Analizziamo in dettaglio tutta la tabella di regole per capire con precisione come ragiona il nostro Firewall NETASQ. I caso sono infiniti lascio a voi il compito di creare situazioni particolari in termine di regole e confrontare il risultato ottenuto a livello di sistema. Darò per scontato che la regola viene eseguita solo se si verifica un match.

1 skip 5 proto tcp from any to any port 113
Salta le prossime 5 regole se la connessione è TCP ed è destinata alla porta 113. La porta 113 è la porta auth, nel caso in cui vogliate vedere la corrispondenza porta standard / service all’interno dell’apparato NETASQ è presente un file specifico e si trova nella directory etc chiamato services. Nota interessante, quando andate tramite la funzione Object a definire nuove porte il file /etc/services viene aggiornato di conseguenza. Ad esempio io ho creato una nuova porta non standard per il servizio VNC e la ritrovo in /etc/service mappata come:

vnc_5501                 5501/tcp

2,3,4,5,6 reset on XXX proto tcp from any to [HOST] port 113
Le 5 regole successive sono tutti identiche l’unica cosa che cambia è l’interfaccia su cui resettare il pacchetto destinato alla porta 113. Questa combinazione di regole dalla 1 alla 6 sono strutturate in modo tale da fornire un default ovvero inizialmente la comunicazione verso la porta 113 viene intercettata e non definita ovvero si lascia l’analisi alle regole successive al blocco. Di default NETASQ blocca quello che non conosce quindi sommado le circostanze le comunicazioni alla porta 113 vengono bloccate. Togliendo la regola 1 è possibile intervenire singolarmente per interfaccia ovvero posso cambiare la regola sulla OUT, ma non sulle interfacce Dialup. Questo stratagemma viene utilizzato spesso come vedremo anche in seguito e forse risulterà essere anche più chiaro.

7 pass on Out proto tcp from any to 151.8.xx.xxx port 1723
Consente le connessioni tcp destinate all’IP presente sull’interfaccia OUT sulla porta 1723. Come potrete vedere da services la porta è quella del servizio PPTP ovvero Point to Point Tunnelling Protocol.

8 pass on Out proto gre from any to 151.8.xx.xxx
Questa regola è differente dalla precedenti perchè non si parla più di connessioni tramite il protocollo TCP, ma tramite il protocollo GRE ovvero Generic Routing Encapsulation. Questo protocollo viene utilizzato nelle connessioni PPTP e non è caratterizzato dall’utilizzo di porte quindi nella regola viene semplicemente specificato che il sistema deve accettare connessioni destinate all’IP presente sull’interfaccia OUT e di tipo GRE.

9 skip 3 on In proto tcp from any to any
Il funzionamento dell’azione skip è già stato spiegato

10 pass attach stream on In proto tcp from any to dynamic 0.0.0.0 port 1300
E’ il primo caso in cui troviamo l’opzione attach tipica di NETASQ. Tramite attach si dice al sitema ASQ di aggangiare alla comunicazione la plugin specifica in questo caso stream. La porta coinvolta è la 1300 TCP ovvero il servizio che consente la comunicazione tra l’apparato NETASQ ed il NUM. Le plugin meritano un discorso a se stante che affronterò in articoli specifici.

11 pass attach stream on In proto tcp from any to dynamic 0.0.0.0 port 22
Identica alla regola 10, ma la porta di riferimento è la 22 ovvero SSH, l’accesso remote console per le appliance NETASQ.

12 pass on In proto tcp from any to 127.0.0.1 port 8080
Regola molto interessante, per la prima volta vediamo qualche riferimento al sistema di proxy integrato in NETASQ. Nota importantissima che salverà ore e ore di debug ai meno attenti, la parola proxy in realtà è leggermente fuorviante ovvero gli apparati NETASQ non sono dotati di quello che genericamente definiamo proxy ovvero un software in ascolto sulla porta 8080 o 3128 che si occupa di dialogare con l’esterno al posto del client. In realtà NETASQ usa una tecnologia di transparent proxy non pura. Per chi avesse già lavorato in transparent proxy sa che le richieste di navigazione vengono intercettate e instradate a forza verso un nostro proxy che agisce come sopra ovvero interponendosi tra il client ed il server. Nel caso NETASQ non è corretta completamente la definizione transparent proxy inquanto non vi è interposizione, ma semplicemente redirezione e controllo. Al nostro interno in modo decisamente esotico preferiamo definirlo un transparent redirected content analysis. Tornando alla regola vengono consentite tutte le connessioni destinate al localhost porta 8080. Ovvero il proxy di NETASQ (tproxyd ricordatelo) è in ascolto sulla porta 8080.

13 pass on loopback from any to any
E’ consentita la comunicazione sulla interfaccia loopback da chiunque a chiunque. Le interfacce loopback definite in NETASQ sono lo0, lo1, lo2, lo3, lo4, lo5 di cui l’unica configurata di default è la lo0 con indirizzo IP 127.0.0.1.

14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41 pass asq noprobe on [INTERFACE] dynamic from 0.0.0.0 to any
Questo set di regole decisamente particolari specificano che su tutte le interfacce presenti all’interno del sistema ad esclusione delle VLAN venga disattivato il motore di analisi ASQ per i pacchetti generati da 0.0.0.0 destinati a chiunque. Per 0.0.0.0 si intende l’apparato stesso. Sostanzialmente si considera l’apparato stesso trusted ovvero si suppone che non generi mai bogus packet.

42 skip 19 from 10.0.0.0:10.0.0.255 to any
Il funzionamento dell’azione skip è già stato spiegato

43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61 pass attach [PLUGIN] proto [PROTO] from [SOURCE] to any port [PORT]

Queste regole vengono utilizzare per agganciare le specifiche plugin al motore ASQ. In particolare le regole vengono applicate a tutta la rete interna destinata a qualsiasi destinazione. Anche in questo caso abbiamo un’esempio di gestione dei default. Per come è strutturato il flusso tutte le regole vengono bypassate. Eliminando lo skip è possibile determinare singolarmente le plugin da attivare.

62 pass from 10.0.0.0:10.0.0.255 to any
Come ultima regola si abilita il traffico della rete interna verso qualsiasi destinazione.

Prima di tutto è indispensabile capire qualche interfaccia di rete vogliamo catturare. Il comando:

Consente di visualizzare lo stato e la configurazione delle interfacce di rete presenti all’interno del NETASQ. Nel caso di un’apparato F50 dovreste visualizzare in modo riassuntivo qualcosa come:

fxp0: flags=18843 mtu 1500
        options=40
        inet 151.8.xx.xxx netmask 0xfffffff0 broadcast 151.8.xx.xxx
        ether 00:0d:b4:01:d4:aa
        media: Ethernet autoselect (100baseTX )
        status: active
fxp1: flags=18843 mtu 1500
        options=40
        inet 10.0.0.xxx netmask 0xffffff00 broadcast 10.0.0.255
        inet 192.168.113.x netmask 0xffffff00 broadcast 192.168.113.255
        ether 00:0d:b4:01:d4:ab
        media: Ethernet autoselect (100baseTX )
        status: active
fxp2: flags=8802 mtu 1500
        options=40
        ether 00:0d:b4:01:d4:ac
        media: Ethernet autoselect (none)
        status: no carrier
...

Tabella di riferimento per il nome delle interfacce di rete:

Ricordate e ve lo ricorderò spesso che in fase di debug pacchetti non è sufficiente intercettare il traffico su una singola interfaccia, ma dobbiamo simultaneamente catturare il traffico su tutte le interfacce coinvolte in modo tale da poter visualizzare il comportamento del motore ASQ sul pacchetto in transito, evidenziarne alterazioni, ecc… ecc…
Ora vediamo come catturare e visualizzare traffico direttamente in console SSH per una interfaccia specifica. Utilizziamo il comando:

Vedrete qualcosa come:

21:04:54.617802 84.55.101.46.27589 > Firewall_Out.46237: udp 42
21:04:58.453413 209.30.162.15.53425 > Firewall_Out.46237: udp 63 [tos 0x50]
21:04:58.499389 86.66.186.130.49102 > Firewall_Out.46237: udp 63
21:05:00.294453 151.59.184.69.55006 > Firewall_Out.46237: S 939509183:939509183(0) win 65535  (DF)
21:05:00.479660 Firewall_Out.14191 > 198.41.0.4.domain_udp:  0+ A? webupdate.netasq.com. (38)
21:05:00.596345 198.41.0.4.domain_udp > Firewall_Out.14191:  0- 0/13/14 (510) (DF)
21:05:00.934854 arp who-has ns.nextrem.it tell 151.8.98.230
21:05:01.504882 10.0.0.133.37337 > 239.255.255.250.ssdp: udp 296 (DF)
21:05:01.602547 81.57.18.159.61283 > Firewall_Out.46237: udp 65

Se tutto questo vi dovesse risultare totalmente incomprensibile vi consiglio di utilizzare il link all’inizio per leggere qualche informazione ulteriore riguardo al tcpdump ed ai protocolli IP. Tuttavia vi potrebbe essere richiesto di eseguire questa operazione direttamente dal supporto tecnico NETASQ o da me Vi consiglio quindi di procedere comunque nella lettura.

A volte l’analisi visiva è sufficiente per determinare l’origine del problema, molto spesso invece è necessario salvare il traffico ed analizzarlo in modalità offline in tutta calma. Fortunatamente tcpdump ci mette a disposizione la funzionalità necessaria per salvare il traffico catturato su file in formato pcap. Per chi fosse interessato ad approfondire l’argomento pcap consiglio caldamente il sito: www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
Il comando per catturare il traffico e salvarlo in formato PCAP è il seguente:

Nel dettaglio tramite l’opzione -i si specifica l’interfaccia da cui catturare il traffico, -s0 specifica lo snaplen ovvero la lunghezza massima del pacchetto da catturare in questo caso viene specificato 0 ovvero non vogliamo porre nessun limite e catturare l’intero pacchetto. Tramite -w specifichiamo su che file vogliamo salvare i pacchetti catturati. Nota importante: nei modelli NETASQ fino a F60 non è presente un’hard disk interno conseguentemente lo spazio disponibile è veramente poco indicativamente 15MB sulla flash e 8MB sul ramdisk. Quindi portate molta attenzione alla dimensione del file pcap su reti trafficate il file raggiunge la dimensione di 1MB in pochi secondi, se si dovesse riempire il disco beh lascio a voi immaginare le conseguenze…
Tornando a noi per interrompere il processo di cattura pacchetti basta premere CTRL+C. Ora per copiare il file generato sulla vostra macchina è indispensabile utilizzare il protocollo SCP. Per gli utenti MAC e Linux il comando scp è disponibile nel sistema operativo e per effettuare il download del file basta eseguire dalla workstation il comando:

Dove 10.0.0.x è l’indirizzo IP del vostro apparato NETASQ. Per gli utenti Windows è disponibile sia lo stesso comando in versione command line che un pratico software ad interfaccia grafica. Il primo è reperibile all’indirizzo: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html e si chiama pscp.exe, mentre il secondo lo trovate all’indirizzo: http://winscp.net/ ed è chiamato WinSCP.
Il file appena scaricato risulta essere in formato binario e conterra (espresso in esadecimale) qualcosa come:

0156600      2fe8    00e0    b40d    d401    08aa    4500    0000    5134
0156620      409b    4000    7d06    976e    6208    4ae2    277d    0753
0156640      005b    de50    5162    d7ff    f35e    80cb    e210    2cf8
0156660      00a3    0100    0801    250a    7170    c1a3    9f3d    32dd
0156700      e68d    aa48    0bff    4200    0000    4200    0000    0000
0156720      7b10    2fe8    00e0    b40d    d401    08aa    4500    0000

Ovviamente non è possibile utilizzare il semplice file, è indispensabile utilizzare un software in grado di convertire, parsare ed analizzare il file PCAP. Esiste un programma gratuito ed open source chiamato Wireshark disponibile per MAC, Linux e Windows in grado di effettuare questa analisi. Lo potete scaricare all’indirizzo: http://www.wireshark.org/
Una volta installato e laciato apparirà la schermata iniziale dell’applicazione:

Wireshark

Ora tramite la funzione File->Open potete caricare il file dump.pcap direttamente all’interno di Wireshark e vedrete qualcosa come:

Wireshark complessivo traffico

Selezionando un pacchetto è possibile vedere nel pannello inferiore il dettaglio del pacchetto stesso a titolo esemplificativo vi riporto un pacchetto:

Wireshark dettaglio pacchetto

Ora avete a disposizione tutti gli strumenti per poter effettuare un’analisi approfondita del pacchetto o per potervi interfaccia con un tecnico di supporto NETASQ. Manca solo da precisare come poter catturare simultaneamente due interfacce di rete. Per fare ciò è sufficiente concatenare due comandi tcpdump. In realtà di sfrutta l’operatore & per mandare in esecuzione background il primo comando e consentire l’esecuzione dei successivi ad esempio:

In questo caso per interrompere il processo di intercettazione pacchetti non basterà premere CTRL+C perchè veerà interrotto solo il secondo comando, mentre il primo continuerà ad essere in esecuzione in background. Per poter interrompere anche il primo basterà eseguire il comando:

Una piccola nota in calce… sarebbe utile soprattutto per i modelli senza hard disk avere la possibilità di montare filesystem remoti NFS purtroppo per me e per voi pare che questo non sia possibile speriamo nelle prossime release di firmware…

• WhiteList
• BlackList
• WhiteListExclude
• BlackListExclude
• MonitoredHost
• HostExclude

Vediamo ora la corrispondenza in NUM di queste liste. Negli esempi verrà utilizzato l’oggetto host “dummy_host” avante indirizzo IP “1.2.3.4” ed il range “dummy_range” avente indirizzi IP da “1.2.3.4” a “1.2.255.255”.
Inseriamo la seguente regola in “Instrusion Prevention”->”Lists”->”Blacklist / Quarantine”:

Eseguiamo ora il comando di visualizzazione della tabella addrlist:

L’output ottenuto risulterà essere:
BlackList:

Se inseriamo la regola:

Eseguiamo ora il comando di visualizzazione della tabella addrlist:
BlackList:

Quindi è possibile specificare sia host singoli che range di indirizzi che reti. Nel caso in cui venga specificato un range od una rete sarà possibile specificare l’esclusione di uno o più host.
Inseriamo la seguente regola in “Instrusion Prevention”->”Lists”->”Blacklist / Quarantine”:

Inseriamo la seguente regola in “Instrusion Prevention”->”Lists”->”Blacklist / Quarantine”->”Exclusion”:

Eseguiamo ora il comando di visualizzazione della tabella addrlist:
BlackList:

BlackListExclude:

Inseriamo la seguente regola in “Instrusion Prevention”->”Lists”->”Bypass”:

Eseguiamo ora il comando di visualizzazione della tabella addrlist:
WhiteList:

Da ricordare che la white list all’interno dell’instrusion prevention non solo sospende tutte le politiche di controllo ai fini di intrusioni, ma anche le policy di filtering sostanzialmente considerando l’host selezionato e le sue comunicazioni (interne ed esterne) di tipo totally trusted.

Queste informazioni vengono scritte all’interno degli slot di configurazione di netasq in particolare nella directory /usr/Firewall/ConfigFiles/ASQ sono presenti i 4 slot di configurazione per il motore ASQ le voci interessate sono:

• [WhiteList]
• [BlackList]
• [BlackListExclude]

Il file può essere modificato manualmente la sintassi è:

Applicato agli esempi precedenti il file di configurazione conterrebbe ad esempio:

[WhiteList]
dummy_host,any

Dopo aver modificato manualmente questo file è necessario eseguire il comando di reload per l’engine ASQ ovvero:

Vediamo i possibili switch del comando: