On 12/02/2012 01:26 PM, tag 636 wrote: > forum.pfsense.org/index.php?topic=1561.0 > > > nel post trovi il boot, se noti pf e' un modulo e viene caricato con > gli rc. .... per design l'interfaccia verra' inizializzata dal kernel > e quindi sara' sempre prima che il demone pf parta e carichi le regole > pf. conf.
Non so come vanno le cose con il kernel dello schema, ma in linux (vado a memoria) le interfacce, dopo essere state configurate, non sono attive fino a che non vengono messe "up", cosa che fanno degli script. Sempre a memoria, la configurazione dei filtri sulle interfacce si può mettere (in qualche distribuzione) in directory che si chiamano /etc/network/if-pre-up e in questo modo vengono attivati prima che le interfacce vadano up. Prima, non c'è nemmeno un indirizzo IP con cui le interfacce rispondano. Con variazioni sul tema, e sempre a memoria, è il sistema con cui si è sempre fatta l'attivazione dei filtri prima che le interfacce possano ricevere pacchetti. Del resto, che un'interfaccia possa essere messa "up" e "down" a sistema avviato credo che sia la norma per molti s.o. e apparati. > > sinceramento non vedo un big deal e mi spiego meglio, l'ip viene reso > disponibile sull'intefaccia e risponde all'icmp, durante il boot, ma > e' il tcp stack del kernel a farlo, questo non significa che un > pacchetto puo' attraversare il bridge wan/lan, quindi non stai > esponendo la rete in quella frazione di secondi. Perché no? Il fatto che il bridging sia o meno attivo in quella fase non è una questione di configurazione del kernel? > > considera che molti vendor appliance son bsd based.... non credo sia > pfsense but il design del kernel/moduli, o quanto meno questa e' la > mia lettura di quello che descrivi. > Conosco poco BSD e quindi non mi sbilancio, ma non darei per scontato quello che dici. Se è come dico io, non serve un kernel hacker ma solo conoscere gli script di boot. Però secondo me c'è un problema di fondo, anzi due, anche nella risposta di Alberto. Anche se è vero che se non ci sono servizi attivi che rispondano localmente e non è attivo il forwarding dei pacchetti, la sicurezza è un muro fatto da tanti mattoncini che nel complesso ti danno ridondanza e difesa in profondità. È vero che se sfili un mattoncino, puoi dire che se tutto il resto del muro è a posto, continua a reggere, ma il tuo muro è stato indebolito. Se qualcuno ti sfila un altro mattoncino, o qualcun altro ha già fatto lo stesso ragionamento da un'altra parte (magari attivando il forwarding di default perché si aspetta che i filtri siano attivati prima delle interfacce) alla fine crolla tutto. Il secondo problema, più importante, è che la sicurezza efficace è fatta molto di applicazione rigorosa di buone pratiche, perché motivi e necessità di indebolirla "legittimamente" poi ce ne sono fin troppi. Se vedo che una buona pratica è stata violata, apparentemente senza motivo, quello che mi chiedo non è tanto come ripristinare le cose, ma perché è stata violata, perché può essere indice di un problema organizzativo o di competenze che magari ha creato problemi da qualche altra parte, dove non li hai visti, o li creerà in futuro. Come dire: se non è stata applicata una patch, il problema non è applicare la patch, ma capire perché non è stata applicata. ciao - Claudio -- Claudio Telmon [email protected] http://www.telmon.org ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
