PROJET AUTOBLOG

PostBlue

Site original : PostBlue

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Debian : APF Firewall, Brute Force Detection et DDoS Deflate

mardi 14 août 2012 à 17:30
You Shall Not Pass

by ~CaptainD.

Mise à jour du 14 août 2012 : ajout de DDoS Deflate et corrections pour BFD sur un VPS Debian.

Renonçant à faire face plus longtemps à mes problèmes et limitations inhérents à un hébergement mutualisé, j’ai décidé de tenter l’expérience et la location d’un VPS. Bien qu’étant un archlinuxien convaincu, j’ai décidé qu’il tournerait sous Debian (comme le montre ce billet), autre distribution pour laquelle j’ai beaucoup d’affection.

Sans vouloir m’embarquer dans une longue prose concernant la sécurité d’un serveur et les marches à suivre concernant celle-ci (le web en pullule, de toutes façons), voici plutôt la présentation et la configuration d’une des facettes de celle-ci (mais ne peut suffire, soyez-en conscient) comme j’ai pu la faire (avec peut-être quelques différences) sur mon serveur.

I can haz firewall

Refusant de jouer péniblement avec iptables, j’ai cherché un logiciel qui automatiserait mes règles de firewall sans me prendre excessivement la tête. C’est pourquoi j’ai jeté mon dévolu sur quelque frontend à iptables : APF Firewall, de et par R-Fx Networks.

APF Firewall : introduction

Outre la facilité de configuration d’APF, ce qui m’a séduit c’est sa capacité à importer directement et automatiquement des listes d’adresses sur Project Honey Pot, Spamhaus, DShield, … et bloquer celles-ci afin d’offrir une première protection contre les spammeurs en tout genre, qu’importe le CMS utilisé.

Que vous installiez depuis l’archive ou les répertoires de Debian, la configuration est similaire à quelques détails près, donc à votre guise. Pour ma part, j’ai préféré la version des dépôts, par facilité (aptitude > wget && tar && sh), mais libre à vous de vous amuser avec la version archivée, que vous pouvez trouver sur cette page. Après avoir installé le paquet, il ne reste plus qu’à configurer au mieux le programme, et c’est, dans mon cas, le fichier /etc/apf-firewall/conf.apf que je dois éditer.

APF Firewall : configuration

Pour débuter, laissez inchangée la ligne DEVEL_MODE="1", celle-ci pourrait vous sauver la mise en cas de problème de configuration : cela désactivera automatiquement le pare-feu au bout de 5 minutes au moyen d’une tâche cron. Une fois que tout est bien configuré, il suffit de passer sa valeur à 0 et le tour est joué.

Il est évident que la configuration suivante n’est qu’un exemple, j’invite plus que vivement à lire les commentaires du fichier de configuration afin de permettre une configuration des plus fines et des plus adaptées.

Sur ma configuration, iptables fait partie d’un noyau monolithique, donc le paramètre SET_MONOKERN="1" est vital sans quoi rien ne fonctionne dans mon cas. Pareillement, il est essentiel d’adapter en conséquence les paramètres IFACE_IN et IFACE_OUT avec la valeur adéquate donnée par ifconfig. Dans mon cas il s’agit de venet0.

En vrac, voici ce que j’ai activé :

Dans le port 80, y’a des paquets qui passent

Ensuite, il convient de configurer les ports à ouvrir, puisque tout autre port sera, lui, bloqué. Dans mon cas, j’ai ouvert les ports 22 (SSH et SFTP), 25 (SMTP) 53 (DNS), 80 (HTTP), 110 (POP3) , 123 (NTP), 143 (IMAP), 443 (HTTPS), 5222 (XMPP – client), 5269 (XMPP – serveur), 9418 (git). Il est évident que cette configuration est essentielle pour les services que vous utilisez (les ports 20 et 21 pour FTP, ou 11371 pour HKP par exemple). Pour plus d’informations concernant les numéros de ports ou les protocoles TCP et UDP, cette liste des ports logiciels est plus qu’utile.

Dans mon cas, donc, les filtres pour le trafic entrant sont les suivants :

Tandis que pour les trafic sortant j’ai ceci :

 Remote Lists

