Debian squeeze Munin : client denied by server configuration

Vous venez d’installer munin via les dépôts officiel de debian squeeze. La configuration de munin est faite en suivant votre guide préféré, mais lorsque vous souhaitez accéder à vos magnifiques graphes, apache vous renvoie une magnifique erreur. Dans votre fichier de log d’apache vous avez ceci : client denied by server configuration

La solution est en fait assez simple, mais j’ai pas mal galérer afin de trouver la solution.

Il faut autoriser l’accès à votre IP dans la configuration de votre serveur apache.
Il faut éditer ce fichier :
/etc/munin/apache.conf
Et ajouter l’IP de sa machine (par ex 192.168.1.1) comme ceci :
Allow from localhost 192.168.1.1/24 ::1
Juste en dessous de celle-ci :
Allow from localhost 127.0.0.0/8 ::1

Puis, il faut redémarrer votre serveur apache et munin-node, et hop cela fonctionne.

Comment récupérer son RIO et savoir quand finit mon contrat?

Je reçois beaucoup de questions, mais 2 questions reviennent assez souvent : comment puis-je récupérer mon RIO ? comment puis-je savoir quand finit mon contrat mobile ? une question simple. Il existe un numéro unique à appeler à partir de son mobile qui vous permettra d’obtenir ces 2 informations et ce, quelque soit votre opérateur.

Il suffit de composer le :

3179

une charmante voix vous annonce votre RIO et la date de fin de votre contrat. Mais ne vous inquiétez pas si vous n’avez pas le temps de tout écrire, vous allez recevoir quelques instants après un SMS récapitulant ces données.

Pourquoi installer DenyHosts sur son serveur ?

Il existe plusieurs de manière de bloquer les vilains assaillants essayant de se connecter à votre serveur en SSH. Vous pouvez utiliser Fail2ban, iptables mais aussi DenyHosts. Alors, pourquoi absolument installer DenyHosts ?

DenyHosts se différencie de Fail2ban sur plusieurs points :

  • il ne s’occupe que du ssh alors que Fail2ban sait bloquer un grand nombre de services se basant sur l’authentification par mot de passe et ayant la capacité de logguer les essais infructueux dans le bon fichier de log
  • le mode de blocage est différent, Fail2ban utilise iptables alors que DenyHosts utilise TCP Wrappers (leurs actions étant différentes, on comprend qu’ils sont complémentaires)
  • synchronisation entre plusieurs DenyHosts : vous avez plusieurs serveurs, et grâce à cette fonction dès qu’un de vos serveurs subis une attaque, tous vos serveurs blacklistent cette IP
  • partage des IP blacklistées via www.denyhosts.net, vous envoyez vos IP blacklistées, mais vous pouvez aussi recevoir les IP blacklistées par les autres utilisateurs (vous pouvez définir des seuils)

Vous aurez compris que DenyHosts, Fail2ban et iptables correctement configurés doivent cohabiter sur vos serveurs.

Je ne vais pas vous détailler l’installation et la configuration de DenyHosts, le fichier de conf /etc/denyhosts.conf est parfaitement commenté.

Si vous hésitez sur la valeur d’un paramètre, je vous invite à poster un message.

Signer la pétition pour une protection de l’apiculture et des consommateurs face au lobby des OGM

Une fois n’est pas coutume, un rapide post pour vous engager à lire la page sur la pétition pour une protection de l’apiculture et des consommateurs face au lobby des OGM, et si vous êtes d’accord avec le texte, je vous engage à la signer. D’abord parce que j’aime le miel et les abeilles, parce qu’il est essentiel de protéger la nature des World Companies qui ne pensent qu’au fric et parce que nos politiques se foutent de nous et de notre avenir et qu’en conséquence, il faut se bouger, sinon on se fait niquer.

Modifier la configuration de yum pour Centos 4

Si vous devez travailler sur des vieilles versions de Centos / Redhat comme la 4, version qui n’est plus maintenue et plus disponible dans les bases Centos, il faut ajuster la configuration de yum.

Pour cela, vider de son contenu /etc/yum.repos.d/CentOS-Base.repo et ajouter ceci :

