[iptables]identificazione processi

[NA01]

è possibile identificare i processi che richiedono l'accesso alla rete sulle catene di output?
per loggare qualcosa del tipo

il processo XX ha stabilito una connessione alle ZZ

ciao!

[NA01]

ho trovato il modulo owner che mi dà la possibilità di creare regole secondo il pid o l'owner.

però così posso bloccare processi che già conosco, io invece vorrei poter intercettare il tentativo di uscita e poterlo elaborare ancora prima che venga decisa la sua sorte

ciao!

[ilsensine]

...ovvero?

[NA01]

mmmmh che brutta domanda, ora chiami l'ambulanza e mi fai sbattere in manicomio
però speravo risponedessi

allora:
supponiamo che io mi metta a lanciare ping.
ho le catene di output su -J DROP.
il mio sogno sarebbe appena il primo pacchetto cerca di uscire su OUTPUT venga spedito a un mio demone i dati relativi al processo che ha generato il pacchetto.

questo dovrebbe essere fattibile, vero?

il problema è che ora il mio bel pacchetto dovrebbe aspettare la risposta del demonuccio prima di uscire.
non so se si può fare...
ma per il momento lasciamo stare questa parte.

diciamo che per il momento mi limito a volere i dati sul processo che lo ha generato.
invece di mandarli a syslog o chi per lui dovrebbe spedirli al mio demone.

si può fare?
non ti chiedo la spiegazione di come si possa fare (suppongo non sia la cosa più veloce da spiegare), mi basterebbe qualche dritta....


grazie, ciao!

[ilsensine]

-j QUEUE
Puoi scrivere quindi il tuo bel programmino userspace che fa ciò che vuole con i pacchetti rigirati dal kernel, tramite le libipq:
http://www.google.it/search?hl=it&ie...nG=Cerca&meta=
oppure tramite i vari bind di questa libreria, come in Perl:
http://michael.toren.net/slides/ipqueue/slide005.html

Se invece ti interessa solo un log particolare, differente da syslog, usa -j ULOG.

[NA01]

sei mitico come al solito!!!

però ho un problemino...
una volta presi i dati con ipq_get_packet se non sbaglio mi trovo con questa struttura

typedef struct ipq_packet_msg {
    unsigned long packet_id; /* ID of queued packet */
    unsigned long mark; /* Netfilter mark value */
    long timestamp_sec; /* Packet arrival time (seconds) */
    long timestamp_usec; /* Packet arrvial time (+useconds) */
    unsigned int hook; /* Netfilter hook we rode in on */
    char indev_name[IFNAMSIZ]; /* Name of incoming interface */
    char outdev_name[IFNAMSIZ]; /* Name of outgoing interface */
    unsigned short hw_protocol; /* Hardware protocol (network order) */
    unsigned short hw_type; /* Hardware type */
    unsigned char hw_addrlen; /* Hardware address length */
    unsigned char hw_addr[8]; /* Hardware address */
    size_t data_len; /* Length of packet data */
    unsigned char payload[0]; /* Optional packet data */
} ipq_packet_msg_t;

e qui sono senza il mio bel pid
ci sono altri modi per andarselo a prendere?

grazie di nuovo, ciao!

[ilsensine]

Ah interessante
C'è una procedura indiretta (ma altamente inefficace) per i datagrammi tcp; forse c'è un modo più semplice, puoi provare a chiedere sulle loro ml.
C'è sempre l'alternativa di modificare i sorgenti di iptables, ovviamente

[NA01]

i sorgenti di iptables li lascerei stare lì come sono

ora vorrei solo un parere sull'idea prima di combinare troppi casini per nulla.

quello che vorrei realizzare è un firewall dinamico nello stile di quelli per windows.
prendi tutte le -m state NEW (la sintassi forse è sbagliata, ma credo che si capisca) e chiedi se accettarne l'uscita o l'entrata.
di conseguenza poi fai passare anche le related.
l'autenticazione dell'applicazione la lascerei con un md5 sull'eseguibile (metterlo anche sulle librerie sarebbe più sicuro, ma credo che diventi troppo pesante).

pensavo di strutturarlo con un demone che possa essere controllato solo da un gruppo di utenti (che ovviamente permetta di bloccare a un utente solo le sue uscite/entrate) e un client per utente che funzioni da interfaccia grafica.

ovviamente ha un senso solo su un desktop, ma aiutrebbe a prevenire problemi con applicazioni burlone che non fanno quello per cui si spacciano.
senza contare l'enorme facilità di configurazione (sarò stupido, ma arrivando da ZA ci ho messo quasi una settimana a capire come funzionava iptables).