Comme je l’ai introduit, l’une des particularités d’APF est de permettre le téléchargement automatique de règles d’exclusion, ce qu’il faut bien évidemment activer :

Lancement et mise en production sur un VPS Debian

Une fois que tout est bien configuré, il est temps d’essayer le tout. Pour ce faire, deux commandes à retenir :

S’il y a un bug, on recommence jusqu’à ce qu’il n’y ait plus d’erreur. Pour vérifier l’ampleur des règles, un petit iptables -L -n suffit, tandis que sudo apf -h permet de jeter un œil aux possibilités de la commande.

Cas particulier des VPS : modules iptables

Si vous obtenez l’erreur « iptables: No chain/target/match by that name« , il est indiqué dans le README les différents modules à charger (ipt_recent est facultatif, par exemple, et avait causé de gros soucis chez moi). Demandez à votre hébergeur / fournisseur si vous ne pouvez les gérer vous-même.

ip_tables
iptable_filter
iptable_mangle
ip_conntrack
ip_conntrack_irc
ip_conntrack_ftp
ipt_state 
ipt_multiport
ipt_limit
ipt_recent
ipt_LOG
ipt_REJECT
ipt_ecn
ipt_length
ipt_mac
ipt_multiport
ipt_owner
ipt_state
ipt_ttl
ipt_TOS
ipt_TCPMSS
ipt_ULOG

Knock knock knockin on server’s door

Who’s there ?

Après avoir installé et configuré APF, il convient maintenant d’en configurer l’extension normale et logique : BFD, par R-Fx Networks également. Cette fois, il n’y a pas de paquet dans les dépôts, donc c’est téléchargement, extraction, et configuration à la main.

Ce serait tout beau, tout mignon, s’il n’y avait un petit problème mineur : cette version ne reconnaît pas celle d’APF installée depuis les dépôts. Pour que tout fonctionne, donc, il faut éditer /usr/local/bfd/conf.bfd comme suit :

Le reste peut être laissé en l’état. Lancez le bousin !

Watcha doin ?

DDoS Deflate : COME AT ME BRO(s) !

Certes si votre configuration est un poil maigrichonne, se croire inattaquable est une utopie digne de la logique la plus médiocre. Nulle raison pourtant de ne pas tenter quelques mesures, dont l’installation de DDoS Deflate, oui monsieur (ou madame, pardon), afin d’envoyer un beau « Go fuck yourself » au moins temporaire à quelques robots / zouaves s’amusant dans vos contrées.

You know what ? Fick dich.

Téléchargement et installation

La chose est résolument simple : télécharger le script, installer le script, ce qui donne :

Rien de plus simple sinon d’accepter la licence de publication du script, et de noter les chemins d’installation histoire de pouvoir éditer la configuration.

Configuration et édition

La configuration dans mon cas se fait dans le fichier /usr/local/ddos/ddos.conf, que j’ai édité de la sorte afin de prendre en compte mes différents programmes :

##### Paths of the script and other files
PROGDIR="/usr/local/ddos"
PROG="/usr/local/ddos/ddos.sh"
IGNORE_IP_LIST="/usr/local/ddos/ignore.ip.list"
CRON="/etc/cron.d/ddos.cron"
APF="/usr/sbin/apf"
IPT="/sbin/iptables"

Mais j’ai aussi dû éditer /usr/local/ddos/ddos.sh qui avait quelques problèmes : d’abord le shebang #!/bin/sh en #!/bin/bash – ainsi que toutes les occurences de /bin/sh tant qu’à faire -, et crond en cron :

#!/bin/bash
########################################
# DDoS-Deflate version 0.6 Author: Zaf #
########################################

(...)