# CentOS-Base.repo # # CentOS-4 is past End of Life ... use at your own risk #

[base] name=CentOS-$releasever - Base baseurl=http://vault.centos.org/4.9/os/$basearch/ gpgcheck=1 gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4 protect=1 priority=1

#released updates [update] name=CentOS-$releasever - Updates baseurl=http://vault.centos.org/4.9/updates/$basearch/ gpgcheck=1 gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4 protect=1 priority=1

#packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons baseurl=http://vault.centos.org/4.9/addons/$basearch/ gpgcheck=1 gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4 protect=1 priority=1

#additional packages that may be useful [extras] name=CentOS-$releasever - Extras baseurl=http://vault.centos.org/4.9/extras/$basearch/ gpgcheck=1 gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4 protect=1 priority=1

#additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus baseurl=http://vault.centos.org/4.9/centosplus/$basearch/ gpgcheck=1 enabled=0 gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4 protect=1 priority=2

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
baseurl=http://vault.centos.org/4.9/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-centos4
protect=1
priority=2

Ensuite, un petit yum update, et vous pouvez de nouveau ajouter des packages et mettre à jour votre centos en attendant d’avoir le temps ou la demande du client afin de migrer le soft vers un système à jour et maintenu (je ne peux que rappeler que c’est indispensable).

Howto : comment renforcer la sécurité du réseau sous linux avec sysctl ?

Il est essentiel de sécuriser ses machines sous linux. Il y a plusieurs étapes indispensables à suivre. Aujourd’hui, nous allons voir comment sysctl va nous aider.

En modifiant un seul fichier de conf, nous allons renforcer la protection réseau :

  • protection contre l’ IP Spoofing
  • protection contre les scans
  • amélioration des logs pour permettre des traitements avec des outils tiers comme fail2ban
  • paramétrages divers

Nous allons éditer le fichier /etc/sysctl.conf et ajouter ou décommenter les lignes suivantes :

# IP Spoofing protection 
net.ipv4.conf.all.rp_filter = 1 
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests 
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing 
net.ipv4.conf.all.accept_source_route = 0 
net.ipv6.conf.all.accept_source_route = 0 
net.ipv4.conf.default.accept_source_route = 0 
net.ipv6.conf.default.accept_source_route = 0

# Ignore send redirects 
net.ipv4.conf.all.send_redirects = 0 
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks 
net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_max_syn_backlog = 2048 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 5

# Log Martians 
net.ipv4.conf.all.log_martians = 1 
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ignore ICMP redirects 
net.ipv4.conf.all.accept_redirects = 0 
net.ipv6.conf.all.accept_redirects = 0 
net.ipv4.conf.default.accept_redirects = 0 
net.ipv6.conf.default.accept_redirects = 0

# Ignore Directed pings 
net.ipv4.icmp_echo_ignore_all = 1

Vous sauvegardez et quittez. Il faut ensuite recharger sysctl pour la prise en compte des modifications :

sysctl -p

Et voilà !

Howto : Automatiser les mises à jour de sécurité sous Ubuntu Server

Si vous n’êtes pas connecté chaque jour sur les listes de diffusion de sécurité de votre distribution préférée (et ça, c’est pas bien), mais que vous souhaitez malgré tout dormir tranquille, Ubuntu a intégré une fonctionnalité pour vous.

Soit vous activez cette fonctionnalité lors de l’installation (choix N°2) :

Soit, via ces commandes :

Il faut que le paquet unattended-upgrades soit installé, dans le cas il ne l’est pas :

sudo apt-get install unattended-upgrades

Puis activer le paquet :

sudo dpkg-reconfigure unattended-upgrades

Suivez attentivement le dialogue intéractif. A l’issue de ce process, 2 fichiers sont créés :

/etc/apt/apt.conf.d/20auto-upgrades

et

/etc/apt/apt.conf.d/50unattended-upgrades

Voilà, votre distribution se mettra à jour automatiquement dès qu’une mise à jour de sécurité est disponible. Il est bien entendu possible de personnaliser l’intervalle de vérification et la possibilité de recevoir un mail à chaque mise à jour, juste pour vous avertir, et vous donner envie de vous connecter afin de vérifier que tout va bien (c’est un conseil, mais une mise à jour peut planter un process !).

