Un serveur web très sécurisé avec OpenBSD.

Ces dernières semaines ont été pour moi l’occasion de faire la connaissance d’OpenBSD, un système d’exploitation orienté serveur, et ce bien plus que Linux. J’y ai retrouvé les mêmes qualités que lors de ma première découverte du monde de GNU/Linux il y a quelques années : fiabilité, sécurité, stabilité. OpenBSD semble faire mieux que GNU/Linux sur ces qualités, ceci induisant une plus grande inertie (le serveur Web par défaut n’étant qu’apache 1). En revanche, celui-ci n’hérite pas du côté « bazar » de GNU/Linux. Tout y est plus propre, plus organisé, et tout le monde possède sa page de man.

Pour explorer ce nouveau monde, il m’a semblé pertinent de commencer par installer et configurer Apache et son acolyte PHP en insistant sur les fonctionnalités de sécurisation d’OpenBSD, qui ont fait la notoriété de ce dernier. C’est cette expérience que je souhaite partager avec vous. Si elle s’avère concluante, je pense utiliser OpenBSD sur mes petits serveurs.

Je commencerais mon article par cette petite citation de Theo De Raadt qui pourrait résumer l’esprit de la communauté BSD, fréquemment surprise à piquer GNU/Linux

Linux people do what they do because they hate Microsoft. We do what we do because we love Unix.

1°Installation du système

Pour ma part, j’installerais mon système dans une VM, afin de pouvoir ensuite l’envoyer sur mon futur serveur ESXi. Bien sûr, la procédure est en tout point similaire en cas d’installation « en dur ».

Après avoir récupéré l’iso sur le site d’OpenBSD, et son lancement dans une machine virtuelle utilisant les pré-réglages de VMware (en utilisant le préréglage FreeBSD cependant), nous arrivons à la première étape d’installation.

Première étape

Dans le cadre d’une première installation, il nous faudra naturellement appuyer sur la touche I.

  1. Il vous demandera ensuite votre keyboard layout. Tapez fr si vous avez un clavier français.
  2. Choisissez votre nom d’hôte.
  3. Laissez lui obtenir son adresse par DHCP, il sera de toute manière possible de revenir là-dessus lors de la mise en production.
  4. Choisissez votre mot de passe root. OpenBSD est un système sécurisé, il serait dommage que sa plus grosse faiblesse vienne d’un mot de passe root anémique. Choisissez-en un unique, aléatoire, long et contenant des caractères spéciaux. Enfin, vous connaissez tout ça, mais ça me parait très important pour un système qui se veut sécurisé. Attention au pavé numérique en tapant des chiffres !
  5. Ensuite, libre à vous d’activer SSH par défaut, pour ma part j’utilise uniquement SSH et ne peut que vous conseiller de faire de la même façon.
  6. Le serveurNTPD n’a pas de sens puisqu’on veut un système léger et avec le moins possible d’angle d’attaque.
  7. Dans le cadre d’un serveur, utiliser X parait inapproprié, pour ma part je répondrais non à l’installeur. Répondez non à la question suivante, ça devrait aller.
  8. Créez ensuite votre compte utilisateur. Je vous conseille vivement de choisir un mot de passe différent que le mot de passe root, mais tout aussi complexe.
  9. Après avoir laissé la configuration par défaut aux questions suivantes, nous arrivons au partitionnement. N’ayant pas de problématique particulière, j’utiliserais tout le disque (W), en utilisant l’auto layout.

Après le formatage du disque, nous arrivons au choix de la source d’installation. Ayant eu des problèmes avec le ftp, je préfère le http. Je n’utiliserai pas de proxy, et garderai l’URL proposée par l’installeur.

Il est ensuite temps de sélectionner les paquets à installer. Refusant le superflu, et souhaitant le système le plus épuré possible, nous désactiverons les paquets game48.tgz, xbase48.tgz, xetc48.tgz, xshare48.tgz, xfont48.tgz et xserv48.tgz en tapant leurs noms précédés du signe – . Ces paquets contiennent le nécessaire pour le serveur graphique que nous n’utilisons pas, ainsi qu’un paquet de jeux.