unbanip()
{
        UNBAN_SCRIPT=`mktemp /tmp/unban.XXXXXXXX`
        TMP_FILE=`mktemp /tmp/unban.XXXXXXXX`
        UNBAN_IP_LIST=`mktemp /tmp/unban.XXXXXXXX`
        echo '#!/bin/bash' > $UNBAN_SCRIPT
        echo "sleep $BAN_PERIOD" >> $UNBAN_SCRIPT
        if [ $APF_BAN -eq 1 ]; then
                while read line; do
                        echo "$APF -u $line" >> $UNBAN_SCRIPT
                        echo $line >> $UNBAN_IP_LIST
                done < $BANNED_IP_LIST
        else
                while read line; do
                        echo "$IPT -D INPUT -s $line -j DROP" >> $UNBAN_SCRIPT
                        echo $line >> $UNBAN_IP_LIST
                done < $BANNED_IP_LIST
        fi
        echo "grep -v --file=$UNBAN_IP_LIST $IGNORE_IP_LIST > $TMP_FILE" >> $UNBAN_SCRIPT
        echo "mv $TMP_FILE $IGNORE_IP_LIST" >> $UNBAN_SCRIPT
        echo "rm -f $UNBAN_SCRIPT" >> $UNBAN_SCRIPT
        echo "rm -f $UNBAN_IP_LIST" >> $UNBAN_SCRIPT
        echo "rm -f $TMP_FILE" >> $UNBAN_SCRIPT
        . $UNBAN_SCRIPT &
}

add_to_cron()
{
        rm -f $CRON
        sleep 1
        service cron restart
        sleep 1
        echo "SHELL=/bin/bash" > $CRON
        if [ $FREQ -le 2 ]; then
                echo "0-59/$FREQ * * * * root /usr/local/ddos/ddos.sh >/dev/null 2>&1" >> $CRON
        else
                let "START_MINUTE = $RANDOM % ($FREQ - 1)"
                let "START_MINUTE = $START_MINUTE + 1"
                let "END_MINUTE = 60 - $FREQ + $START_MINUTE"
                echo "$START_MINUTE-$END_MINUTE/$FREQ * * * * root /usr/local/ddos/ddos.sh >/dev/null 2>&1" >> $CRON
        fi
        service cron restart
}

(...)

 

Pour finir, un simple /usr/local/ddos/ddos.sh -c permet d’ajouter les règles au crontab, que tout système a – du moins habituellement et pourra bloquer de façon cyclique ceux qui s’amusent un peu trop sur vos pages.

sysadmincat

flattr this!

The Pirate Bay, Belgacom et la censure du retour contre-attaque

jeudi 9 août 2012 à 00:38

The Pirate Bay

Souvenez-vous d’il n’y a pas si longtemps, quand quelques fournisseurs d’accès à internet – dont l’opérateur historique – étaient condamnés par la Cour d’Anvers à bloquer The Pirate Bay. Enfin, du moins à empêcher la résolution de différents noms de domaine (DNS pour les intimes), ni plus, ni moins.

Pour l’utilisateur de base, cette mesure était efficace : il allait voir ailleurs. Franchement, vous avez cru qu’il se rabattrait sur des offres légales inexistantes ou inintéressantes ? Quoiqu’il en soit, l’action prit de l’ampleur, et l’on eut beaucoup à dire des méthodes employées :

Sauf qu’en l’occurrence la censure était encore simple à contourner : un changement de DNS sur votre système comme l’a expliqué Martin, et le tour était joué. J’avais moi-même commis une bafouille à ce sujet, visant une modification non pas du gestionnaire de réseau mais plus simplement des DNS inclus à la BBox2.

Home fucking is killing prostitution

Hélas, depuis peu, il semblerait que ces méthodes ne fonctionnent plus ! Passé à la vitesse supérieure, Belgacom s’amuserait dorénavant à censurer tout simplement l’adresse IP de The Pirate Bay.

<script src="//platform.twitter.com/widgets.js" charset="utf-8">
Il est donc confirmé sur Twitter qu’il s’agirait l’application d’une décision judiciaire. S’il s’agit de celle rendue l’année passée par la Cour d’Anvers (en néerlandais), celle-ci ne prescrivait qu’un blocage par DNS. S’il n’y a pas d’autre jugement, la décision de bloquer l’IP est donc totalement arbitraire de la part de Belgacom (neutralité du réseau, quelqu’un ?), l’IP aurait été censurée en toute largesse et sans jugement l’avalisant.

Pirate Party Belgium

Qu’à cela ne tienne : le Parti Pirate belge héberge en ses pages une copie du site que voici, en attendant d’en savoir plus quant à ce sac de nœuds (et des gros, de nœuds). Certes il existe une ribambelle de miroirs plus ou moins maintenus, mais je trouvais la réponse adéquate et, d’une certaine manière, tellement chiche que trop belle pour être éludée.

