Newsgroup: it.comp.os.linux.sys
Titolo: iptables recent + owner

Ciao,
secondo voi è possibile, con i due moduli in oggetto (o analoghi) riuscire a limitare il numero di connessioni NEW in uscita, utente per utente ?
 
Ad esempio, ciascun uid deve poter creare, in uscita, al massimo 2 connessioni al minuto. Sinceramente non so come come scrivere la regola.
 
Va da se che non voglio scrivere utente per utente altrimenti saprei già come fare.

 Ad esempio, ciascun uid deve poter creare, in uscita, al massimo 2 connessioni al minuto. Sinceramente non so come come scrivere la regola.
 
Ma limit non ti va bene?
 
 
iptables -N DONTGO
iptables -A OUTPUT -m owner --uid-owner 1001 -m state --state NEW -j DONTGO
iptables -A DONTGO -m limit --limit-burst 2 --limit 2/m -j RETURN
iptables -A DONTGO -j DROP
 
Dovrebbe funzionare.

 iptables -A OUTPUT -m owner --uid-owner 1001 -m state --state NEW -j DONTGO
 
devo indicare uid per uid, cosa che non voglio fare (sono circa 1200!)
 
Vorrei fare in modo che ciascun UID possa aprire al massimo X connessioni al secondo e non che tutti insieme possano aprire X connessioni.
 


[!] --uid-owner userid[-userid]
 
    Matches if the packet socket's file structure (if it has one) is
    owned  by  the given user. You may also specify a numerical UID,
    or an UID range.
 
[!] --gid-owner groupid[-groupid]
 
    Matches if the packet socket's file structure is  owned  by  the
    given  group.   You  may  also specify a numerical GID, or a GID
    range.
 
 
Ciao  Manlio

 [!] --gid-owner groupid[-groupid]
 
Questo lo so, ma io devo limitare le connessioni TOTALI PER UTENTE senza specificare gli utenti uno ad uno.
 
Adottando la soluzione di whiplash dovrei creare una catena per ciascun utente:
 
iptables -N UID1001
iptables -N UID1002
iptables -N UID1003
 
iptables -A OUTPUT -m owner --uid-owner 1001 -m state --state NEW -j UID1001 
iptables -A OUTPUT -m owner --uid-owner 1001 -m state --state NEW -j UID1002
iptables -A OUTPUT -m owner --uid-owner 1001 -m state --state NEW -j UID1003
 
iptables -A UID1001 -m limit --limit-burst 2 --limit 2/m -j RETURN 
iptables -A UID1002 -m limit --limit-burst 2 --limit 2/m -j RETURN 
iptables -A UID1003 -m limit --limit-burst 2 --limit 2/m -j RETURN 
 
iptables -A UID1001 -j DROP 
iptables -A UID1002 -j DROP 
iptables -A UID1003 -j DROP 
 
 
e non va bene.
Se invece mettessi tutti gli uid nella stessa catena usando un range, lui mi limita tutta la catena (quindi tutti gli utenti in una volta) a 2 connessioni al minuto complessive.
 
Posso anche fare le catene ad-hoc per ciascun utente, ma dover creare 1200 regole non mi piace affatto.
 
for UID in $(seq 1024 2100); do
   iptables -A OUTPUT -m owner --uid-owner ${UID} \
                      -m limit --limit-burst 2 --limit 2/m \
                      -m state --state NEW \
                      -j ACCEPT
 
   iptables -A OUTPUT -m owner --uid-owner ${UID} \
                      -m state --state DROP
done
 
 
E se poi gli utenti diventassero 5000 ? Sarebbe comunque gestibile o collasserebbe?
Se ci fossero soluzioni migliori mi piacerebbe conoscerle.


E agendo sul gid invece che sugli uid ?
Ovviamente  se quegli uid appartengono o si fanno appartenere allo 
stesso gruppo
 

 devo indicare uid per uid, cosa che non voglio fare (sono circa 1200!)
 
E capirai, con un for o un while che sforzo...:-)

 stesso gruppo
 
Son tutti diversi, ma anche in questo caso, agendo a livello di gruppo, tutto il gruppo sarebbe soggetto ad un unico limite
 

 E capirai, con un for o un while che sforzo...:-)
 
No, non è un problema di sforzo, bensì di performance.
Ho paura che migliaia di regole possano rallentare tutto, dopotutto lui le deve parsare cicliclamente no ?
 
Per ora sto testando il ciclo di cui sopra.


Tu hai scritto questo:
 
Ad esempio, ciascun uid deve poter creare, in uscita, al massimo 2 
connessioni al minuto
 
 
Il che significa che il limite è costante per tutti
 

 Il che significa che il limite è costante per tutti
 
 
Si, esatto.
CIASCUN uid deve poter fare 2 connessioni, non tutti insieme al massimo 2 connessioni. C'è una grossa differenza.
 
Stesso limite per tutti, ma applicato singolarmente. 2 connessioni te, 2 connessioni io, 2 connessioni Pippo. E non 2 connessioni diviso noi 3.

 No, non è un problema di sforzo, bensì di performance.
 
 
Guarda, con quel numero di regole non credo che avresti problemi.
 
Tanto per rendere l'ordine di grandezza, io ho un firewall così:
 
$iptables -vnL | wc -l
2523
 
$iptables -t nat -vnL | wc -l
392
 
$iptables -t mangle -vnL | wc -l
32
 
]$ip link ls ]$ip link ls | grep ^[0-9] | tail -n 1 | cut -d : -f 1
32
 
Macchina vecchia, 32 bit, 4 giga di ram, fa anche altre cosucce, non se ne accorge neanche.
 
Ad ogni buon conto, di gente che ha sbattuto le corna contro ruleset mastodontici
ce n'è stata parecchia, dai un'occhiata a questa presentazione che dà spunti interessanti:
http://www.slideshare.net/brouer/netfilter-making-large-iptables-rulesets-scale
 


Si è chiaro.
O accetti una media globale a livello di gruppo o per tutti(Es: 500 
utenti x 2 = 1000) o si va con gli uuid
Altre soluzioni non ne vedo
 

 2523
 
Per essere ho un firewall con quasi il doppio di regole, ma la macchina
è paurosamente sovradimensionata rispetto a quella dove devo applicare la
policy in uscita quindi non mi sono mai posto il problema.
 
Per ora ho tamponato con un ciclo da UID >= 1024 a 2500 in modo da tenermi un po di margine in caso di creazione utenti.

 2523
respect
 
Non vorrei essere nei tuoi panni a modificare il fw perï¿œ
 
-- 
************** (.)_(.) *******************
Un amico ï¿œ uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 Non vorrei essere nei tuoi panni a modificare il fw però
 
E' tutto scriptato, pieno di catene, lo script di init può ricaricare la singola
catena ma in effetti inizia ad essere ingombrante. Troppa gente che ci ha zampettato
negli anni, scarsa manutenzione eccetera.
Scelte di management discutibili, tanto per cambiare, che prima o poi si pagheranno, anche
care. Quel giorno spero di non essere lì e di sghignazzare da lungi. :)