[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
>
>
>
>
>
> !DSPAM:1,469e23e0262441214316380!

________________________________
French OpenBSD mailing list
misc AT openbsd-france POINT org
http://www.openbsd-france.org/ml