<script src="//platform.twitter.com/widgets.js" charset="utf-8">

flattr this!

NGinx : HTTPS en tout simplicité avec un certificat CAcert.org

mardi 7 août 2012 à 16:12

Désirant  quelques certificats dont je disposerais par ci par là sur mes sphères – qui je le rappelle tournent dorénavant sous NGinx -, j’ai été confronté à un choix plus ou moins éthique : serai-je ma propre autorité de certification ou puis-je faire confiance à un tiers pour cela ? De façon égoïste, cela ne me gène nullement mais le visiteur, lui, me fera-t-il confiance si d’aventure son navigateur lui envoie des signaux d’alerte ?

Cruel dilemme : par principe, je n’ai que moyennement confiance en une autorité qui avaliserait tout et n’importe quoi pour peu que l’on « allonge la thune », je cherchais donc une structure participative de validation.

CACert Logo

Compromis entre autorité et partenariat : CAcert.org

Me renseignant sur les différentes autorités existantes proposant des certificats gratuits (c’est la crise ma bonne dame), je suis tombé bienheureusement sur CAcert, une association sans but lucratif australienne qui de loin déjà ressemblait à ce que je recherchais.

Ainsi qu’expliqué dans la page d’à propos, corrigez-moi si je me trompe, CAcert.org est avant tout une communauté, puisque l’on parle d’autorité de certification dirigée par sa communauté. Comment ?

CAcert a été conçue par la communauté pour la communauté, et plutôt que de faire peser tout le poids sur une autorité centrale et ainsi augmenter le prix des certificats, l’idée était de faire travailler la communauté de concert avec ce site pour que la confiance soit maintenue de manière distribuée et automatisée! – source.

Web of Trust et points d’assurance

Afin de créer des certificats, vous devez prouver votre identité (mail, nom de domaine, …) ou mieux encore, rencontrer des notaires afin d’obtenir des points de confiance. L’obtention de points de confiance est sinon importante, au moins rudement pratique : cela vous permet de générer des certificats valides non pas 6 mais 24 mois, par exemple.

Création d’un certificat

La manière la plus simple de procéder est, à mon avis, de suivre les solutions que proposent CAcert, en l’occurrence, j’utiliserai un script trouvé sur leur serveur afin de créer une demande de certificat : CSRGenerator.

CSRGenerator : téléchargement et chmod +x

Pour l’utiliser, rien de bien sorcier : enregistrez un fichier texte avec le contenu de la page liée, que ça soit sur votre ordinateur personnel ou votre serveur. Pour ma part, ce sera sur le serveur, par SSH : wget http://svn.cacert.org/CAcert/Software/CSRGenerator/csr -O CSRGenerator, ne me restant plus qu’à le rendre exécutable au moyen d’un chmod +x CSRGenerator.

CSRGenerator : exécution

L’exécution en soi ne devrait pas poser le moindre problème, les champs étant d’une simplicité et d’une clarté confondantes :

Nota : Cyril propose de générer le CSR en se passant de script, soit comme ceci (je le cite) :

  • openssl genrsa [longueur de la clé] > [emplacement de la clé privée]
  • openssl req -new -key [ta clé] > [ta demande de certificat]

Suite à quoi, rendez-vous sur le site de CAcert et, dans votre interface d’administration, collez votre demande de signature de certificat (CSR) dans le champs d’envoi – vraiment rien de sorcier. Après votre envoi, votre certificat serveur devrait vos être livré, copiez-le dans un fichier (pour la démonstration, j’utiliserai example_server.pem) auprès des autres fichiers générés par le script. Ainsi j’obtiens :

NGinx Logo

Configuration de NGinx

Histoire de bien commencer, il suffit de créer un dossier où seront stocké les certificats. Quoi de plus simple que quelque part dans le dossier de NGinx ? Pour ce faire, un simple mkdir -p /etc/nginx/ssl/cacert/ suffit, à vous de choisir où vous les mettrez de préférence.

NGinx et le CRT racine

