Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

Maxime Augier

PolyLAN 4: Coding Session n°2
Résumé de la Coding Session n°2 avec Nitro:

- Configuré Metalog pour la gestion d'évènements sur Guardian
- Polissage et test du script de suivi dhcp (dhcp-follow.pl)
- Installé les MIBS et testé le code SNMP
- Codé et testé le nouveau code de tracking fonctionnant avec une topologie arbitraire (PolyLAN::Switch, track.pl)
- Ecrit un outil pour manipuler rapidement des bases berkeley a la main si nécessaire (bdb-edit.pl)
- Interface web pour accéder au programme de tracking (thx Nitro)
- Ecrit un outil pour récupérer rapidement et dans un format lisible la table de forwarding d'un switch (fwtable.pl)
- Implémenté l'interface de requête de support technique (thx Nitro)

Problèmes:

- Changé la carte réseau de Guardian, essayé de débugger pendant 2h ce qui semble etre un conflit d'IRQ bizarre

Objectifs pour la prochaine fois:

- Monter 2e carte réseau sur Guardian et configurer pour failover semi-automatique
- Terminer composants de suivi de topologie
- Système de backup de la configuration des switches par tftp
Posted by Maxime Augier at 4:55
PolyLan 4: MAC Spoofing
Je remercie Martin Vuagnoux de m'avoir fait remarquer un scénario d'attaque possible, dans lequel un joueur malicieux peut, en falsifiant son addresse MAC, pousser un hôte légitime dans la zone restreinte, sans y tomber lui-même. Il peut également dénier le service a un hôte légitime s'il connaît à l'avance son addresse MAC.

N'ayant pas de contrôle de bas niveau sur le fonctionnement de nos switches, il est difficile de se prémunir contre ce genre d'attaques. Fort heureusement, un très simple changement suffit a assurer que la machine malicieuse soit isolée aussi pour le premier cas, le reste se réglant grâce a deux ou trois gros bras dans l'équipe réseau.

Moyennant une flexibilité réduite en cas de panne ou problème technique lié à un port particulier du switch, il est aussi possible de protéger l'utilisateur légitime.

J'ai également testé l'utilisation de Metalog comme interface de passage d'évènements. Jusqu'a présent, tout semble se comporter correctement.

Je posterai prochainement une version mise a jour du diagramme dataflow de l'ensemble, pour refléter la présence du "bouton d'appel", du chasseur de serveurs dhcp, et de 2-3 autres trucs.
Posted by Maxime Augier at 21:35
Comments (3)
PolyLan 4: Réseau, suite
- Un joli diagramme de la structure du système, pour s'y retrouver un peu mieux (vous avez dit pas clair ?)

- Ré-écrit le code ARP de PLT pour utiliser l'outil arping d'Alexey Kuznetsov. Ceci devrait diminuer la charge réseau d'un facteur 2. L'ancien code reste toutefois présent en option, car le nouveau a besoin de s'executer avec le privilège NET_RAWIO.
Posted by Maxime Augier at 12:07
PolyLan4: Etat des travaux réseau
La "coding session" avec Nitro vient de se terminer, après 10h de travail acharné. Ce qui a avancé:

- Le routage est entièrement opérationnel sur la passerelle primaire (thx Nitro)
- Les bases berkeley pour le suivi des leases dhcp, l'enregistrement des machines de la zone admin, et les blocages MAC sont en place
- L'outil en ligne de commande pour l'édition de la base des machines admin est OK
- L'outil web similaire fonctionne aussi (thx again Nitro)
- L'outil de régénération de la configuration dhcp est presque prêt (difficultés de configuration pour les classes et sous/classes, blah blah)
- Le script de suivi DHCP pour la mise a jour de la base berkeley fonctionne
- Le démon de surveillance du cache arp fonctionne
- Le serveur DNS interne fonctionne
- Le code de PLT est maintenant sur le serveur Subversion de la JE
- Le RAID de Guardian a finalement réussi a se reconstruire tout seul comme un grand

Et surement plein d'autres trucs que j'ai oubliés.

