Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Serveur

Niveau :      
Résumé : apachetop ; mytop

Vous connaissiez xrestop, iftop, top, htop, ntop voici maintenant deux nouveaux, apachetop et mytop.

Apachetop

Comme vous vous en doutez, apachetop permet de monitorer l'activité d'apache. Il le fait en lisant ses fichiers de log, donc attention, si vous logguez des choses dans des fichiers inhabituels, c'est à vous de préciser quels fichiers lire. Apachetop vous affiche :

  • les statistiques depuis le début de la session, en requête, en octets, ...
  • la proportion de chacun des codes de retour (200,300,...) correspondante
  • les statistiques depuis les 30 dernières secondes, en requête, en octets, ...
  • la proportion de chacun des codes de retour (200,300,...) correspondante
  • la liste des url les plus appelées
$ apachetop -l -f /var/log/apache2/virtual1.access.log -f /var/log/apache2/virtual2.access.log

Mytop

Comme vous vous en doutez, mytop permet de monitorer l'activité de mysql. Il le fait en appelant régulièrement show processlist et en vous formatant la sortie.

  • Attention, parfois ce processus consomme beaucoup.
  • Attention, il ne lit pas le fichier .my.cnf donc les valeurs par défaut ne sont pas bonnes.
  • Attention, s'il y a une erreur de config mytop affiche sa config, y compris le mot de passe, ce qui est pas top.
  • Mytop demande une base de données valide, mais ne s'en sert pas vraiment, -> --db mysql
  • La connexion se fait par défaut en tcp -> option -S pour spécifier la socket
  • Après un changement de mode d'affichage, on est obligé de quitter (touche q)
$ mytop --db mysql --user toto --prompt

Il vous affichera les connexions avec leur thread id, leur machine, leur user et leur commande. Notez que le manuel vous indiquera quelques touches permettant d'afficher diverses informations.

Niveau :      
Résumé : inetd ; xinetd

Écrire un service c'est facile. La preuve en ligne avec un serveur qui dit bonjour en shell en 5mn.

Tout d'abord codons un script qui vous dit bonjour.

#!/bin/sh
echo "Quel est votre nom ?"
read nom
echo "Bonjour $nom"

Appelons-le /srv/tests/serveur.sh et testons le :

$ chmod +x /srv/tests/serveur.sh
$ /srv/tests/serveur.sh

Et maintenant transformons tout ça en service. Pour cela il nous faut un inetd fonctionnel, soit le vieux netkit-inetd, soit xinetd, soit le plus récent openbsd-inetd.

Ajoutons une configuration inetd (netkit ou openbsd):

1234    stream  tcp     nowait  root    /srv/tests/serveur.sh

Qui nous donne pour xinetd :

service 1234
{
        type            = UNLISTED
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        server          = /srv/tests/serveur.sh
        port            = 1234
}

Testez :

$ telnet localhost 1234

C'est prêt !

Niveau :      

Résumé : mod_setenvif ; mod_header

Savez-vous que la lecture et l'écriture de variables d'environnement sont particulièrement lentes ?

Je suis tombé récemment sur un problème de performances sur apache. Après analyse, il s'est avéré que le coupable est mod_setenvif. Nous utilisions ce dernier pour modifier des header avec cette méthode :

SetEnvIf Cookie (.*) value
SetEnvIf value (.*) value debut$1fin
RequestHeader Cookie value

Or à partir d'apache 2.2.4, il est possible d'utiliser une expression régulière directement avec RequestHeader :

RequestHeader edit Cookie (.*) debut$1fin

Le temps de réponse par requête a été divisé par 5. Bien sûr on peut accuser les expressions régulières, mais vous constaterez que ce sont les 2 mêmes.

De plus, un test a montre que setenv était environ dix fois plus lent qu'un simple malloc. Même si on ne peut pas vraiment comparer, l'explication me convient.

Niveau :      
Résumé : subjectAltName

On vous a toujours dit qu'il n'était pas possible de faire des virtualhost en https. En gros vous devriez avoir une ip par site. Mais réveillez vous camarade, on vous ment, on vous spolie ... En effet tout est possible en informatique, ou presque, c'est juste une question de temps passé à mettre à jour les navigateurs du monde entier.

TLS

Tout d'abord, faut-il vraiment faire du SSL ? C'est une vraie question. En effet, il existe le TLS, "successeur" du SSL qui permet une négociation de la couche de sécurité après une connexion normale. Il existe déja une RFC pour faire du HTTP sur TLS (2817 et 2818) mais pour permettre les virtualhost, il faut une extension supplémentaire (SNI, RFC 3546). C'est probablement une solution d'avenir, mais :

  • SNI is supported in Firefox 2, IE 7 on Vista, Opera 7.6+ and other modern browsers. For Apache, mod_gnutls supports it, but not mod_ssl (OpenSSL). I'm not sure about IIS.
  • Le support dans lighthttpd en est encore au stade du patch

