Limiter l’accès SSH à certains utilisateurs

02/01/2009

Dans un contexte de serveur d’hébergement offert à plusieurs utilisateurs, il est de coutume de leur donner un accès via FTP pour qu’ils puissent mettre en ligne leur site et de limiter leur accès à leur /home (via un chroot).

Si vous utilisez la liste des utilisateurs système pour le FTP, ces utilisateurs ont également par défaut un accès SSH et donc des droits en lecture sur pas mal de fichiers, ce qui est légitime de vouloir restreindre aux utilisateurs de confiance.

La solution est de créer un groupe d’utilisateurs, que nous nommerons par exemple sshallow dans le quel il suffit de placer les utilisateurs qui disposeront d’un droit d’accès à SSH. La création d’un groupe se fait via la commande addgroup sshallow.

Nous ajoutons alors les utilisateurs désirés dans le groupe adduser nom sshallow. N’oubliez pas d’y ajouter l’utilisateur avec lequel vous administrez la machine!!!

Ensuite, nous informons le serveur SSH de l’existence du groupe en éditant le fichier /etc/ssh/sshd_config et en y rajoutant la directive AllowGroups sshallow.

Il ne reste plus qu’à redémarrer le serveur ssh. Avant de fermer la fenêtre, je vous recommande de tester une nouvelle connexion avec l’utilisateur que vous utilisez habituellement pour administrer la machine afin de s’assurer qu’il n’y a aucun blocage.

Système ,

Accepter les connexions SMTP sur un port supplémentaire

01/01/2009

Certains FAI bloquent le port 25 en sortie de leur réseau, ce choix étant justifié par deux raisons précises:

  • vous obliger à utiliser leur serveur SMTP;
  • luter contre les machines zombies. Une machine zombie est une machine sur laquelle a été installé à l’insu de son utilisateur un logiciel généralement inoffensif pour la machine en elle-même, mais qui s’en sert pour envoyer du spam, lancer des scans, du flood, …

Si vous souhaitez utiliser le serveur SMTP d’un serveur précis, cela est alors impossible puisqu’il vous est impossible de le contacter sur le port 25. Pour les utilisateurs nomades, qui se connectent sur différents réseaux au gré de leur déplacements, le même problème survient, puisqu’ils ne connaissent pas le serveur SMTP local; et même s’ils le connaissent, c’est un paramètre à modifier à chaque fois, ce qui devient vite handicapant pour gérer efficacement son courrier.

Une solution à ce double problème est d’ouvrir un second port sur votre serveur SMTP.

Pour postfix, puisque c’est un des objets de ce blog, cela se fait facilement (comme toute manipulation sous Postfix ;-) ) en éditant le fichier /etc/postfix/master.cf.

Il suffit de rajouter une ligne de la forme

5025      inet  n       -       -       -       -       smtpd
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

où 5025 représente le numéro du port que nous allons ouvrir. Il vous est loisible de rajouter les directives que vous souhaitez à la fin de la ligne (par exemple pour faire appel à un filtre de contenu).

Nous indiquons à Postfix de n’accepter sur ce port que les personnes s’authentifiant en SASL. En effet, si les spammeurs découvrent que votre serveur accepte les connexions sur un autre port sans filtrage, je crois que vous croulerez vite sous le spam !

Vous pouvez rajouter autant de lignes similaires que vous le souhaitez, en modifiant le numéro du port à la valeur désirée. N’en ouvrez tout de même pas des millions, ça ne sert à rien. Les ports au dessus de 1024 ne sont généralements pas filtrés par les FAI et autres réseaux d’entreprise, un seul devrait donc suffire …

Il faut évidement redémarrer Postfix après cette manipulation.

Courrier électronique , , ,

Ne pas surcharger le serveur de courrier secondaire

30/12/2008

Lors d’une configuration typique d’un domaine ayant un serveur MX principal et un ou plusieurs secondaires, un problème généralement rencontré est que les spammeurs envoient le courrier au serveur MX secondaire, espérant ainsi trouver un serveur moins bien protégé contre le spam.

Une parade existe à cela. Prenons l’exemple du domaine example.org, ayant deux serveurs MX définis:

  • le premier, mx1.example.org, serveur principal, défini avec une priorité de 1;
  • le deuxième, mx.backupserver.tld, défini avec une priorité de 10;