Howto : comment utiliser Sipp pour tester la montée en charge de votre serveur SIP ?

Après le précédent guide détaillant l’installation de sipp sur debian/centos, il est temps maintenant d’apprendre à utiliser ce fabuleux outil.

Le scénario du jour (sur sipp, nous avons la possibilité de créer de nombreux scenarii ce qui apporte une grande richesse à cet outil open source) a pour but de tester la montée en charge de votre tout nouveau serveur SIP que ce soit un Asterisk, un Freeswitch, un Kamailio, un Opensips ou tout autre solution libre ou propriétaire.

Voici le schéma du test, SIPP et le proxy SIP étant installés sur 2 serveurs différents :

Sipp UAC —> Proxy SIP —> Sipp UAS

Sipp Client :

./sipp -sf uac_pcap.xml -d 10000 -s 0917000000 10.254.254.249:5060 -l 10000 -mi 10.254.254.9 -i 10.254.254.9 -mp 6000 -r 1

Explication de la commande :

  • -sf uac_pcap.xml : exécute le scénario contenu dans le fichier xml
  • -d 1000 : définit la durée de l’appel en ms (durée de l’instruction pause du script pour être précis)
  • -s 0917000000 : définit le username de la requête URI 10.254.254.249:5060 : serveur à tester avec le port d’écoute SIP
  • -l 10000 : nombre max d’appels simultanés
  • -mi 10.254.254.9 : adresse IP locale pour le flux média
  • -i 10.254.254.9 : adresse IP de l’interface locale d’écoute -mp 6000 : port local RTP echo (défaut : 6000)
  • -r 1 : nombre d’appels par seconde

Sipp Serveur :

./sipp -sf uas.xml -p 5062 -i 192.168.52.221 -mi 192.168.52.221 -mp 7000

La configuration de votre proxy SIP est à adapter en conséquence : les 2 comptes SIP (client et serveur) et la table de routage des appels.

Bon test.

HowTo : comment faire des recherches sur google anonymement ?

Chaque fois que vous faites une requête de recherche via google, google trace tous vos faits et gestes. Vous souhaitez malgré tout continuer à profiter de l’exhaustivité de la base de données de google tout en protégeant votre vie privée. Oui, c’est possible. Il y a un site pour ça : startpage.com .

Ils s’engagent dans leur charte à n’enregistrer aucune donnée personnelle, ni l’adresse IP du terminal et n’enregistre aucun cookie. Les requêtes via leur serveur se font via une connexion cryptée et sécurisée.

Startpage appartient à une société de droit hollandais. Le moteur de recherche a obtenu plusieurs prix : 1er prix du label européen de la protection de la confidentialité (European Privacy Seal) décerné par l’autorité de certification Europrise et désigné meilleur métamoteur de recherche par Search Engine Watch en 2000, 2002 et 2004.

HowTo : comment overclocker votre carte Raspberry PI ?

Table des matières

Introduction

Vous adorez votre carte Raspberry mais vous trouvez qu’elle manque un peu de pêche pour certains projets, notamment multimédia ? je vais vous guider afin de doper (légalement, on est pas dans le cyclisme 🙂 ) votre Raspberry.

Les étapes de l’overclocking

Pour cela, nous avons 3 étapes (quand même !) à suivre :

  1. ajouter un radiateur à notre carte
  2. mettre à jour notre distribution
  3. paramétrage

Choix du radiateur

Il faut en effet ajouter un radiateur, car en augmentant les fréquences et les tensions, le chip va émettre plus de chaleur qu’il va falloir dissiper. Il faut bien avoir en tête, que le vieillissement d’un composant électronique s’accélère très fortement avec l’augmentation de sa chaleur (et l’augmentation n’est pas linéaire). Il existe plusieurs modèles (je ne les ai pas testé, il faudrait avoir des specs plus détaillées pour comparer les performances).

Sur Kubii.fr, on trouve un dissipateur en céramique (Réf. : 1892471 – 2,51 €TTC, sur kibuck.fr), on trouve un kit de 3 dissipateurs pour 1,49 €TTC, et enfin, un superbe boitier intégrant 3 dissipateurs sur le site de Adafruit à 74,95 $ (ah oui, ce n’est pas donné !)

