Proxy on Zwindler's Reflection

Monitorez le fait que les URLs bloquées sont bien bloquées par le proxy

Sat, 18 Nov 2017 12:45:25 +0000

Comment je vérifie que les sites bloqués par mon proxy sont bien bloqués ?

Il y a plein de raisons qui peuvent expliquer qu’un site non légitime soit bloqué sur un lieu de travail (par exemple). Et autant de raisons qui font que, parfois, les proxies ne bloquent pas bien des sites que vous aviez pourtant bloqués !

Pour tout ce qui est supervision des pages web, Nagios fourni le plugin check_http, dans les nagios-plugins (collection officielle de plugins), et qui permet de vérifier qu’une page web donnée est accessible (ou non).

Limitations

Cependant, il existe plusieurs cas où ce plugin ne « fonctionne pas » comme je le souhaite :

D’abord, dans le cas où l’URL checkée renvoie un 30x (redirection), le check_http considère que c’est bon et ne va pas chercher plus loin. Hors, il arrive que le site soit down au-delà de la redirection. Dans ce cas là, check_http ne nous notifie pas de l’échec.
Ensuite, dans le cas où vous voulez traverser un proxy pour vérifier si une page est accessible ou non comme dans mon introduction, vous ne pouvez pas spécifier si un code retour 40x est une bonne chose ou non. Dans tous les cas, avec check_http, un 40x sera considéré comme un WARNING, jamais comme un CRITICAL ou un OK.

Pour résoudre ces problèmes, j’ai donc réécris un petit script bash simple, permettant de résoudre tous les cas ci-dessus. Avec check_proxy_http_url, vous pouvez vérifier des URLs en spécifiant un proxy, suivre correctement les redirections (301 ou 302 par ex.) et spécifier si le fait qu’une page soit accessible (ou pas accessible) est une bonne chose ou non.

Installation

Le script est simplissime. Pour des raisons de facilité je me suis simplement appuyé sur un script bash et de wget, présents sur la plupart des serveurs par défaut. Il n’y a pas d’autres prérequis.

Dans un futur (plus ou moins) proche j’ajouterai également une compatibilité avec cURL, qui a tendance à le remplacer.

Usage

Là encore, j’ai fait au plus simple. Le script dispose d’un nombre limité d’arguments, permettant de réaliser les usecases indiqués précédemment.

/var/lib/nrpe/plugins/check_proxy_http_url.sh -u TARGET_URL [-p PROXY_ADDRESS:PROXY_PORT] [-r] [-v]

TARGET_URL : obligatoire - l’URL que vous souhaitez superviser. Par défaut, un code retour de type 200 induira un OK, un 4XX/5XX un CRITICAL
PROXY_ADDRESS & PROXY_PORT : optionnels - le hostname ou l’adresse de votre proxy, si nécessaire
-r : optionnel - permet d’inverser les codes retours de Nagios. Un code retour 200 induira un CRITICAL (URL qui est accessible alors qu’elle ne le devrait pas) et un 4XX/5XX induira un OK

Exemples

Vérifier que http://@IPsome_forbidden_website.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -u some_forbidden_website.com -r
OK: URL some_forbidden_website.com isn't available and it shouldn't - 403

Vérifier que http://@IPsome_allowed_website_that_isnt_accessible.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -p internal_proxy:8181 -u some_allowed_website_that_isnt_accessible.com
CRITICAL: URL some_allowed_website_that_isnt_accessible.com isn't available and it should - 403

Code source

Comme d’habitude avec mes plugins « Nagios compatibles », les sources sont disponibles sur Github à l’adresse suivante :

github.com/zwindler/check_proxy_http_url

Le lien pour Nagios Exchange est également disponible ici !

Mes autres plugins sont également disponibles sur le Github :

Utiliser le gestionnaire d’extension Perl CPAN derrière un proxy

Wed, 29 Mar 2017 12:00:26 +0000

Aaaah, CPAN, un vrai bonheur

Ceux qui me suivent savent que, bien qu’il m’arrive d’utiliser Perl de temps en temps (et même de coder un peu de Perl, ce qui m’a fait acheter Learning Perl et Programing Perl de chez O’Reilly), je passe surtout la plupart de mon temps à pester contre le CPAN (voir cet article où je détaille entièrement comment installer un simple plugin Nagios sans accès à Internet).

