[gl-como] Newbe - ubuntu e firewall

[pirla]

Il giorno mar, 26/01/2010 alle 11.38 +0100, Riccardo (SCASI) ha scritto:

> ti ripeto, io non ho riscritto una mia versione di /etc/init.d/iptables, 
> semplicemente non lo utilizzo per gestire il firewall del gw aziendale. 
> Questo anche in relazione al fatto che /etc/init.d/iptables al momento 
> *non è in grado di soddisfare le mie esigenze* (vedi gestione del qos).
> Nel momento in cui emergerà uno standard(*) per la gestione dei firewall 
> sotto Linux (compreso appunto il qos) sarò ben felice di utilizzarlo.

> (*) a parte i comandi iptables, tc, ip etc, intendo
Scusa, non ho mai approfondito l'argomento, ma i casi sono due:
O i comandi tc ip etc non c'entrano con le regole di iptables, o, se
modificano le regole di iptables, allora devono essere gestibili con i
comandi standard di iptables.
Se siamo nel primo caso allora /etc/init.d/iptables soddisferebbe solo
la parte di firewalling, e il resto o lo metti appunto in rc.local
oppure usi un modo (se esiste) "stamdard".
Se invece siamo nel secondo caso allora siamo in presenza di un bug che
"deve" essere affrontato e risolto.

Ripeto, non ho mai approfondito la questione, quindi non so.

> si ma io i comandi iptables e altre cose non le digito a mano, dico allo 
> script che ho fatto quali comandi generare. Certo potrei sempre lanciare 
> lo script e poi digitare 'service iptables save', ma non ne vedo 
> l'utilità e rimane sempre fuori il discorso relativo a 'tc'.
Lo so che non li digiti a mano, ci mancherebbe altro.
Non so se hai visto il file generato da iptables-save. E' veramente così
semplice che potresti editare direttamente quello.
E poi per caricare le regole, basta un /etc/init.d/iptables restart e
sei a posto.
Poi ognuno usa il metodo che preferisce. Fatto sta che se usi un metodo
"standard" questo diventa facilmente portabile, e soprattutto facilmente
manutenibile anche da altri.
 
> > Il secondo è che lo script controlla, verifica, ed in caso carica, tutti
> > i moduli che servono per far funzionare bene il firewall.
> > Questo non è poco, e poi eventuali bachi o altro vengono aggiornati con
> > gli aggiornamenti del sistema operativo, oltre ad essere una cosa
> 
> questo non è vero:
> a) le soluzioni ai bachi di kernel/iptables/iproute etc li ho anch'io
> b) i bachi nelle regole di iptables non vengono 'sistemate' nemmeno nel 
> tuo caso:
> 1) iptables -I INPUT -i ppp0 -j ACCEPT
> 2) service iptables save
> 3) yum update
Beh, qui hai frainteso. Non parlavo degli errori che tu fai
nell'implementare un firewall. Quelli sono cavoli tuoi, e poi per me
potrebbe essere un baco, mentre per te no, o viceversa.
Ma se ci fosse un malfunzionamento nello script iptables allora questo
sarebbe aggiustato con un aggiornamento.

> > standard, per cui domani che vai da un cliente ti aspetti che la cosa
> > funzioni così, e se così non è, come con ubuntu "smadonni" oppure dici,
> > ma chi è quel coglione che ha fatto sta cosa che non si capisce niente.
> > Peggio ancora se perdi 3 ore di tempo a capire dove cavolo vengono
> > caricate delle regole di firewall che tu non avevi mai specificato.
> > Non so se mi sono capito, ma fa lo stesso
> 
> questo appunto perché per ora non è emerso il famoso standard.
> Inoltre, iirc, rc.local è l'ultimo script che viene lanciato al boot, 
> pertanto potresti 'segare' le regole iptables che non si sa da dove 
> vengano e impostare solo le tue.
Infatti rc.local è li per tutto quello che non è fattibile con gli
strumenti "standard". Quindi magari il tuo tc, ma non iptables che ha
già un qualcosa di pronto all'uso, flessibile, testato e certificato.

> > Questione di punti di vista, ma il problema è proprio questo.
> > Non ci sono standard purtroppo. E continuo a sentirmelo dire dai clienti
> > dove vado in giro. Molti stanno facendo degli sforzi, altri invece fanno
> > i dittatori o gli "asociali" dicendo che "come faccio io è meglio e
> > quindi non rompetemi".
> 
> io non mi considero 'dittatore' o 'asociale' (ok, asociale magari un po' 
> lo sono, ma _non_ in ambito informatico :) ) e non mi sono mai espresso 
> in questi termini; ti ho semplicemente detto l'approccio che utilizzo 
> io, che ha il vantaggio di essere abbastanza agnostico (se so cosa vuol 
> dire) in merito alla distribuzione usata.
Il riferimento non era a te come persona, ma ad una certa comunità di
sviluppatori.
Il "nostro" problema è il fatto che noi prendiamo in mano un cliente, o
un nostro server, o qualsiasi cosa, come se fosse quello di casa nostra.
Non sempre è possibile fare così, non c'è uno straccio di documentazione
(e su ubuntu ti assicuro che ho cercato), le cose vengono fatte in modo
"artistico" a seconda di come ci girava quel giorno.
Ma se poi (toccando tutto quello che si deve) ci passa un TIR sopra?
O se il server svampa miseramente e bisogna ricostruirlo da zero?
Non ci si ricorda mai quello che si era fatto, dove stavano le cose ecc
ecc.
Niente di personale quindi, ma solo un critico scambio di idee.
La mia idea è quella di riesntrare il più possibile in uno standard
condiviso, intelligente, logico e semplice.
In molti casi è possibile, in altri lo è meno... pazienza. Bisognerà
lavorare per farlo diventare prima di tutto logico, poi semplice e poi
condiviso. Sull'intelligenza invece ci si può scornare :-)

-- 
Ciao
        Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) gdit.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---
--->     Linux User #389536     <---
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        non disponibile
Tipo:        application/pgp-signature
Dimensione:  197 bytes
Descrizione: Questa è una parte del messaggio firmata digitalmente
URL:         <http://lists.linux.it/pipermail/gl-como/attachments/20100126/f84062a2/attachment.pgp>