Les téléchargements commencent, prenez le temps de boire un café (ou un thé selon vos préférences). Il vous faudra ensuite régler l’heure, puis c’est tout. Qui a dit qu’installer OpenBSD était fastidieux ?
Finalement, tapez reboot pour redémarrer.

2° Prise en main initiale du système

Bienvenue chez vous ! Vous pouvez vous connecter en root. Pour commencer, lisez votre premier mail, en tapant la commande éponyme. Il contient de nombreuses instructions post-installation.

Une des premières opérations à effectuer est d’activer sudo pour notre compte. Entrez la commande visudo et dé-commentez la ligne qui donne au groupe wheel le droit d’utiliser sudo. Attention, c’est vi, c’est assez pénible quand on connait pas.

A présent, je me connecterais en SSH à mon serveur pour avoir le clavier bien mappé et tout ça.

Vous remarquerez que le système prend moins de 500 Mo une fois installé. Il est bien sûr possible de descendre en deçà, mais la légèreté par défaut est très agréable.

Nous allons ensuite modifier notre .profile afin d’avoir toujours la variable PKG_PATH active. C’est cette variable qu’utilisera pkg_add pour  télécharger les logiciels.

J’y ajouterais les lignes suivantes :

export PS1="\u@\h:\w\$ "
export PKG_PATH=ftp://ftp.arcane-networks.fr/pub/OpenBSD/4.8/packages/amd64/

La première ligne sert à avoir une console affichant des informations sur le nom d’utilisateur, le nom d’hôte et le répertoire actuel. Ces informations éviteront d’inverser les serveurs, de se tromper d’utilisateur ou travailler sur les mauvais répertoires. Vous pouvez choisir l’URL de votre path selon vos préférences, le miroir que j’ai sélectionné me parait suffisamment sérieux.

Un rapide passage de nmap sur le serveur montrera qu’il y a déjà trop de services activés : ident, daytime et time. Ces petits services émanent du démon inetd. Celui-ci sert à lancer des services en cas de connexion sur des ports précis. Par exemple, il peut écouter le port ftp et attendre une connexion sur ledit pour lancer le serveur ftp. Ceci évite d’avoir le service ftp lancé si on utilisation est rare. Je désactiverais inetd car il nous sera inutile dans le cadre d’un serveur web simple, et dominera ainsi la surface d’attaque possible pour un attaquant potentiel. Pour cela, modifiez /etc/rc.conf et changez le YES en NO sur la ligne correspondante. Vous remarquerez que ce fichier contient tous les services, et s’ils doivent se lancer au démarrage. J’en profiterais pour désactiver sendmail car je ne l’utilise pas, mais faites comme vous en avez l’habitude.

Nous en profiterons pour activer apache, puisqu’après tout, c’est pour lui que nous travaillons.

# use -u to disable chroot, see httpd(8)
 httpd_flags=YES # for normal use: "" (or "-DSSL" after reading ssl(8))

Nous pouvons passer à l’installation de PHP. Rassurez-vous, ça devient intéressant

3° Installation de PHP et intégration dans l’environnement de chroot.

Sous OpenBSD, apache est chrooté. Pour faire simple, cela signifie qu’il est strictement cantonné à un répertoire, en plus de tourner sous un utilisateur spécifique. Cela signifie que, dans l’hypothèse d’une compromission de son processus, l’attaquant sera tristement cantonné au répertoire d’apache, réduisant ses possibilités d’obtenir un shell root, de modifier le reste du système ou de mettre la main sur d’autres données.

C’est le moment de mettre les points sur les i. Toutes ces protections ne sont pas complètement sécurisées pour toujours : les possibilités de failles logicielles et d’exploitation seront toujours présentes. Il s’agit simplement de multiplier les barrières au pirate potentiel afin de lui rendre la tâche plus compliquée, en espérant qu’il bute sur une de ces barrières. Vous allez penser que le titre de mon article vous vendait du rêve, je suis désolé d’entacher vos illusions, mais je pense qu’on sera d’accord pour dire qu’un système d’information infaillible et inviolable est une chimère. Le meilleur moyen de sécuriser un système, c’est de le débrancher (et de retirer la batterie sur un portable, bien sûr) et de ne rien attendre de lui. Néanmoins, relativisons, OpenBSD est très sécurisé, et à moins que votre système serve à contrôler des usines d’enrichissement d’uranium illégales, et que l’unité 8200 veut votre peau, il devrait pouvoir contenir un grosse majorité d’attaquants.