Le principe, lors de l’envoi d’un mail, est de d’abord essayer le serveur ayant la priorité la plus importante (plus petit nombre). En cas de non réponse du premier serveur, on passe au suivant, et ainsi de suite. Si aucun d’entre-eux ne répond on garde le mail en queue et on attend un peu avant de recommencer.

Les spammeurs, eux, commencent parfois dans l’ordre inverse (à partir de la plus faible priorité), surchargeant ainsi le serveur de backup. La solution est donc de rajouter une troisième entrée MX dans la zone du domaine, ayant la priorité la plus faible mais pointant vers le même serveur que le MX principal. Au final, la configuration de la zone du domaine example.org deviendrait:

  • mx1.example.org, priorité 1
  • mx.backupserver.tld, priorité 10
  • mx1.example.org, priorité 100

On peut utiliser pour la troisième entrée un hostname différent pointant vers la même ip pour brouiller les pistes.

Avec cette configuration DNS, l’activité du serveur de backup sera considérablement réduite, les spammeurs utilisant cette technique tomberont bien sur le serveur principal.

Il est évident que ceci n’est qu’une réponse à une technique précise des spammeurs, ils en utilisent malheureusement bien d’autres.

Général , ,

Postfix: mails en double lors de la livraison vers une boîte avec copie vers une autre

29/12/2008

Voici un problème couramment rencontré sur un serveur de courrier équipé d’un logicel antispam ou anti-virus. Une boîte mail a un transfert automatique (via un alias ou un bcc) du courrier vers une autre boîte. Le courrier se trouve en double dans la boîte en copie.

La cause de ce problème est en réalité assez simple. Un mail arrive de l’extérieur, il est injecté dans postfix. Postfix regarde alors dans la table des alias ou des BCC et voit que l’adresse destinataire intègre une deuxième destination, le mail est donc dupliqué vers la deuxième destination. Les deux mails sont ensuite passé au filtre antispam ou antivirus, puis réinjectés dans postfix, qui reprend le même processus : le destinataire intègre une deuxième destination et le mail est à nouveau dupliqué. Trois copies du mail orginal existent alors: celle vers l’adresse de base, celui vers la deuxième destination, dupliqué avant le filtre de contenu, et enfin, celui vers la deuxième destination dupliqué après le filtre de contenu. Deplus, votre filtre a été appelé deux fois, le mail ayant été dupliqué avant son appel.

Mais, rassurez-vous, il existe une solution à ce problème. Il est en effet possible de dire à postfix de ne pas traduire les alias. Pour ce faire, éditer le fichier /etc/postfix/master.cf, et à la ligne smtpd, qui contient -o content_filter=nomdufiltre (c’est généralement la première ligne), rajouter -o receive_override_options=no_address_mappings. Ne pas oublier de redémarrer postfix pour prendre en compte la nouvelle configuration.

Le comportement sera alors normal lors de la réception d’un mail: il est passé au content_filter, et seulement après sa réinjection, les alias sont interprétés.

Courrier électronique , , ,

Eviter la coupure d’une connexion SSH inactive

28/12/2008

Vous avez sûrement déjà constaté qu’une connexion SSH laissée ouverte trop longtemps sans activité fini par se couper au bout d’un certain temps. La raison vient du fait que votre FAI coupe les connexions inactives au bout d’un certain temps.

Pour éviter celà et ne pas devoir vous reconnecter intempestivement, il suffit d’éditer le fichier /etc/ssh/sshd_config, et d’y rajouter la directive ClientAliveInterval 60, sans oublier de redémarrer le serveur SSH.

Avec cette directive, le serveur SSH enverra à votre client un paquet « keep-alive » toutes les 60 secondes pour éviter que la connexion soit déclarée inactive et donc coupée :)

Système

Délai de conservation des logs système

27/12/2008

Par défaut, les logs du système, situés dans /var/log ne sont conservés que 7 jours. Il est utile de les conserver plus longtemps afin d’avoir une trace d’évenements plus anciens, notamment pour des raisons légales (serveur mail par exemple).

Vous aurez remarqué que changer cela dans les paramètres par défaut de logrotate ne sert à rien. La rotation de ces logs est gérée dans le fichier /etc/cron.daily/sysklogd.

Cherchez dans ce fichier la ligne « savelog -g adm -m 640 -u ${USER} -c 7 $LOG >/dev/null ». L’argument indiquand le nombre de fichiers à conserver est le -c. Indiquez simplement à sa suite le nombre désiré.