Tâches prioritaires:

- Comprendre ce qui ne va pas avec les classes et pools dhcp
- Analyser les messages syslog du serveur dhcp pour intégrer le script de suivi à Metalog
- Implémenter le mécanisme d'enregistrement
- Nettoyer la configuration des switches et tester l'isolation par vlans
Posted by Maxime Augier at 4:11
Syslog comme mécanisme d'IPC ?
Le développement des outils de monitoring pour PolyLAN 4 avance gentiment. Je me propose de bâtir mon système de surveillance autour du dispositif syslog, et plus précisément autour de metalog (alternative à syslog de Frank Denis).

Syslog est un outil idéal pour construire rapidement un système basé sur plusieurs tâches synchronisées uniquement par l'envoi de messages, lorsque la charge du système reste à un niveau modéré.

Syslog est une cible naturelle pour un démon de réception de traps snmp, comme pour tout porgramme perl via Sys::Syslog. Metalog permet de dispatcher les messages suivant des critères avancés, vers un log directory ou par exécution d'un shell script à chaque message. Ceci permet de programmer des scripts en réponse à des évènements. Le stockage permanent se fait via par exemple une base Berkeley, qui inclut des transactions primitives mais suffisantes dans notre cas.

Une autre approche est d'utiliser un logger plus conventionnel, capable d'écrire dans des tubes nommés, et de lancer des processus qui lisent ces tubes et traitent les messages entrants.
Posted by Maxime Augier at 18:33
PolyLan4: Serveurs réseaux installés
Les deux machines sur le rack a roulettes sont bootables. L'une "gateway" servira de routeur et moniteur de traffic, l'autre "guardian" de serveur dhcp, dns, monitoring des équipements réseaux, et routeur failover en cas de panne de l'autre. Il reste encore a configurer firewall et NAT sur ces deux machines, tester le fonctionnement de la résolution dns, et tester les scripts de gestion de la sécurité (quarantaine par vlans, traçage des participants, etc..)

A l'exception de ces deux machines, tous les autres hôtes IP de la lan seront configurées par DHCP. Une vérification périodique du cache arp de la passerelle devrait permettre d'identifier les problèmes (comparaison avec les leases du serveur dhcp). Les hôtes malicieux peuvent être mis en quarantaine par le mécanisme des vlans. En raison des limitations du firmware des switches, il ne sera pas possible d'implémenter le schéma initialement prévu. La procédure de quarantaine/libération est légèrement complexifiée, et il n'est pas possible d'isoler les machines quarantinées les unes des autres sans modifications consiférables du dispositif.

Le réseau sera organisé en étoile, avec au centre deux switches Dell PowerConnect 5000 Series reliés par un trunk 6 x 1000BaseT, desquels partiront respectivement 4 et 5 trunks 2x 1000BaseT vers 9 switches Dell PowerConnect 3000 Series, chacun équipé de 24 ports libres 100BaseT. Un est destiné aux consoles des administrateurs, les autres sont pour les joueurs. Un switch reste en réserve en cas d'augmentation du nombre de participants, ou en cas de problème technique pendant la lan. Les serveurs de jeux seront connectés sur les ports restants des switches centraux, en essayant de les répartir en fonction de la position dans la salle des équipes les plus importantes, pour décharger le tronc.

Une mini-lan devra être organisée pour tester le fonctionnement de l'ensemble. L'infrastructure sera réduite à 2 switches en périphérie au lieu de 9, un minimum de trois participants sera suffisant pour tester le comportement du système a faible charge.
Posted by Maxime Augier at 20:40
VLANS, suite...
Ou comment des analogies mal choisies peuvent nous faire passer à côté de l'évidence.

Le plan initial était d'utiliser les vlans comme des zones virtuellement séparées. Se pose alors le problème de la configuration de la passerelle de sécurité, qui doit communiquer avec des machines sur le même subnet mais sur des interfaces différentes, et toutes les complications qui s'ensuivent.

