Archives 11/2009
18/11/2009 fail2ban sshd et pf
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.
16/11/2009 Dwm
Après avoir passé beaucoup de temps sur wmfs, je cherchais un wm encore plus léger et surtout plus rapide, avec une conf toute simple. Rien que sur wmfs, qui est loin d'être le plus lourd des wm, je n'utilise que 10% des fonctionnalités, la conf est blindée et le démarage reste assez lent.
Au hasard du web je suis tombé sur dwm, un wm développé par la communauté suckless dont voici un extrait du manifeste :
Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. The more code lines you have removed, the more progress you have made. As the number of lines of code in your software shrinks, the more skilled you have become and the less your software sucks.
À partir de là tout est dit. Dans dwm pas de fonctions à tout faire, mais du code efficace, sans bugs et utilisable. Le dernier point dépend bien entendu que de vous. Personnellement toutes les fonctions que j'attends d'un wm y sont.
Dans dwm pas de fichier de configuration, il y a dans le répertoire des sources un fichier config.h dans lequel vous devez mettre votre configuration. Il faut recompiler à chaque modification de la configuration, comme ça vous avez votre propre dwm et c'est assez sympa comme principe je trouve.
De plus vous pouvez créer vos propre fonctions assez facilement, le code est simple, lisible et surtout très court (~2000 lignes). Pour vous donner un exemple il n'y a pas de fonction qui permette d'atteindre le tag précédent ou suivant. Vous pouvez vous inspirer de mon config.h (c'est un vieux patch que j'ai trouvé sur la mailing list que j'ai du un peu modifier pour que ça marche avec dwm 5.8). Beaucoup d'autres patchs sont disponibles sur le site de dwm.
Je crois que j'ai trouvé mon wm, mais bon je le dis à chaque fois que je trouve un wm :-)
2/11/2009 Controler les leds sur ALIX 2D3
Il y a 4 leds sur le devant, la première est réservée par l'alimentation et la dernière par la carte minipci, mais les deux autres sont à disposition pour nos amis scripteur. Ces deux leds se contrôlent sur les broches 25 et 27 du gpio.
Il faut les activer avant que securelevel passe à 1. Dans /etc/rc.securelevel :
# Configuring the leds echo -n "Configuring the leds : " /usr/sbin/gpioctl gpio0 25 set out led2 /usr/sbin/gpioctl gpio0 27 set out led3
Un petit reboot, et vous pouvez controler vos leds (q = quiet) avec :
gpioctl -q gpio0 led2 off gpioctl -q gpio0 led2 on
A vous de scripter ce que vous voulez derrière, style un script qui fait clignoter la led si la passerelle est accessible etc.