Si vous avez configuré votre serveur avec une partition / spécifique, il est conseillé de placer les logs sur la partition /home au moyen d’un lien symbolique pour éviter de saturer la /.

Système ,

Bloquer les scans ssh, pop3 et imap : fail2ban

27/12/2008

Fail2ban est un démon qui lit les fichiers de logs au fur et à mesure de leur écriture afin de bloquer les ip indésirables pendant un temps donné. Le but est simplement d’éviter de surcharger votre serveur avec des dizaines de requêtes par seconde dont le seul but est d’essayer de trouver un couple utilisateur/mot de passe valide afin de tenter de hacker votre machine ou de s’en servir comme relais pour l’envoi de courrier électronique indésirable.

Fail2ban intègre par défaut le contrôle des scans SSH, en lisant votre fichier /var/log/auth.log. Il n’y a donc pas de configuration particulière à faire pour ssh.

Il est possible de le configurer pour qu’il lise aussi votre /var/log/mail.log afin de bloquer les adresses ip qui floodent votre serveur de courrier avec des couples login/mots de passe invalides. L’espoir des hackeurs est de tomber sur un serveur qui pratique le pop-before-smtp, c’est à dire la technique qui consiste à d’abord lire son courrier puis d’utiliser le serveur smtp. Le fait de s’authentifier avec succès sur le serveur pop implique que votre adresse ip est autorisée à envoyer du courrier pendant un certain temps, vers toutes les destinations. Les hackeurs peuvent alors se servir de votre serveur pour envoyer leur spam à la terre entière.

La première étape est de demander à dovecot de transcrire dans les logs les tentatives de connexion échouées. Cela se fait en éditant son fichier de configuration /etc/dovecot/dovecot.conf et en positionnant la directive auth_verbose à true.

Ensuite, il faut éditer le fichier /etc/fail2ban/jail.local et y rajouter

[dovecot-auth]
enabled  = true
port     = imap,imaps,pop3,pop3
sfilter   = dovecot-auth
logpath  = /var/log/mail.log

Vous pouvez rajouter d’autres directives: maxretry (nombre de tentatives après blacklistage), ignoreip (liste d’ip qui ne seront pas blacklistées séparées par des espaces) et bantime (temps de blacklistage en secondes). Attention, ne pas oublier de mettre 127.0.0.1 dans la liste des ip à ignorer, sans quoi des tentatives infructueuses via un webmail conduiraient à un auto-blacklistage, ce qui aurait un impact sur toutes les applications (postfix ne saurait plus se connecter à MySQL, par exemple). En haut du fichier, ces 3 directives sont présentes de manière globale, le fait de les repréciser dans une règle leur fait prendre le dessus pour la règle en cours.

Ensuite, créer un fichier /etc/fail2ban/filter.d/dovecot-auth.conf et y mettre

[Definition]
failregex = auth-worker(.*): sql(.*,<HOST>): unknown user

Il est évident qu’il peut être nécessaire d’adapter la regexp à votre situtation, l’ip à blacklister étant représentée par <HOST>. Dans ce cas-ci, on ne bloquera que les utilisateurs inexistants, la regexp peut par exemple être adaptée pour prendre en compte les vrais utilisateurs qui se trompent de mot de passe.

Redémarrer fail2ban et dovecot pour les faire prendre en compte leur nouvelle configuration.

Fail2ban consigne ses actions dans le fichier /var/log/fail2ban.log.

Système , , , , , ,

Bilan de santé : htop

26/12/2008

Au menu d’aujourd’hui, un utilitaire fort utile qui permet de voir en un clin d’oeil l’état d’une machine : htop, que l’on peut considérer comme un top des temps modernes.

Une jauge d’utilisation est affichée pour chaque core, la mémoire RAM ainsi que la SWAP. Le nombre de processus total ainsi que le nombre de processus actifs sont affichés à droite de l’écran.

Il est possible de classer les processus par utilisation du cpu, de la ram, du temps machine utilisé ainsi que de les grouper par utilisateur (touche F6), d’obtenir une vue des processus en arbre, afin de voir la hiérarchie des processus lancés par un processus donné (touche F5), de killer un processus (touche F9), d’augmenter ou de diminuer la priorité d’un processus (respectivement F8 et F7).

Et, last but not least, htop intègre le support de la souris, il suffit de cliquer sur la ligne d’un processus pour la mettre en surbrillance !

htop

Système , , , ,