Parmi les changements depuis la version 4.0, on trouve l'amélioration du support de l'architecture sparc64, des nouveaux pilotes wifi (zyd, malo), le support des Macs i386, un fsck plus robuste, des améliorations dans OpenRCS (la couche en dessous d'OpenCVS), un nouveau démon de routage RIP, l'intégration d'OpenSSH 4.6 et de son support de la configuration par utilisateur (option de configuration Match), diverses améliorations du système de pare-feu packet filter (expiration du contenu des tables, tables de routages indépendantes, un comportement par défaut plus simple et sûr,...) et un nouveau démon de répartition de charge : hoststated(8).
Comme d'habitude, des nouveaux T-shirts, posters et CD sont disponibles. L'image retenue est sous les traits de "Puffy Baba et les 40 voleurs".
NdM : Merci à travisnux pour avoir soumis une dépêche similaire. Le projet OpenBSD fournit un système d'exploitation de type Unix libre, multi plates-formes et basé sur 4.4BSD. Les efforts portent sur la portabilité, la standardisation, l'exactitude, la sécurité proactive et la cryptographie intégrée.
Le nouveau démon hostated permet principalement de garder des tables pf à jour en vérifiant que les hôtes qui y sont listés sont disponibles de manière à permettre une répartition de charge sur plusieurs serveurs qui ne sont pas nécessairement tous disponibles en même temps.
À noter qu'il existe déjà des mises à jour de sécurité pour cette nouvelle version d'OpenBSD.
Aller plus loin
- OpenBSD (8 clics)
- l'annonce sur la liste de diffusion openbsd-misc (2 clics)
- les principales nouveautés (1 clic)
- liste complète des changements entre 4.0 et 4.1 (2 clics)
- un article détaillant l'intérêt d'hoststated (0 clic)
# T-shirt
Posté par olivn . Évalué à 8.
Ce que l'on traduit généralement par
Une société qui est prête à sacrifier un peu de sa liberté contre un peu de sa sécurité, ne mérite ni l'une ni l'autre, et perdra les deux.
[^] # Re: T-shirt
Posté par Pol' uX (site web personnel) . Évalué à 6.
Quelqu'un qui est prêt à sacrifier un peu de sa liberté contre un peu de performance, ne mérite ni l'une ni l'autre.
N'y voyez pas un troll sur les blobs nvidia ;-)
Adhérer à l'April, ça vous tente ?
[^] # Re: T-shirt
Posté par Krunch (site web personnel) . Évalué à 0.
Apparement il n'est plus en vente.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: T-shirt
Posté par patrick_g (site web personnel) . Évalué à 10.
[^] # Re: T-shirt
Posté par TeraHertZ . Évalué à -1.
Si on était dans un monde binaire, oui pourquoi pas...
[^] # Re: T-shirt
Posté par Krunch (site web personnel) . Évalué à 3.
(c'est mon t-shirt obsd préféré, le bleu du t-shirt est moins pourri que celui de l'image :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pf(4), de plus en plus simple
Posté par herodiade . Évalué à 10.
La dépêche ne détaille pas ce point, alors j'y vais ;).
La directive "keep state" du firewall pf(4) est maintenant activée par défaut pour les règles "pass" ainsi que le contrôle des en-tetes TCP "flasg S/SA". Cela peut surprendre : « pourquoi ont-ils choisi de faire une modification de ce type, pas rétro-compatible, qui risque de poser des pbs à certains parmi ceux qui ne RTFM pas avant d'upgrader ? ».
Et bien c'est précisément ce type de décisions courageuses que j'admire : elles font que pf(4) se bonifie et que son utilisation se simplifie avec le temps au lieu de devenir kludgy au fur et à mesure que les fonctionnalités s'empilent.
Un exemple : nous voulons autoriser l'accès ssh depuis l'extérieur.
Il y a un an ou deux, nous écrivions :
ext_if="re0"
pass in on $ext_if from any to any port 22 keep state flags S/SA
Mais les choses ont évoluées :
- Depuis un moment déjà, il n'est plus nécessaire d'écrire "from any", "to any" et encore moins "from any to any"- "keep state" servait à rendre la règle statefull (en quelque sorte, « bidirectionnelle » : on autorise le traffic sortant du port 22 en réponse à une requête externe). Il est désormais activé par défaut pour les "pass".
- "flags S/SA" était généralement ajouté aux règles "pass" : cela signifie "accepte les paquets TCP initiant de nouvelles connexions uniquement s'ils ont le flag SYN et pas le flag ACK". C'est maintenant activé par défaut pour les règles "pass".
- On utilisait typiquement une macro comme $ext_if pour désigner notre interface externe. Maintenant on peut utiliser le groupe "egress" : le nom de l'interface par laquelle passe la route par défaut est automatiquement et dynamiquement substitué. Dynamiquement = même si on change à chaud la cnx/route ou la carte réseau (ou bien à froid/au reboot : si on met le disque dans une autre machine, par ex, le ruleset reste valable).
Désormais, pour le même résultat, il suffit donc de :
pass in on egress to port 22
Bien que le nombre de fonctionnalités explose, les rulesets deviennent de plus en plus compacts, portables, simples et lisibles.
[^] # Exemple de ruleset domestique classique
Posté par herodiade . Évalué à 7.
- On veut normaliser ("scrub": defragmente, vire les martiens etc.)
- On veut NATer le lan
- On veut autoriser les acces web, ssh et l'icmp venant de l'extérieur
- On veut autoriser tout le trafic sur le lan et le loopback
- On veut autoriser le trafic sortant de la passerelle
scrub all
nat pass on egress -> (egress)
pass quick proto tcp to port { ssh, http }
pass quick proto icmp
block quick on egress
pass all
C'est tout.
Remarquez que ce type de ruleset est complètement portable : on peut le copier tel quel sur d'autres passerelles aux besoins identiques, on n'a pas eu besoin d'écrire des noms d'interfaces ni d'adresses IP en dur.
Et le nouveau machin pour configurer l'IPsec, ipsecctl(8) et ipsec.conf(5), est du même tonneau :)
[^] # Re: Exemple de ruleset domestique classique
Posté par Krunch (site web personnel) . Évalué à 5.
« Ben oui... »
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Exemple de ruleset domestique classique
Posté par octane . Évalué à 2.
CLUSTERIP
This module allows you to configure a simple cluster of nodes that share a certain IP and MAC address without an explicit load balancer in front of them. Connections are statically distributed between the nodes in this cluster.
--new
Create a new ClusterIP. You always have to set this on the first rule for a given ClusterIP.
--hashmode mode
Specify the hashing mode. Has to be one of sourceip, sourceip-sourceport, sourceip-sourceport-destport
--clustermac mac
Specify the ClusterIP MAC address. Has to be a link-layer multicast address
--total-nodes num
Number of total nodes within this cluster.
--local-node num
Local node number within this cluster.
--hash-init rnd
Specify the random seed used for hash initialization.
et une petite doc avec des avertissements interessants concernant certaines limites inherentes au load balancing : http://iptables-tutorial.frozentux.net/iptables-tutorial.htm(...)
[^] # Re: Exemple de ruleset domestique classique
Posté par vosgien_ . Évalué à 4.
-- possibilité de distribuer le trafic au delà de routeurs (CLUSTERIP semble n'accepter que des adresses MAC),
-- possibilité de distribuer les connexions avec plus de flexibilité : algorithmes plus nombreux,
-- possibilité de faire du load balancing de niveau 3 ou 7 en combinant avec hoststated.
Après je ne connais pas le fonctionnement de CLUSTERIP en détail.
[^] # Re: Exemple de ruleset domestique classique
Posté par carlo . Évalué à 4.
j'ai un peu du mal à voir comment marche ce egress (j'ai juste parcouru rapidement la faq PF qui dit juste "The egress group, which contains the interface(s) that holds the default route(s)", ça semble dire que ça contient l'interface qui conduit à la passerelle/route par défaut) mais en tout cas la (encore) simplification de la syntaxe PF est une bonne nouvelle, une très bonne nouvelle !
J'apprécie en effet particulièrement OpenBSD et PF pour cela : la puissance, la sécurité et la simplicité de la syntaxe, ce qui implique la sécurité puisqu'il y a moins de risque de faire des erreurs.
Bravo encore à l'équipe !
[^] # Re: Exemple de ruleset domestique classique
Posté par vosgien_ . Évalué à 2.
Ces groupes d'interfaces se configurent avec ifconfig.
Tu peux écrire ton fichier pf.conf avec des noms d'interfaces ou de groupes. Tout fonctionne de la même manière.
L'avantage avec egress est la portabilité puisque tu n'as plus besoin de te soucier de la portabilité de ton fichier si tu change de machine ou de carte réseau pour ta passerelle.
C'est aussi utile dans d'autres cas : par exemple, pour mon laptop, j'ai un seul fichier pf.conf écrit en fonction d'egress. Dès que je bascule sur le wifi, le basculement se fait automatiquement par PF, je n'ai pas besoin de recharger les règles.
Avec les groupes tu peux aussi faire des choses très intéressantes et simplifier grandement ton fichier. Imaginons que tu gères un routeur/firewall avec de multiples interfaces ayant les mêmes politiques, elles peuvent toutes être rassemblées dans un seul groupe. Une seule politique de filtrage pour le groupe est nécessaire.
[^] # Re: Exemple de ruleset domestique classique
Posté par reno . Évalué à 3.
Puisqu'il ont fait des modifications incompatibles, tant qu'à faire..
[^] # Re: pf(4), de plus en plus simple
Posté par TazForEver . Évalué à 1.
[^] # Re: pf(4), de plus en plus simple
Posté par panda panda . Évalué à 1.
sachant que tout ce qui touche aux interfaces se gere avec ifconfig sous open... ca parait logique non ?
[^] # Re: pf(4), de plus en plus simple
Posté par TazForEver . Évalué à 1.
[^] # Re: pf(4), de plus en plus simple
Posté par vosgien_ . Évalué à 2.
[^] # Re: pf(4), de plus en plus simple
Posté par herodiade . Évalué à 3.
Même chose, par exemple, pour le groupe "lo" (auquel sont ajoutées automatiquement toutes les interfaces de loopback).
Tout est documenté dans la page de man de ifconfig(8). L'utilisation est simplissime :
- ifconfig nom_if group nom_groupe pour ajouter une if dans un groupe. Ex :
$ ifconfig lo0 group toto
- ifconfig (tout court) pour afficher les interfaces et leurs groupes, par ex:
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
groups: lo toto
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
Benoît : il y a eu des modifications de pf (afin de permettre de nommer une interface par son groupe et pas seulement son nom, dans les rulesets).
# typo
Posté par panda panda . Évalué à 6.
je sais j'ai change souvent de nom, mais faut pas ajouter a la confusion.
[^] # Re: typo
Posté par BAud (site web personnel) . Évalué à 3.
et ça veut dire quoi ;-) ?
[^] # Re: typo
Posté par panda panda . Évalué à 7.
Pour completer un peu la news, hoststated est un load balancer niveau 3 et niveau 7.
la version contenue dans OpenBSD 4.1 ne fournit que les fonctionnalites de load balancing niveau 3. Dans les versions -current d'OpenBSD vous trouverez en plus les fonctionnalites niveau 7.
Ce daemon permet de synchroniser l'etat de tables pf avec le statut reel des machines en faisant partie. Le statut est determine grace a un test (soit icmp, soit tcp /ssl, soit http/https).
Dans sa mouture niveau 3 hoststated maintien a jour des tables PF ainsi que des regles de redirection (RDR).
Enfin l'outil hoststatectl permet de connaitre l'etat des tables et regles, ainsi que d'activer ou desactiver a la demande des membres de chaque table.
Un petit tutorial (qui ne couvre que le niveau 3) en anglais ici: http://spootnik.org/hoststated/hoststated_introduction.html
[^] # Re: typo
Posté par herodiade . Évalué à 2.
# Site Francophone des Utilisateurs d'OpenBSD
Posté par banga . Évalué à 6.
http://www.openbsd-france.org
qui contient:
- des documentations pour OpenBSD: http://www.openbsd-france.org/documentations/
- une liste de discussions officielles Fr : http://www.openbsd-france.org/ml/
- un channel irc : #openbsd.fr sur irc.freenode.net
Tout ça en Français bien entendu.
[^] # Re: Site Francophone des Utilisateurs d'OpenBSD
Posté par gaston . Évalué à 5.
http://www.openbsd101.com/
http://www.openbsdsupport.org/
Au passage, le 2e miroir français est mis à jour avec cette dernière version :
ftp://ftp.irisa.fr/pub/OpenBSD/4.1/
# Installation sans CD ?
Posté par Moonz . Évalué à 3.
Comment installeriez vous OpenBSD sans lecteur CD, sans lecteur disquette et sans réseau ? Y a t'il un moyen de l'installer depuis Linux, de la même manière que je peux installer une Gentoo depuis une Debian ? (je sais, c'est pas comparable, et ça me parait mal barré vu que j'ai pas vu d'équivalent de disklabel et que Linux semble pas pouvoir écrire sur les partitions *BSD, mais ça coûte rien de demander naïvement...)
[^] # Re: Installation sans CD ?
Posté par Miod in the middle . Évalué à 4.
[^] # Re: Installation sans CD ?
Posté par gde . Évalué à 2.
[^] # Re: Installation sans CD ?
Posté par rdem . Évalué à 1.
Idée inspirée de http://open.bsdedibox.net
[^] # Re: Installation sans CD ?
Posté par Psychofox (Mastodon) . Évalué à 2.
Sinon y'a toujours l'usb...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.