Le
script de Tero Karvinen permet de mettre en place un pare-feu léger pour un ordinateur personnel. J'ai juste fais quelques ajustements pour ceux que ça intéresse :
- Organisation plus claire
- Pas de réponse aux demande de ping
- Survie des règles au redémarrage qui fonctionne pour Debian
#!/bin/sh
# firewall.sh - Configurable per-host firewall for workstations and
# servers.(c) 2003 Tero Karvinen - tero karvinen at iki fi - GPL
# Policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
# Cleanup old rules
iptables --flush
iptables --delete-chain
# Rules
iptables -A INPUT -i lo -s localhost -d localhost -j ACCEPT
iptables -A INPUT -m state --state "ESTABLISHED,RELATED" -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
# Holes
#iptables -A INPUT -p udp -s mafreebox.freebox.fr -j ACCEPT
#iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
# Save
iptables-save > /etc/iptables.up.rules
echo "#!/bin/sh" > /etc/network/if-up.d/iptables
echo "iptables-restore < /etc/iptables.up.rules" >> /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables
echo "Firewall(.sh) : done"
# Troll
Posté par Moonz . Évalué à 10.
Quel est, de base, l’intérêt de simplement spécifier une licence pour un truc comme ça ? Si encore c’étaient dix lignes de Ook ou de Brainfuck, je pourrai comprendre, mais là…
Vous pouvez moinser.
[^] # Re: Troll
Posté par Ymage . Évalué à 3.
Qui plus est, même pour une portée éducative, ce script ne comporte pas le moindre commentaire expliquant la signification de chaque ligne.
Je doute enfin que Tero ait pu ajouter quelques lignes concernant sa freebox finlandaise, même en commentaire.
Quel peut donc bien être l'intérêt de ce script ?
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Troll
Posté par FTF3k3 . Évalué à 4.
[^] # Re: Troll
Posté par Ellendhel (site web personnel) . Évalué à 2.
Certes, il est fonctionnel mais pour une personne qui un jour ou l'autre aura besoin d'affiner une règle ou deux ce sera un peu plus dur de broder autour.
Non pas que les règles soient mauvaises ou que ce soit impossible, mais sans explication sur les options, l'importance de l'ordre des règles, ... cela fera sûrement perdre beaucoup de temps au départ.
À moins d'être dans un univers hostile ouvert à tout vent (hotspot wifi public, ...) autant prendre le temps de consulter un bon tutoriel sur le sujet pour préparer ses règles au fur et à mesure.
pub subliminale
http://olivieraj.free.fr/fr/linux/information/firewall/index(...) mais il y a sûrement d'autres sites de la même veine
[^] # Re: Troll
Posté par Axone . Évalué à 2.
- déterminer une politique générale (tout rejeter ou tout accepter
- effacer les anciennes règles (ça peut être drôlement embêtant si on l'oublie)
- des exemples basiques mais néanmoins très didactiques sur des autorisations spécifiques.
- etc
C'est beaucoup plus facile de lire une page de man ensuite en se basant sur ce genre d'exemples, car on voit déjà comment utiliser concrètement iptables dans les grandes lignes. Les pages man se contentent malheureusement trop souvent d'être un listing d'options commentées.
[^] # Re: Troll
Posté par Laurent Cligny (site web personnel) . Évalué à 4.
# claire
Posté par suJeSelS . Évalué à 9.
On peut faire la même chose en 2 fois moins long avec packet filter et lisible facilement.
[^] # Re: claire
Posté par Ymage . Évalué à 7.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: claire
Posté par suJeSelS . Évalué à 3.
[^] # Re: claire
Posté par Anthony Jaguenaud . Évalué à 2.
[^] # Re: claire
Posté par suJeSelS . Évalué à 3.
[^] # Re: claire
Posté par ZeroHeure (site web personnel) . Évalué à 2.
ils disent même feeeeeiiiiignant
et autrefois on devait dire fait-néant
du coup les élèves survivants ne savent plus quoi dire
et personne n'engueule les profs
ah il est loin le temps des cahiers au feu
et la maîtresse au milieu
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: claire
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: claire
Posté par Larry Cow . Évalué à 4.
[^] # Re: claire
Posté par ZeroHeure (site web personnel) . Évalué à 3.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: claire
Posté par Dr BG (site web personnel) . Évalué à 3.
[^] # Re: claire
Posté par Dr BG (site web personnel) . Évalué à 3.
Si, de fait, les formes faignant ou feignant sont aujourd’hui « populaires », elles sont les premières attestées, et c’est fainéant qui a constitué une altération populaire, d’après fait (forme verbale de faire) et néant, de faignant, feignant, participe présent de feindre, au sens ancien de « se dérober (à la tâche), rester inactif ».
source : http://academie-francaise.fr/langue/questions.html#faineant
[^] # Re: claire
Posté par bzubzu . Évalué à 1.
C'est moi ou c'est devenu à la mode de mettre des "e" à la fin des mots quand ils n'en nécessites pas ? Une histoire de parité ? Une volonté de supplanter l'erreur fréquemment commise "é" VS "er" des verbes ?
[^] # Re: claire
Posté par bzubzu . Évalué à 1.
op je me cache.
J'ai craqué et posté sur le mauvais exemple, les lois de Murphy sont impénétrable...
[^] # Re: claire
Posté par Kerro . Évalué à 3.
"nécessitent"
L'arozeure arozé :-)
[^] # Re: claire
Posté par nodens . Évalué à 3.
Par contre je suis plus mitigé en ce qui concerne un exemple compliqué, par exemple un grand nombre de serveurs avec du nat.
Dans ce cas, moi qui ait appris à maîtriser la syntaxe netfilter (dans la douleur, certes), pf me pose des soucis. Par exemple, je n'arrive pas à saisir le cheminement d'un paquet dans les différentes règles. Avec netfilter, à défaut d'être simple et clair c'est bien expliqué, y'a même un schéma [1].
Je n'ai jamais été fichu de me mettre dans la tête à quoi faisait référence « in » et « out » : à l'interface ? au système ?
Intellectuellement j'aurais envie de dire l'interface, mais à chaque fois j'ai un doute.
Autre chose qui fait que c'est parfois pas facile à lire, toujours dans le cas d'un grand nombre de serveurs avec du nat, c'est qu'on est obligé de mettre d'abord les règles de nat etc, et ensuite les règles de filtrage. Pas moyen de faire des blocs de règles nat + filtrage par serveur par exemple.
Après, qu'on ne me fasse pas dire ce que je n'ai pas dit, techniquement je n'ai rien à reprocher à pf bien au contraire. Notamment la notion d'ancres (dommage qu'on ne puisse pas hériter des macros) et de tables est géniale (netfilter a ipset mais c'est plus compliqué à mettre en oeuvre). Ah si, un truc qui m'embête quand même : l'absence de conntrack pour le ftp. ftp-proxy, sur un grand nombre de serveurs NATés, c'est pas gérable [2].
[1] http://fr.wikipedia.org/wiki/Fichier:Netfilter_schema.png - Si quelqu'un me trouve l'équivalent pour PF je suis preneur.
[2] oui, le NAT c'est mal, et le ftp aussi, mais il faut bien faire avec l'existant, et c'est quand même bien pratique.
# Pas de réponse aux demande de ping
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
[^] # Re: Pas de réponse aux demande de ping
Posté par FTF3k3 . Évalué à -2.
[^] # Re: Pas de réponse aux demande de ping
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: Pas de réponse aux demande de ping
Posté par phyce . Évalué à 7.
<pre>
# Protection ping-flood
iptables -A ICMPINPUT -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A ICMPINPUT -p icmp --icmp-type echo-request -m limit --limit 3/s -j ACCEPT
iptables -A ICMPINPUT -p icmp --icmp-type echo-request -m limit --limit 6/m -j LOG --log-prefix "[PING_FLOOD] "
iptables -A ICMPINPUT -p icmp -j REJECT
# L'icmp entrant passe a travers la chaine ICMPINPUT
iptables -A INPUT -p icmp -j ICMPINPUT
</pre>
Un équivalent existe pour le SYN flood, laissé à la sagacité du lecteur ;)
[^] # Re: Pas de réponse aux demande de ping
Posté par dyno partouzeur de drouate . Évalué à 2.
iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
[^] # Re: Pas de réponse aux demande de ping
Posté par benoar . Évalué à 4.
Bon, ils peuvent aussi être utilisés à mauvais escient aussi (respectivement pour ralentir une connexion, mais bon, c'est le but de la QoS, augmenter le travail effectué par la pile IP, et puis aussi spoofer grâce à l'icmp-redirect), mais quand même, les OS modernes sont à peu près protégés de ça.
Et surtout, SURTOUT, en IPv6, l'ICMP sert à tout : le router-advertisement pour broadcaster son préfixe et faire ainsi l'autoconfiguration, pour le neigbour discovery (équivalent d'ARP), la distribution de paramètres comme les serveurs DNS, etc.
Bref, ne bloquez pas tout inutilement, vous pourriez le regretter un jour où vous aurez oublié que vous le bloquiez, et vous ne comprendrez pas pourquoi ça ne marche pas ...
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . Évalué à 3.
· le fait qu'il soit très simple de tuneller à peu près n'importe quoi dans le ping (bon ça marche aussi avec les requêtes DNS, et d'autres trucs...)
· il y a beaucoup de types / codes inusités, qui servent beaucoup au fingerprinting et à la découverte de réseaux (http://www.securitypronews.com/securitypronews-24-20030929OS(...) est un bon résumé)
En ce qui concerne le premier point, un bon IDS fait l'affaire pour la majeure partie des cas (et quand le contenu est crypté au point d'être invisible, ben c'est qu'on est tombé sur un sacré balaise, et là on a du souci à se faire). De plus, limiter le nombre de réponses au ping va poser des problèmes à l'utilisateur du tunnel (par exemple ne répondre qu'à 1 ping sur 3).
Pour le second, il y a des méthodes qui relèvent plus de la configuration des systèmes protégés que du pare-feu lui même. Par exemple, sous linux, ne pas répondre à un ping sur l'adresse de réseau ou de diffusion. Ce genre de chose se configure à coup de sysctl. De plus, on peut limiter les réponses aux types de messages considérés comme légitimes.
Voici ce que j'ai sur un pare-feu ipv4 only (en ipv6 j'ai pas encore creusé la question) :
for icmptype in echo-request echo-reply fragmentation-needed port-unreachable host-unreachable ttl-exceeded; do
$ipcmd -A INPUT -m limit --limit 2/second -p icmp --icmp-type $icmptype -j ACCEPT
$ipcmd -A OUTPUT -p icmp --icmp-type $icmptype -j ACCEPT
done
$ipcmd contient évidemment "/sbin/iptables <les options que je veux toujours mettre>"
(dans certains cas on peut vouloir autoriser l'icmp redirect en plus, mais c'est à limiter à l'interface sur laquelle on en a besoin).
[^] # Re: Pas de réponse aux demande de ping
Posté par dyno partouzeur de drouate . Évalué à 3.
Moi en ma qualité d'utilisateur, j'estime devoir être en mesure de me connecter en ssh à mon PC chez moi quand j'en ai envie. Et également j'estime avoir droit au respect de ma vie privée, donc mon firefox utilise une connexion SSL vers mon proxy SOCKS perso chez moi. Et si mon admin estime que ce n'est pas normal, celà signifie qu'il veut pouvoir surveiller à quel site je me connecte, et donc que j'ai raison de vouloir protéger ma vie privée.
Après, il peut filtrer les procs, je mettrai mon proxy sur le porc 80, ou 443, ou whatever. Il peut essayer de détecter les communications qu'il ne veut pas avec un IDS comme toi, mais ça commence à être du grand n'importe quoi :
* quel sont les buts recherchés ?
* pourquoi l'entreprise ne peut pas faire confiance à ses salariés ?
* qu'est-ce qui justifie d'investir autant là-dedans ?
* n'est-ce pas de toutes façons voué à l'échec ? Un mec qui veut passer des données y arrivera, quitte à utiliser sa connxion 3G ou une bête clé USB.
Il faudrait un peu arrêter avec ces conneries de flicage en entreprise, c'est pire que sarkoland dans bien trop d'endroits.
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . Évalué à 2.
Toujours est-il que ce n'est pas forcément une question de confiance, c'est une question de contrat.
Quand on parle de réseau, ce n'est pas forcément un réseau d'utilisateurs... Ca peut être des serveurs, le tunnel icmp peut être une manière furtive de sortir des données, et ça peut poser un problème aux utilisateurs du dit serveur. Il y a peut-être des données confidentielles et personnelles dessus. Si quelqu'un parvient à s'introduire sur le serveur (mettons par une faille php, classique), l'idée est qu'il ne puisse pas sortir d'information sans que ça se voie... En plus j'ai déjà vu un gros truc bien évident (type reverse backdoor bloquée par le firewall, tentatives maladroite d'escalade de privilège) qui servait surtout à dissimuler une fuite d'information via un tunnel icmp ou DNS...
Et puis bon, pour les réseaux interne, la question n'est pas de savoir si c'est bien ou pas, c'est de savoir si tu veux avoir la maîtrise de ton réseau. Si on bloque le ssh à l'extérieur, c'est pas pour laisser passer un truc aussi vieux qu'un tunnel icmp. Si on ne le bloque pas, on loggue au moins les accès externe pour savoir qui se connecte où, et faire la différence entre le gars qui se connecte de temps en temps chez lui pour faire de l'irc (inoffensif et pas gênant a priori) et celui qui uploade une énorme quantité de données en ukraine... Personnellement je n'ai aucun problème à laisser sortir un utilisateur en ssh pour se connecter à un serveur perso entre midi et deux, mais le jour où ça sert à sortir des infos confidentielles, c'est que je n'ai pas joué mon rôle. Sans parler du jour où ça sert à lancer des attaques dictionnaire un peu partout... ;-)
La sécurité, c'est pas simple, ce n'est pas les gentils utilisateurs contre les vilains admins, ni l'inverse ; et surtout ça ne peut se faire que si tout le monde y met du sien. Il ne s'agit pas de s'aliéner les utilisateurs (même si parfois il y a des têtes de c**), mais de se protéger contre les indélicats (le gars qui passe plus de temps à bosser sur des trucs perso que pour l'entreprise, celui qui joue double jeu et tente de récupérer des clients à son compte avant de démissionner...), et contre les maladresses (j'ai cliqué sur le mauvais lien, ça m'a installé un troyen et maintenant on est attaqués en justice parce que notre ip de sortie a servi à pirater un ordinateur du minefi).
Bien sûr qu'un type déterminé y arrivera. Ce n'est qu'une question de savoir faire, de motivation et de temps. Mais moi je suis payé pour lui compliquer la vie ! ;-)
[^] # Re: Pas de réponse aux demande de ping
Posté par benoar . Évalué à 2.
- le tunneling par icmp ping, tu me parleras de l'efficacité ... franchement, c'est ce prendre la tête pour un problème minime
- pour le fingerprinting : et alors ? je m'en fous qu'on sache que je tourne sous un OS sécurisé ;-) Et pour la découverte de réseau ... t'as une référence ?
Je trouves ces problématiques bien trop tatillonnes pour ce que c'est. Bon, d'un autre coté, je ne suis pas admin réseau !
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . Évalué à 2.
Pour l'exemple de découverte du réseau, l'icmp c'est quand même le plus vieux protocole pour ça :-)
Sinon, un exemple typique de découverte du réseau et de fingerprinting en une passe : envoyer un paquet icmp echo request sur l'adresse broadcast, et regarder qui répond quoi. Ou encore sur l'adresse du réseau, même principe. Les fonctionnement par défaut des os sont assez disparates (y'a ceux qui répondent normalement, ceux qui l'ignorent, ceux qui répondent un truc spécifique...).
Quand aux dangers du fingerprinting, je suis assez d'accord à la base, mais au final c'est, plus qu'une véritable mesure de sécurisation (assimilable à une porte blindée ou une serrure), un truc qui permet de ralentir ou de décourager le pirate de passage. Ca ne fera que ralentir un peu le vrai gars déterminé, mais déjà si on s'est débarrassé des attaques automatiques et des Jean-Kévin c'est toujours ça de pris. On peut comparer ça au fait de mettre sa maison sur une colline un peu escarpée :-)
Bon, après, le défaut c'est que ça peut avoir l'effet inverse chez le hacker - le vrai - curieux : « tiens ça m'a l'air bien protégé par ici... Est-ce que je vais réussir à passer, et qu'est-ce que ça cache ? » ;-)
En plus on parle théorie, là, dans la vraie vie on n'a pas toujours le loisir de mettre autant de protections de manières systématique. Encore une fois, c'est une question de gestion du risque, il faut faire le rapport entre le risque qu'on prend quand on ne le fait pas et ce que ça coûte (en argent, temps, énergie...).
# serveur dedié (un poil hs)
Posté par Anonyme . Évalué à 2.
j'ai loué un serveur dedié avec une mise en place a 1H. aprés 1 journée d'attente je ne l'attendais plus. 48H plus tard ils m'envoient un mail vers 10h00 du matin que je lis vers les 20H00 comme quoi c'est bon mon serveur dedié sous debian 5.0 m'attend
arg ! 10h00 tous seul sur le ternet, je m'empresse de mettre des regle iptable qui bloque tous entrée et sortie sauf ssh, j'avais deja fais une bourde a ce sujet \o/
maintenant j'ouvre gentiment ce que j'ai besoin, histoire de de voir ce qui arrive sur mon serveur, j'utilise iftop http://www.ex-parrot.com/~pdw/iftop/ c'est simple et c'est efficace. bon je remarque que pas mal de personnes aimeraient avoir mon serveur pour leur propre besoin sans rien payer, et j'ai des tentatives de connection vers l'exterieur dont je n'arrive pas trouver l'origine snif...
CONCLUSIONS: je pensai naivement qu'avec un dedié je serais un poil plus tranquille niveau securité qu'a la maison c'est faux, et c'est pire !
sinon maintant j'eteind mes ordinateurs la nuit ainsi que ma freebox, j utilise le dedié principalement pour la compilation et d'autre truc necessitant de la puissance, et aussi comme support de sauvegarde.
je saisis mieux l'interet d'avoir un eeepc, a la place de mon portable bruyant et de la tour qui prend de la place. En plus tous cela est bien au frais et en securité.
[^] # Re: serveur dedié (un poil hs)
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
En fait c'est totalement logique. Un serveur dédié se trouve généralement dans un datacenter, ce qui est une assurance (en temps normal) de stabilité de la connectivité réseau et électrique. Ajoute à cela la grosse bande passante disponible (souvent symétrique d'ailleurs) et, dans une moindre mesure l'espace de stockage, les serveurs dédiés sont une cible de choix.
On compare un serveur branché sur du 100Mbit/s symétrique avec 300Gio de disque et allumé 24x7 avec un pc domestique avec l'adsl 20Mbit/s en download et environs 1Mbit/s en upload et allumé on ne sait trop quand.
[^] # Re: serveur dedié (un poil hs)
Posté par nodens . Évalué à 4.
Du coup la cible c'est plutôt du windows, tout simplement parce qu'il y a moins de chances de se faire repérer (un utilisateur de système alternatif a tendance à s'intéresser à ce qui se passe sur son système), et qu'il y en a plus donc les attaques de masse sont plus rentables. En plus le layer 8 est généralement plus vulnérable.
Par contre un serveur dédié, c'est royal pour tout ce qui demande de la bande passante ou une faible latence, et les machines unix-like sont idéales comme machines rebond pour attaquer d'autres machines.
La finalité des attaques n'est donc pas la même (mais elles ne sont pas moins nombreuses pour autant, surtout que la durée de vie d'une machine piratée n'est pas forcément très longue, on se fait parfois repérer assez vite donc il faut en avoir un certain nombre sous le coude).
Du coup, le "public" à l'origine des attaques est différent. D'ailleurs les moyens de sécurisation les plus rentables ne sont pas les mêmes non plus (par rentables, j'entend qui rapporte le meilleur ratio attaques/protection).
Un serveur unix-like qui ne peut pas établir de connexions vers l'extérieur et qui n'a que du 80 et du 22 ouvert en entrée, et ce par un par feu sur une machine distincte, présente peu d'intérêt. Par contre toute possibilité de sortie (p2p, irc, web, ssh...) le rend particulièrement attrayant, si on a le moyen de le contrôler (et les connect-back servent à ça).
# Soit dit en passant.
Posté par Maxime DERCHE (site web personnel) . Évalué à 2.
[^] # Re: Soit dit en passant.
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
Si tu en as trop, contacte moi en MP ;)
[^] # Re: Soit dit en passant.
Posté par nodens . Évalué à 3.
[^] # Re: Soit dit en passant.
Posté par Maxime DERCHE (site web personnel) . Évalué à 3.
En gros, tu détermines le sens in et out par rapport au sens de l'interface "principale" de la machine qui sert de routeur (en règle générale c'est $ext_if vu que c'est celle qui a accès à Internet).
Sinon, pour l'histoire des blocs NAT + filtrage, c'est à vérifier, mais maintenant que set require-order est à no par défaut (arrivé dans -current y'a quelques semaines, ce sera pour 4.6), y'a peut-être moyen de moyenner ce genre de construction...
Le bouquin sort jeudi en librairie, alors tu pourras l'acheter et progresser. =)
Cordialement,
Maxime
PS : Le livre donne deux exemples de scripts minimaux pour ordinateur personnel. C'est *beaucoup* plus court et vraiment très beaucoup plus lisible que le script donné dans ce journal...
[^] # Re: Soit dit en passant.
Posté par nodens . Évalué à 3.
Exemple de cas gênant : si ma machine c'est une passerelle dont le rôle est de tagguer des vlan (disons 500 interfaces) et de les filtrer, et qui n'est pas « connectée à internet » mais fait partie d'un backbone, in/out ça devient complètement arbitraire comme appellation... Et du coup vachement moins lisible.
D'ailleurs je ne vois pas comment on filtre entre deux vlans à ce compte là, il faudrait que je recreuse.
Le set require-order à no c'est une bonne nouvelle. Je ne savais pas que ça existait. C'est un paramètre noyau ou pf ? Ca existe (même à yes par défaut) dans des versions antérieure ? Faut que j'attende son apparition dans une version stable de FreeBSD pour pouvoir en profiter sur l'existant :-).
(Ben oui les nouveaux trucs, sauf pour la gestion de la QoS, j'ai tendance à les mettre sous linux du coup).
[^] # Re: Soit dit en passant.
Posté par Maxime DERCHE (site web personnel) . Évalué à 2.
Y'a eu une discussion pas plus tard que tout-à-l'heure sur misc@ concernant set require-order : http://marc.info/?l=m=124638546506021. Apparemment, cette option existe depuis 2002, soit depuis le tout début. Elle était par défaut à yes. Et c'est une option de PF, (mal documentée, je te l'accorde).
Cordialement,
Maxime
[^] # Re: Soit dit en passant.
Posté par nodens . Évalué à 2.
Je prends note sur set require-order. J'ai passé pas mal de temps sur cette problématique et la seule réponse que j'avais trouvé c'était que j'étais obligé de respecter l'ordre, et ça me gênait énormément (le pire étant les ancres). Il faut que je regarde ce que ça implique pour les ancres, justement, mais au pire je me passerait d'ancres quitte à générer le pf.conf à la volée pour séparer en plusieurs fichiers.
Moralité, il vaut mieux se plaindre sur DLFP que sur un chan irc, fut-il consacré à *BSD. On a plus de réponses utiles ;-P
[^] # Re: Soit dit en passant.
Posté par Maxime DERCHE (site web personnel) . Évalué à 1.
[^] # Re: Soit dit en passant.
Posté par Maxime DERCHE (site web personnel) . Évalué à 1.
# Règles par défaut
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Bref, je n'aime pas les scripts de firewall qui joue sur les timeout système pour leur mise en place. J'aime bien pouvoir faire un copier coller et que les choses ait exactement le même comportement. Dans mes scripts à moi, je comme TOUJOURS par les lignes suivantes :
# Policies
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
Puis, j'accepte en entrée sortie (deux règles écrites explicitement) tout ce qui concerne la loopback (lo). Dans ton script à toi, il n'y en a qu'une car il y a une règle implicite sur la loopback. Je n'aime pas les règles implicites...
Enfin, je finit sur le bas du script par les règles par défaut définitive
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
En effet, j'écris aussi des règles explicites sur la chaîne OUTPUT. Je trouve plus clair d'écrire à coté des règles d'entrée INPUT le correspond pour la sortie OUTPUT que de laisser tout sortir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.