Pour revenir à nos moutons, le chroot est aussi une petite difficulté pour nous : php a besoin de certains fichiers qui ne sont pas dans l’environnement de chroot, et il va falloir mettre les mains dans le cambouis pour pallier à cela. Par chance, le php dans les dépots prend en compte toutes ces spécificités, évitant de devoir l’analyser pour copier dans le chroot les fichiers dont il a besoin. Pour l’avoir fait, c’est une manipulation assez peu intéressante.

Premièrement, installer php :

# pkg_add php5-core-5.2.13p0.tgz
 php5-core-5.2.13p0:libxml-2.7.6: ok
 php5-core-5.2.13p0: ok
 --- +php5-core-5.2.13p0 -------------------
 To enable the php5 module please create a symbolic
 link from /var/www/conf/modules.sample/php5.conf
 to /var/www/conf/modules/php5.conf.
ln -s /var/www/conf/modules.sample/php5.conf \
 /var/www/conf/modules
The recommended php configuration has been installed
 to /var/www/conf/php.ini.

Écoutez l’installeur et faites le lien comme demandé :

 ln -s /var/www/conf/modules.sample/php5.conf  /var/www/conf/module

Vous devez ensuite modifier /var/www/conf/httpd.conf et ajouter

AddType application/x-httpd-php .php

ou décommenter la ligne spécifique.

Ligne à décommenter

Ligne à décommenter

Il faut alors (re)lancer apache avec la commande

sudo /usr/sbin/apachectl restart

Pour vérifier l’installation  de notre php, nous poserons un fichier php avec phpinfo() et nous essaierons (avec succès normalement) d’y accéder depuis notre navigateur.

4° Un Apache sous haute surveillance avec systrace

Le chroot offre une bonne sécurité au niveau du système de fichier : Apache sera confiné à son répertoire et, à moins d’une faille dans chroot lui-même, le pirate potentiel sera déjà pas mal limité. Cependant, dans son répertoire, Apache pourra faire ce que bon lui semble.

Systrace permet de s’assurer qu’apache fait uniquement ce qu’il doit faire en surveillant attentivement ses appels système. Systrace se place comme un system call proxy, en se plaçant entre Apache et le kernel. Ainsi, il surveillera les appels système de Apache afin de s’assurer qu’il ne fait que des actions qui entrent dans le cadre de ses fonctions. Il faut donc créer les policies, listant tout ce que le logiciel fait en temps normal. Pour se faire, arretez apache avec sudo apachectl stop, puis relancez le avec sudo systrace -A  httpd.

Il faut à présent utiliser votre site dans ses moindre retranchements, afin de laisser systrace créer les règles. Pensez à utiliser toutes les fonctionnalités de votre site. Mon site possédait une fonctionnalité d’envoi d’images, je n’avais pas pensé à l’utiliser la première fois, cassant ladite fonctionnalité lors de la mise en production avec l’application de la police.

Une fois ce laborieux travail effectué, vous pouvez arrêter apache avec apachectl stop.

Il va falloir nettoyer la police afin de l’optimiser. Le fichier sera utilisé à chaque appel pour vérifier les droits, il faut donc qu’il soit très clair, et le plus condensé possible afin de minimiser l’inévitable impact sur les performances. Le fichier contenant la police sera créé dans le dossier .systrace de votre home. La lecture de ce fichier sera d’autant plus intéressante qu’elle vous apprend la totalité des actions entreprises par apache et vous dévoile son fonctionnement intrinsèque.

Je suppose que votre fichier ressemblera au mien :

Vous voyez tout les appels qu’apache à utilisé. Il faut à présent les condenser : Par exemple, apache aura besoin de lire dans /var/www, puisque c’est dans son répertoire. On a par exemple la ligne

native-fsread: filename eq "/var/www" then permit

qu’on peut transformer en :

native-fsread: filename match "/var/www/*" then permit

