Je loue une machine virtuelle chez lost-oasis à (12€ par mois, 256Mo de RAM) pour faire du monitoring nagios, du mx/dns secondaire et du mirror http pour mes autres machines dans mon appart. Elle tourne sur Debian (en paravirtualisation kvm, virtio etc), avec de l'openvz par dessus. 256Mo ça fait pas beaucoup, et en browsant sur mon top, j'ai remarqué que c'était bind qui prenait le plus de mémoire (loin devant postgresql et php-cgi).

Je me met donc à la recherche d'un serveur dns qui serait plus léger que bind et qui fasse aussi bien dns primaire et secondaire pour mes 5 petites zones et je me souviens avoir vu passer une news à propos de l'intégration récente de nsd dans OpenBSD-Current. Ni une ni deux je dégaine mon apt-get install nsd3 et après quelques jours d'utilisation j'en suis très content.

Ce qu'il faut savoir à propos de nsd :

• C'est un serveur authoritative only (contrairement à bind qui fait aussi cache et récursion)
• Il est utilisé par quelques uns des root dns servers (on peut donc lui louer une certaine robustesse)
• Il sait lire les même fichiers de zones que bind
• La configuration est extrêmement simple
• Il est bien plus léger en RAM que bind même configuré pour faire la même chose.
• Il fonctionne très bien avec bind en master (j'ai pas testé dans l'autre sens)

Que du bon donc, laisser moi vous montrer un bout de config comme c'est simple :

server:
    hide-version: yes

# Une config master avec deux slaves 
zone:
    name: "philpep.org"
    zonefile: "master/philpep.org"

    notify: 217.70.177.40 NOKEY
    provide-xfr: 217.70.177.40 NOKEY

    notify: 212.85.155.53 NOKEY
    provide-xfr: 212.85.155.53 NOKEY

# Une config slave avec un master
zone:
    name: "philpep.org"
    zonefile: "slave/philpep.org"

    allow-notify: 82.229.137.130 NOKEY
    request-xfr: AXFR 82.229.137.130 NOKEY

# Apparemment nsd master ne gère que les transferts de zone AXFR (et pas IXFR)
# Ça n'a pas d'incidence l'un est testé puis l'autre si ça marche pas. Mais vous pouvez éviter
# un message de log en mettant AXFR dans request-xfr dans le cas d'un nsd master et slave.

Les zones sont strictement les mêmes que celles de bind.

Bien sûr il est possible de faire des config bien plus velues avec des clés pour faire des zones dynamiques, du chroot etc, voyez nsd.conf(5)

Il y a aussi un utilitaire bien convi pour controler le serveur : nsdc(8). Avant de démarrer le serveur pour la première fois, il faut compiler les zones avec nsdc rebuild.

J'ai trouvé nsd tellement pratique que je l'ai aussi installé en master sur mon serveur FreeBSD (dns/nsd), bind sert toujours pour le cache,récursion et mes zones en local, mais je vais certainement le remplacer par un djbdns ou un dnsmasq

Le script rc de nsd sur FreeBSD /usr/local/etc/rc.d/nsd est pas terrible, utilisez plutôt nsdc ou attendez que mon patch soit accepté :-)

Sur mon serveur FreeBSD j'ai 4 jails et par défaut le système envoie régulièrement des security run output à root@localhost pour l'informer de ce qu'il se passe sur le système (nouveau fichiers etc). Tout ça c'est très bien sauf que un hote et 4 jails ça fait 5 compte mail à visiter, c'est pas trop convi et en plus on a pas envie de faire tourner sendmail juste pour ça.

J'ai donc décidé d'utiliser un MTA très simple appelé (devinez comment) : Simple smtp agent. Chaque mail envoyé depuis la machine (en appelant sendmail) partira vers un serveur smtp de mon choix, ainsi je récupère tous les mails sur mon compte mail usuel.

# cd /usr/ports/mail/ssmtp
# make install
Information for ssmtp-2.62.3:
Install notice:
sSMTP has been installed successfully.
To replace sendmail with ssmtp type "make replace"
# make replace

Ensuite j'ai crée mon /usr/local/etc/ssmtp/ssmtp.conf :

# Serveur de mail à contacter pour l'envoi + le port
# par defaut c'est le port 25
mailhub=mail.philpep.org:578
# Domaine d'où semble venir le mail
rewriteDomain=philpep.org
# Domaine à donner pendant le HELO
# À accorder avec le reverse DNS de votre machine
# vu depuis le serveur de mail.
hostname=shen.philpep.org

Arrangez vous pour que le serveur de mail accepte de vous relayer, moi c'est le cas parce que je suis en local et mon postfix relaie ce qui vient du réseau local. Mais si ce n'est pas le cas (genre vous utilisez le serveur mail de votre fournisseur de mail), on peut configurer l'authentification SMTP, SSL/TLS et tout le reste.

Ensuite désactivez sendmail dans /etc/rc.conf puisqu'il ne sert plus :

sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

Pour tester l'envoi :

$ dmesg | mail -s "works ?" lapin@barreenfer.com
$ if [[ $? -ne 0 ]]; then man ssmtp; fi

EDIT 5/01/10 17:15

• client smtp -> MTA

Mon /var/log/auth.log est blindé de choses du genre :

