VoIP and Hacking | Consulenza Documentazione

Specter è un flessible daemon di logging per il target ULOG di netfilter. Fornisce un’ ampia gamma di funzioni e la sua flessibilità dipende dalla comunicazione tra (sembra un gioco di parole) l’ output dei plugins di input e l’input dei plugins di output.

Per coloro che volessero dare da vicino una occhiata al codice, la structure usata per lo scambio dei dati tra plugins di input e di output è  definita in specter.h, e si chiama specter_iret_t.

Un altro importante aspetto di specter è la suddivisione dinamica in gruppi di esecuzione. Ciascun gruppo ha il proprio set di plugins, i quali vengono invocati in maniera indipendente. Questo implica che vi possano essere sets separati di opzioni di configurazione. Tale modello permette di impostare differenti regole iptables e collegarvi azioni ugualmente differenti. Attualmente vi sono due metodi di raggruppamento implementati - uno basato sui gruppi netlink, l’altro su sui marcatori di netfilter (marks).

Dato che l’ultima versione del software risale al 7 gennaio 2008, l’installazione può tranquillamente avvenire, per una fiammante Ubuntu 9.04 come la mia, tramite packages (specter e specter-mysql oppure specter-pgsql). Tuttavia, se qualcuno avesse esigenze particolari può scaricare il tarball dei sorgenti da http://joker.linuxstuff.pl/specter/ e procedere ad una compilazione manuale.
In tal caso, volendo generare specter col supporto MySQL, occorre utilizzare ‘./configure –with-mysql’. Si può pure specificare il percorso delle librerie mysql usando ‘–with-mysql=path’.
La stessa procedura si applica al supporto PostgreSQL (si usa ‘./configure –with-pgsql’ con o senza path verso le librerie).
Se si intende che altre applicazioni possano usare la libreria libipulog contenuta nel package, si può considerare generarla come shared. Per far ciò, si usa ‘./configure –with-sharedlib’.
Se si intendesse allestire una configurazione sofisticata e vi fosse necessità di un numero maggiore dei 32 execution groups di default, si può ridefinire SPECTER_GROUPS_MAX usando l’opzione di configurazione ‘–with-group-max=valore’. Dato che però il raggruppamento per netlink permette di specificare solamente 32 gruppi, e tale limite deriva dal kernel, occorre necessariamente usare gli nfmarks.
Per compilare ed installare il programma, si invoca ‘make install’. I vecchi files di configurazione non verranno sovrascritti.
Si può anche utilizzare ‘make install-strip’ per escludere i simboli ridondanti dal binario di specter.
Occorre ovviamente aggiungere delle regole all chain del firewall usando il target ULOG.
Un esempio molto semplice:

# iptables -A FORWARD -j ULOG –ulog-nlgroup 32 –ulog-prefix forwarded_pkt

Per aumentare le performance del logging , si può utilizzare la opzione –ulog-qthreshold N (dove 1 < N <= 50). Il numero specifica quanti pacchetti debbano venire raccolti insieme in un messaggio multipart netlink. Impostandolo a 20, il kernel schedula specter solo una volta ogni 20 paccetti raccolti. Tutti i 20 pacchetti sono poi processati da specter. Questo riduce il numero di context switches tra kernel e userspace.
Se già si stava usando ulogd e se ne vuole mantenere la configurazione, lo script ulogd2specter.pl, presente in contrib/, effettua tale conversione.

Specter legge i propri parametri di configurazione da un file, di solito ‘/etc/specter.conf’. Esso è suddiviso in blocchi. Ciascun blocco inizia con una parentesi graffa aperta { e finisce con una parentesi graffa chiusa }. L’annidamento di blocchi è vietato. Per poter operare una distinzione tra blocchi, ciascuno ha un nome. Si può utilizzare un nome qualsiasi per un blocco, ad eccezione di due nomi speciali: global (che viene usato per specificare parametri generali del daemon) e plugins (che elenca gli add-ons disponibili). Numeri nel range 1-SPECTER_GROUPS_MAX hanno uno speciale significato funzionale.

Ciascun blocco deve iniziare in una nuova linea, col proprio nome ed una parentesi graffa aperta. Tutti i blocchi (ad eccezione di global e plugins) sono suddivisi in sezioni logiche, che definiscono un ambito configurativo per ogni plugin. Una sezione inizia con il simbolo di due-punti (:) seguito dal proprio nome. Nel corpo della sezione viene specificata la configurazione. I blocchi global e plugins sono più semplici e non contengono alcuna sezione. Un blocco termina con una parentesi graffa chiusa. Perciò, in generale, la definizione di un blocco appare come di seguito:

nome {
   include altro_blocco
   :sezione_uno
   opzione valore
   # commento
   altra_opzione “stringa che necessita di spazi”
   :sezione_due
   # questa sezione ha una opzione non valorizzata, ma importante da specificare
   :sezione_tre
   opzione_tre
   opzione valore # un altro commento
   [...]
}

Alcuni esempi

Ipotizziamo di voler effettuare il log dei pacchetti tcp ed udp non-related in files separati.
Occorre prima impostare netfilter:

# iptables -A INPUT -p tcp -m state –state INVALID -j ULOG –ulog-nlgroup 1
# iptables -A INPUT -p udp -m state –state INVALID -j ULOG –ulog-nlgroup 2

e quindi usare questa configurazione per specter:

plugins {
   BASE    /lib/specter/specter_BASE.so
   LOCAL   /lib/specter/specter_LOCAL.so
   LOGEMU  /lib/specter/specter_LOGEMU.so
}

1 {
   :BASE
   :LOCAL
   :LOGEMU
   logfile /var/log/specter.tcp
}

2 {
   :BASE
   :LOCAL
   :LOGEMU
   logfile /var/log/specter.udp
}

Se invece volessimo salvare tutti gli IPs che ci pingano in un database, loggando anche le richieste tcp, senza tuttavia occupare più di un gruppo netlink, decidendo perciò di usare il modulo mark di iptables per dividere i pacchetti in gruppi, si posson impostare queste regole per iptables:

# iptables -t mangle -A INPUT -p icmp –icmp-type echo-request -j MARK –set-mark 13
# iptables -t mangle -A INPUT -p tcp -m state –state NEW -j MARK –set-mark 15
# iptables -A INPUT -m mark –mark 13 -j ULOG –ulog-nlgroup 1
# iptables -A INPUT -m mark –mark 15 -j ULOG –ulog-nlgroup 1

Questa invece la configurazione per specter:

global  {
   grouping nfmark
   nlgroup 1
}

plugins {
   BASE    /lib/specter/specter_BASE.so
   MYSQL   /lib/specter/specter_MYSQL.so
}

13 {
   :BASE
   :MYSQL
   db mydb
   host localhost
   user username
   pass password
   table pings
}

15 {
   :BASE
   :MYSQL
   db mydb
   host localhost
   user username
   pass password
   table tcp_requests
}

Se non dovessimo gradire troppo i pacchetti frammentati potremmo automaticamente bloccare chiunque ce li invii, usando da una parte questa singola regola per iptables:

# iptables -A INPUT -p tcp -f -j ULOG –ulog-nlgroup 1

Quindi utilizzare questa configurazione per modificare dinamicamente la configurazione netfilter con l’uso del plugin EXEC:

plugins {
   BASE    /usr/lib/specter/specter_BASE.so
   EXEC    /lib/specter/specter_EXEC.so
}

1 {
   :BASE
   :EXEC
   command “/usr/sbin/iptables -A INPUT -p tcp -s %S –sport %s -j DROP”
}

Ad essere sinceri, era stata proprio la disponibilità di questo particolare plugin di output ad indurmi a parlare di specter.
Lo spunto era invece fornito dalla curiosità di scoprire quante tra le innumerevoli scansioni quotidianamente ricevute siano opera di pc infettati dal worm Conficker, attivando una controscansione specifica nella direzione opposta, non appena ricevuto il primo pacchetto.
Perciò prima ho impostato netfilter per catturare i pacchetti ricevuti e destinati a porte tipiche dei servizi Microsoft:

# FILTER=”-i eth0″; MSPORTS=”–destination-ports 139,445″
# iptables -A INPUT $FILTER -m multiport -p tcp $MSPORTS -j ULOG –ulog-nlgroup 1

Per dare un tocco di maggiore realismo ho impostato nephentes in modo da limitarsi a simulare i servizi di un server Windows:

[...]
nepenthes
{
   modules(
   moduledir               “lib/nepenthes”;        // relativo alla workdir
   moduleconfigdir         “etc/nepenthes”;        // relativo alla workdir
   [...]
   modules(
   // vulnerability modules
   ”vulnnetbiosname.so”,           “vuln-netbiosname.conf”,        “”
   ”vulnms08067.so”,               “vuln-ms08067.conf”,            “”
   );
   [...]
};

e successivamente lo ho riavviato.

Per quanto riguarda invece specter, questa la configurazione:

plugins {
   BASE    /usr/lib/specter/specter_BASE.so
   EXEC    /lib/specter/specter_EXEC.so
}

1 {
   :BASE
   :EXEC
   command “nmap -PN -T4 -p139,445 -n -v –script smb-check-vulns,smb-os-discovery –script-args safe=0 %S”
}

Una volta lanciato specter è iniziata anche la caccia …

Send post as PDF to