Vous devez, de cette façon, remodeler le fichier de police afin de réduire son nombre de règles. Pensez par exemple aux droits d’écriture dans le dossier tmp de php, ou dans le dossier des logs. Pensez également qu’après le chroot, le nouveau dossier racine est /var/www, il va donc falloir autoriser la lecture dans /htdocs et non /var/www/htdocs, etc. Notez les ports dont il a également besoin, comme le port dns 53, car ils nous serviront plus tard à configurer le pare-feu. Systrace offre également la possibilité de faire les règles en interaction avec le switch -t, cependant celle-ci ne créait pas toujours les règles avec les arguments des appels, créant ainsi des polices très laxistes.  Je suppose qu’on peut ordonner les appels par ordre croissant d’utilisation, afin d’éviter à systrace de parcourir toute la police à chaque fois. Toutes les opérations usuelles, telles les lectures dans /htdocs devraient être en haut. Je ne peux que vous inviter à passer du temps à concocter ces règles, celles-ci pouvant être la source de nombreux dysfonctionnements. Et en plus, c’est une activité assez intéressante car dévoilant les tréfonds de votre fidèle Apache. Vous remarquerez que les exécutables des shell, tels /bin/sh ne sont pas autorisés. En toute logique cela signifie que des shellcodes lançant des shells seront ainsi inefficace.  De plus, les appels concernant le réseau sont aussi interdits (sauf pour les dns et bien sur l’écoute sur le port 80), obligeant le pirate à réutiliser la connexion utilisée par le service de la page en HTTP, rendant une hypothétique exploitation bien plus compliquée.

Systrace peut également se montrer utile pour débugguer rapidement un programme en examinant les appels faits avant un crash. Systrace peut aussi servir à lancer une application nécessitant le compte root avec un compte limité, en exécutant lui même en root les quelques appels système root que le programme demande.

Il faut maintenant déplacer la police dans /etc/systrace/ avec mv et modifier /etc/rc pour qu’il lance httpd avec systrace, en ajoutant systrace -a avant la ligne lançant apache.

Modifications dans rc

Ligne à corriger

Lors du prochain redémarrage, httpd devrait se lancer, confiné dans son chroot et sous l’étroite surveillance de systrace. Je n’ai pas pu chiffrer l’impact sur les performances, mais je suppose qu’elles ne sont pas négligeables. Dans le cas d’un serveur non critique, l’activation de ce système n’est pas obligatoire, mais son approche et son application me parait assez intéressante pour être abordée.

5° Un système hermétique avec pf

Afin de limiter au strict minimum les interactions possibles avec notre serveur, et ce dans les deux sens, nous allons appliquer une stratégie très paranoïaque avec notre firewall. L’idée est que seuls les services nécéssaires soient accessibles depuis l’extérieur d’une part, et qu’une éventuelle compromission de notre serveur reste confiné en autorisant seulement certaines connexions sortantes.

La première question à se poser est « De quoi ai-je besoin ? ». Dans notre cas, nous aurons besoin de http sur le port tcp 80 en entrée et sortie, de ssh sur le port tcp 22 en entrée seulement. Il ne faut pas oublier les quelques interractions secondaires que notre serveur peut avoir vers l’extérieur. Par exemple, les dns sont utilisés fréquemment par plusieurs parties du système, on autorisera ainsi le port tcp/udp 53 en entrée et en sortie. Mon site a également besoin de se connecter à un serveur smtp pour envoyer des mails, ainsi ajouterai-je le port tcp 25. L’heure en synchronise en NTP, il faudra donc autoriser le port udp 123. Ajoutez à cette liste les ports dont vous avez besoin dans votre configuration.
Il ne reste qu’a modifier /etc/pf.conf pour y ajouter les règles suivantes, à la fin :

table <bruteforce> persist

tcp_in = " {www} "
tcp_out = " {domain, smtp} "
block all
block quick from <bruteforce>
pass in proto tcp to port $tcp_in
pass out proto tcp to port $tcp_out
pass in quick proto tcp from any to any port ssh flags S/SA keep state (max-src-conn 10, max-src-conn-rate 3/3, overload <bruteforce> flush global)

Ces règles sont certes très fermes puisque n’autorisant que le strict nécessaire (il vous sera impossible de faire des ping !) mais reste dans la continuité de notre stratégie consistant à n’autoriser que le strict nécessaire, et ce afin d’éviter contamination ou contagion.

