Dwm sur FreeBSD

date
8 / 12 / 2009
comments
0

Pour installer dwm sur freebsd il y a deux méthodes. Soit par les ports soit en récupérant la dernière sur le dépôt mercurial. Le problème avec la version mercurial c'est qu'il faut modifier un peu le config.mk pour que ça compile proprement puis faut se tenir au courant des mises à jours etc. Et dans mon imaginaire la version des dépôt compilait avec un config.h fixé, mais en fait c'est faux le Makefile laisse le choix o/

.if defined(DWM_CONF)
        @${ECHO_MSG} "creating config.h from ${DWM_CONF}"
        @${CP} ${DWM_CONF} ${WRKSRC}/config.h
.endif

Donc hop, j'ai juste à lui donner mon config.h dans /etc/make.conf

echo "DWM_CONF=/home/phil/config/dwm/config.h" >> /etc/make.conf
make -C /usr/ports/x11-wm/dwm install clean

Et roulez jeunesse.

pfstat

date
6 / 12 / 2009
comments
0

J'aime pas franchement les graphe les chiffres tout ça (j'entends déjà rire les gens qui me connaissent devant ce mensonge éhonté). Mais j'avoue que j'aime bien les stats donnée par pfstat (le site est souvent down en ce moment). Ce petit soft récolte des statistiques temporelles sur pf et peut les cracher sous forme de graphe.

Petit exemple tout de suite, ce graphe représente le traffic entrant/sortant (in/out) autorisé/bloqué (block in/block out) sur mon routeur pour les dernières 24h.

stats solo

C'est assez interessant, il peut faire une multitude de graphes configurables, je vais pas poser ma conf ici parce que je l'ai honteusement pompée sur calomel. À noter que pfstat est aussi disponible en daemon (pfstatd), ça permet de générer les images des statistiques d'une autre machine. Il suffit de lancer pfstatd sur la machine ou l'on veut faire des statistiques, et lancer pfstat (dans cron par exemple) avec les options -r host:port.

Vous pouvez voir ici ce qui se passe sur mes deux modestes machines qui font exister philpep.org.

EDIT 10 janvier 2010 : pfstat ne semble plus maintenu :/ , en tout cas il a du mal avec les dernières versions de pf. Bref les graphes que vous voyez sont vieux

fail2ban sshd et pf

date
18 / 11 / 2009
comments
0

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.

Dwm

date
16 / 11 / 2009
date
wm
comments
4

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 :-)

Controler les leds sur ALIX 2D3

date
2 / 11 / 2009
comments
0

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.