Deblan blog

Tag #Adminsys

[TIP] Générateur SPF

SPF est une des solutions techniques qui permet d'identifier un serveur comme légitime pour envoyer un email avec un nom de domaine précis. On s'appuie sur les DNS pour effectuer cette configuration. Pour plus d'informations, je vous invite à consulter l'article SPF sur Wikipedia.

La syntaxe n'est pas très compliquée mais il a quelques subtilités qui nécessitent de regarder de la doc avant de valider les modifications. Par conséquent, j'ai écrit un script shell qui permet de générer facilement une entrée SPF.

Voici quelques exemples d'utilisation :

$ spfgenerator -d '*' -mx -ip 109.190.159.83 -ip 5.135.190.125 -p fail
*	IN	TXT	"v=spf1 mx ip4:109.190.159.83 ip4:5.135.190.125 -all"
$ spfgenerator -a "" -mx -ip 1.2.3.4 -ip fe80::7e7a:91ff:fe27:d29c/64 -i example.com -s
v=spf1 mx a ip4:1.2.3.4 ip6:fe80::7e7a:91ff:fe27:d29c/64 include:example.com ?all

Et le code source : https://gitnet.fr/deblan/spfgenerator.deb/src/master/usr/bin/spfgenerator.

Enjoy :)


Un nouveau serveur (encore)

Haruhi

Je l'expliquais dans l'article juste en dessous, j'attendais une nouvelle machine pour redonder Hinata (le serveur de deblan). Elle est arrivée et son installation s'est bien passée. Bienvenue à Haruhi !

J'ai essuyé quelques questions ces derniers jours. Des gens se demandent quel est l'intérêt de s'embêter à avec des serveurs à la maison, d'autres se demandent si le coût n'est pas un vrai problème.

J'ai déjà fais un article à ce sujet et je l'explique assez souvent oralement. Cependant, il me paraît essentiel de ré-expliquer encore mes choix.

La base d'Internet est l'interconnexion de réseaux. L'objectif de cette toile est de rendre impossible son démantèlement : si on rompt une partie du réseau, l'autre partie va continuer à fonctionner. Quand on fait de l'Internet, on est censé supprimer le plus possible la notion de centralisation. L'intelligence est dite en périphérie du réseau, pas au centre comme le minitel. Sur Internet, tout le monde est client et serveur. Concrètement, si vous faites du peer to peer, vous faites de l'Internet. À l'inverse, quand vous téléchargiez sur Megaupload, vous faisiez du minitel.

Le premier serveur arrivé chez moi était maintenu par mon frère qui étudiait au département SRC à Montbéliard. Quelques temps plus tard, c'est une machine à moi qui prit le relais. Voila 5 ans que j'ai une machine qui tourne en permanence chez moi. Seulement, c'est compliqué et la solution entreprise par énormément de gens est l'achat ou la location d'espaces chez des professionnels. Pour une poignée d'euros, on va souscrire chez un hébergeur et allons disposer d'un espace de travail en ligne. Dans le monde des Bisounours ça fonctionne bien, on a jamais aucun problème est on dispose d'un service super fiable. Mais dans la vraie vie c'est tout le contraire. Pour avoir eu des comptes mutualités et dédiés, il y a arrive toujours le moment où la panne survient avec potentiellement des pertes d'accès complètes.

Cette solution qui pourrait bien fonctionner admet donc plusieurs problèmes : on est jamais sûr de ce qu'il va arriver et on centralise nos fichiers, nos mails et les autres services chez des gens qui n'en ont rien à foutre de vous. Dans l'absolu, ils peuvent couper l'accès à vos données sans que vous ne puissiez la ramener, ils ont la possibilité de fouiller dedans sans que vous le sachiez et le services de polices pourraient avoir des accès facilités. Et dans l'absolu absolu, ce n'est pas chez vous qu'on ira faire péter une bombe, mais chez eux avec leurs milliers de clients.

Bref, tout ça pour dire deux choses : je veux garder un accès complet à mes données et gérer son accessibilité comme je l'entends. Enfin, je ne suis souhaite pas centraliser ces mêmes données chez des sociétés qui n'ont qu'un seul objectif : se faire du fric. Je veux interconnecter le réseau que j'ai chez moi et contribuer à Internet.

Au delà de l'aspect idéologique qui se trame dans ma démarche, il y a aussi un coté pratique : j'utilise les logiciels que je veux, je configure les services comme j'en ai envie et je ne suis limité que par mes capacités techniques.

Évidement, tout ceci a un coût. Grossièrement, mes machines doivent me prendre 300 euros d'électricité par an et de temps en temps le matériel tombe. Cette année le serveur Hinata a du être totalement changé et j'ai acheter une machine pour le répliquer. Mais il est possible de rendre tout ceci moins coûteux. Il existe des machines pas très gourmandes capables de fonctionner à l'énergie solaire par exemple. Comme a expliqué Benjamin Bayart, placer ses services dans des centres de données n'est pas non plus une réponse.