Car CPAN et les modules/dépendances Perl, c’est bien, mais c’est quand même mieux quand on a accès à Internet !

Pas d’Internet dans mon DC (ou presque)

Il n’est pas rare que je n’ai pas accès à Internet lorsque j’installe un serveur, et c’est généralement dans ce genre de cas qu’on essaye de trouver des bidouilles.

Par exemple, dans les DC qui n’ont accès qu’à un proxy avec authentification NTLMv2 (Microsoft), je n’hésite pas à installer cntlm (ou avant ntlmaps). C’est crade, mais ça me permet d’avoir mon proxy pour Yum, wget, etc… qui ne seraient pas (ou mal) gérés autrement. Et ça m’a sauvé bien des fois !

Dans le cas qui nous concerne dans cet article sur CPAN, j’ai découvert avec stupeur qu’il existe un « shell » CPAN, auquel on peut tout simplement ajouter une configuration particulière, notamment pour lui donner un proxy !

Voilà de quoi régler une partie de mes problèmes !

Pour activer le shell CPAN, deux méthodes (similaires) :

perl -MCPAN -e shell
#ou
cpan

Configurer le proxy pour CPAN

o conf init /proxy/
If you're accessing the net via proxies, you can specify them in the
CPAN configuration or via environment variables. The variable in
the $CPAN::Config takes precedence.
<ftp_proxy>
Your ftp_proxy? [] @IP:<port>
<http_proxy>
Your http_proxy? [] @IP:<port>
<no_proxy>
Your no_proxy? [] @IP:<port>
Please remember to call 'o conf commit' to make the config permanent!

Et comme nous sommes disciplinés, nous n’oublierons pas d’enregistrer les modifications avec la commande indiquée plus haut

o conf commit

Désactiver le proxy

o conf no_proxy 1

Et on sauvegarde !

o conf commit

Bonus track : forcer le proxy HTTP plutôt que FTP

Je me suis retrouvé avec CPAN qui essayait à un moment donner de passer par FTP pour télécharger les packages alors que je n’avais qu’un proxy HTTP. Et pour ce problème particulier, je suis tombé sur cette page sur serverrfault qui donne quelques clés pour s’en sortir :

Simplest way of having it not use FTP is to shove HTTP URLs on the front of your urllist - or replace it completely like sebastionopilla said.

Pour afficher les URLs utilisées