Mise à jour du système

Maintenant que votre carte est bien protégée de l’excès de chaleur, il est essentiel de mettre à jour votre firmware. Pour cela, il faut lancer la commande :

sudo rpi-update

Si aucune erreur n’est détectée, vous devez redémarrer afin d’activer le nouveau firmware.

Paramétrage

Passons à l’étape d’overclocking.

Il est possible de modifier les fréquences du microprocesseur, de la mémoire ainsi que du processeur graphique.

Afin de modifier ces valeurs, il faut éditer le fichier config.txt qui se trouve dans /boot . Ce fichier est lu par le GPU avant l’initialisation du processeur ARM.

sudo nano /boot/config.txt

A noter, que sous la distribution Rasbian, il est possible de modifier ces paramètres directement en tapant sudo raspi-config et ceci sans perte de garantie. Pour ceux qui fonctionne sur une autre distribution n’intégrant pas encore cette fonctionnalité, il faut modifier les variables suivantes :

force_turbo=0

en passant la variable à 1, on désactive le mode « turbo », c’est à dire la possibilité au système d’adapter les fréquences en fonction de la charge et de la température. A part des applications très spécifiques, ce n’est pas recommandé, car en plus d’accélérer le vieillissement, on augmente la consommation électrique.

Passons aux variables permettant de régler les fréquences :

  • arm_freq : fréquence du processeur ARM en MHz. Défaut : 700.
  • core_freq : fréquence du GPU en MHz. Défaut: 250.
  • sdram_freq : fréquence de la mémoire SDRAM en MHz. Défaut : 400.

Il est aussi possible de définir des valeurs minimum :

  • arm_freq_min : valeur min de arm_freq utilisée pour la gestion dynamique de la fréquence. Défaut : 700
  • core_freq_min : valeur min de core_freq utilisée pour la gestion dynamique de la fréquence. Défaut : 250
  • sdram_freq_min : valeur min de sdram_freq utilisée pour la gestion dynamique de la fréquence. Défaut : 400

Attention, avant de choisir vos fréquences, il est important de comprendre qu’elles sont liées entre elles. Le processeur GPU core, h264, v3d and isp partage la même PLL, ainsi les fréquences sont liées.

Il est aussi possible de changer la tension, mais dans ce cas la garantie saute (d’autres éléments peuvent faire sauter la garantie, attention) !

Après avoir modifié le fichier, redémarrer afin que les nouveaux paramètres soient bien pris en compte.

Vérifications d’usage

Maintenant, il possible de vérifier en ligne de commande, différentes données :

  • Fréquence du processeur ARM : /opt/vc/bin/vcgencmd measure_clock arm
  • Fréquence du core : /opt/vc/bin/vcgencmd measure_clock core
  • Température du chip BCM2835 : /opt/vc/bin/vcgencmd measure_temp
  • Tensions core et mémoire : vcgencmd measure_volts core (remplacer core par sdram_c, sdram_i et sdram_p pour les données de la mémoire)

Allez, je vous donne un petit script afin de voir les données en une seule commande :

#!/bin/sh echo Core `/usr/bin/vcgencmd measure_temp` echo Core `/usr/bin/vcgencmd measure_volts` echo sdram phy `/usr/bin/vcgencmd measure_volts sdram_p` echo sdram i/o `/usr/bin/vcgencmd measure_volts sdram_i` echo sdram controller `/usr/bin/vcgencmd measure_volts sdram_c` echo Arm `/usr/bin/vcgencmd measure_clock arm` echo Core `/usr/bin/vcgencmd measure_clock core` echo v3d `/usr/bin/vcgencmd measure_clock v3d`

Conclusion

On peut encore booster sa carte avec divers paramètres, en désactivant certaines fonctions si elles ne sont pas utiles comme par exemple, l’USB, permettant de récupérer 10% de puissance complémentaire au processeur ARM. Il faut avant tout bien définir ses besoins, et régler aux petits oignons votre superbe Raspberry.

Good hack !