C'est donc un investissement en argent (même si jusqu'à cette année, je n'ai bossé qu'avec du matériel de récupération) et aussi du temps, pas mal de temps...Mais au delà de ça, quand on va sur mon site, quand on m'envoie un mail, quand on veut me parler sur IRC, ce n'est pas chez un fournisseur avec des machines je ne sais où qui répond, mais c'est chez moi et pas ailleurs !

Cette manière de faire n'empêchera pas de grossir et de prendre du poids sur le web. Avec le réseau IRC monté avec elskwi, on souhaite que le Neutral Network ne soit pas situé à un seul endroit en France, mais partout ! Ça a déjà commencé avec 3 machines qui sont géographiquement très éloignées, sur des réseaux différents. On ne veut pas passer pour des geeks barbus avec des idéos à la con. On veut de redonner vie à ce qui a été créé début des années 90 et de mettre une claque à la tendance actuelle de tout mettre à un seul endroit et de pleurer quand c'est mort. C'est ça Internet, même si certains rigolent en me lisant.

Salle machines


Raspberry PI #1

J'ai (enfin) reçu mon Raspberry PI et j'ai commencé à faire joujou avec.

J'ai utilisé l'image officielle avec une Debian Wheezy hacked pour lancer le RPI (Raspberry PI). C'est donc une Debian optimisée pour la machine avec l'environnement LXDE de base. Je l'ai bien sûr dégagé pour installer i3wm en gagnant ainsi une dizaine de Mo sur la Ram consommée. Sans trop de surpise, on a un système pas très rapide mais qui suffit à faire des tâches simples. Je pense que la carte SD achetée est aussi une cause de lenteur.

J'envisageais d'installer de quoi monitorer le système mais munin est trop gourmand. Je vais essayer de trouver une solution alternative.

Edit : ce qui prend le plus de ressource est la génération de graphs. J'ai laissé Hinata fait ceux du RPI donc plus aucun souci de performances. Je poserai des graphs d'ici quelques heures !


Edit 2 : j'annonçais des lenteurs qui étaient certainement dues à la carte SD utilisée. Il s'avère que c'est bien l'origine du problème qui va se régler très rapidement en la changeant. J'ai installé Munin et des graphiques sont à présent disponibles. Tout est disponible en ligne.


Raspberry PI Deblan

À l'heure actuelle, j'ai configuré un serveur web nginx et j'ai installé un Wordpress [http://pi.deblan.org/wordpress/]. Le serveur de base de données est sur une Hinata (le serveur de deblan) le temps de passer le blog sur une db SQlite. Globalement ça fonctionne pas trop mal bien que les accès disques lents ralentissent le temps de réponse. Il n'est pas directement accessible depuis l'extérieur mais via Hinata (encore) qui fait proxy HTTP.

Une salle dédiée a été aménagée pour les serveurs, puisque qu'en plus d'Hinata et du RPI, une 3ème machine va arriver pour redonder les services importants de Deblan (web, email et irc). Il se peut qu'elle devienne aussi un dépot FreeBsd.

Salle machines Deblan

La finalité du RPI n'est pas encore finie. Je ne sais pas si le mettre en frontend des serveurs sera une bonne idée (Firewall ou LoadBalancer à la Varnish). À voir...

En tout cas c'est belle petite bestiole, qui prend trois fois rien comme place et qui fonctionne vraiment bien. Je suis donc agréablement supris et je vais songer à en acheter un ou deux de plus pour faire des tests de cluster.


Détection de scan serveur

Scanner un serveur permet de découvrir quels ports sont ouverts. Potentiellement, ça permet également découvrir quels services et logiciels sont utilisés sur la machine.

L'objectif d'un scan n'est pas nécessairement de faire du mal mais c'est souvent le prémice d'une ou plusieurs attaques.

Dans cet article, je vais vous expliquez très rapidement comment détecter un scan pour ensuite vous prévenir. Dans l'exemple ci-dessous, je décide de ne pas bannir l'ip associée au scan : ça serait trop bourrin et il est préférable de faire du cas par cas.

Dans un premier temps, nous allons installer portsentry, un daemon qui est dédié à la détection de scans. Sur Debian, il suffira d'utiliser le gestionnaire de paquets :

# aptitude update && aptitude install portsentry

Voyons à présent comment configurer (rapidement) l'outil.

