TP de sécurité Unix et réseau
Printemps 2020
Résumé
Ce TP propose quelques tâches liées à l’administration sécurisée de machines Unix et de réseaux IP.
Avertissement : ce tp vous prépare à être éventuellement administrateur système et réseau dans votre vie professionnelle future. Il est clair que les techniques exposées ici sont à utiliser selon l’éthique de cette profession et non dans des buts illicites !
Pensez à apporter des papiers d’identité en règle avec photographie récente pour la partie 11.5.
Vous avez des suggestions, des idées pour améliorer ce TP ? Nous les attendons avec impatience !
Note pour les bidouilleurs indomptables : vous êtes priés de laisser les machines dans l’état où vous auriez aimé les trouver en arrivant ! S’il vous prend l’envie de changer la config de quoi que ce soit qui n’est pas indiqué dans le TP, veuillez rétablir la configuration initiale (même si c’est juste la couleur du fond d’écran). De même, il est interdit d’écrabouiller la configuration initiale des routeurs en mémoire flash (i.e. Interdiction de faire des write mem).
Le réseau que nous allons utiliser tout au long de ce TP a la structure indiquée en figure 1 qui permet de simuler un réseau d’entreprise avec un filtrage de certains paquets ip.
On commencera par vérifier le câblage du réseau au cas où les encadrants se seraient trompés.
La configuration a déjà été faite... enfin... normalement... Il est plus prudent de vérifier (commandes /sbin/ifconfig, ip address, /sbin/route -n, ip route). Ainsi, le cas échéant, pour configurer le réseau de chaque machine, passer sous root et lancer le script de configuration avec :
En principe, le routeur a été également configuré par ce script à partir du fichier configrouteur. Vous pouvez vérifier cela depuis l’ordinateur relié au routeur (donc ne marche pas sur tous les ordinateurs, notamment ceux du milieu...) avec l’outil gtkterm (ou minicom) : dans cette console d’administration vous pouvez taper des commandes pour le routeur (voir annexe A) :
Récupérez l’addresse IP de votre machine et des machines des voisins (commande /sbin/ifconfig, ip address). Vérifiez les routes (/sbin/route -n, ip route)
La connexion à Internet devrait marcher grâce à de la translation d’adresse réalisée par le routeur de la salle.
Avant que ce ne soit fait par un pirate, il est indispensable de tester si un utilisateur n’a pas un mot de passe trop facile par rapport à une attaque par dictionnaire.
Pour ce faire il convient à un administrateur de faire tourner régulièrement un outil du style crack, L0phtCrack ou John the Ripper et de bloquer les comptes qui ont été cassés. Ces comptes ne seront ré-activés qu’après changement de mot de passe sérieux.
L’intérêt de John the Ripper est qu’il peut être rajouté directement au système de pam (Pluggable Authentication Module, cf man 7 pam) du système (via pam_passwdqc) afin de refuser à un utilisateur la possibilité de mettre un mot de passe craquable facilement par n’importe qui. C’est aussi un logiciel portable, optimisé et pouvant casser des mots de passe Windows, etc.
Le paquetage john est déjà installé sur nos machines. Autrement, il faudrait :
Les utilisateurs locaux à la machine elle-même sont définis dans les fichiers /etc/passwd et /etc/shadow.
Notez que ce premier fichier est accessible en lecture à tout le monde, alors que le second (qui contient les mots de passe chiffrés) n’est accessible qu’à l’administrateur.
Regardez le contenu de ces fichiers (commande cat).
Cette manipulation n’est pas disponible dans notre salle réseau, mais est faisable dans une salle de TP banalisée de l’école où les PC utilisent encore le système NIS 2, quoi que de plus en plus on lui préfère le système LDAP 3 qui offre une sécurité plus grande (il faut d’abord s’authentifier auprès du serveur dans un canal TLS pour récupérer le hash du mot de passe).
Il serait possible (au conditionnel!) de s’entraîner avec comme source les mots de passes chiffrés de l’École qu’on pourrait récupérer sur une machine élève où on se connecterait par ssh (§ 6), et en faisant
car les nis sont utilisés pour distribuer des tables système de manière globale à l’École. Il est clair que dans la vraie vie il ne faudrait pas utiliser les nis mais utiliser un système qui rend la vie plus difficile aux pirates du dimanche...
Cependant, il est interdit d’essayer de casser ces mots de passe et encore plus d’utiliser ceux-ci. Néanmoins, il est très probable qu’il existe un certain nombre de mots de passe faibles dans la base de l’école…
Nous allons utiliser John sur un fichier de mots de passe d’exemple crée pour l’occasion à récupérer à l’adresse donné par l’encadrant du TP. Ce fichier d’exemple a été placé dans le répertoire /opt/TP/TPSec.
Jetez un petit coup d’œuil au contenu du fichier passwd.xyz qui vous est fourni (commande less, more, cat, etc.), et admirez les mots de passe stockés sous forme chiffrée. 4
Puis lancer avec la configuration de base 5
Réfléchir aux méthodes de communication positives et pédagogiques permettant d’éviter que de pareils cas se reproduisent. Évidemment cela n’empêche pas de faire tourner régulièrement un logiciel de craquage afin d’éviter ce genre d’étourderies. La bonne nouvelle est que ce logiciel possède un mode qui envoie un courriel à une personne dont le mot de passe est trouvé afin de la prévenir de la faiblesse trouvée.
Les plus curieux regarderont le fichier de configuration (less /etc/john/john.conf), et le fichier explicatif (zless /usr/share/doc/john/RULES.gz); ou, si vous venez de le compiler, john.ini en conjonction avec le fichier explicatif doc/RULES. Par défaut le système utilise les noms des utilisateurs comme source de mot de passe, puis des combinaisons du petit dictionnaire /usr/share/john/password.lst avant de se lancer dans une recherche par force brute.
Pour une mise en production dans la vraie vie il faudrait utiliser un dictionnaire de mots plus important spécialisé par exemple dans le français. On pourrait regarder comment en rajouter un…
L’exercice précédent a permis d’illustrer deux problèmes : (i) la «qualité» des mots de passe que l’on se choisit (est-ce qu’ils sont triviaux ou non à deviner avec les techniques actuelles), et (ii) comment sont stockés ces mots de passe sur le serveur.
À retenir :
L’exercice suivant va illustrer un autre problème avec les mots de passe : comment est-ce qu’ils sont échangés entre le client et le serveur.
Afin de se convaincre d’utiliser des protocoles sécurisés nous allons observer en quoi consistent les protocoles «de base» existant sur Internet depuis l’origine des temps.
Dans un premier temps on peut lancer un programme tcpdump ou wireshark10 et faire un telnet11, un ftp ou utiliser un navigateur www entre 2 machines. Que constatez-vous?
Suggestion d’un élève d’un tp précédent : demander à votre binôme de commander quelque chose sur son site Internet préféré avec sa carte bancaire et son code secret et regardez pendant ce temps-là ce qui passe sur le réseau pour vérifier le niveau de sécurité. ☺
On va automatiser le concept en utilisant le logiciel dsniff qui est capable de reconstruire le contenu d’une communication utilisant de nombreux protocoles.
Lancer sur le PC2 un
et essayer de vous connecter par exemple du PC3 vers le PC1 avec un protocole non sécurisé style telnet ou ftp (ne tapez pas votre vrai mot de passe ☺). Que constatez-vous à la fin de la connexion? Variante : à défaut d’intercepter le code de carte bancaire du binôme qui se commande une pizza (qui, espérons-le, transitera dans du https), vous pourrez au moins connaître la pizza qu’il s’est choisit : sur le PC2 lancez la commande driftnet et observez ce qu’elle affiche lorsque votre binôme surf sur le web depuis PC1 en HTTP (pas en HTTPS) .
Mettre à la poubelle les protocoles non sécurisés telnet, ftp, rsh,... et utiliser à la place ssh, scp, sftp,...
Imaginez les attaques faisables sur un réseau sans fil non sécurisé avec de l’espionnage de paquets ou des attaques par interception au milieu : sécurisez la configuration réseau et utilisez de toute manière des protocoles sécurisés.
Le courrier électronique a été conçu pour pour offrir le même niveau de service et d’usage que le courrier papier. Tout le monde peut envoyer et reçevoir des lettre à destination et de la part du monde entier. La poste ne contrôle pas si les utilisateurs sont autorisés ou non, ni si le contenu du courier est légitime ou non. Par exemple, n’importe qui peut passer dans votre rue et glisser dans votre boîte aux lettres un courrier similaire à celui de votre banque. Le système de courrier électronique a le même cahier des charges : assurer l’achminement de messages, c’est tout...
Le protocole SMTP (Simple Mail Tranfert Protocol) est utilisé pour l’envoi d’email entre un client et un serveur et pour l’échange d’email entre deux serveurs. Pour consulter sa boîte mail, on utilise généralement le protocole IMAP (Internet Message Access Protocol).
Le contenu d’un email comporte deux parties : les entêtes et le corps. Ces deux parties sont séparées par une ligne vierge. Comme sur un papier à entête, l’entête du courrier électronique contient le sujet du email, son expéditeur, son destinataire, une date, et d’autres informations comme la liste des serveurs par lesquels le email est passé, etc.
Ci-dessous, un dialogue typique entre un client email et un serveur SMTP. L’échange entre le client et le serveur se fait de manière textuelle. Un être humain peut ainsi dialoguer avec un serveur sans logiciel client spécifique (même si c’est tout de même plus confortable). Notons que l’on a à faire ici à un serveur SMTP un peu verbeux, les implémentations plus modernes sont moins avenantes pour un être humain.
Dans cet échange vous observerez deux grandes partie : tout d’abord des informations portées par l’enveloppe du message, puis après le mot-clef DATA le courrier lui-même (et donc "à l’intérieur" de l’enveloppe), avec son entête et le corps du message.
Le récepteur de l’email (celui dont l’adresse a été donné via la commande RCPT TO: sur l’enveloppe) recevra le texte qui a été passé via la commande DATA. L’adresse passée à la commande MAIL FROM: n’est utilisé qu’en cas d’erreur lors de la livraison du message (un email d’erreur sera envoyé à cette adresse). L’adresse d’expédition contenue dans les entêtes de l’email (From:) peut être complètement différente et le serveur d’email ne fait, à priori, aucune vérification dessus. Or c’est cette adresse, et non celle donnée à la commande MAIL FROM: qui sera affichée par le logiciel de courrier du récepteur. Il est donc assez facile de tromper des utilisateurs en jouant avec cette adresse et de créer un mail qui, pour le récepteur, semble provenir de bill.gates@microsoft.com…
De la même manière, on a deux champs pour indiquer l’adresse du destinataire... L’adresse passée à la commande RCPT TO: est la boite email qui recevra le message. Par contre, le champ To: est l’adresse du destinataire qui sera affichée dans le lecteur d’email...
Considérons un utilisateur ordinaire, qui utilise un logiciel de messagerie électronique (MUA - Mail User Agent) qu’il a pris soin de configurer avec les indications techniques fournies par l’établissement qui lui a attribué une adresse électronique (typiquement l’adresse du serveur IMAP pour lire les emails, l’adresse du serveur SMTP pour envoyer des emails (ce n’est pas forcément le même), etc.)
Pour envoyer un email, le logiciel en question (MUA) se connecte donc au serveur SMTP, et comme dans l’exemple précédent, utilise les commandes EHLO, RCPT TO:, MAIL FROM:, DATA, etc. Le serveur SMTP va stocker tout ça dans sa file d’attente de traitement des emails en partance, puis le moment venu va dépiler cette file d’attente pour traiter les email. Il va alors faire attention à l’adresse du destinataire indiquée dans le RCPT TO:. La chaîne de caractère après le @ est le domaine du destinataire. Notre serveur SMTP a besoin de connaître le nom du serveur SMTP qui gère ce domaine. Pour la connaître il fait une requête DNS de type MX (Mail eXchange).
Par exemple, essayez la commande host -t MX imt-atlantique.net
Ensuite, notre serveur SMTP se connecte au serveur SMTP du destinataire, et tenter de lui relayer le courrier en question. Le serveur destinataire va (éventuellement) l’accepter et le délivrer dans la boîte email de l’utilisateur destinataire.
À priori il n’y a pas besoin de passer par d’autre serveur entre l’expéditeur (From) et le destinataire (To). Par contre, un domaine peut avoir plusieurs serveurs SMTP en redondance, ou même avoir plusieurs équipements en série par lesquels transitent les emails (par exemple pour détecter les spams ou fichiers attachés douteux). Un domaine peut éventuellement confier la gestion de son email a un prestataire triers. Cependant, tout ceci est transparent pour l’expéditeur qui se contente d’utiliser l’adresse renvoyée par la requête DNS.
À cause d’un certain nombre d’abus sur Internet, les serveurs d’emails sont de plus en plus protégés. D’autant plus que, contrairement au courrier postal, c’est quasiment gratuit.
On va par exemple essayer de se protéger contre le relai ouvert : typiquement, si vous mettez en place un serveur d’emails c’est pour vos utilisateurs. Par conséquent, vos utilisateurs (c.à.d. le ou les domaines que vous gérez) sont soit expéditeur soit destinataires des emails qui passent par votre serveur. On peut ainsi détecter et filtrer les tentatives de relay : quelqu’un de l’extérieur qui adresse des emails à l’extérieur en passant par vous... ça n’a à-priori rien à faire sur votre serveur, c’est filtré et cela lève des alarmes auprès des administrateurs du serveur. Tout serveur de mail qui relaierait des mails en provenance de tout l’Internet serait rapidement exploité par des spammeurs et se retrouverait très rapidement inscrit dans les listes noires anti-spam. (Ces listes noires sont parfois employées comme mesure de protection, avec beaucoup d’effets de bord négatifs, mais comme il y a un certain business...) Cette protection contre le relais est extrêmement importante (mais largement insuffisante pour luter contre les spams ou le fishing).
On rajoute souvent une couche de chiffrement TLS par dessus les protocoles réseau SMTP ou IMAP : cela permet au client d’authentifier le serveur (et rârement la réciproque), et d’éviter les écoutes passives.
On peut également configurer les firewalls de façon à ce que les postes de l’établissement ne puissent accéder qu’au serveur email de l’établissement et pas à des serveurs externes. Ceci évite qu’une machine de l’établissment contaminée par un virus ne se rendre coupable de spam et arrose le reste du monde... Car l’établissement porte alors la responsabilité d’une telle attaque.
D’autres vérifications sont également couramment pratiquées par les serveurs de mail : vérification de l’existence du domaine de l’expéditeur, etc. Enfin des techniques plus évoluées sont en cours de discussion/standardisation/déploiement tels que SPF 12 (Sender Policy Framework), DKIM 13 (DomainKeys Identified Mail) qui connaît un certain succès, etc.
On pourrait expérimenter le fonctionnement de SMTP pour comprendre comment procèdent les spammeurs. Notez que la charte d’usage du réseau à IMT Atlantique stipule que c’est interdit. Notez également que la loi dite LOPSI2, article 226-4-1, punit de 1 an d’emprisonnement et de 15000€ d’amende le délit d’usurpation d’identité sur Internet (c’est du pénal...).
Par conséquent, si vous testez l’envoie de faux courriel, faites-le sur votre propre adresse électronique, soit sur celle d’une personne pleinement consentante... 14
Constatez que le protocole SMTP est très simple comme l’indique le s du nom.
Il est donc très simple d’envoyer du courrier électronique avec un simple :
Est-ce gênant? Oui et non : le courrier standard n’offre pas plus de garanties et on peut faire de fausses lettres ou des lettres anonymes encore plus facilement en postant discrètement dans une boîte aux lettres.
Il existe des protocoles d’échange plus sécurisés entre les facteurs et on peut de surcroît envoyer des lettres chiffrées au niveau du contenu indépendamment de l’enveloppe et de son transport (voir § 11). Idée d’expérimentation : Pour ces essais, on vous propose d’utiliser un serveur SMTP spécifique : 10.29.90.3. Il s’agit d’un serveur interne, qui ne procède pas à beaucoup de filtrage; il est donc plus “pédagogique”. Ce n’est pas un raison pour ne pas l’utiliser de manière sérieuse et responsable!
Tout d’abord, tentez de faire un courrier simple. Astuce : préparez vos commandes dans un éditeur texte, et faites des copier-coller dans le telnet. À la réception, regardez attentivement les entêtes.
Ensuite, introduisez des variations entre l’enveloppe et l’entête. Soyez attentif au résultat sur le message reçu. Note : Lorsque vous recevez un mail (un faux ou un prétendu vrai), prenez la peine de regarder les entêtes en détail! 16
Ne pas croire tous les courriels que vous recevez, même de personnes connues...
La section précédente a montré clairement les limites des protocoles simples mais non sécurisés. Une première limitation va être d’en restreindre l’usage depuis l’extérieur par exemple pour 2 raisons :
Le filtrage concernera sur la figure 1 la machine PC3.
B Attention : certains administrateurs systèmes considèrent que le simple fait qu’on regarde quels sont les ports ouverts constitue une violation de leur vie privée...
Parmi les options utiles, nmap -O permet de deviner quel est le type d’une machine, -sS permet de faire un test de ports assez rapide, -P0 permet de faire un test même si la machine ne répond pas au ping.
Essayer cet outil pour tester les ports ip ouverts sur diverses machines. Comparer par exemple www.enst-bretagne.fr, www.telecom-bretagne.eu, www.emn.fr, www.imt-atlantique.fr, www.microsoft.com.
On peut analyser des réseaux entiers comme enstb.org/25 par exemple.
Il existe des interfaces graphiques (xnmap, nmapfe, zenmap) pour les amateurs de cliquodrome.
Éventuellement lancer un outil d’espionnage style tcpdump ou wireshark en même temps pour comprendre comment nmap peut fonctionner aussi rapidement malgré les temporisations protocolaires (tcp,...). En particulier on peut comprendre la différence entre les aspects closed et filtered. Dans le dernier cas ce n’est pas le protocole style tcp qui répond mais le protocole icmp annonçant l’interdiction. Ce sera pratique dans la suite pour mettre au point les filtrages.
Cette partie nécessite un routeur CISCO ou un logiciel à syntaxe compatible tel que Zebra ou Quagga.
Voir la documentation du constructeur, le cours de sécurité et les tps précédents. À défaut, reportez-vous aux l’annexes A et B.
Pensez à l’utilisation de
17 pour la complétion automatique et ? 18 pour l’affichage de l’aide contextuelle.
On se connecte sur le CISCO par la liaison série en utilisant le logiciel gtkterm (ou minicom).
Tapez ↩ 19 puis identifiez-vous. (Le mot de passe du routeur vous sera donné en séance.)
Ensuite, pour passer en mode d’administration sur le routeur :
Pour afficher la configuration actuelle :
Pour entrer dans le mode de configuration interactive :
Pour configurer chaque ligne de l’access-list 100 par exemple :
Pour supprimer l’access-list 100 :
Pour entrer dans la configuration d’une interface :
B Une fois rajoutée une access-list à une interface, tout le trafic est bloqué tant qu’on ne l’a pas explicitement autorisé avec des règles de filtrage! Note : Il est également possible de rentrer dans l’édition d’une access-liste avec ip extended access-list 100. Cela permet d’ajouter des lignes, voir d’en supprimer. Il est également possible de réordonnancer la liste avec ip extended resequence 100 ... (Je vous laisse chercher dans la doc Cisco.) Cependant, pour la suite des manipulations, il peut être plus simple de préparer ses access-listes dans un fichier texte, puis de faire un copier-coller à la souris lorsque l’on pense être ok...
Proposez un filtrage qui interdit les connexions telnet (port TCP 23), et autorise tout le reste.
En fonction du temps disponible, réalisez les filtrages des questions suivantes.
Pour s’inspirer sur les noms des services et leur numéros, regarder dans /etc/services ou bien comme d’habitude chercher dans le www.
Dans la suite on fera des expérimentations avec nmap pour vérifier depuis l’intérieur ou l’extérieur ce qu’on peut faire réellement.
Remarquez au passage l’intérêt d’avoir un compte root à l’extérieur ne serait-ce qu’un accès par modem à un fournisseur d’accès Internet pour faire de l’audit du réseau avec des outils comme nmap, etc.
Dans cette approche on n’interdit que le trafic potentiellement dangereux ou non sécurisé. C’est bien pour les utilisateurs mais dangereux car le moindre trou de sécurité à la mode a le plus de chances d’être exploité.
On commence par tout interdire.
Seuls les services indispensables seront ouverts.
Les manipulations précédentes étaient sur les routeurs. Mais on peut aussi mettre un firewall sur une machine terminale. Pour linux, cela se passe avec iptables (et ip6tables).
En fonction du temps disponible...
Refaire une manipulation similaire sur les postes terminaux avec iptables (voir annexe C).
Très pratiques les scripts iptables-save (affiche/sauve la configuration courante) et iptables-restore (recharge toute une configuration iptables).
Notez que depuis quelques temps déjà la communauté Linux migre progressivement de iptables vers nftables, considérées plus efficace et plus souple d’utilisation. 23. stateless vs. stateful firewall Jusqu’à maintenant on a réfléchi au niveau des paquets. Le routeur prend sa décision seulement en considérant le paquet; il ne garde pas d’information en mémoire concernant les paquets précédents : c’est un firewall stateless. Par contre, on peut vouloir des règles plus fines : p.ex. «Interdire tous les paquets entrants, sauf s’ils sont en réponse à une requête sortante.» Pour faire cela, il faut que le firewall ait l’intelligence suffisante pour comprendre qu’un paquet est une requête, et qu’un autre paquet est une réponse, et que telle réponse est liée à telle requête précédente. Il faut donc qu’il fasse du suivi de connexion et qu’il garde des informations en mémoire : c’est un firewall stateful. Dans le vocabulaire Linux, on parle de conntrack. L’annexe C montre cela. Dans le monde cisco il faudrait passer par des class-map type inspect ....
Bon, c’est bien gentil tout ça, mais on n’a configuré notre firewall que pour le protocol IPv4 (en principe obsolète depuis quelques dixaines d’années)... mais il y en a d’autre des protocoles de routage!
Refaites tout pour IPv6!
(Non, je rigole, pas pour le TP. Mais dans la vraie vie...)
On va utiliser OpenSSH en privilégiant le protocole version 2 plus sécurisé. On supprimera le protocole version 1 du fichier de configuration globale (si ce n’est déjà fait) car c’est un protocole qui a intrinsèquement de nombreuses failles connues.
La commande ssh permet de se connecter à distance ou de lancer des commandes à distance.
La commande scp permet de copier des fichiers à distance. La commande sftp fournit une interface ftp pour les nostalgiques.
Se connecter via ssh sur une machine distante d’un collègue.
Remarquez qu’à la première utilisation ssh dit qu’il ne connaît pas la clé publique du sshd de la machine distante et l’affiche.
C’est typiquement le problème de l’authentification par mécanisme public et l’œuf ou la poule : comment être sûr que le sshd qu’on veut atteindre est bien celui auquel on pense et qu’on n’est pas redirigé par un moyen quelconque vers un sshd pirate qui espionnera tout ce que vous faites?
C’est justement les clés du serveur sshd de la machine distante qui permet de vérifier ça. Si vous vous êtes déjà connecté sur la machine distante via ssh, le fichier ~/.ssh/known_hosts contient déjà un hash (fingerprint) de la clé publique du serveur ssh de cette machine, et ssh reconnaissant une machine amie ne vous posera pas la question précédente. Si votre connexion est détournée, ssh refusera la connexion car la clé renvoyée par le sshd distant ne sera probablement pas celle de ~/.ssh/known_hosts. 24 25
Notez qu’un serveur sshd, s’il est configuré pour fonctionner sur les deux versions du protocole ssh (la 1 et la 2), il aura naturellement deux clés d’identification différentes, voir trois ou quatre (ECDSA ED25519 RSA DSA). Si votre client ssh en connaît une, il ne connaît pas nécessairement les autres. Une attaque man in the middle ssh consistait justement à jouer là-dessus : le client naïf (si lui aussi accepte les deux versions du protocole) croit que c’est un serveur qu’il ne connaît pas encore, au lieu de se rendre compte que l’identité de ce qu’il croit être son serveur a été détournée. Pour cette raison, il est préférable de configurer à la fois les serveurs et les clients pour n’utiliser que la version 2 du protocole ssh.
Mais revenons au problème de la question initiale de «la première fois» : comment être sûr que c’est la bonne clé qui est envoyée et donc que c’est bien la même machine? Plusieurs solutions :
D’une manière générale, on appelle ce type de mécanisme TOFU (Trust On First Use). Si on préfère une vérification plus sérieuse, on peut publier les clés SSH de son serveur dans le DNS utilisant des enregistrements de type SSHFP (cf. RFC4255)
Essayer d’espionner les paquets qui passent avec tcpdump, wireshark ou snoop (sous Solaris). Comparer à une connexion telnet ou rlogin.
À partir d’ici oublier que telnet, rlogin ou ftp aient pu exister ☺ et ne les utilisez plus que sous la menace.
Avant de commencer, regardez bien sous quel utilisateur vous travaillez (e.g. root, user, ou autre?). Tapez la commande id. Et utilisez de préférence le compte user.
Se créer un joli couple de {clé publique, clé secrète} protocole version 2 avec :
que l’on chiffrera éventuellement avec la belle phrase secrète demandée. Cela crée deux fichiers : ~/.ssh/id_rsa.pub avec la clef publique et ~/.ssh/id_rsa avec la clef privée. Observez au passage les permissions unix de ces fichiers. Note : ce sont les noms de fichiers par défaut, et id_rsa est le nom de votre identité par défaut. Si vous choisissez un autre nom de fichier ce sera le nom d’une autre identité. (Voyez l’option -i des diverses commandes ssh.)
Afin de permettre les connexions ssh depuis une machine A vers une machine B on mettra le contenu du ~/.ssh/id_rsa.pub de A dans le fichier ~/.ssh/authorized_keys de B. On peut le faire «à la main» ou utiliser la commande ssh-copy-id (lisez le man). Ainsi les connexions des utilisateurs possédant le ~/.ssh/id_rsa correspondant pourront se connecter à B.
Pour que sshd soit content dans sa grande paranoïa altruiste et vous laisse vous connecter, vérifiez les permissions sur le fichier ~/.ssh/authorized_keys : typiquement, seul l’utilisateur doit disposer des droits de lecture-écriture. (Si ce n’est pas le cas, faire un chmod go-rw ~/.ssh/authorized_keys)
Vérifiez que cela fonctionne depuis A avec un
Si on fait une utilisation intense du réseau (connexion à plein de machines en continu, mises à jour avec des serveurs cvs via ssh, utilisation d’ordinateurs parallèles avec du mpi sur ssh, etc.), on est amené à taper sans arrêt sa (ses) phrase(s) secrète(s), ce qui va rebuter n’importe quel(le) informaticien(ne) 27. C’est pour cela qu’a été créé le serveur ssh-agent gardien suprême des clés qui, une fois lancé et instruit des clés, va répondre à votre place.
Les systèmes de fenêtrage modernes démarrent généralement automatiquement un processus ssh-agent lors de la connexion d’un utilisateur, ou un équivalent quelconque (p.ex. gnome-keyring-daemon). Vérifier si tel est le cas.
Si ce n’est pas le cas lancez la commande suivante :
Cette commande a pour effet de lancer ssh-agent d’une part, et d’autre part d’initialiser des variables du shell qui donneront aux futurs ssh le moyen de se connecter à l’agent d’authentification. Pour bien faire on pourrait arranger son environnement de travail pour que ssh-agent soit lancé lors de votre connexion à votre ordinateur et que toutes les fenêtres en héritent. Les agents proposés par les environements graphiques (genre Gnome) font cela : on les reconnaît à leur fenêtre graphiques envahissantes et leurs multiples options à chocher pour le confort de l’utilisateur (par exemple la possibilité de stocker les secrets de l’utilisateur dans une base chiffrée par le mot de passe que l’utilisateur fournit à l’ouverture de sa session, et que ce daemon garde en mémoire...). Si vous faites face à un agent Gnome qui se propose de garder vos secrets, éviter de cocher "oui" partout à moins de savoir ce que vous faites.
On utilise ensuite ssh-add pour rajouter des clés secrètes dans l’agent. Sans paramètre supplémentaire c’est la clé rsa qui sera rajoutée par défaut avec :
Essayer de vous connecter sans mot de passe depuis A vers B avec un
Demander avec ssh-add -L la liste des clés chargées dans votre agent d’authentification.
L’intérêt du système est donc de faire une centralisation de l’authentification pour ne plus avoir à taper son mot de passe ou sa phrase secrète à chaque fois qu’on veut utiliser ssh, scp ou sftp.
Il y a un mode de configuration de ssh/sshd permettant aussi de faire suivre à travers la connexion l’accès au ssh-agent (c’est-à-dire de faire un proxy-ssh-agent). L’intérêt est qu’on peut sauter transitivement de machine en machine avec des ssh sans avoir à s’authentifier à nouveau ou lancer de nouveaux ssh-agent. Le danger est que si vous vous connectez sur une machine piratée, le pirate aura accès via le proxy-ssh-agent de la machine piratée qu’il contrôle à la clé secrète tournant dans votre ssh-agent et donc pourra utiliser vos droits pour se connecter à vos machines... Donc réfléchir sur ce compromis luxe/sécurité en fonction de vos usages réels.
On se propose d’utiliser ici ssh pour faire des connexions www sécurisées et d’autre part d’encapsuler le protocole peu fiable telnet en entrée. Pour ce faire on va utiliser le mécanisme de redirection de port tcp de ssh, à savoir user des options -R et -L lors d’une connexion à distance. En fait avec les versions récentes de ssh, pour des raisons de sécurité, les redirections de port ne sont autorisées que venant depuis les machines locales faisant tourner le client ou le serveur ssh. Il existe néanmoins l’option -g autorisant côté client ssh des connexions non locales. Pour l’autoriser côté serveur, c’est plus compliqué : il faut que la configuration du serveur l’autorise (option GatewayPorts), et que dans la commande de création du tunnel on précise que l’on veut que le serveur se bind sur l’adresse joker * et non pas uniquement l’adresse loopback... ce qui est loin d’être gagné avec la config par défaut...
On va supposer ici que vous faites du télétravail et que le PC3 est chez vous à la maison (cf. figure 2). On veut pouvoir accéder directement aux serveurs www internes de l’entreprise accessibles depuis la machine interne PC1. (C’est-à-dire que l’on suppose que l’entreprise refuse toutes les connexions entrantes, excepté sur le port ssh). On a aussi envie, si vous avez laissé allumé chez vous votre PC3, de se connecter depuis son bureau avec PC1 sur votre PC3 qui est lui-même hyper-protégé par le firewall de la maison qui ne laisse rien entrer, pas même le port ssh. (Note : on fera semblant qu’il y a un tel firewall... pas la peine d’en configurer un pour PC3...)
Essayer par exemple de faire qu’une connexion ssh (en mode verbeux) du PC3 vers le PC1 vous permette :
Éventuellement faire un schéma pour comprendre les encapsulations à réaliser ☺. Éviter de vous marcher sur les pieds entre groupe de TP, c’est déjà assez compliqué comme ça...
Configurer son navigateur www sur PC3 pour utiliser le mandataire (proxy en anglais) www distant via ssh.
Se connecter avec ssh depuis le PC1 vers le PC3 en remontant la connexion existante. Le truc qui aide : regarder l’option -p de ssh...
On vient de voir des tunnels auxquels on a accroché des sockets TCP client/serveur à chaque bout. Mais on peut y accrocher bien d’autre chose. Par exemple, un proxy SOCKS5 (option -D, un mécanisme de proxy avec des redirections "dynamiques" de port). Mais également des sockets Unix (voir les subtilités des options -L et -R). On peut y accrocher des interfaces réseau virtuelles, et donc faire un VPN (option -w). Ou encore, des agents X11 pour des applications graphiques à distance (voir ci-après).
Eh bien c’est possible! Si on avait le temps on pourrait voir par exemple sur http://www.hsc.fr/ressources/breves/remote_windows_ssh.html, http://www.putty.org/, ou https://resel.fr/wiki/tutoriaux/putty-ssh-sur-windows.
X11 est un protocole permettant de faire des affichages graphiques à distance ce qui est extrêmement pratique et est ce qui est typiquement utilisé dans le monde Unix au niveau du fenêtrage.
Par défaut les applications (clientes X11) essayent de se connecter à l’écran de la machine locale (le serveur X11) mais si on définit une variable d’environnement DISPLAY ou qu’on joue avec une option d’exécution on peut rediriger l’endroit d’affichage vers l’écran dont on indique le nom, ce qui est extrêmement puissant :
Le format d’un nom d’écran X11 est du style
Dans une fenêtre afficher la valeur par défaut du nom d’écran utilisé avec par exemple :
Se connecter sur une machine distante avec ssh -X (ou ssh -Y) et lancer une application X11 (par exemple xclock ou xeyes) sans rien toucher à la variable d’environnement DISPLAY. Miracle!
Regarder ce qui passe entre les deux machines. Mais par où passe donc le protocole X11?
Afficher la valeur de $DISPLAY dans la fenêtre ssh et dans la fenêtre de votre machine locale. Essayer de comprendre le principe utilisé.
Nous allons maintenant faire des connexions graphiques sans passer par des tunnels ssh, mais en utilisant le mécanisme historique de X11 : les commandes graphiques X11 entre une application et le serveur graphique passent naturellement sur des sockets TCP.
En fait, pour des raisons de sécurité, le protocole TCP est désactivé par défaut sur la plupart des serveurs X11. Seules les connexions locales par socket Unix sont possibles.
Pour le réactiver, en tant que root, modifiez le fichier /etc/lightdm/lightdm.conf :
Comme précédemment, l’idée est de se connecter sur machine-distante , d’y exécuter une commande graphique (p.ex. xclock ou xeyes), et de faire en sorte qu’elle s’affiche sur machine-locale . (C.à.d. le même scénario ssh -X que précédemment, mais sans ce tunnel ssh -X.)
Toutes les commandes qui suivent sont à utiliser de préférence sous le compte user de la machine locale, car c’est cet utilisateur qui "possède" la session graphique en cours.
Sur la machine distante, dans la fenêtre ssh ou autre (rlogin, telnet,...), supposons qu’on n’utilise pas le mode mandataire X11 de ssh, faisons un
Expliquer comment cela marche et pourquoi. 29 Regarder éventuellement ce qui passe sur le réseau.
Quelle est la différence avec un :
Bon, on supprime ce trou de sécurité sur sa machine en revenant en arrière avec
Vous voyez que xhost est un contrôle d’accès par liste blanche d’adresses IP, et pas d’utilisateurs...
Une sécurisation intermédiaire si on n’a pas ssh sous le coude serait d’utiliser l’authentification par secret partagé au moyen de xauth. On peut obtenir la liste des secrets 30 avec
et en rajouter par exemple sur la machine distance avec
Repérez une ligne du type :
linuxX/unix:0 MIT-MAGIC-COOKIE-1 b6edafcc...857eda7
Connectez-vous sur une machine distante et faites :
xauth add 192.168.aaa.bbb:0 MIT-MAGIC-COOKIE-1 b6edafcc...857eda7
I.e. un copier-collé de la ligne précédente, en prenant soin de remplacer linuxX par son adresse IP (genre 192.168.aaa.bbb), et de supprimer la mention /unix puisque l’on va se connecter non pas via une socket unix mais via une socket TCP.
Il ne reste plus qu’à positionner la variable d’environnement DISPLAY=192.168.aaa.bbb:0, puis à exécuter une commande graphique. Et voila!
Note : Pour cette expérience on suppose bien évidemment que l’on avait préalablement désactivé le contrôle d’accès façon xhost avec un xhost -
Philosopher sur le sens de la vie... Réfléchir à la facilité qu’apporte ssh et X11 : non seulement c’est simple mais en plus c’est sécurisé!
Les droits Unix standards sur les fichiers (le fameux UGO) sont un peu limités. On peut obtenir une gestion beaucoup plus souple et fine de ces droits grâce aux ACL (Access Control List, voir annexe D). Les ACL sont activées sur les machines de l’école (au moins sur le disque local). Testez les ACL sur une machine de l’école (regardez la documentation des commandes getfacl et setfacl). Essayez de partager un document avec votre binôme (et uniquement celui-ci) sans créer de groupe particulier, etc.
Se connecter à un site sécurisé par SSL/TLS avec votre navigateur WWW et analyser le certificat utilisé par le site. Comparer par exemple la connexion à http://www.google.fr/ avec https://www.google.fr/, ou encore http://www.imt-atlantique.fr/ vs. https://www.imt-atlantique.fr/. (Note : la différence n’est pas particulièrement visuelle pour l’internaute moyen, ce que l’on peut considérer comme fort regrettable pour sa sécurité...) Regardez également les serveurs de l’école (zimbra bscw, etc.). Quelle est la différence? Enquêtez…
Regarder la liste des certificats de confiance installés avec le navigateur (double-clic sur le cadenas ou dans Préférences / Avancé / Certificats, ou dans le coin gauche de la barre d’url, ou ...). À quelles autorités faites-vous confiance, combien, et pourquoi? Où sont stockés vos certificats racine?
Que fait la commande : openssl version -d?
Que fait la commande suivante?
for i in * ; do openssl x509 -in $i -noout -issuer; done 2>/dev/null| sort -u| wc -l
Regarder les messages de log avec les commandes adéquates. (Fichers dans /var/log/.)
Considérons pas exemple auth.log (il y en a pleins d’autres très intéressants!). Que trouve-t-on dedans?
Nous allons nous familiariser ici avec le chiffrement de documents et les concepts associés avec le logiciel gpg (GNU Privacy Guard http://www.gnupg.org), l’implémentation GNU du RFC 4880, alias PGP (Pretty Good Privacy).
Les réfractaires à la ligne de commande peuvent essayer l’interface graphique seahorse31 (non installé sur nos machines, ha ha ha!).
La sécurité d’un système de signature à la pgp repose sur la notion distribuée de chaîne de confiance, où des individus font confiance à d’autres individus. La robustesse est basée sur la confiance en chaque maillon de la chaîne. Si un maillon casse, la chaîne aussi. C’est donc très différent des systèmes de certificats où la confiance est concentrée sur l’autorité de certification.
Regardez http://pgp.cs.uu.nl/ pour naviguer dans cette chaîne de certification. Par exemple regarder le dessin des chemins de signature de la clé 135EA668 à la clé 3D2A57E7 et dans l’autre sens. Regardez aussi les statistiques fournies par cet outil. Très instructif!
Les clés publiques sont stockées sur des serveurs de clés mondiaux tel que http://pgp.mit.edu et les outils tels que gpg y récupèrent ces clés.
Le mode le plus simple de fonctionnement de gpg est de pouvoir chiffrer un document pour soi avec un algorithme symétrique utilisant une phrase secrète et de pouvoir relire le document avec cette même phrase.
Chiffrer un document avec
Passons aux choses plus compliquées...
Sur http://www.gnupg.org/gph/fr/manual.html on peut trouver une introduction plus étendue qu’ici.
Créer son couple de clé publique-clé privée avec
en choisissant par exemple les options par défaut. L’adresse de courrier et le nom que vous y mettez ont de l’importance car ils seront utilisés de manière officielle lors des signatures électroniques pendant un temps certain, en particulier après votre sortie de l’école. La phrase secrète a été utilisée pour chiffrer le fichier contenant votre clé privée. Ainsi même si quelqu’un lit vos fichiers il ne la récupèrera pas.
Cela a généré des choses dans ~/.gnupg.
Ce répertoire sera à conserver avec vous toute votre vie pour conserver votre clé secrète!
Tant qu’à faire on va créer un certificat de révocation qui servira en cas de vol ou de perte de votre clé secrète à annuler les copies de votre clé publique qui seront disséminées sur Internet.
Vous pouvez afficher son contenu avec
... avec l’empreinte numérique de chaque clé de votre trousseau
Envoyez votre clé publique à un(e) collègue pour qu’il puisse ensuite vous envoyer un couriel chiffré. Pour se faire il faut exporter une de vos clés publiques, par exemple celle avec votre nom , avec
Récupérez la clé publique d’un(e) collègue et intégrez-la à votre porte-clé avec
Mais le plus simple est d’envoyer sa clé publique vers les serveurs de clés style hkp://keys.gnupg.net, hkp://pgp.mit.edu, hkp://keyring.debian.org, hkp://keyserver.ubuntu.com, etc. Ainsi, quelqu’un qui en a besoin pour vous envoyer du courrier chiffré ou vérifier votre signature n’a qu’à l’y récupérer. Ces différents serveurs se synchronises entre eux de temps en temps (ou pas). Aussi, il peut être préférable d’indiquer à vos amis sur quel(s) serveur(s) ils peuvent récupérer votre clé.
Pour l’envoyer, il suffit de faire un
À partir d’ici votre système de chiffrement est correctement configuré et on peut aussi utiliser des outils de courrier classique, par exemple depuis les icônes du système (ThunderBird, Evolution, Kmail) afin de se faciliter la tâche.
Il faut déjà récupérer la clé publique du destinataire. Le plus simple est de la récupérer depuis un serveur de clé avec :
Créez un document chiffré pour un(e) collègue qui vous aura envoyé sa clé publique au préalable ou dont vous aurez récupéré la clé comme précédemment, avec
Déchiffrez un document qui vous est destiné avec
Créez une signature à un document avec :
Vérifier la signature d’un courriel non chiffré :
La sécurité peut aussi être l’occasion de soirées festives, les key-signing parties ! Enfin une soirée chébran! ☺
Pour éviter de se marcher sur les pieds avec des ordinateurs portables ou non, chacun va imprimer l’empreinte de sa clé publique et son nom sur un papier et la distribuer aux hôtes de la fête. C’est une bonne idée d’imprimer simplement ses cartes de visite avec dessus aussi son empreinte de clé Openpgp.
On suppose que vous avez déjà envoyé votre clé aux serveurs de clés selon § 11.3.
À chaque fois qu’on reçoit une carte avec une empreinte, on vérifie soigneusement l’identité de la personne avec l’aide des papiers d’identité de celle-ci. L’idée est qu’on évite ainsi qu’un intrus ne distribue une fausse clé publique pour quelqu’un autre dont il voudra par la suite usurper l’identité.
Ensuite, à tête reposée, on va signer chaque clé publique reçue avec sa propre clé privée. Pour ce faire, on commence par chercher les identifiants de chacun sur un serveur de clés et ensuite faire une récupération massive avec :
Ensuite vous allez signer les clés une par une, en vérifiant bien que l’empreinte de la clé publique que vous allez signer correspond bien à celle que vous avez reçu de la main à la main, avec :
Une fois toutes les clés signées, il faut les renvoyer sur les serveurs de clé avec :
Pour d’autres idées, http://www.cryptnet.net/fdp/crypto/gpg-party.html est une bonne source.
Vous connaissez maintenant les concepts d’usage d’un système de chiffrement et de signature de fichiers!
Compliqué? Bah, il existe probablement sur le site de GPG un client s’adaptant à votre système de gestion de courrier favori.
Il existe une interface intégrant pgp dans Emacs pour simplifier la tâche, dans ThunderBird, Kmail, Evolution,... et aussi des systèmes pgp sous Windows avec fenêtres et tout.
N’oubliez pas de garder précieusement votre répertoire .gnupg.
Ce travail utilise des routeurs Cisco 1841. Chaque routeur est équipé d’un certain nombre de ports d’entrées-sorties. Évoquons rapidement le port console pour l’administrer via un terminal RS232 33, et le port aux pour brancher des équipements auxiliaires. Intéressons nous plus spécifiquement aux ports réseau. Les routeurs disposent de deux ports Ethernet numérotés 0/0 et 0/1. Ils sont équipés également de deux slots pour insérer des cartes d’extension. Ces slots portent les numéros 0 et 1. Dans chaque routeur, une carte d’extension est installée sur le slot 0 et comporte deux ports pour la communication via une ligne série. Ils sont numérotés 0/0/0 et 0/0/1.
La documentation complète de configuration de ces routeurs est disponible sur Internet [?]. Dans le cadre de ce travail, nous nous limitons à quelques commandes qui sont décrites dans ce chapitre. Pour une description plus complète des commandes, voir [?].
Les routeurs fonctionnent dans trois modes différents : les modes exec, exec privilégié et global configuration. Le mode exec permet d’exécuter quelques commandes de base, mais sans modifier la configuration du routeur. Le mode exec privilégié permet de modifier certains paramètres du routeur et d’accéder à des commandes complémentaires. Le mode global configuration permet lui de modifier complètement la configuration du routeur. On peut voir le mode exec comme étant destiné à l’utilisateur normal tandis que les modes exec privilégié et global configuration sont destinés au gestionnaire du routeur.
Ce mode permet essentiellement de visualiser l’état des routeurs et d’exécuter quelques commandes simples. C’est le mode par défaut dans lequel on se trouve après s’être connecté sur le routeur. À tout instant, le routeur peut indiquer les commandes utilisables en réponse à la touche ?. Cette touche peut également être utilisée pour obtenir de l’aide sur les paramètres d’une commande.
La liste ci-dessus reprend les commandes disponibles en mode exec. Les plus intéressantes dans le cadre de ce travail sont :
La commande show comprend de nombreux paramètres. Parmi ceux-ci, les plus utiles en mode exec sont show running-config qui permet de visualiser la configuration actuelle du routeur et show interfaces pour visualiser les différentes interfaces. D’autres paramètres sont accessibles en mode exec privilégié.
Exemple de configuration de l’interface FastEthernet 0/0 d’un routeur Cisco :
Une autre variante intéressante de la commande show est show ip route. Cette commande permet de visualiser le contenu de la table de routage du routeur.
Exemple de table de routage sur un routeur Cisco :
Cette table de routage s’interprète de la façon suivante. La lettre dans la première colonne indique le type de route (R : route annoncée par le protocole RIP, C : réseau directement connecté, S : route statique). L’examen de la ligne «R 192.168.5.0 [120/1] via 192.168.2.100, ...» nous fournit les renseignements suivants :
La distance administrative n’est pas utilisée dans le cadre de ce travail, nous nous contenterons de la métrique associée à la route. Celle-ci correspond au nombre de «sauts», de routeurs, qu’il faut traverser pour arriver au réseau destination.
Toutes les commandes possibles de l’IOS sont accessibles en mode exec privilégié y compris de passer en mode global configuration. Le passage en mode exec privilégié se fait avec la commande enable. (On en ressort avec disable).
Lorsque le routeur se trouve en mode exec privilégié, son prompt devient «#».
On peut entrer dans ce mode grâce à la commande configure terminal. Ce mode permet de changer la configuration courante du routeur. On quitte le mode global configuration en utilisant la commande exit.
Ce mode permet de réaliser les opérations principales relatives à la configuration du routeur et des protocoles de routage. Parmi les nombreuses commandes disponibles dans ce mode, vous devrez utiliser notamment les commandes de configuration des interfaces du routeur ainsi que les commandes de configuration des protocoles de routage.
La configuration des interfaces se fait interface par interface. Pour configurer l’interface FastEthernet 0/0 d’un routeur, utilisez les commandes suivantes :
La configuration des interfaces série est un petit peu différente de celle des interfaces Ethernet. Pour configurer l’interface série d’un routeur Cisco, faites les commandes suivantes :
Ces commandes étant effectuées, il faut ensuite assigner une adresse IP et activer l’interface. Ceci est faite en utilisant les mêmes commandes que pour la configuration d’une interface Ethernet.
Après avoir configuré toutes les interfaces du routeur, il est possible de manipuler notamment les tables de routage. Deux types de routage sont utilisables. Le premier est le routage statique où les tables de routage sont configurées manuellement sur chaque routeur du réseau. Le second est le routage dynamique où un protocole de routage est utilisé pour distribuer les routes dans l’ensemble du réseau.
Le routage statique est supporté avec notamment les commandes ip routing et ip route. La première active les possibilités de routage. La deuxième prend quatre paramètres : le réseau destination, le masque de ce réseau, l’adresse IP du routeur passerelle et enfin la métrique associée à cette route. Par exemple, la commande
permet d’insérer une route pour le réseau 192.168.1.0 avec un masque de 24 bits et en utilisant le routeur 192.168.3.240 et avec une métrique de 10. Pour supprimer cette route de la table de routage, il suffit d’utiliser la commande
L’utilisation des protocoles de routage dynamique se fait en activant le protocole de routage par l’intermédiaire de la commande router. Par exemple, router rip active la version 1 du protocole RIP sur le routeur. Une fois le protocole de routage activé, le routeur est prêt à accepter les messages RIP venant d’autres routeurs du réseau. Un routeur n’annoncera des routes avec le protocole RIP que si chaque route à annoncer est explicitement spécifiée. Cela se fait avec la commande network. Par exemple, les commandes ci-dessous permettent au routeur Cisco1 d’annoncer à l’ensemble du réseau qu’il parvient à joindre le réseau 192.168.0.0.
Outre l’annonce de routes, il est possible de configurer certains paramètres opérationnels du protocole RIP. Par défaut, un routeur RIP envoie ses vecteurs de distance toutes les trente secondes. Ce délai peut être modifié grâce à la commande timers basic.
Voici quelques combinaisons de touches (non documentées) Cisco.
Lorsque l’on tape un mot non reconnu comme une commande, Cisco l’interprète comme un nom de machine et fait un ping 30 fois dessus... ça peut être long.
Pour l’interrompre : Ctrl-Shift-6 deux fois.
Suivant les versioons d’IOS, c’est parfois : Ctrl-Shift-6 puis x
Exemple sur Cisco :
Exemple sur Cisco :
Permet par exemple de :
http://www.netfilter.org/documentation/tutorials/blueflux/
Les paquets passent par
Exemple de pare-feu protégeant un réseau privé derrière une adresse publique
Remettre à "zéro" le firewall de Linux signifie supprimer toutes les règles de toutes les tables, et choisir comme politique par défaut d’accepter tous les paquets. Donc, un simple iptables -f ne suffit pas...
Voici comment pousser une config à "zéro" dans iptables :
Auteur : Ronan Keryell
1.Cela permet au passage de se familiariser avec les techniques classiques de compilation de logiciels et d’installation à partir des sources...
2.http://fr.wikipedia.org/wiki/Network_Information_Service
3.http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
4.Le format de ce fichier est documenté : lisez le man 5 passwd ainsi que le man 3 crypt
5.Si vous venez de compiler john, lancez-le dans le répertoire run.
8.http://passwordsafe.sourceforge.net/
9.http://sourceforge.net/projects/secretmanager/
10.Ce programme a un mode intéressant de reconstruction de sessions tcp plus compatible avec les cerveaux humains dans le menu Analyze/Follow tcp Stream.
11.Vous constaterez que nos serveurs telnet sont un peu long à ouvrir une session. En effet ils tentent de faire une résolution de nom inverse sur l’IP du client pour en apprendre un peu plus sur lui... Or nos machines ne sont pas dans le DNS, dommage !
14.Une autre option est d’utiliser un répondeur de courrier automatique http://www.bortzmeyer.org/repondeurs-courrier-test.html
15.HELP permet d’avoir le mode d’emploi en ligne. Malheureusement cette commande est souvent desactivée sur les serveurs modernes.
16.Dans Zimbra, faites un clic droit sur le mail et choisissez Montrer l’original.
17.La touche <TAB> du clavier.
18.La touche <?> du clavier.
19.La touche <TENTRÉE> du clavier.
20.Pour vos essais, pensez à configurer votre navigateur en conséquences (Préférences / Réseau / Proxy).
21.Dangereux pour l’ordinateur, voire pour le rendement de l’utilisateur... ☺
22.Sachant que de toute manière un utilisateur pourra toujours avoir un modem dans son bureau ou tirer un tunnel sur n’importe quel protocole autorisé et ouvrir un canal caché... Donc rester raisonnable dans les restrictions et plutôt convaincre les utilisateurs.
23.https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
24.Habituellement, dans ce fichier, le nom de l’hôte et sa clé sont stockés de manière hachés avec une graine aléatoire, un peu comme le fichier passwd Unix. Pour rechercher un host dans ce fichier : ssh-keygen -F host. Pour retirer une identité de host de ce fichier : ssh-keygen -R <host>
25.Pour afficher le fingerprint de la clef publique de votre propre serveur ssh : ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
26.Évidemment, l’intérêt en France est que la majorité des gens capables de décoder ça sont à la retraite, mais méfions-nous des espions soviétiques... ☺
27.Ne devient-on pas informaticien(ne) par flemme, pour faire travailler les ordinateurs à sa place ?
28.C’est-à-dire pas que "les vôtres" ! ! ! ☹
29.Exemple de la souplesse et la beauté d’Unix au passage.
30.Ou seulement celui de votre session X en cours : xauth list $DISPLAY
31.http://projects.gnome.org/seahorse/
32.Sinon un pirate pourrait au passage la remplacer par sa propre clé publique...
33.Un PC doté du logiciel minicom et relié via son port série au port console joue ce rôle de terminal d’administration.