che ne dici? varrebbe la pena di perderci un pò di tempo o è totalmente inutile/infattibile?

per ora sulla difficoltà sono ottimista, sull'utilità... bhò! attendo pareri

ciao!

[ilsensine]

Originariamente inviato da NA01

i sorgenti di iptables li lascerei stare lì come sono

Dai, è facile

quello che vorrei realizzare è un firewall dinamico nello stile di quelli per windows

.
che è pericolosissimo, a meno che non fai qualcosa tipo:

l'autenticazione dell'applicazione la lascerei con un md5 sull'eseguibile

Buona idea, però...

(metterlo anche sulle librerie sarebbe più sicuro, ma credo che diventi troppo pesante).

Bravo, così un LD_PRELOAD ti frega.

che ne dici? varrebbe la pena di perderci un pò di tempo o è totalmente inutile/infattibile?

L'idea non è balzana e suppongo che qualcosa esista già, ma esce dal mio ambito.
Dovresti discuterne sulle mailing list di netfilter.

[NA01]

Originariamente inviato da ilsensine

L'idea non è balzana e suppongo che qualcosa esista già, ma esce dal mio ambito.
Dovresti discuterne sulle mailing list di netfilter.

si, qualcosa esiste già per bsd se ben ricordo nella versione grafica si chiama xsystrace.
il porting per linux esiste, ma passa per una patch al kernel.
pessima cosa per ciò che è fatto per semplificare la vita.

Bravo, così un LD_PRELOAD ti frega.

mmmhh...
me la devo pensare meglio

se trovo una soluzione un salto su netfilter lo faccio, chissà che non esca qualcosa...

grazie di nuovo dell'attenzione!

ciao

[ilsensine]

Comunque ti do uno spunto che, almeno personalmente, potresti provare. Devi applicare un paio di patch al kernel (rigorosamente non testate in esecuzione):

La prima è alquanto dubbia, ma per quello che devi fare potrebbe andar bene. E' una modifica al layer socket che consente di tenere traccia del pid del creatore di un socket:

--- linux-2.6.11.4/net/socket.c.org	2005-06-13 20:51:53.000000000 +0200
+++ linux-2.6.11.4/net/socket.c	2005-06-13 20:39:11.000000000 +0200
@@ -404,6 +404,7 @@
 		file->f_mode = FMODE_READ | FMODE_WRITE;
 		file->f_flags = O_RDWR;
 		file->f_pos = 0;
+		file->f_owner.pid = get_current()->pid;
 		fd_install(fd, file);
 	}