Le fichier de configuration est /etc/portsentry/portsentry.conf. Nous allons l'éditer et modifier les variables suivantes : ADVANCED_PORTS_TCP et ADVANCED_PORTS_UDP. Dans chacune d'elles, il faudra indiquer les ports ouverts et accessibles de votre serveur. Admettons que vous avez un serveur SSH, un serveur Web et un serveur FTP :

ADVANCED_PORTS_TCP="21,22,80,443"
ADVANCED_PORTS_UDP="21,22,80,443"

Maintenant, éditons le fichier /etc/default/portsentry. Remplacez "tcp" et "udp" par "atcp" et "audp" de manière à avoir cette config (c'est plus efficace) :

TCP_MODE="atcp"
UDP_MODE="audp"

Nous allons de nouveau éditer /etc/portsentry/portsentry.conf pour s'assurer qu'aucun bann n'est fait suite à une détection. Recherchez dans le fichier ces variables et placez leur valeur à "2" : BLOCK_UDP et BLOCK_TCP.

BLOCK_UDP="2"
BLOCK_TCP="2

Cette configuration permet de déléguer à un script externe les tâches à effectuer pendant la détection.

Nous allons écrire un script qui va envoyer un mail avec les informations suivante : l'IP initiatrice du scan, le port scanné et le mode de scan (atcp ou audp).

Si vous n'avez pas de serveur SMTP, installez postfix :

# aptitude install postfix
# echo "votre.notre.de.domaine" > /etc/mailname
# service postfix restart

Voici un script simple que je vous invite à améliorer :

# mkdir ~/bin/ && touch ~/bin/scan_report && chmod u+x ~/bin/scan_report
#!/bin/sh

MAIL=vous@example.com
SUJET="[IMPORTANT] Scan détecté"


IP="$1"
PORT="$2"
TYPE="$3"

(
	echo "Scan détecté :"
	echo "---------------------------------------"
	echo "IP   : $IP"
	echo "PORT : $PORT"
	echo "TYPE : $TYPE"
	echo "---------------------------------------"
) | mail -s "$SUJET" "$MAIL"

Indiquons à portsentry d'éxécuter ce script. Éditez de nouveau /etc/portsentry/portsentry.conf puis recherchez la chaine $TARGET$. Placez à cette endroit du fichier cette ligne (un exemple est commenté) :

KILL_RUN_CMD="/root/bin/scan_report $TARGET$ $PORT$ $MODE$"

Vous pourrez modifier la valeur de SCAN_TRIGGER et placer un niveau d'alerte. Par défaut c'est "0" : la réaction est immédiate. De mon coté je l'ai laissé à "0" et je la changerai si ça me pose des problèmes.

La configuration effectuée, vous pouvez maintenant relancer portsentry de cette manière :

# service portsentry restart

En cas de détection de scan, des logs sont générés dans /var/log/syslog. Pour les retrouver, utilisez le mot clé "attackalert" comme suit :

# grep attackalert /var/log/syslog

En principe on est tout bon :)


Statistiques de son site web

En règle générale, les personnes apprecient avoir un retour de leur travail. Quand on a un site web, il paraît évident de ressortir quelques chiffres sur les visteurs : quelles pages lisent-ils ? D'où viennent t-ils ? Combien de temps restent-ils ? etc.

Il existe une grande quantité d'outils qui permettent de générer des rapports. Le plus connu du grand public est sans doute Google Analytics. Mon problème c'est que j'ai du mal à confier des choses à des sociétés externes. Quels sont mes outils d'analyse sur mes sites ? En voici quelques uns.

Open Web Analytics (OWA) est un outil open source. Il est très similaire à Google Analytics et s'installe sur son hébergement. Il dispose de pas mal de fonctionnalités : statistiques sur la consultation des pages, les domaines de référence, l'analyse des requêtes sur les moteurs de recherche, création de campagnes, etc. Il est complet et permet de gérer plusieurs sites. Il fonctionne via l'ajoût de scripts javascript et/ou PHP au sein des pages.

Open Web Analytics

Webalizer est un générateur de rapport html qui se repose sur les logs Apache2. Il va sortir des chiffres sur la consultation des pages, les url de référence et de sortie, quelques données sur la bande passante utilisée et quelques infos sur les clients.

Il se lance en ligne de commande. Voila une commande type qui va générer un rapport nommé "Mon blog", dans le répertoire "stats" via le fichier de log "mon_site.log" :

webalizer -n "Mon blog" -o stats mon_blog.log

Webalizer est packagé sur Debian.

Webalizer

Le dernier outil est goaccess. C'est un programme qui s'exécute en ligne de commande et le rendu se fait dans console (interface ncurses).

goaccess

goaccess -f mon_blog.log

Goaccess est packagé sur Debian.

Pour lire un fichier de log apache2, vous devez disposez d'un accès root (comportement de base).

C'est primordiale de confronter les données générées par ces outils.