La dernière ligne a pour effet de laisser passer le SSH, mais empêche les attaques bruteforce en bloquant les adresses IP des personnes ayant ouvert plus de 10 personnes à la fois, ou 3 connections en moins de 3 secondes, ce qui n’arrive jamais en utilisation légitime. Si vous utilisez plus de 10 connections simultanées en SSH, vous pouvez naturellement changer les valeurs.

6° Les file flags, et le securelevel ou comment empêcher la modification du système

OpenBSD possède une autre fonctionnalité de gestion des droits : il est capable d’apposer des drapeaux sur les fichiers afin d’éviter leur modification ou leur suppression (entre autre). Nous allons nous servir de ces flags pour empêcher un intrus de modifier notre noyau, ou de modifier/ajouter des binaires. Cela rendra la pose de porte dérobée ou l’altération du système moins discrète puisque l’attaquant devra redémarrer, voire un peu plus compliqué. Nous allons poser le drapeau schg, qui rend le fichier immuable, sur les dossiers /bsd (qui contient le noyau), /bin et /sbin (qui contiennent les exécutables). Attention, pour retirer un file flag, il faudra que le système s’exécute avec un securelevel de -1. Les securelevel définissent un comportement sécuritaire global sur le système. Pendant l’exécution, il est possible de monter le securelevel, mais pas de le descendre. Pour le monter, il faut utiliser sudo sysctl -w kern.securelevel=1 Pour le diminuer, il faut redémarrer après avoir modifié /etc/rd.securelevel.

Les securelevel sont les suivants :

  • -1 : Tout est comme un UNIX normal. Si vous voulez bidouiller, c’est le runlevel à adopter.
  • 0 : Ce securelevel est utilisé pendant la procédure du boot, avant que le système passe en multi utilisateur. Lors du passage en multi utilisateur, le securelevel est de toute manière élevé à 1, donc mettre securelevel=0 dans /etc/ rc.securelevel revient à un securelevel de 1.
  • 1 : Par défaut. C’est ici que l’utilité du runlevel se fait sentir :
    • Personne peut écrire dans /dev/mem et /dev/kmem (périphériques de la mémoire / mémoire du kernel)
    • Les raw disk devices sont en read only, tout doit passer par le système de fichier.
    • Les files flag ne peuvent pas être supprimés
    • On ne peut pas ajouter le modules au kernel. Mais ça n’ aucun impact pour nous autres administrateurs système légitimes puisque le noyau est de toute manière monolithique.
  • 2 : Niveau maximum. Comme le niveau 1 plus :
    • L’horloge système ne peut pas être reculée ou proche du point d’overflow
    • pfctl ne peut pas modifier les règles PF ou NAT
    • Les valeurs sysctl du débogueur de noyau ddb ne peuvent pas être changées.

Pour en revenir à nos file flags, nous allons placer schg sur les dossiers invoqués plus haut :

sudo chflags -R schg /sbin/
sudo chflags -R schg /bin/
sudo chflags schg -r /bsd

Pour retirer les file flag, il faudra modifier /etc/rc.securelevel et mettre le securelevel -1, puis redémarrer et taper les commandes

chflags noschg /bsd

L’idée de mettre un schg sur /etc m’a caressé l’esprit, mais étant donné que le fichier pour changer le securelevel est dedans, j’ai préféré éviter la catastrophe en abandonnant l’idée. Il est bien sur possible de mettre les flags fichier par fichier en fonction de ce que vous souhaitez protéger. Vous pouvez ensuite relancer le serveur avec le securelevel de 2.

Une autre pratique courante est de poser un flag sappnd sur l’history des shell, pour garder une trace de toutes les manipulations des utilisateurs.

7° Le mot de la fin

