par ·0 Commentaires

Mes serveurs Linux lorsqu’ils sont provisionnés via Foreman (j’y reviendrais) vont s’enregistrer à mon FreeIPA qui gère l’authentification et mon DNS interne.
Histoire de pousser un peu la sécurité, je me connecte en SSH depuis mon MacOS à ces machines via Kerberos.
Et pour cela il faut configurer votre MacOS mais surtout vérifier deux choses avant de démarrer :
1. Une bonne résolution DNS de vos FreeIPA (2 MMR dans mon cas)
2. Que votre date et heure coïncide avec vos serveurs FreeIPA, le plus simple étant de pointer votre MacOS sur vos serveurs FreeIPA

Mais trêve de bavardage, commençons.

Lire la suite de

par ·0 Commentaires

Lors de chaque connexion a mes machines Linux depuis RoyaTSx, ce message « LC_CTYPE: cannot change locale (UTF-8): No such file or directory » apparaissait à la connexion, mais aussi a l’exécution de chaque script.
Pour se débarrasser de celui-ci il faut aller dans la configuration par defaut du plugin iTerm2 :
RoyalTSx - 1

Et décocher la case suivante :
« Set locale variables automatically »
RoyalTSx - 2

A la prochaine connexion sur une de vos machines cela devra être bon.

par ·1 Commentaire

Lors de l’utilisation d’un service web tel que Apache, il est intéressant de fournir le service de façon sécurisé même au sein de l’entreprise, ne serais-ce que pour éviter la transmission des mots de passe en clair sur le réseau.

Lors de mes différentes interventions, je vois souvent la mise en place d’un certificat auto-signé  affichant dans le navigateur un message d’avertissement effrayant auprès des utilisateurs. Hors dans la majorité des cas, les postes clients sont des machines Windows intégré à un annuaire Active Directory, grâce à cela il est possible de pousser des certificats par GPO. Mais ce n’est pas le plus élégant; en effet depuis des années Microsoft fourni une PKI intégré directement dans l’Active Directory. Chacun des postes intégré à l’AD dispose dans son magasin de certificat la CA root de l’entreprise.
Et c’est sur cette base que nous allons créer une certificat qui sera reconnu par les navigateurs (enfin la Internet Explorer car le magasin de certificat windows n’est utilisé que par IE).

Le scénario est le suivant :

  • ActiveDirectory 2008 R2 incluant la PKI
  • Un client Windows 2008 R2 intégré au domaine (j’avais que ça sous le coude)
  • Serveur Web apache2 sous CentOS 6.4 et OpenSSL (la version non troué :p )

Cette procédure est effectué sur une CentOS, mais je suis certain que cela fonctionne sur d’autres distributions

On commence par créer la clef privé du serveur :

centOS# openssl genrsa 2048 > /etc/pki/tls/private/apache.domain.tld.key

Puis on génère la requête :