Par chance, le matériel que nous avons a disposition ne semble pas nous imposer de quelconque corrélation entre les vlans attribués aux paquets entrants, et l'appartenance d'un port a la livraison de paquets sortants. Nous pouvons donc voir les vlans comme des canaux de communication unidirectionnels si nécessaire, ce qui peut grandement nous simplifier la vie!

Le schéma précédemment utilisé décrivait deux zones: Trusted et Untrusted. Les serveurs sont en zone Trusted, les clients basculent de l'une a l'autre selon le bon vouloir de la passerelle. Au milieu de la frontière, la passerelle devient délicate a configurer... (je n'ai aucune expérience avec le bridging sous linux). Stupidement, je n'ai pas pensé a utiliser un 3e vlan pour la passerelle, solution pourtant conceptuellement plus simple.

Le nouveau schéma décrit trois classes de traffic:
- Trusted : communications émanant des clients sûrs et des serveurs
- Untrusted: communications émanant des clients non sûrs
- Gateway: communications émanant de la passerelle.

La catégorisation du traffic ingress est ainsi trivialement donnée. Pour le traffic egress, on utilisera les regles suivantes:

- Trusted: délivré aux clients sûrs, serveurs et passerelle
- Untrusted: délivré à la passerelle
- Gateway: délivré a tout le monde sauf la passerelle.

Pour basculer un client en statut sécurisé, il suffit de:

- Changer le vlan par défaut du traffic ingress du port de Untrusted en Trusted
- Ajouter le port a la liste de livraison de la classe Trusted.

Le schéma peut être simplifié en fusionnant les classes Trusted et Gateway, les machines non vérifiées sont alors atteignables par les autres stations, mais aucun retour direct n'est possible, ce qui ne devrait pas s'avérer trop problématique. Ceci permet de réduire le statut de chaque port a son VLAN ingress par défaut, ce qui est changable atomiquement par SNMP, et réduit encore les risques d'accident de configuration. C'est peut-etre la solution qui sera retenue.
Posted by Maxime Augier at 16:19
Comments (1)
PolyLAN 4: Outils de gestion réseau, en bonne voie
Le développement des outils d'administration réseau sadique avance bien.

Pour la dernière fois, nous avions déja un IDS et de quoi retrouver rapidement les fauteurs de troubles (ahh, la beauté des switches manageables...). Cette fois, nous allons essayer de pousser le schéma un cran plus loin. Au programme: détection active de certaines nuisances (serveurs dhcp rebelles, entre autres), et isolation semi-automatique des fauteurs de troubles ou machines non authentifiées.

La solution envisagée repose sur la mise en place de Virtual Lans (802.1Q) dynamiques pour définir des zones correspondantes aux différents niveaux de confiance accordés aux postes. Le tout est coordonné par une passerelle de sécurité, notifiée via des traps SNMP du changement de l'états de différents ports, qui reconfigure les switches en fonction du statut de l'adresse MAC associée au port. (nous n'autorisons pas la présence d'équipements réseaux autres que le notre).

La configuration de la dite passerelle pose quelques intéressants challenges de configuration, mais rien de techniquement infaisable. Le support du noyau officiel Linux pour le 802.1Q, ainsi que les fonctionnalités de routage avancé, seront d'une aide précieuse.
Posted by Maxime Augier at 21:51
Mon laptop remarche, whee !
Après cinq heures de tournevissage acharné, mon laptop remarche enfin. Et il n'y avait que quatre vis en trop à la fin du remontage !

Il va être possible de reprendre le travail, quelle joie !

Note a Benêt 1: La prochaine fois, ne pas oublier de rebrancher le ventilateur principal...
Posted by Maxime Augier at 22:37
Les blogs remarchent, whee.
Et hop. encore quelques octets inutiles... prends ça comme acompte, entropie universelle.

Je me suis définitivement converti a Subversion pour remplacer CVS. L'idée de faire passer le truc par dessus WebDAV est assez géniale, de même que le n° de révision unifié et le versionnage des répertoires. Reste a convertir mes collègues programmeurs...
Posted by Maxime Augier at 23:47
Page : « Previous 1 2 3 Next »