Nov 18 17:56:27 lenine sshd[49297]: Invalid user marcio from 24.17.93.35
Nov 18 17:56:27 lenine sshd[49297]: error: PAM: authentication error for illegal user marcio from 24.17.93.35
Nov 18 17:56:27 lenine sshd[49297]: Failed keyboard-interactive/pam for invalid user marcio from 24.17.93.35 port 63330 ssh2
Nov 18 17:58:05 lenine sshd[49312]: Address 92.126.194.108 maps to alfa.navsystem.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Nov 18 17:58:05 lenine sshd[49312]: Invalid user marcio from 92.126.194.108
Nov 18 17:58:05 lenine sshd[49312]: error: PAM: authentication error for illegal user marcio from 92.126.194.108
Nov 18 17:58:05 lenine sshd[49312]: Failed keyboard-interactive/pam for invalid user marcio from 92.126.194.108 port 38920 ssh2

C'est une attaque classique par dictionnaire mais distribuée. Ma seule défense pour l'instant c'est mon parre feu qui bloquait les bruteforces un peu trop rapides. Alors même si pf en filtre quand même pas mal, les petits malins tournent sur plusieurs IPs pour faire un bruteforce moins visible.

J'ai donc décidé de bloquer le reste avec fail2ban, la conf par défaut n'est pas adapté à ma config, j'ai des besoin précis sur le filtre sshd et il faut que ça marche avec pf.

L'install est toujours aussi simple :

# make -C /usr/ports/security/py-fail2ban install

La conf est dans /usr/local/etc/fail2ban

En premier lieu, créer l'action pour pf :

action.d/pf.conf

[Definition]
actionstart = 
actionstop = 
actioncheck = 
actionban = pfctl -t flood -T add <ip>
actionunban = pfctl -t flood -T del <ip>

Comme vous voyez on va largement utiliser les tables pf, il y a donc quelques modifs à faire dans votre /etc/pf.conf :

# La table
table <flood> persist
# On laisse passer tout sauf les IP de <flood>
pass in inet proto tcp from ! <flood> to $ext_if port ssh

Ensuite on modifie le filtre filter.d/sshd.conf :

[INCLUDES]

before = common.conf

[Definition]

_daemon = sshd

failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
               ^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT\s*$

ignoreregex =

Et on active le filtre dans jail.conf :

[ssh-pf]
enabled  = true
filter   = sshd
action   = pf
          sendmail-whois[name=SSH, dest=root@localhost, sender=noreply@localhost]
logpath  = /var/log/auth.log
maxretry = 1
bantime  = 86400

Ils sont bannis pour 1 jours (de quoi leur faire perdre beaucoup de temps). En prime pour chaque ban vous recevez le whois de l'IP concernée par mail.

Finalement on oublie pas de lancer fail2ban :

# echo fail2ban_enable=\"YES\" >> /etc/rc.conf
# /usr/local/etc/rc.d/fail2ban start

Ce qui pourrait être intéressant c'est de choper automatiquement les adresses mail Abuse du whois pour envoyer un mail au FAI du méchant pour lui dire tout ce qu'on pense de son client. Mais bon, on ne va pas non plus faire de délation à la HADOPI.

Spamd ou comment bloquer les spams sans discriminer à priori des adresses IPs et sans remettre en cause la neutralité du réseau.

J'ai écrit une page sur spamd sur le principe de fonctionnement et sa mise en place sur OpenBSD.

Ce tout nouveau wiki cogéré par philpep.org et bender-labs.org est plus adapté que mon blog pour ce genre de choses car vous pouvez aussi apporter votre contribution pour faire part de votre expérience (ne serait-ce que pour corriger d'éventuelles fautes d'orthographes et de grammaires :-) ).

Je viens de réaliser une petit prouesse qui vaut bien un billet.

La situation : j'ai une super sono qui ne marche malheureusement qu'avec une entrée optique. Et la seule machine qui a une sortie optique chez moi c'est la machine qui sur laquelle vous êtes connectée en ce moment, mon serveur. Je n'ai pas d'écrans sur ce serveur et je n'ai pas envie d'installer X.org et tout ce qui vient avec. Par contre j'ai un portable avec une belle interface graphique, seulement j'ai un son tout pourri là dessus.

L'idée est donc de faire jouer le son par le serveur et d'afficher l'image sur le portable. Ce que X.org permet par son architecture client/serveur le serveur X (mon portable) pourrait afficher l'image que lui envoie le client (mplayer sur mon serveur) et le son serait joué par le client (donc sur le serveur ici). Sauf qu'une image, et à plus forte raison une serie d'image comme un film, ça représente beaucoup de donnée à transmettre sur le réseau, et même sur le reseau local il y a des latences qui ne sont pas négligeables.

Donc je me suis dit que faire l'inverse doit être plus rapide. C'est à dire mplayer sur mon portable qui envoie les données audio par le réseau au serveur. Et c'est possible avec NAS (Network Audio System). Voilà comment faire :

Installer NAS sur le serveur (ici sur FreeBSD)

make -C /usr/ports/audio/nas install clean

La configuration par defaut marche très bien. On peut ensuite lancer NAS en tand qu'utilisateur normal :

nasd :0 -aa -b -config /usr/local/etc/nasd.conf.eg

L'option :X dis à nasd d'écouter sur le port 8000+X (je sais c'est vraiment pas convi mais bon c'est comme ça).

Et voilà pour nous (8000 + 0) c'est sur le port 8000 filtrez le comme vous voulez avec votre parre-feu.

Ensuite sur le client (mon portable) il suffit d'indiquer à mplayer l'host et le port du serveur nas comme expliqué dans la page de man. Puis lancez votre film/musique. L'host peut être une IP ou un nom de domaine peu importe.

export AUDIOSERVER=tcp/host:8000
mplayer -ao nas fichier.avi