Une fois le serveur redémarré, il devrait être « fonctionnel ».
« Fonctionnel », car le client aura ce qu’il veut, soit un site accessible. Cependant, toutes ces sécurités apportent une lourdeur d’administration assez conséquente : sans redémarrer, il est impossible de mettre à jour les logiciels, de modifier les règles du pare-feu, de pinger, de télécharger un fichier, etc. Comme toujours, une sécurité accrue se fait au détriment de l’ergonomie pour le sysadmin. C’est pour cela qu’il faudra « vitrifier » le système qu’une fois tout rodé. Enfin, ce type d’architecture est plus intéressante utilisée conjointement avec un load balancing avec un système bsd + pf en frontal, afin de pouvoir mettre à jour les serveurs sans interruption de service.
En outre, il ne vous protège pas d’attaques périphériques, comme un attaquant s’introduisant sur votre machine pour poser un keylogger pour obtenir votre mot de passe SSH, de vol de clef, de MITM ou plus sobrement de shoulder surfing. La surveillance  des logs du serveur pourra permettre de surveiller des intrusions, et il est bien sur possible d’utiliser des IDS/HIDS pour surveiller tout cela.

Si vous voyez des failles, des mauvais réglages ou si vous avez des choses à ajouter, je vous invite à me contacter. Amusez-vous bien avec OpenBSD !

 

Update 1 : Mise à jour des règles du pare feu, merci à ptr pour ses éclairements. (Voyez les commentaires pour plus d’informations)

Cet article a été publié dans OpenBSD, Sécurité, Technique avec les mots-clefs , . Bookmarker le permalien. Laisser un commentaire ou faire un trackback : URL de trackback.

