Problème d'heure

mimique

Bonjour
Je suis en pleine configuration de deux PfSense. Je me retrouve avec un problème un peu agaçant concernant l'heure. Je l'ai configuré par défaut sur Europe/Paris avec 0.pfsense.pool.ntp.org comme serveur de temps (je n'en ai pas sur mon réseau).

L'heure affiché est correcte seulement dans mes logs j'ai un mélange d'heures.


May 25 07:11:16 	php[44749]: /index.php: Successful webConfigurator login for user 'admin' from 192.168.10.10
May 25 07:15:52 	dnsmasq[40690]: read /etc/hosts - 3 addresses
May 25 09:17:47 	check_reload_status: syncing firewall
May 25 09:17:48 	check_reload_status: reloading filter
May 25 07:25:22 	dnsmasq[40690]: read /etc/hosts - 3 addresses
May 25 07:39:13 	dnsmasq[40690]: read /etc/hosts - 3 addresses
May 25 09:53:31 	check_reload_status: syncing firewall
May 25 09:53:32 	check_reload_status: reloading filter

Mes connexions au webgui sont aussi touché par ce problème. Comme si mon [UTC +1/UTC +2] n'était pas toujours prit en compte
Qu'est-ce que je dois faire pour corriger ce problème d'heure?

Quand je tape en ligne de commande ntptime j'obtiens ceci

$ ntptime
ntp_gettime() returns code 5 (ERROR)
  time d18737b2.b29ac000  Wed, May 25 2011 10:09:22.697, (.18523466),
  maximum error 33769000 us, estimated error 500000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 4 s,
  maximum error 33769000 us, estimated error 500000 us,
  status 0x40 (UNSYNC),
  time constant 0, precision 0.000 us, tolerance 496 ppm,
  pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.

Le code d'erreur 5 correspond a un ntp non synchronisé.

En regardant dans mon /etc/ntp.conf je n'ai pas trouvé le serveur de synchronisation de PfSense mais ceux par défaut (les freebsd). Le temps est-il géré autrement sous PfSense?

Actuellement, mes deux PfSense 2.0RC1 (Février) sont sur un serveur DELL avec ESX 4.1.
Cordialement

ccnet

Actuellement, mes deux PfSense 2.0RC1 (Février) sont sur un serveur DELL avec ESX 4.1.

Vous devez aimer les ennuis.

Je ne sais pas ce que vous souhaitez faire avec Pfsense mais trois observations s'imposent.

1. La version 2 n'est que RC1 donc inadaptée à la production car pas encore stable. Il suffit de regarder la liste de tickets encore ouverts.

2. On ne virtualise pas un firewall pour des raisons évidentes de sécurité. Raisons multiples mais principalement deux catégories. Celle inhérente aux failles possibles de l'hyperviseur lui même. Une sortie d'isolation, par exemple, compromet totalement le firewall, donc toute l'entreprise. La probabilité d’occurrence est faible mais l'impact énorme. Le risque est donc trop fort.L'autre catégorie c'est la complexité induite par la plateforme de virtualisation en particulier sur le plan réseau. Je vous recommande cette lecture : http://www.hsc.fr/ressources/presentations/cio-virtualisation/pres20090326-hsc.pdf en particulier la page 8 pour les flux réseau. cette complexité est de nature à provoquer de réels problème par manque de maitrise.

3. La gestion de la synchro horaire n'est plus du tout la même dès lors que vous êtes sur une ESX. Avez vous regardé les documents vmware sur les problèmes posés avec Linux sur ce point ?

Pour essayer de commencer à répondre à votre question, il faudrait savoir quels choix vous avez fait pour vos vm sur ce plan. Vous ne dites pas non plus si c'est un seul ESX pour les deux pfsense, si c'est deux ESX, si vous utiliser Vcenter (synchro horaire critique pour vmware) ou non, si vous avez un stockage partagé, si vous utilisez HA, Vmotion ? En fait quelle licence Vmware.

Beaucoup, beaucoup d'éléments qui modifie le bon positionnement de votre problème.

mimique

Bonjour.
Merci pour l'information concernant les firewalls sur environnement virtualisé, je n'en savais rien. Concernant PfSense 2.0RC1 je sais que c'est une version de développement et non une version de production, j'ai déjà été faire un tour du bugtracker pour avoir un aperçu .
Je me permets de poster ici, car je possédais aussi ce problème d'heure sur PfSense 1.2.3 monté sur machine physique (un vieux PIII) et j'en ai conclu que cela vient de moi (la façon dont je configure PfSense).
Je viens de lire la documentation que vous m'avez donnée. Courte, mais intéressante . N'étant pas un expert de la virtualisation je vais donc penser a 2 machines physiques.

Je n'ai pas regardé du côté de l'ESX car je voulais voir dans un premier temps si c'était lié à mon PfSense.

Sinon c'est sur un seul et même ESX.
Côté connectique réseau, j'ai une carte physique dédiée pour mes deux pfSense. J'ai créé un groupe de port de machine par PfSense (avec un ID VLAN pour chacun). De cette façon je récupère le flux de chaque PfSense selon le VLAN.

J'ai fait un peu plus de recherche sur le problème de la virtualisation des firewalls et je suis tombé sur une discutions (sur un autre forum) entre vous, jdh et une personne proposant la virtualisation d'ipcop. Je comprends mieux maintenant.

Au risque de dériver du sujet, la sortie d'isolation se traduit par l'accès a tous les réseaux concerné par l'ESX? (Ou les ESX si reliés par vCenter)? Mon ESX est lié a 4 réseaux. Mes deux réseaux pfSense, un autre réseau ne comportant pas de données sensibles, et le réseau Internet. En ce cas, les dangers sont l'accès a mon interface d'administration ESX? Je vous pose ces questions, car je n'arrive pas à bien comprendre le risque lié a ce genre d'exception et je ne peux donc pas l'évaluer (je ne savais pas qu'il existait un tel risque, même minime avant que vous m'en ayez parlé.
Je n'ai ni vCenter ni Vmotion ni HA.

jdh

(Puisque je suis cité …)

J'abonde dans le sens de ccnet. (Ce n'est pas anormal d'être d'accord parce qu'il y a un peu de lecture et d'expérimentation ...)

Pour le temps :

La synchronisation de temps est un problème MAJEUR dans le cas de la virtualisation.
Une machine physique est capable d'utiliser une puce lui donnant des "ticks" qu'il suffit de compter pour gérer l'heure.
Mais avec les sources de temps sur Internet (protocole NTP), il faut de plus savoir ajuster l'horloge du noyau (doucement).

En mode virtualisation, la machine virtuelle dispose de ressources, pas en continu, mais par tranches de temps.
Par voie de conséquence le temps ne peut plus se calculer exactement pareil.

Il y a des documents très intéressants à ce sujet dans la KB de VMware, en effet.

Concernant les serveurs de temps, je recommande l'utilisation de fr.pool.ntp.org (voire eu.pool.ntp.org ...)

Il n'est pas forcé de mettre NTP sur le pfSense : s'il y a Domain Controler Windows dans le réseau local, il peut faire l'affaire très bien.
Mais il faut comprendre qu'il ne doit y avoir QU'UNE seule machine à se synchroniser et toutes celles locales doivent se synchroniser avec elle.
(Raison d'économie mais aussi garantie qu'elles restent synchronisées entre elles).

Pour la version :

Sauf besoin spécifique impérieux, il vaut mieux rester en 1.2.3 qu'en 2.0RC.
Bien sur, certaines fonctions ne sont pas présentes (le filtrage dans un VPN, et quelques autres) mais 1.2.3 offre déjà beaucoup.

Le positionnement :

Outre la difficulté "temps", chaque système vient avec sa conception réseau.

Quand un système dispose de plusieurs pattes réseaux, il faut que le noyau gère parfaitement l'orientation des flux entre différentes pattes.
C'est le rôle d'un firewall (ajustement fin : protocole par protocole), pas celui de l'hôte de virtualisation !

On peut tester mais pas mettre en production un firewall en virtuel.

...
Pour VMware, il y a des switchs capables de gérer les VLAN

ccnet

Au risque de dériver du sujet, la sortie d'isolation se traduit par l'accès a tous les réseaux concerné par l'ESX?

Elle peut avoir lieu d'une vm vers une autre, ou d'une vm vers l'hyperviseur. Difficile mais possible. Mais quid demain si une faille est découverte dans une version d'ESX ? Dans tous les cas la compromission est grave puisque potentiellement toutes les vm seront touchées et donc tous les réseaux connectés seront impactés.

C'est ancien mais cela montre que le risque peut devenir réalité :
http://www.mag-securs.com/Alertes/tabid/63/articleType/ArticleView/articleId/21386/HSC-Multiples-vulnerabilites-dans-VMware.aspx

Et plus de détails : http://ebookbrowse.com/clusif-vmware-20090204-pdf-d41613000

Non vraiment le firewall virtualisé il ne faut pas.

mimique

Entendu, je prend tout cela en compte :). Je vais me documenter sur les problème de temps entre Linux et Vmware.