o conf urllist
urllist
0 [http://example.org/]
1 [http://example.org/]
2 [http://example.org/CPAN/]

Exclure une URL de la configuration (un miroir par exemple)

o conf urllist unshift http://example.org/here/

Pour tout vider

o conf urllist -
o conf urllist shift

Source : serverfault.com/questions/130690/force-cpan-to-download-via-http/292696

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 2

Tue, 22 Sep 2015 16:31:03 +0000

Tutoriel pas à pas pour installer Shinken 2.4 - partie 2

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur Shinken 2.4 et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Installation

Vous savez maintenant c’est conçu, on peut se lancer dans le bain !

En réalité, c’est un peu plus compliqué que cela ;-). D’autant plus que le logiciel a subit plusieurs modifications de philosophie et de fonctionnement au fil du temps et que la page de documentation 10 Minutes Shinken Installation Guide n’est malheureusement plus à jour et parfois même incomplète.

Prérequis et installation via pip

D’abord, il va falloir installer quelques prérequis si vous voulez pouvoir installer Shinken sur un serveur CentOS 7 « Desktop ». On les retrouve dans le 10 minutes Shinken installation Guide cité plus haut.

La méthode la plus simple consiste à utiliser pip qui récupère les sources directement depuis pypi.python.org et les installe tout seul c’est donc celle là que je vais présenter. Pour CentOS 7, pip est contenu dans le package python-pip, lui même disponible via le dépôt EPEL Release.

[New]Si comme moi vous en avez marre d’installer des Desktop pou rien ca rvous n’utilisez pas la partie graphique, il faut ajouter le package redhat-lsb en Minimal, prérequis aux scripts de démarrage de Shinken

yum install epel-release
#ou rpm -iUvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
yum update
yum install python-pip
yum install redhat-lsb

A partir de là, on peut reprendre les commandes citées sur la page principale du site.

adduser shinken
pip install shinken

Auquel on nous conseille (sans trop nous le dire) d’ajouter

pip install cherrypy
yum install nagios-plugins

Et enfin quelques derniers prérequis pas du tout cités et qui seront utiles pour la suite :

yum install python-crypto #necessaire pour installer les modules via "shinken install"
yum install mongodb mongodb-server #necessaire pour plusieurs modules dont la WebUI
yum install httpd-tools #utile pour une authentification simple et rapide de la WebUI

Si vous êtes derrière un proxy (moi j’ai besoin de ntlmaps ou cntlm pour sortir sur Internet), n’oubliez pas de le positionner dans la variable https_proxy (notez le S de https).

export https_proxy=http://localhost:8080/

pip devrait maintenant se charger de tout récupérer sur Internet pour vous.

Collecting shinken
Downloading Shinken-2.4.tar.gz (26.7MB)
65% |##################### | 17.5MB 106kB/s eta 0:01:27

Votre machine dispose maintenant du cœur de Shinken installé. C’était rapide, mais ne criez pas victoire trop vite.

Il faut maintenant configurer les démons et ajouter les modules.

Configuration de base

Le cœur de la configuration se situe dans le fichier /etc/shinken/shinken.cfg.

C’est dans ce fichier que vous allez définir les paramètres globaux et les fichiers de configuration complémentaires à parcourir de la même façon que vous l’auriez fait avec nagios.cfg.

Les démons

J’en parlais dans les articles précédents, l’architecture de Shinken diffère de celle de Nagios du fait que Shinken fonctionne avec des démons, chaque démons ayant un rôle particulier.

L’installation de base créé un fichier de configuration pour chaque type de démon dans son propre répertoire :

ll /etc/shinken/arbiters/
total 4
-rw-r--r--. 1 shinken shinken 2744 19 sept. 19:54 arbiter-master.cfg

A ne pas confondre : vous pourriez être surpris par la présence de fichiers [demon]d.ini dans le répertoire daemons/. Ces fichiers servent plutôt à la modification des paramètres « systèmes » des démons, comme le user+group, mais pas à l’ajout de modules ou à la définition de paramètres interne à Shinken, comme le fait que le démon soit un spare ou pas, affecté à un realm, etc.

ll /etc/shinken/daemons
-rw-r--r-- 1 shnkn shnkn 1231 17 sept. 14:34 brokerd.ini
-rw-r--r-- 1 shnkn shnkn 1223 17 sept. 14:34 pollerd.ini
-rw-r--r-- 1 shnkn shnkn 862 17 sept. 14:34 reactionnerd.ini
-rw-r--r-- 1 shnkn shnkn 856 17 sept. 14:34 receiverd.ini
-rw-r--r-- 1 shnkn shnkn 983 17 sept. 14:34 schedulerd.ini

Démarrage automatique

On s’arrange pour qu’ils démarrent tous au démarrage. La documentation propose la boucle suivante pour ajouter tous les démons dans le démarrage pour un OS qui utilise systemd et plus System V (Debian/Ubuntu/RHEL/CentOS dans leurs dernières versions pour ne citer qu’eux).

for i in arbiter poller reactionner scheduler broker receiver; do
systemctl enable shinken-$i.service;
done

Cela étant dit, j’ai plutôt utilisé le service shinken qui « chapeaute » le tout et qui suffit dans le cas d’une architecture standard (sans haute disponibilité et répartition de charge) comme celle que nous sommes en train d’installer. A votre convenance.

systemctl enable shinken

Quelque soit la méthode, un CentOS/RHEL 7 devrait vous renvoyer l’erreur suivante :

shinken.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig shinken on
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).

Il est probable que le script n’ait pas encore totalement été modifié pour fonctionner avec systemd (pour des raisons de compatibilité peut être ?). Ça mériterait un petit ticket sur github pour voir avec les core devs…

A ce stade, c’est « fonctionnel » dans le sens ou on peut lancer le démon principal et qu’on se rendra compte que tout « fonctionne ».

systemctl start shinken
systemctl status shinken
shinken.service - LSB: Shinken monitoring daemon
Loaded: loaded (/etc/rc.d/init.d/shinken)
Active: active (running) since dim. 2015-09-20 16:34:12 CEST; 7s ago
[...]

Pour autant, je ne suis pas certain que cela vous soit très utile car :

vous n’avez pas encore ajouté vos serveurs à superviser
vous n’avez pas encore d’interface graphique.

Direction l’article suivant pour régler ça !