8 Commentaires

  1. ptr
    Publié le 17 janvier 2011 à 21 h 42 min | Permalien

    >Pour ma part, j’installerais mon système dans une VM, afin de pouvoir ensuite l’envoyer sur mon futur serveur ESXi

    Mauvaise idée, les VM c’est moche, et mal supporté par OBSD. M’enfin je suppose que t’utilises Vmware c’est le moins
    mauvais des choix… surtout avec les derniers commit sur vmt(4). Pense à utiliser sysutils/vmwh si tu veux utiliser X.
    Fin bon, garde en tête qu’OpenBSD sur une vm c’est un peu la loterie. (et ça perd de son intérêt aussi d’un point de vu sécu).

    >le serveur Web par défaut n’étant qu’apache 1

    Oui et non, c’est plus un fork qu’autre chose, le code n’a plus rien avoir avec l’upstream.

    >Une des premières opérations à effectuer est d’activer sudo pour notre compte.

    Ubuntu user? Activer sudo c’est bien, le configurer c’est mieux. Sudo avec du ALL(ALL) c’est pas idéal.. (btw c’est un tool issu d’openbsd).

    >pf ruleset […]

    En général on rajoute un set skip lo.
    C’est pas une bonne idée d’avoir block all en bas du ruleset, ok là t’as tout en quick mais au fur et à mesure que ton fichier va grandir ça
    sera pas toujours le cas (t’as pas intérêt) et là tu te feras avoir.
    Oh et utilise les macro combinée avec les list pour te faciliter la vie.
    Jéte un oeil à /etc/services aussi.

    J’ai fait que survolé mais bon voilà ce que j’ai vu.

    — opensour-lab

    :wq

    • Simon
      Publié le 17 janvier 2011 à 22 h 16 min | Permalien

      À propos de VMware, j’avais remarqué qu’OpenBSD était mal supporté par rapport à par exemple mon Debian que je connais un peu plus (il supporte la paravirtualisation par exemple) mais c’est la solution sur laquelle j’ai du me rabattre, ne pouvant pas multiplier les serveurs dans ma petite chambre, pour des raisons de coût, de chaleur et de bruit ;) En espérant que la situation évolue, d’autres BSD ont l’air d’avoir engagé le pas dans le sens là…
      Pour le reste des informations que tu m’as donné, j’ai cherché rapidement mais ai trouvé peu de documentation, (configuration plus poussée de sudo par exemple…)
      Quant à pf, j’ai lu pas mal de doc, j’ai pas trouvé d’autres solutions plus propres que le block all et tout les quick tout en étant aussi ferme, je vais creuser le problème, il faudra qu’on en reparle !
      En tout cas, merci pour ton commentaire !
      (au passage pas mal le :wq en signature :) )

  2. ptr
    Publié le 17 janvier 2011 à 22 h 41 min | Permalien

    >ne pouvant pas multiplier les serveurs dans ma petite chambre,

    Faut connaitre ses priorités :€. Tu vires windows et tu fous obsd :).

    >Quant à pf, j’ai lu pas mal de doc, j’ai pas trouvé d’autres solutions plus propres que le block all et tout les quick tout en étant aussi ferme

    Je t’ai pas dis que block all était pas propre, au contraire c’est bien. (C’est même la base) Je t’ai dis de le mettre en haut de ton ruleset.
    Au cas où tu connaisses pas la façon dont pf gère les ruleset un petit rappel (sinon saute :p) :
    En fait il fait de bas en haut mais il les fait toutes (si t’es un cizcoee boy t’as l’habitude que ça s’arrête au premier match là c’est pas le cas).
    Sauf bien sur si y’a un quick qui traine. (si la rule qui match contient un quick il s’arrête là).
    Donc si tu mets ton block all en bas, *tout* sera bloqué (si y’a pas de quick sur les rules avant bien entendu).
    Pour le reste c’est dans la config de base il me semble (set skip lo).
    A terme si tu veux ssh depuis l’extérieur fait moi signe y’a un une rule un poil tricky (à base de max-src-conn) pour bloquer les skiddies qui BF.

    Pour macro + lists voilà ce que je voulais dire :

    /************************************************/
    tcp_services = « {ssh, www, domain, smtp} »

    block all
    pass in proto tcp to port $tcp_services
    /************************************************/

    Pour finir sudo, c’est juste que l’utilisation faite dans ubuntu ça m’hérisse. sudo c’est là pour renforcer la sécurité, pas pour apporter un sucre syntaxique aux users.
    En gros ça permet d’avoir une gestion fine des commandes que tu permets à tes users avec privilèges plutôt que de balancer le mot de passe root à tout va.

    –opensource-lab’ly yours

    :wq

    • ptr
      Publié le 17 janvier 2011 à 22 h 44 min | Permalien

      >En fait il fait de bas en haut mais il les fait toutes (si t’es un cizcoee boy t’as l’habitude que ça s’arrête au premier match là c’est pas le cas).

      Il faut lire « de haut en bas » bien entendu au temps pour moi!

      ps : pour pf la faq + man sont très très bien. (comme tout man obsd d’ailleurs).

      pps : ton système de commentaire me bouffe tout les sautes de lignes rendant mes pavés illisibles.

      :wq

      • Simon
        Publié le 17 janvier 2011 à 22 h 55 min | Permalien

        Merci d’avoir pris le temps de développer ! C’est amusant de voir qu’on est tellement conditionné par le fonctionnement du firewall cisco qu’on s’efforce de reproduire le schéma sur un système avec un fonctionnement différent ;)
        Je prendrais rapidement le temps de regarder tout ça, après quoi je mettrais à jour mon article ;)

        • ptr
          Publié le 18 janvier 2011 à 12 h 45 min | Permalien

          Voilà la régle pour les skiddies qui BF ton ssh (je suppose que tu vas l’ouvrir sur le net à
          un moment ou un autre .. ) :
          /********************************************************************/
          # cat /etc/pf.conf

          table persist

          block quick from

          pass in proto tcp to port ssh \
          keep state (max-src-conn 15, max-src-conn-rate 15/3, \
          overload flush global)

          /********************************************************************/
          Sa fait comme fail2ban (en mieux).
          Je te laisse man maintenant que t’as les mots clef et adapter à tes besoin.

      • ptr
        Publié le 17 janvier 2011 à 22 h 59 min | Permalien

        oh boy, j’ai oublié message en trois partie tout ça :’.

        >En espérant que la situation évolue, d’autres BSD ont l’air d’avoir engagé le pas dans le sens là…

        Ni compte pas, aucun n’effort sera fait de ce côté là. Et ce pour plein de raisons. (la première raison étant
        qu’a l’heure actuelle c’est pas un vrai X86 qui est émulé, mais un simili-copie).
        Tiens par exemple récemment on s’est aperçu en débuguant que le registre ecx ou esp me rappelle plus
        sous virtual box se retrouvait de temps en temps remplie de crap. (/random).
        Fin je vais pas m’étendre sur ce topic, on pourrait y passer du temps.

        :wq

  3. Fdt
    Publié le 31 octobre 2011 à 7 h 09 min | Permalien

Laisser un commentaire

Votre e-mail ne sera jamais publié ni communiqué. Les champs obligatoires sont indiqués par *

*
*

Vous pouvez utiliser ces balises et attributs HTML <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>