Pour le temps :

La synchronisation de temps est un problème MAJEUR dans le cas de la virtualisation.
Une machine physique est capable d'utiliser une puce lui donnant des "ticks" qu'il suffit de compter pour gérer l'heure.
Mais avec les sources de temps sur Internet (protocole NTP), il faut de plus savoir ajuster l'horloge du noyau (doucement).

En mode virtualisation, la machine virtuelle dispose de ressources, pas en continu, mais par tranches de temps.
Par voie de conséquence le temps ne peut plus se calculer exactement pareil.

Il y a des documents très intéressants à ce sujet dans la KB de VMware, en effet.

Concernant les serveurs de temps, je recommande l'utilisation de fr.pool.ntp.org (voire eu.pool.ntp.org …)

Il n'est pas forcé de mettre NTP sur le pfSense : s'il y a Domain Controler Windows dans le réseau local, il peut faire l'affaire très bien.
Mais il faut comprendre qu'il ne doit y avoir QU'UNE seule machine à se synchroniser et toutes celles locales doivent se synchroniser avec elle.
(Raison d'économie mais aussi garantie qu'elles restent synchronisées entre elles).

Donc on est d'accord, pfSense obtient de deux façon l'heure : La première c'est via un serveur de temps (ntp) et l'autre c'est via un module chargé dans le noyau (en dur ou non) qui reprend l'heure de la machine physique. D’où le problème pour cette dernière méthode en environnement virtualisé. Mais je pensais que l'idée du ntp était de remplacer le temps machine (tout du moins cela évite de configurer le temps machine par machine).

En y repensant bien, c'est évident que l'on ne virtualise pas un firewall…... On a rarement vu le cas de la virtualisation d'un routeur Cisco, HP ou autre marque. Tout est en physique.

En tout cas je vous remercie pour toutes les informations que vous m'avez donner et pour le temps passer a rabâcher sur un sujet que vous avez du avoir beaucoup de fois sur les forums. Je vais potasser tout ça tranquillement.
Bien cordialement.

mimique

Merci pour la doc sur ce type de faille. J'abandonne l'idée de la virtualisation ;D