Certificats SSL

Supposons que vous vouliez donc rester en SSL classique. Alors la bonne solution, celle qui marche pour tous les navigateurs est d'utiliser des certificats avec "SubjAltNames".

Openssl étant codé un peu bizarrement, il ne propose pas de modifier ce paramètre en ligne de commande. Il faut donc modifier le fichier de configuration. Comme nous ne somme pas root et que sous sommes fainéants, nous allons recopier la configuration par défaut dans notre répertoire de travail :

$ cp /etc/ssl/openssl.cnf .
$ vi openssl.cnf

Il faut avoir une section req demandant d'utiliser les extensions et une section spéciale pour l'extension. Et c'est dans cette extension que nous mettrons nos différents virtualhosts.

[ req ]
req_extensions = toto
...

[ toto ]
subjectAltName     = DNS:wiki.toto.fr, DNS:blog.toto.fr

continue reading...

Niveau :      
Résumé : openssl

Je vous propose de devenir votre propre autorité de certification.

Pour quoi faire ?

En général une autorité de certification permet de garantir à un utilisateur lambda que le certificat que vous allez lui présenter correspond bien à ce que vous prétendez et ce sans devoir chercher à le vérifier lui-même. Pour que cela fonctionne, il faut que le client en question fasse déjà confiance à cette autorité.

Or si vous êtes votre propre autorité, personne ne vous fera confiance. En fait ceci n'est utile que dans deux cas. Le premier pour faire des tests sans devoir payer (relativement cher). Le deuxième pour avoir des certificats SSL sur un parc de clients que vous pouvez maîtriser. Par exemple sur un intranet pour pouvez exiger des clients qu'ils installent votre autorité.

Comment faire ?

Créez votre propre clé privée :

$ openssl genrsa -des3 -out ca.key 2048

Créez votre demande de certificat

$ openssl req -new -key ca.key -out ca.csr
# vous avez le droit à ce que vous voulez dans le CN

Signez le certificat par lui-même :

# longue durée
$ openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

Bravo ! Vous avez maintenant un certificat que vous pouvez utiliser pour signer tous vos autres certificats. Le certificat est dans ca.crt et sa clé privée dans ca.key.


continue reading...

Niveau :      
Résumé : allow where .html|.php

Vous hébergez des sites web développés par vous ou par d'autres. Et bien sûr vous êtes sujets à quelques petits travers de développement, ou à quelques erreurs. Que celui qui n'a jamais poussé un répertoire CVS ou un fichier de log sur un serveur web me jette le premier octet ! Et je ne parle pas de ceux qui font joujou avec vi directement en production et créent des fichiers ~.

J'ai la solution à tous vos tracas de sécurité, il s'agit d'interdire le transfert de tous les fichiers dont l'extension n'est pas explicitement autorisée.

La méthode est simple, il suffit d'ajouter les lignes suivantes dans votre configuration apache :

    # À garder en premier
    <Files "*">
            deny from all
    </Files>
    # Liste des extensions à autoriser
    <FilesMatch ".(html|php)$">
            allow from all
    </FilesMatch>
    # On autorise aussi les urls qui se terminent par un /
    # -> implicitement les fichiers d'index
    # -> implicitement les /?var=valeur
    <LocationMatch "/$">
            allow from all
    </LocationMatch>
    # ajoutez vos règles

Au passage cela vous permettra de sécuriser un peu mieux les blogs ou wikis fournis avec des .txt et des .tgz

Niveau :      
Résumé : Match

Savez vous qu'en ssh vous pouvez imposer des contraintes à certains utilisateurs seulement.

Exemple pour interdire l'utilisation de mots de passe à un groupe d'utilisateurs (à mettre dans /etc/ssh/sshd_config) :

Match Group glandus
PasswordAuthentication no

Attention, toutes les lignes qui suivent un match sont liées à ce match juqu'au prochain match ou à la fin du fichier de configuration. Placez donc vos directives match à la fin du fichier.

Pour forcer l'utilisation d'une commande à un utilisateur donné :

Match User toto
ForceCommand /bin/cat /etc/php5/apache2/php.ini

Pour forcer l'affichage d'un texte d'avertissement avant la connexion pour les machines venant d'un certain réseau :

Match Host *.linux.fr
Banner /etc/ssh_warn

Pour interdire le forwarding de port à une machine (un utilisateur un peu doué saura bien sûr contourner ça) :

Match Address 192.168.1.1
AllowTcpForwarding no