Re: [obsdfr-misc] Etre sûr de son pf.conf

[jean-philippe luiggi <jpl AT didconcept POINT com>]

Bonjour,

Je dirais que c'est une affaire de goût. :-)
J'ai testé PFSense dans le passé, la seule chose bloquante à mes yeux
est le manque de granularité des options possibles ne serait ce que
dans la gestion de la QOS (au moment ou je l'avais regardé).
Après, dans le cadre sécuritaire, c'est toi qui va être aux commandes
(si tu fais une "boulette", que ce soit via l'interface de PFSense ou
via un "vi /etc/pf.conf", le résultat va être similaire). :-)

Je dirais que nous sommes tout à fait dans une logique d'analyse de
risques, quels sont-ils ? 

- Coté FW : PFSense ou OpenBSD = risques potentiels identiques si une
faille est découverte. 
- Coté règles de filtrage : Pareil
- Que les machines du LAN soient piratées : hors de contrôle du FW

Et coté interface, tu as FWBuilder.

En résumé, je ne pense pas que laisser tourner un Open bien configuré
soit plus risqué qu'un PFSense.

Salutations,

Jean-philippe.

On Thu, 19 Jul 2007 09:33:45 +0200
"Chardhoo Chardhoo" <patriotefr AT gmail POINT com> wrote:

> Je pense me tourner vers une distribution comme PFSense car je serais
> sûr de la configuration de PF car je part pendant 6 mois et je ne
> reviens pas donc le but est d'avoir un reseau bien protégé et je
> n'aimerais pas que ma famille soit privé d'internet pendant 6 mois
> non-stop ca serait la calamité alors j'ai pensé faire renaitre mon
> vieux PIII 1ghz pour etre sûr de cette tache.
> Pouvez vous me dire s'il est judicieu de garder Open ou de passer par
> PFSense ?
> car j'aime mon poisson lune mais d'un coté il y a une interface
> graphique c'est plus ergonomique..
> Que choisir ? entre quelques lignes de configuration PF et une
> distribution faite pour ça..
> 
> On 7/18/07, jean-philippe luiggi <jpl AT didconcept POINT com> wrote:
> >
> > Bonjour,
> >
> > Je pense que tu devrais (si ton FW est en frontal vis
> > à vis d'internet) laisser entrer les paquets ICMP type 3 code 4 sur
> > l'interface externe (utile lors du PMTUD).
> >
> > On pourrait aussi jouer avec les "tag" et ne laisser sortir que les
> > paquets déjà "taggés".
> >
> >
> > Cordialement,
> >
> > Jean-philippe.
> >
> >
> > On Wed, 18 Jul 2007 16:08:09 +0200
> > "Chardhoo Chardhoo" <patriotefr AT gmail POINT com> wrote:
> >
> > > Bonjour à la communauté !
> > >
> > > Je suis depuis 2 jours en train de me documenter pour réaliser mon
> > > fichier pf.conf par rapport à d'autres et ainsi garantir la
> > > protection de mon serveur et du réseau.
> > > Je souhaiterais avoir l'avis de personne s'y connaissant sur le
> > > sujet car je ne veut surtout pas avoir de doute concernant cette
> > > partie là ! c'est trop important..
> > > alors je met mon fichier pf.conf qui fonctionne chez moi à votre
> > > disposition pour que vous l'analisiez et recherché s'il y a des
> > > bétises et je vous dresse un topo de mon reseau et de mes
> > > ambitions pour que vous y mettiez une touche de sécurité en plus
> > > si possible est.. :
> > >
> > > Machines clientes = 192.168.1.0/24
> > > Serveur = Lan:dc0:192.168.1.1 & egress:192.168.0.2 /SSH/
> > > accessible de l'interieur uniquement
> > > Routeur en DMZ = 192.168.0.1
> > >
> > > il y a 5 ordinateurs qui vont l'avoir comme passerelle,
> > > 192.168.1.2 va faire office de serveur
> > >
> > > #####MACROS#####
> > > int_if="dc0"
> > > ports_ouverts_pour_lequipe="{ http https ftp smtp }"
> > >
> > > ########### options ###############
> > >     set block-policy return
> > > # en cas de "block", quand on refuse un paquet, on envoie
> > > # - un TCP RST pour les paquets TCP bloqués
> > > # - un ICMP UNREACHABLE pour les paquet UDP bloqués
> > >
> > >
> > > #####TABLES#####
> > >     table <ip_de_lequipe> { 192.168.1.2, 192.168.1.3, 192.168.1.4,
> > > 192.168.1.5, 192.168.1.6 }
> > >     table <ip_de_serveur_2> { 192.168.1.2 }
> > >
> > > #####SCRUB#####
> > >  #Normalise tout les packets:
> > >     scrub in all
> > >
> > > #####NAT/RDR#####
> > > #On active le nat pour le réseau local:
> > >     nat pass on egress -> (egress)
> > >
> > >     rdr on egress proto tcp from any to any port 4562 ->
> > > <ip_de_serveur_2> rdr on egress proto udp from any to any port
> > > 4572 -> <ip_de_serveur_2>
> > >
> > > #####FILTRAGE#####
> > >     block in
> > >
> > > # Activation de la protection contre l'usurpation sur toutes les
> > > interfaces: block in quick from urpf-failed
> > >
> > >     pass out
> > >     pass in on egress proto tcp from <ip_de_lequipe> to port
> > > $ports_ouverts_pour_lequipe flags S/SFRA
> > >     pass in on egress proto tcp from <ip_de_serveur_2> to port
> > > 4562 pass in on egress proto udp from <ip_de_serveur_2> to port
> > > 4572
> > >
> > > # Les connexions ssh ne sont autorisées qu'en provenance du réseau
> > > local # et de la machine 192.168.1.4. "block return" provoque
> > > l'émission d'un # paquet TCP RST pour mettre fin aux connexions
> > > illicites. "quick" # assure que cette règle n'est pas contredite
> > > par les règles "pass".
> > >
> > >     block return in quick on $int_if proto tcp from ! 192.168.0.2
> > > \ to $int_if port ssh
> > >
> > >
> > > Merci de votre aide
> > >
> > >
> > >
> > >
> > >
> > > 
> >
> > ________________________________
> > French OpenBSD mailing list
> > misc AT openbsd-france POINT org
> > http://www.openbsd-france.org/ml
> >
> >
> 
> 
> 
> 
> 
> !DSPAM:1,469f1413282485876319797!