Manquement des versions actuelles de NGinx, celui-ci ne semble pas gérer les certificats racine (comme celui de CAcert par exemple). Qu’à cela ne tienne, une simple manipulation suffit à faire fi du problème : fusionner le certificat racine et le certificat serveur. Pour ce faire, une simple commande – cat /etc/ssl/certs/cacert.org.pem example_server.pem >> example_crt.pem – et le tour est joué.

Vous pouvez dès lors copier example_crt.pem et example_privatekey.pem dans /etc/nginx/ssl/cacert/, c’est là qu’ils vous seront les plus utiles.

Configuration du VHOST

Je prends pour acquis que vous sachiez configurer un vhost sous NGinx. Pour l’heure, j’utilise un simple serveur HTTP/HTTPS, rassemblant les directives pour les ports 80 et 443 ainsi qu’expliqué dans la documentation. Certes ce n’est pas le meilleur exemple à suivre, mais il a le mérite d’être simple et intuitif.

server {
    listen               80;
    listen               443  ssl;
    server_name          www.example.domain;
    ssl_certificate      /etc/nginx/ssl/cacert/example_crt.pem;
    ssl_certificate_key  /etc/nginx/ssl/cacert/example_privatekey.pem;
    ...
}

Il ne vous reste plus qu’à redémarrer le processus après modification : service nginx restart.

flattr this!

Thunderbird : pas de nouveauté, pas de chocolat

dimanche 8 juillet 2012 à 22:24

Grande tempête ces dernières jours dans les internets libres : ô malheur, Thunderbird, le client mail, est mort annonce macgeneration. Notons déjà que ceux qui s’expriment ont « mac » dans leur nom de domaine, ce qui fouette le lol à des kilobits à la ronde. Non pas qu’il n’aient pas le droit de s’exprimer sur ce sujet, mais cela ouvre une perspective partisane sur le sujet.

Certains libristes s’emballent, lisent vite la nouvelle de la génération mac se faisant une bonne gorge chaude à dire que « chez-eux-c’est-mieux-d’abord », et nous y sommes : Mozilla va arrêter le développement de Thunderbird. D’autres d’ailleurs vont plus loin encore, puisque l’arrêt de Thunderbird enfoncerait la crédibilité de la communauté opensource.

Ce dernier titre est juste, mais pour une autre raison : la communauté opensource n’est pas crédible quand elle hurle à la mort, au fork et à l’ignominie quand l’on touche à ce qui la constitue, dès que les choses changent un peu. Pour mart-e Thunderbird n’est pas mort, et à relire les annonces, les articles, les sources, je penche grandement de son avis. Alors que prenant compte cette nuance dans l’annonce, Cyrille BORNE enterre lui aussi le logiciel en parlant de la vraie fausse mort de Thunderbird.

<édition>

La palme revient à Presse-Citron qui vire en plein sensationnalisme en parlant d’une fin des mises à jour de Thunderbird. Soyons clairs : le support de Thunderbird est assuré dans sa version actuelle jusqu’à sa version 17 (source).

</édition>

<mise à jour>

Voici l’annonce d’ajustement de la feuille de route de Thunderbird, du moins en ce qui concerne la Fondation Mozilla. Je tiens une fois de plus à rappeler que ce genre de projet est activement maintenu par une communauté, la Fondation n’étant pas seule sur le projet.

Il est donc proposé (quoique cela nécessite une discussion en détail) de scinder la maintenance de Thunderbird en deux :

</mise à jour>

Pour moi, voir la mort d’un projet à l’arrêt de sa course effrénée aux nouveautés, au profit d’une recherche plus poussée de stabilité et de sécurité est, en soi, quelque chose de drôle. Oui, vraiment : drôle. Allons dire ça à Debian ou à LaTeX, qu’on se marre. Il ne m’étonnerait même pas qu’on en vienne à se se taper sur la cuisse, le rire gras et tonitruant, en pensant à tant de beauf^WAppl^WUbun^Wsuperficialité à l’égard du logiciel. Pas de nouveauté, pas de chocolat, c’est ça ?