La seconda è una patch al modulo ip_queue. Invece di inserire un campo pid nella struct ipq_packet_msg (sarebbe l'ideale, ma ti obbligherebbe a ricompilare anche iptables), "riciclo" il campo timestamp_usec per metterci dentro il pid:

--- linux-2.6.11.4/net/ipv4/netfilter/ip_queue.c.org	2005-06-13 20:56:37.000000000 +0200
+++ linux-2.6.11.4/net/ipv4/netfilter/ip_queue.c	2005-06-13 20:56:28.000000000 +0200
@@ -234,7 +234,9 @@
 	pmsg->packet_id       = (unsigned long )entry;
 	pmsg->data_len        = data_len;
 	pmsg->timestamp_sec   = entry->skb->stamp.tv_sec;
-	pmsg->timestamp_usec  = entry->skb->stamp.tv_usec;
+//	pmsg->timestamp_usec  = entry->skb->stamp.tv_usec;
+	pmsg->timestamp_usec  = entry->skb->sk->sk_socket->file ? 
+		entry->skb->sk->sk_socket->file->f_owner.pid : 0;
 	pmsg->mark            = entry->skb->nfmark;
 	pmsg->hook            = entry->info->hook;
 	pmsg->hw_protocol     = entry->skb->protocol;

Ho verificato che, almeno nella catena OUTPUT della tabella nat (quella che ti interessa, per i programmi locali), il risultato è corretto per un programma a singolo thread. Non ti consiglio di usare QUEUE per le altre catene; te lo sconsiglio vivamente per le catene di ingresso, qualsiasi esse siano (non ho verificato la patch su queste; se ti va bene, il campo ->file è nullo e non succede altro; se ti va male, c'è una "remota" possibilità di kernel oops )

mmmhh...
me la devo pensare meglio

Apri /proc/<pid>/maps, prendi i file indicati nei segmenti marcati "x" (eseguibile), e ne fai l'md5sum. I path sono assoluti, LD_PRELOAD è fregato.

[ilsensine]

Originariamente inviato da NA01

il porting per linux esiste, ma passa per una patch al kernel.

Hai un link a questa patch?

pessima cosa per ciò che è fatto per semplificare la vita.

Hai il coltello dalla parte dei sorgenti, USALI diamine!

[NA01]

Originariamente inviato da ilsensine

Apri /proc/<pid>/maps, prendi i file indicati nei segmenti marcati "x" (eseguibile), e ne fai l'md5sum. I path sono assoluti, LD_PRELOAD è fregato.

si, questo pomeriggio ci ho fatto qualche prova, mi era passato per la testa di leggere man proc e è stato molto istruttivo
la mia paura è che diventi un mattone a rilanciare gli md5 tutte le volte che apro il client di posta o firefox.

domani dopo l'esame (per cui avrei dovuto studiare oggi pomeriggio invece di girare per proc a fare cose a caso ) provo a fare qualcosa.

per le catene in ingresso dovrebbe bastare chiedere l'autorizzazione nel momento in cui viene aperta una porta in ascolto. non so se si può fare (intendo intercettare ll'apertura della porta).
sto rileggendo di corsa gapil e nel frattempo guarderò sui sorgenti di netstat per cercare di farlo senza toccare niente (sempre che sia possibile, altrimenti si vagherò verso altre strade ).

la patch in versione 2.6 è qui:
http://www.citi.umich.edu/u/provos/s....6.1-v1.5.diff
qui in versione 2.4
http://www.citi.umich.edu/u/provos/s...4.24-v1.5.diff

comunque data la relase del kernel il port non sembra essere mantenuto.
dopo netstat lo guarderò (sperando di esserne all'altezza, il kernel lo ho toccato un paio di volte sui moduli di iptables e basta).

sei sempre mitico!!!
ciao!

[ilsensine]

Originariamente inviato da NA01

si, questo pomeriggio ci ho fatto qualche prova, mi era passato per la la patch in versione 2.6 è qui:
http://www.citi.umich.edu/u/provos/s....6.1-v1.5.diff

Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).

[NA01]

Originariamente inviato da ilsensine

Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).

ok!
ho quasi rifinito gapil, tra un paio di giorni torno alla carica

Stanne lontano. La mia patch è un hack a rischio di esplosione, ma almeno l'ho detto da subito
In quel link c'è almeno una race e alcune imprecisioni. E un semaforo bloccato dentro uno spinlock (un errore serio).

una curiosità, come diavolo fai a passarti il codice così velocemente? mi umili terribilmente
nel frattempo spero di aver trovato una soluzione al problema delle catene di input. nel caso ti posto la patch, spero di avere un tuo parere
ti sto usando tantissimo, se spacco i gioielli di famiglia lasciami stare

ciao!

[gurutech]

da qui
OWNER match v1.2.8-20030601 options:
[!] --uid-owner userid Match local uid
[!] --gid-owner groupid Match local gid
[!] --pid-owner processid Match local pid
[!] --sid-owner sessionid Match local sid
[!] --cmd-owner name Match local command name

non puoi semplicemente usare il cmd-owner ?

[_YTS_]

bel thread, sono interessato anche io, resto sintonizzato.

byez

[ilsensine]

Originariamente inviato da gurutech

non puoi semplicemente usare il cmd-owner ?

Credo volesse fare qualcosa di più complesso: prendere il pid di un processo che stava tentando una nuova connessione, e verificare runtime che il processo era "autorizzato" (controllando un hash dell'eseguibile e delle sue librerie).

[NA01]

Originariamente inviato da ilsensine

Credo volesse fare qualcosa di più complesso: prendere il pid di un processo che stava tentando una nuova connessione, e verificare runtime che il processo era "autorizzato" (controllando un hash dell'eseguibile e delle sue librerie).

si, l'idea è questa.

il modulo lo vorrei utilizzare, ma con il pid per far passare su queque solo le new.
in questo modo eviterei ulteriore carico al sistema.
il processo chiede l'accesso alla rete e se è accettato metto in cima alla catena di filtraggio --pid-owner con accept.
l'ultimo elemento della catena deve rimanere queque, e il resto tutto droppato.

ho iniziato ora a fare qualche prova per vedere come funziona il tutto. vi tengo informati!

ciao!


PS: forse era meglio studiare per l'esame che guardare queste cose... ne avevo nettamente bisogno

[ilsensine]

Originariamente inviato da NA01

il processo chiede l'accesso alla rete e se è accettato metto in cima alla catena di filtraggio --pid-owner con accept.

...e quando il processo termina, chi pulisce?