centOS# openssl req -new -key /etc/pki/tls/private/apache.domain.tld.key > /etc/pki/tls/private/apache.domain.tld.req
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) [XX]:FR
 State or Province Name (full name) []:IDF
 Locality Name (eg, city) [Default City]:Paris
 Organization Name (eg, company) [Default Company Ltd]:Les Titans
 Organizational Unit Name (eg, section) []:
 Common Name (eg, your name or your server's hostname) []:apache.domain.tld
 Email Address []:admin@domain.tld
Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Une fois le fichier de requête transféré au serveur Windows, on va demander à la CA de créer un certificat via la mmc dédié :

Apache-MPKI-01

Apache-MPKI-02

Mais pourquoi cela ne fonctionne pas ?

La solution est simple,la PKI de Microsoft ne sais pas sur quel template SSL il doit s’appuyer pour créer le certificat et comme vous êtes des barbus, vous n’avez pas installé l’interface IIS pour gérer les certificats (sinon il faut copier-coller la demande sur le site web et roule ma poule)

Il ne nous reste plus qu’a sortir la ligne de commande windows et :

windows# certreq -submit -attrib "CertificateTemplate:WebServer" apache.domain.tld.req

Apache-MPKI-03

Grâce a cette commande, le système nous proposer de sauvegarder le certificat signé par la PKI. Il faut savoir que je m’appuie sur le template web standard où la validité du certificat est limité à 2 ans…

Il ne reste plus qu’a l’intégrer dans votre serveur apache :

vim /etc/httpd/conf.d/ssl.conf (ou autre fichier pour votre site web)

SSLCertificateFile /etc/pki/tls/private/apache.domain.tld.crt <= notre certificat
SSLCertificateKeyFile /etc/pki/tls/private/apache.domain.tld.key

Enfin pour tester on lance son navigateur web depuis  le client on va sur l’url de notre site web et on oh miracle :

Apache-MPKI-05

Références :

– https://dusk1911.wordpress.com/2012/07/10/issuing-exchange-certificate-from-ca-without-gui-and-getting-denied-by-policy-module-0x80094801/

par ·2 Commentaires

Il m’est arrivé de ne plus me souvenir du mot de passe admin d’une plateforme Zabbix de préproduction que j’avais mis en place quelques temps auparavant. Après avoir cherché un peu je suis tombé sur la solution et la marque ici afin d’avoir un pense bête en cas de nouvel oublis.
Il faut bien évidement avoir accès root à la machine puis :

mysql -u root -p
use zabbix;
update zabbix.users set passwd=md5('MYNEWPASSWORD') where alias='Admin';

Avec ça reset le mot de passe admin (ou autre utilisateur), par contre ce que j’avais oublié c’est que j’avais connecté ce Zabbix sur un LDAP, du coup même le reset du mot de passe ne m’a servi à rien.

La solution consiste à changer la méthode d’authentification le temps de tout reconfigurer correctement :

mysql -u root -p
select zabbix;
update zabbix.config set authentication_type=0 where authentication_type=1;

Puis, pour que cela ne se reproduise plus j’ai créé un nouveau groupe qui ne s’authentifiera qu’en interne :

et le tour est joué !

par ·1 Commentaire

A la suite de divers changement d’humeurs, je ne savais plus quelles versions de Linux j’avais installé au sein de mon infrastructure. Alors plutôt que de me connecter sur chaque serveur et vérifier quelle version et quelle révision de était présente, j’ai utilisé la fonction d’inventaire de Zabbix pour effectuer l’opération. Pour cela on va créer un nouvel item dans le template OS Linux fourni de base dans l’installation de Zabbix :

Aller dans Configuration -> Template -> Template OS Linux -> Items -> Create Item

puis créer l’item avec les informations suivantes :

Explications des informations importantes :

Name : System Distribution

-> Ici c’est le nom de l’item

Type : Zabbix Agent

-> le type de check qui va être effectué. Dans notre cas c’est l’agent Zabbix qui va nous remonter l’information.

Key : system.sw.os[name]

-> On positionne la clef que l’on souhaite remonter. Le « name » permet de ne remonter que la distribution, d’autres options sont disponibles.

Type of information : Character

-> la donnée remonté est de type character

Update interval : 86400

-> l’intervalle d’interrogation, étant donné que je ne met pas a jour mes serveurs tous les quatre matins, je l’ai positionné a 1 jour.

Populate host inventory field : OS (Short)

-> ici on stipule où sera placé l’information dans l’inventaire.

Attention : ceci n’est disponible qu’avec un agent égal ou supérieur à la version 2.0

Une fois que l’item est sauvegardé, il suffi de patienter que l’information remonte :

par ·3 Commentaires

Je continue sur ma lancé avec la supervision de NGINX avec zabbix. Plusieurs sites effectue cette opération via des scripts. Comme je l’ai dis dans mon précédent article, je préfèré une solution qui fonctionne « out of the box » (comme dirait les commerciaux).

Nginx dispose d’un module de status (a la apache) . Si vous voulez avoir plus d’informations sur ce qu’il monitore, je vous conseil de lire la documentation officiel.

Maintenant que l’on sais ce que l’on va monitorer, voici comment il faut faire :

Création d’un virtualhost spécifique accessible uniquement par l’agent zabbix :

Au niveau de votre serveur NGINX, il faut créer un virtualhost avec la configuration suivante :

server {
      listen 127.0.0.1:8080; # écoute en local sur un port différent
      location / {
          stub_status on; # on charge le module de status
          access_log off; # on ne logge pas inutilement les accès
          allow 127.0.0.1; # autorisation uniquement depuis le localhost
          deny all; # on refuse tout le reste
       }
 }

et bien sur faire un reload de NGINX a la fin de votre configuration

Modification du fichier zabbix_agentd.conf

Afin que le système prenne en compte les futurs checks contenu dans le template on ajoute ces paramètres utilisateurs à la configuration de l’agent zabbix (zabbix_agentd.conf):

UserParameter=nginx.active[*],wget -O- -q $1:$2 | awk ‘/^Active/ {print $NF}’
UserParameter=nginx.reading[*],wget -O- -q $1:$2 | awk ‘/Reading/ {print $$2}’
UserParameter=nginx.writing[*],wget -O- -q $1:$2 | awk ‘/Writing/ {print $$4}’
UserParameter=nginx.waiting[*],wget -O- -q $1:$2 | awk ‘/Waiting/ {print $$6}’
UserParameter=nginx.accepted[*],wget -O- -q $1:$2 | awk ‘/^[ \t]+[0-9]+[ \t]+[0-9]+[ \t]+[0-9]+/ {print $$1}’
UserParameter=nginx.handled[*],wget -O- -q $1:$2 | awk ‘/^[ \t]+[0-9]+[ \t]+[0-9]+[ \t]+[0-9]+/ {print $$2}’
UserParameter=nginx.requests[*],wget -O- -q $1:$2 | awk ‘/^[ \t]+[0-9]+[ \t]+[0-9]+[ \t]+[0-9]+/ {print $$3}’

Il ne reste plus qu’a importer et associer à vos hosts le template Zabbix qui suit : Template_nginx