Mais faut-il vraiment innover ? Fuir vers l’avant ? À quoi bon réinventer la roue afin de satisfaire les « neo-addicts » qui pensent qu’elle roulera toujours mieux, si in fine ce n’est qu’une vaine débauche de moyens ? Certes, j’estime qu’il est possible de repenser en profondeur l’utilisation et la disposition des clients mail vers une simplification extrême de ceux-ci, réduits à une fonction : envoyer et recevoir des mails – soit ce qu’ils sont sensés faire originellement. Toute autre fonction s’écartant de cette simplicité de tâche me semble superfétatoire, donc en mon sens n’y a-t-il plus rien à ajouter à Thunderbird. Par contre, il y aurait énormément à enlever à mon avis.

Kristian Bjornard, CC BY-SA 2.0.

La stabilité et la sécurité d’un logiciel tel qu’un client mail en sont pour moi les deux caractéristiques essentielles, qui ne peuvent pas s’effacer au bénéfice d’un « effet d’annonce » aussi vide que l’éjaculat-pré-release de Firefox. Cette illusion de la nouveauté, parée de tant d’artifices clinquants, m’effraie : peut-on avoir confiance en un projet qui, tous les trois mois et demi, ajoute un bouton ci et là, change un menu mais pas ses fonctions, juste histoire de rester psychologiquement à jour, sans pour autant assumer de se consacrer à la stabilité et à la sécurité de celui-ci ? À mon avis, non.

De là à annoncer la mort totale du client mail dans le monde libre… Sylpheed, Postler, Geary, Balsa, Claws Mail, Evolution, … Le démon-pas-beau-du-privateur me semble tout de même loin de ceux qui utilisent des clients libres. Bien qu’à mon avis Thunderbird n’était déjà pas le meilleur des clients, je ne le vois quand même pas mourir si la communauté reste satisfaite par la fonction-même du produit, par ce qu’il est déjà, et restant insensible au bad buzz qui l’entoure, véhiculé par ceux qui au lieu de défendre un logiciel libre qu’ils aiment préfèrent l’enterrer.

Vouloir voir ailleurs si l’on est satisfait en l’état d’un logiciel qui reste sécurisé, stable, compatible, et maintenu, me semble aussi débile que de forker quelque chose de modifiable en profondeur et ouvert aux contributions, ou de rejeter une distribution pour son environnement par défaut – et pour ça seulement.

XKCD, CC BY-NC 2.5.

Suivez mon regard.

Enfin, concernant une possible victoire du cloud ou du webmail sur les clients locaux, cela est pour moi déduit en tout inconscience de certaines contraintes, surtout professionnelles, ou du confort induit par la puissance d’un bon client local :

En résumé :

flattr this!

Mac OS X : liste d’applications

jeudi 5 juillet 2012 à 16:15

J’espère que les plus libristes de mes lecteurs me pardonneront l’infamie présumée du présent billet, mais j’estime que nos compagnons qui utilisent une bébête à la pomme (Mac OS X pour les incultes) ne le font pas forcément de leur plein gré. Je crois possible, aussi, que leur choix de système d’exploitation peut ne pas être exclusif : le dualboot est possible, soyons sereins, leur âme n’est pas perdue.

Ce ne doit en aucun cas nous empêcher, libristes, de leur conseiller des solutions libres et efficaces, afin d’au moins les faire connaître et les faire exister dans l’esprit de l’iClient. La vertu du libre passe par l’éducation et la connaissance (ainsi qu’un choix idéologique, mais passons cette incartade Stallmanienne, ce n’est pas le jour), souvenons-nous que beaucoup d’entre nous ont très certainement utilisé Windows avant d’être des barbus intégristes.

Seul l’un des deux a fonctionné de manière autonome et continue pendant plus de 800 ans, et est capable de changer lui-même ses pièces.

Voici donc une liste plus ou moins complète d’applications dédiées au système d’exploitation pommé – sans pour autant assurer leur compatibilité à travers les âges et les versions, c’est tout de même un système d’exploitation qui n’est jamais rentré chez moi.

Tout d’abord, parce que ce programme doit être connu :

Multimédia (vidéo, image, gravure…) :

Discussion :

Veille / Internet :

Pair à pair :

Bureautique :

Jeux :

N’importe quoi :

Maintenance / sécurité :

Le troll de la fin.

Sources :

flattr this!