Bonjour
Vous trouverez ici diverses astuces pour vous faciliter la vie sur votre unix préféré. Mais celles-ci ne seront bientôt plus mises à jour. En effet, dadmin devient
linux attitude
Sysadmin en herbe (Linux Attitude)
Ce site est en jachère, retrouvez la version la plus récente sur Linux AttitudeArchives
- novembre 2007 (11)
- octobre 2007 (18)
- septembre 2007 (16)
- août 2007 (15)
- juillet 2007 (19)
- juin 2007 (16)
- mai 2007 (17)
- avril 2007 (17)
- mars 2007 (9)
Publicité
La suite en direct sur http://linux-attitude.fr/post/Acces-refuse
Niveau :
Résumé : MaxStartups
Comment bloquer l'accès d'une personne à son serveur en une ligne ?
Pourquoi ? Parce qu'il existe une directive dans ssh pour protéger le serveur contre les attaques. Il s'agit de MaxStartups qui indique le maximum de connexions non authentifiées autorisées, par défaut il vaut 10. Au delà, il faudra attendre que l'une de ces connexions tcp se termine, ce qui peut prendre beaucoup de temps. Un petit malin peut donc vous bloquer indéfiniment l'accès à votre serveur.
Attention, augmenter cette valeur ne vous protège pas pour autant car le malin peut faire de même avec ses clients. Un moindre mal est d'utiliser la forme 1:2:3
Exemple :
Cela vous donne une petite chance devant un ennemi impatient, mais c'est bien peu.
Une autre chance vous est donnée par l'option LoginGraceTime
Vous pouvez aussi passer MaxStartups à une valeur extrêmement grande, mais cela ne vous protégerait plus des syn flood. Est-ce mieux ? À vous de voir où vous placez vos limites.
Niveau :
Résumé : MaxStartups
Comment bloquer l'accès d'une personne à son serveur en une ligne ?
$ for i in $(seq 1 10) ; do nc ssh.youpi.net 22 & done
Pourquoi ? Parce qu'il existe une directive dans ssh pour protéger le serveur contre les attaques. Il s'agit de MaxStartups qui indique le maximum de connexions non authentifiées autorisées, par défaut il vaut 10. Au delà, il faudra attendre que l'une de ces connexions tcp se termine, ce qui peut prendre beaucoup de temps. Un petit malin peut donc vous bloquer indéfiniment l'accès à votre serveur.
Attention, augmenter cette valeur ne vous protège pas pour autant car le malin peut faire de même avec ses clients. Un moindre mal est d'utiliser la forme 1:2:3
Exemple :
# À partir de 10 connexions le client à 20% de chances de s'en voir refuser une nouvelle
# Cette probabilité augmente linéairement jusqu'a 30 connexions
# À partir de 30 connexions il ne pourra plus se connecter
MaxStartups 10:20:30
Cela vous donne une petite chance devant un ennemi impatient, mais c'est bien peu.
Une autre chance vous est donnée par l'option LoginGraceTime
# apres 10s sans tentative de login, la connexion est coupée (la valeur par défaut est 120)
LoginGraceTime 10
Vous pouvez aussi passer MaxStartups à une valeur extrêmement grande, mais cela ne vous protégerait plus des syn flood. Est-ce mieux ? À vous de voir où vous placez vos limites.
La suite sur http://linux-attitude.fr/post/Round-Robin
Niveau :
Résumé : Round Robin DNS
Contrairement à ce que vous pensez, il ne s'agit pas du mignon de Batman mais d'une méthode de répartition. Nous allons parler du round robin dns.
Le but est de répartir la charge d'un serveur sur des machines distinctes. Le principe est simple, il s'agit de fournir plusieurs IP pour la même entrée dns. Le client choisira alors de lui-même une de ces IP au hasard. C'est ce hasard qui répartira la charge entre les différents serveurs renseignés.
Les entrées DNS ressembleront donc à ceci
Attention tout de même :
Notez au passage qu'un CNAME dans le DNS est un véritable alias, donc la ligne suivante conserve la fonction round robin DNS à test.toto.net :
Notez aussi que le round robin DNS est un concept intégré au mail depuis longtemps. On l'utilise aussi fréquemment pour irc. C'est une solution permettant le partage de charge à peu de frais, mais pour le web on lui préférera l'utilisation d'un loadbalancer lorsqu'on en a les moyens et lorsque c'est possible. En effet leur utilisation est plutôt difficile entre plusieurs sites géographiques distincts.
Niveau :
Résumé : Round Robin DNS
Contrairement à ce que vous pensez, il ne s'agit pas du mignon de Batman mais d'une méthode de répartition. Nous allons parler du round robin dns.
Le but est de répartir la charge d'un serveur sur des machines distinctes. Le principe est simple, il s'agit de fournir plusieurs IP pour la même entrée dns. Le client choisira alors de lui-même une de ces IP au hasard. C'est ce hasard qui répartira la charge entre les différents serveurs renseignés.
Les entrées DNS ressembleront donc à ceci
www.toto.net IN A 10.0.0.1
www.toto.net IN A 10.0.0.2
Attention tout de même :
- En cas de problème sur une des 2 IP, le client doit faire de lui-même l'accès à une autre IP, ce qu'un certain nombre de logiciels devraient faire naturellement.
- Si le problème se situe au dessus de la couche TCP (par exemple une erreur HTTP 500), le logiciel client ne se rendra pas compte qu'il devrait interroger l'autre IP et l'utilisateur verra l'erreur. Pour une bonne gestion de la tolérance aux pannes, on préférera donc un loadbalancer.
- Les applicatifs doivent faire attention à la notion de session. Si l'applicatif se nomme irc, il n'y a pas de problème car il y a une session par connexion. Si l'application est en PHP, vous avez le choix entre ne pas utiliser de session, stocker les données de session dans une base de données partagée ou enfin partager le répertoire contenant les données de session PHP (avec NFS ou OCFS par exemple)
Notez au passage qu'un CNAME dans le DNS est un véritable alias, donc la ligne suivante conserve la fonction round robin DNS à test.toto.net :
test.toto.net IN CNAME www.toto.net.Par contre, il est impossible de spécifier plusieurs CNAME pour un nom, et donc d'espérer faire du round robin de cette façon.
Notez aussi que le round robin DNS est un concept intégré au mail depuis longtemps. On l'utilise aussi fréquemment pour irc. C'est une solution permettant le partage de charge à peu de frais, mais pour le web on lui préférera l'utilisation d'un loadbalancer lorsqu'on en a les moyens et lorsque c'est possible. En effet leur utilisation est plutôt difficile entre plusieurs sites géographiques distincts.
Vivez la suite de l'article sur http://linux-attitude.fr/post/Plus-loin-que-le-SMTP
Niveau :
Résumé : Submission
Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.
Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP.
Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.
La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.
La différence se fera donc au niveau des vérifications faites sur le serveur.
Un serveur servant à recevoir des mails devra vérifier :
Un serveur submission doit :
Un serveur submission devrait :
D'autre part, du fait de sa position privilégiée, un serveur submission peut :
L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.
Niveau :
Résumé : Submission
Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.
Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP.
Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.
La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.
La différence se fera donc au niveau des vérifications faites sur le serveur.
Un serveur servant à recevoir des mails devra vérifier :
- que le destinataire est valide et accepté localement
Un serveur submission doit :
- fournir de nouveaux codes d'erreur pour que le client mail puisse mieux interpréter les problèmes
- envoyer des mails uniquement avec des domaines valides dans l'enveloppe
- vérifier si possible que les adresses fournies sont valides
Un serveur submission devrait :
- répondre par un code d'erreur en cas de rejet et non par un mail au return path
- vérifier que l'émetteur est valide et reconnu comme utilisateur par le serveur (voire l'authentifier) et donc que le chemin de retour est valable
- rejeter les mails avec des adresses connues comme invalides
- loguer les erreurs
D'autre part, du fait de sa position privilégiée, un serveur submission peut :
- vérifier les droit d'envoi des utilisateurs
- demander une authentification
- vérifier la validité du contenu du mail
- modifier les en-têtes du mail : champ date, sender, message-id ...
L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.
La suite sur http://linux-attitude.fr/post/Connaitre-le-format-des-mails
Niveau :
Résumé : RFC 2822
Un mail est composé d'en-têtes et d'un corps. Les en-têtes sont de 2 types. Les en-têtes d'enveloppes et les autres. Un serveur qui ne fait que faire transiter un mail devrait toujours ajouter une en-tête d'enveloppe au tout début des en-têtes et ne pas toucher du tout au reste du mail. Ces en-têtes précisent par où et à quelle heure le mail est passé, elles se lisent de bas en haut.
Les autres en-têtes sont celles écrites par l'émetteur. Seul l'émetteur et le récepteur ainsi que les serveurs de mailing-list (qui sont les 2 à la fois) devraient toucher à ces en-têtes. De nos jour, cela inclue aussi les serveurs qui font de l'antispam et/ou antivirus.
Les en-têtes obligatoires :
Les utiles :
Les indispensables mais incompris :
Les inconnus:
Les en-têtes d'enveloppe :
Les autres :
Les en-têtes commençant par X- permettent à leurs utilisateurs de créer les en-têtes qui leur sembkent utile. En voici quelques exemples :
Et comme toujours, les détails dans la RFC 2822 http://www.faqs.org/rfcs/rfc2822.html
Niveau :
Résumé : RFC 2822
Un mail est composé d'en-têtes et d'un corps. Les en-têtes sont de 2 types. Les en-têtes d'enveloppes et les autres. Un serveur qui ne fait que faire transiter un mail devrait toujours ajouter une en-tête d'enveloppe au tout début des en-têtes et ne pas toucher du tout au reste du mail. Ces en-têtes précisent par où et à quelle heure le mail est passé, elles se lisent de bas en haut.
Les autres en-têtes sont celles écrites par l'émetteur. Seul l'émetteur et le récepteur ainsi que les serveurs de mailing-list (qui sont les 2 à la fois) devraient toucher à ces en-têtes. De nos jour, cela inclue aussi les serveurs qui font de l'antispam et/ou antivirus.
Les en-têtes obligatoires :
- From: Savez vous que vous pouvez mettre plusieurs from ! Dans ce cas, il Faut préciser Sender:
-
Date: devinez
- To:
- Cc:
- Subject:
- Bcc: Sisi il existe, donc vous devez être au courant quand vous êtes destinataires d'un Bcc (vous n'êtes jamais non destinataire d'un mail direct). Mais pourquoi les client mail ne le précisent-ils pas pour éviter les bourdes !
Les utiles :
- Reply-To:
Les indispensables mais incompris :
- Message-ID: de la forme <truc@machin> doit être universellement unique
- In-Reply-To: donne uniquement le parent (duplique l'information du suivant)
- References: donne tout le fil parent (important pour suivre les conversations)
Les inconnus:
- Comments: Mais qui les liraient ?
- Keywords: C'est pas comme si vos mails étaient indexés
- Resent-From:
- Resent-Date:
- Resent-Message-ID:
Les en-têtes d'enveloppe :
- Return-Path: Indique où renvoyer les mails d'erreur (MAIL FROM: du protocole SMTP)
- Received: date, heure, lieu de réception par le serveur
Les autres :
Les en-têtes commençant par X- permettent à leurs utilisateurs de créer les en-têtes qui leur sembkent utile. En voici quelques exemples :
- X-Mailer
- X-Spam-Level
- X-Loop
Et comme toujours, les détails dans la RFC 2822 http://www.faqs.org/rfcs/rfc2822.html
Suivez cet article sur http://linux-attitude.fr/post/Connaitre-le-protocole-SMTP
Niveau :
Résumé : SMTP
Connaitre le protocole SMTP est indispensable. Cela permet de faire quelque blagues, mais surtout de comprendre en quoi le protocole contient fondamentalement des failles et comment le spam fonctionne.
Le protocole est extrêmement simple, une session se résume en quelques commandes. Les codes de retour sont un peu les mêmes que FTP et HTTP , ainsi un 2xx indique une réussite. Voici une session typique :
Le EHLO devrait être suivi par le fqdn de l'émetteur. De plus en plus souvent le serveur vérifie ce qu'il contient. Il peut être évité ou remplacé par un HELO sur les serveurs mails qui font peu de vérifications.
MAIL FROM et RCPT TO doivent être indiqué dans cet ordre, ils indiquent la personne de qui vient le mail (non vérifié) et à qui il est destiné (le vrai destinataire). La norme suggère le mettre les adresses mail entre <> et certains serveurs l'exigent.
Enfin la commande DATA indique le contenu du mail. Lequel ne se termine que pas un '.' seul sur une ligne. Ce mail peu contenir absolument tout ce que vous voulez. Le serveur le transférera tel quel à la boite du destinataire avec quelques en-tête supplémentaires. Éventuellement il peut le faire passer par un antispam, antivirus, serveur de mailing-list ...
Pour plus de détails Lisez la RFC http://www.ietf.org/rfc/rfc2821.txt
Vous aurez compris que les failles se situent dans les vérifications. Dans les champs, seul RCPT TO est toujours vérifié et entièrement validé seulement si le destinataire est local.
Le mail lui-même n'est pas vérifié. Le format est (potentiellement) libre. Le mail étant lu par le client final, il est tout de même préférable qu'il respecte la RFC http://www.ietf.org/rfc/rfc0822.txt
On peut donc spécifier un destinataire ou un émetteur différent dans le corps et dans les informations données au serveur.
Il vous faudra attendre l'article suivant pour pouvoir écrire un mail complet.
Niveau :
Résumé : SMTP
Connaitre le protocole SMTP est indispensable. Cela permet de faire quelque blagues, mais surtout de comprendre en quoi le protocole contient fondamentalement des failles et comment le spam fonctionne.
Le protocole est extrêmement simple, une session se résume en quelques commandes. Les codes de retour sont un peu les mêmes que FTP et HTTP , ainsi un 2xx indique une réussite. Voici une session typique :
$ telnet smtp.mail.net 25
220 smtp.mail.net ESMTP ; Wed, 1 Aug 2007 14:44:41 +0200
EHLO toto
250-smtp.mail.net Hello localhost [127.0.0.1], pleased to meet you
MAIL FROM: ben@fr.fr
250 ben@fr.fr... Sender ok
RCPT TO: bob@fr.fr
250 bob@fr.fr... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Coucou !
.
250 OAA25287 Message accepted for delivery
QUIT
221 smtp.mail.net closing connection
Le EHLO devrait être suivi par le fqdn de l'émetteur. De plus en plus souvent le serveur vérifie ce qu'il contient. Il peut être évité ou remplacé par un HELO sur les serveurs mails qui font peu de vérifications.
MAIL FROM et RCPT TO doivent être indiqué dans cet ordre, ils indiquent la personne de qui vient le mail (non vérifié) et à qui il est destiné (le vrai destinataire). La norme suggère le mettre les adresses mail entre <> et certains serveurs l'exigent.
Enfin la commande DATA indique le contenu du mail. Lequel ne se termine que pas un '.' seul sur une ligne. Ce mail peu contenir absolument tout ce que vous voulez. Le serveur le transférera tel quel à la boite du destinataire avec quelques en-tête supplémentaires. Éventuellement il peut le faire passer par un antispam, antivirus, serveur de mailing-list ...
Pour plus de détails Lisez la RFC http://www.ietf.org/rfc/rfc2821.txt
Vous aurez compris que les failles se situent dans les vérifications. Dans les champs, seul RCPT TO est toujours vérifié et entièrement validé seulement si le destinataire est local.
Le mail lui-même n'est pas vérifié. Le format est (potentiellement) libre. Le mail étant lu par le client final, il est tout de même préférable qu'il respecte la RFC http://www.ietf.org/rfc/rfc0822.txt
On peut donc spécifier un destinataire ou un émetteur différent dans le corps et dans les informations données au serveur.
Il vous faudra attendre l'article suivant pour pouvoir écrire un mail complet.
Cet article est maintenant sur http://linux-attitude.fr/post/Connaitre-le-protocole-IMAP
Niveau :
Résumé : IMAP
Ceci est le début d'une série sur le mail.
Comment tester un serveur IMAP qu'on vient juste d'installer ? Il suffit de connaître les bases du protocole IMAP.
Tout d'abord, chaque commande IMAP est précédée d'un identififant permettant au client de repérer à quelle requête correspond la réponse donnée par le serveur, ceci car le protocole peut être asynchrone. La plupart des client mettent des numéros, mais vous pouvez aussi les remplacer simplement par des '.'.
Tentons une connexion de base avec création d'un répertoire (en gras ce qui nous intéresse, ce que vous tapez) :
Passons à quelque chose de plus sérieux.
On sélectionne le répertoire INBOX, puis on liste les messages de 1 à la fin (1:*) et on récupère un message.
En résumé retenez :
Il existe un grand nombre d'autres commandes et paramètres à FETCH, mais ceci devrait vous suffire pour du debug. Plus de détails sur la RFC : http://www.faqs.org/rfcs/rfc3501.html
Niveau :
Résumé : IMAP
Ceci est le début d'une série sur le mail.
Comment tester un serveur IMAP qu'on vient juste d'installer ? Il suffit de connaître les bases du protocole IMAP.
Tout d'abord, chaque commande IMAP est précédée d'un identififant permettant au client de repérer à quelle requête correspond la réponse donnée par le serveur, ceci car le protocole peut être asynchrone. La plupart des client mettent des numéros, mais vous pouvez aussi les remplacer simplement par des '.'.
Tentons une connexion de base avec création d'un répertoire (en gras ce qui nous intéresse, ce que vous tapez) :
$ telnet imap.net.net 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
1 LOGIN user password
1 OK Logged in.
2 CREATE toto
2 OK CREATE completed
3 LOGOUT
* BYE Logging out
3 OK Logout completed.
Connection closed by foreign host.
Passons à quelque chose de plus sérieux.
On sélectionne le répertoire INBOX, puis on liste les messages de 1 à la fin (1:*) et on récupère un message.
$ telnet imap.net.net imap
* OK Dovecot ready.
. LOGIN user password
. OK Logged in.
. SELECT toto
* FLAGS (Answered Flagged Deleted Seen Draft $MDNSent Junk $Label1 $Label2 $Label3 $Label4 $Label5)
* OK [PERMANENTFLAGS (Answered Flagged Deleted Seen Draft $MDNSent Junk $Label1 $Label2 $Label3 $Label4 $Label5 *)] Flags permitted.
* 278 EXISTS
* 0 RECENT
* OK [UNSEEN 248] First unseen.
* OK [UIDVALIDITY 1149259473] UIDs valid
* OK [UIDNEXT 6333] Predicted next UID
. OK [READ-WRITE] Select completed.
. STATUS INBOX (MESSAGES RECENT UNSEEN)
* STATUS "INBOX" (MESSAGES 278 RECENT 0 UIDNEXT 6333 UNSEEN 5)
. OK Status completed.
. FETCH 1:* RFC822.SIZE
* 1 FETCH (RFC822.SIZE 14036)
* 2 FETCH (RFC822.SIZE 11317)
[...]
. OK Fetch completed.
. FETCH 1:1 (RFC822)
* 1 FETCH (RFC822 {14036}
[...]
)
. OK Fetch completed.
. LOGOUT
* BYE Logging out
En résumé retenez :
. LOGIN user pass
. SELECT box
. FETCH 1:* (RFC822)
. FETCH 1:* (ENVELOPE)
. FETCH 1:1 (RFC822)
. LOGOUT
Il existe un grand nombre d'autres commandes et paramètres à FETCH, mais ceci devrait vous suffire pour du debug. Plus de détails sur la RFC : http://www.faqs.org/rfcs/rfc3501.html
Cet article est maintenant sur http://linux-attitude.fr/post/En-vrac-6
Niveau :
Résumé : cal ; ncal : fc
Quel jour est-on ?
Et quel jour était-on quand je suis né ?
Le sens ne vous plait pas ?
Préparer votre planning :
Lister les 50 dernières commandes (il dit qu'il ne voit pas le rapport) :
Envoyer un bip sur irc :
Savez-vous que dans un gnome-terminal, les mouvements de votre molette sont pris comme des évènements flèche vers le haut ? Essayez de lancer un less d'un fichier assez long dans un gnome-terminal et roulez !
Si vous constatez de nombreuses attaques sur votre serveur ssh et que cela vous gêne, essayez de changer le port sur lequel il écoute pour quelque chose comme 1022, vous n'en verrez plus jamais.
Niveau :
Résumé : cal ; ncal : fc
Quel jour est-on ?
$ cal
Et quel jour était-on quand je suis né ?
$ cal 01 2000
Le sens ne vous plait pas ?
$ ncal
Préparer votre planning :
$ ncal -wy
Lister les 50 dernières commandes (il dit qu'il ne voit pas le rapport) :
$ fc -l -50
Envoyer un bip sur irc :
ctrl-g coucou
Savez-vous que dans un gnome-terminal, les mouvements de votre molette sont pris comme des évènements flèche vers le haut ? Essayez de lancer un less d'un fichier assez long dans un gnome-terminal et roulez !
Si vous constatez de nombreuses attaques sur votre serveur ssh et que cela vous gêne, essayez de changer le port sur lequel il écoute pour quelque chose comme 1022, vous n'en verrez plus jamais.