Citation:
Le port par défaut sur lequel circulent les
paquets ntp est UDP #123. Si nous voulons accéder
à un serveur ou que des machines accèdent à notre
serveur nous devons l’ouvrir. Pour les
distributions en noyau 2.4.x qui utilisent iptable
la règle iptables à appliquer est :
Si les paquets circules en utilisant le port 123
par defaut, je dois ouvrir ce port en entrée
(INPUT), mais si ma machine doit contacter un
serveur ntp mon firewall doit ouvrir le port 123
(OUTPUT)
Merci pour me permettre de comprendre
Bayrouni
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Si les paquets circules en utilisant le port 123 par defaut, je dois ouvrir ce port en entrée (INPUT), mais si ma machine doit contacter un serveur ntp mon firewall doit ouvrir le port 123 (OUTPUT)
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
C'est un peu bizarre comme règle : on part du principe qu'un paquet est
accepté si il provient du port 123 (--sport 123) et qu'il est destiné au
port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine
possède un serveur de temps ou contacte un serveur de temps.
Si les paquets circules en utilisant le port 123
par defaut, je dois ouvrir ce port en entrée
(INPUT), mais si ma machine doit contacter un
serveur ntp mon firewall doit ouvrir le port 123
(OUTPUT)
Si la machine doit contacter un serveur de temps elle doit pouvoir faire
sortir des paquets à destination du port 123 (OUTPUT), mais également
permettre à ces paquets de « revenir », donc en provenance du port 123,
mais cette fois ce en INPUT.
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Si les paquets circules en utilisant le port 123 par defaut, je dois ouvrir ce port en entrée (INPUT), mais si ma machine doit contacter un serveur ntp mon firewall doit ouvrir le port 123 (OUTPUT)
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat est probant: PC A (gateway): ################## iptables --append INPUT --match tcp --protocol tcp --source 0/0 --sport 123 --jump ACCEPT
C'est un peu bizarre comme règle : on part du principe qu'un paquet est
accepté si il provient du port 123 (--sport 123) et qu'il est destiné au
port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine
possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire
sortir des paquets à destination du port 123 (OUTPUT), mais également
permettre à ces paquets de « revenir », donc en provenance du port 123,
mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat
est probant:
PC A (gateway):
##################
iptables --append INPUT --match tcp --protocol tcp
--source 0/0 --sport 123 --jump ACCEPT
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat est probant: PC A (gateway): ################## iptables --append INPUT --match tcp --protocol tcp --source 0/0 --sport 123 --jump ACCEPT
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Pas si bizarre que ca. Le protocole ntp utilise le port udp 123 aussi bien en source comme en destination, un 'tcpdump port 123' sur ta passerelle te le montrera. Restreindre le port source comme le port destination est plus sure mais n'est pas forcement une bonne idée car certains outils comme ntptrace n'utilisent pas le port 123 en source pour pouvoir etre utilisés par des utilisateurs non root. Windows aussi n'utilise pas le port 123 en source car il utilise sntp, une version allégée de ntp. Par contre, il manque bien la regle pour pouvoir sortir (OUTPUT).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat est probant: PC A (gateway): ################## iptables --append INPUT --match tcp --protocol tcp --source 0/0 --sport 123 --jump ACCEPT
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta passerelle a une adresse ip public, tu devrais limiter les possibilités d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme et la 4eme lignes, un client qui utilise le port 123 en source (comportement par defaut de ntpdate) peut interroger ton serveur depuis n'importe où. Utilise pour cela le module de suivi de connexion (-m state) pour pouvoir differencier les regles client (ta passerelle interroge un serveur sur internet) des regles serveur (tes clients interrogent ta passerelle).
PC B (client de A): ###################### iptables --append INPUT --match tcp --protocol tcp --source 192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de connexion n'est pas aussi utile dans ce cas, car le fait que le serveur puisse interroger ses clients ne devraient pas poser de probleme dans la mesure ou tu controles les 2.
A+
les differents utilitaires ntp prouvent que A se synchronise sur le serveur ntp internet et que B se synchronise sur le serveur A local
C'est un peu bizarre comme règle : on part du principe qu'un paquet est
accepté si il provient du port 123 (--sport 123) et qu'il est destiné au
port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine
possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Pas si bizarre que ca. Le protocole ntp utilise le port udp 123 aussi
bien en source comme en destination, un 'tcpdump port 123' sur ta
passerelle te le montrera. Restreindre le port source comme le port
destination est plus sure mais n'est pas forcement une bonne idée car
certains outils comme ntptrace n'utilisent pas le port 123 en source
pour pouvoir etre utilisés par des utilisateurs non root. Windows aussi
n'utilise pas le port 123 en source car il utilise sntp, une version
allégée de ntp. Par contre, il manque bien la regle pour pouvoir sortir
(OUTPUT).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire
sortir des paquets à destination du port 123 (OUTPUT), mais également
permettre à ces paquets de « revenir », donc en provenance du port 123,
mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat est probant:
PC A (gateway):
##################
iptables --append INPUT --match tcp --protocol tcp --source
0/0 --sport 123 --jump ACCEPT
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta
passerelle a une adresse ip public, tu devrais limiter les possibilités
d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme
et la 4eme lignes, un client qui utilise le port 123 en source
(comportement par defaut de ntpdate) peut interroger ton serveur depuis
n'importe où. Utilise pour cela le module de suivi de connexion (-m
state) pour pouvoir differencier les regles client (ta passerelle
interroge un serveur sur internet) des regles serveur (tes clients
interrogent ta passerelle).
PC B (client de A):
######################
iptables --append INPUT --match tcp --protocol tcp --source
192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de
connexion n'est pas aussi utile dans ce cas, car le fait que le serveur
puisse interroger ses clients ne devraient pas poser de probleme dans la
mesure ou tu controles les 2.
A+
les differents utilitaires ntp prouvent que A se synchronise sur le
serveur ntp internet
et que B se synchronise sur le serveur A local
C'est un peu bizarre comme règle : on part du principe qu'un paquet est accepté si il provient du port 123 (--sport 123) et qu'il est destiné au port 123 (--dport 123). C'est l'un ou l'autre, suivant si la machine possède un serveur de temps ou contacte un serveur de temps.
Oui, je n'osais pas le dire (règle bizarre).
Pas si bizarre que ca. Le protocole ntp utilise le port udp 123 aussi bien en source comme en destination, un 'tcpdump port 123' sur ta passerelle te le montrera. Restreindre le port source comme le port destination est plus sure mais n'est pas forcement une bonne idée car certains outils comme ntptrace n'utilisent pas le port 123 en source pour pouvoir etre utilisés par des utilisateurs non root. Windows aussi n'utilise pas le port 123 en source car il utilise sntp, une version allégée de ntp. Par contre, il manque bien la regle pour pouvoir sortir (OUTPUT).
Si la machine doit contacter un serveur de temps elle doit pouvoir faire sortir des paquets à destination du port 123 (OUTPUT), mais également permettre à ces paquets de « revenir », donc en provenance du port 123, mais cette fois ce en INPUT.
En effet, j'ai suivi cette logique et le resultat est probant: PC A (gateway): ################## iptables --append INPUT --match tcp --protocol tcp --source 0/0 --sport 123 --jump ACCEPT
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta passerelle a une adresse ip public, tu devrais limiter les possibilités d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme et la 4eme lignes, un client qui utilise le port 123 en source (comportement par defaut de ntpdate) peut interroger ton serveur depuis n'importe où. Utilise pour cela le module de suivi de connexion (-m state) pour pouvoir differencier les regles client (ta passerelle interroge un serveur sur internet) des regles serveur (tes clients interrogent ta passerelle).
PC B (client de A): ###################### iptables --append INPUT --match tcp --protocol tcp --source 192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de connexion n'est pas aussi utile dans ce cas, car le fait que le serveur puisse interroger ses clients ne devraient pas poser de probleme dans la mesure ou tu controles les 2.
A+
les differents utilitaires ntp prouvent que A se synchronise sur le serveur ntp internet et que B se synchronise sur le serveur A local
Merci Jean Michel Oltra Bayrouni
-- Pensez
Bayrouni
Marc PERRUDIN wrote:
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta passerelle a une adresse ip public, tu devrais limiter les possibilités d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme et la 4eme lignes, un client qui utilise le port 123 en source (comportement par defaut de ntpdate) peut interroger ton serveur depuis n'importe où. Utilise pour cela le module de suivi de connexion (-m state) pour pouvoir differencier les regles client (ta passerelle interroge un serveur sur internet) des regles serveur (tes clients interrogent ta passerelle).
PC B (client de A): ###################### iptables --append INPUT --match tcp --protocol tcp --source 192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de connexion n'est pas aussi utile dans ce cas, car le fait que le serveur puisse interroger ses clients ne devraient pas poser de probleme dans la mesure ou tu controles les 2.
A+
Bonjour,
Bien, voilà ce que j'ai fait:
Passerelle en tant que client de serveur horaire externe (internet) ##################################################################### la passerelle doit pouvoir contacter un serveur ntp donc: OUTPUT --match udp --protocol udp --destination 0/0 --dport 123 --jump ACCEPT
la passerelle doit laisser entrer les réponses aux requetes faites aux serveurs ntp: cette règle existe indépendemment de ntp INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
La passerelle en tant que serveur du réseau local 192.0.0.0/24 ################################################################### la passerelle doit pouvoir accepter les requetes de ces clients locaux: INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24 --sport 123 --jump ACCEPT
la passerelle doit pouvoir repondre à ses clients locaux: cette règle existe indépendemment de ntp, OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Merci à tous Bayrouni
-- Pensez
Marc PERRUDIN wrote:
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta
passerelle a une adresse ip public, tu devrais limiter les possibilités
d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme
et la 4eme lignes, un client qui utilise le port 123 en source
(comportement par defaut de ntpdate) peut interroger ton serveur depuis
n'importe où. Utilise pour cela le module de suivi de connexion (-m
state) pour pouvoir differencier les regles client (ta passerelle
interroge un serveur sur internet) des regles serveur (tes clients
interrogent ta passerelle).
PC B (client de A):
######################
iptables --append INPUT --match tcp --protocol tcp --source
192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de
connexion n'est pas aussi utile dans ce cas, car le fait que le serveur
puisse interroger ses clients ne devraient pas poser de probleme dans la
mesure ou tu controles les 2.
A+
Bonjour,
Bien, voilà ce que j'ai fait:
Passerelle en tant que client de serveur horaire externe (internet)
#####################################################################
la passerelle doit pouvoir contacter un serveur ntp donc:
OUTPUT --match udp --protocol udp --destination 0/0 --dport 123 --jump ACCEPT
la passerelle doit laisser entrer les réponses aux requetes faites aux serveurs ntp:
cette règle existe indépendemment de ntp
INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
La passerelle en tant que serveur du réseau local 192.0.0.0/24
###################################################################
la passerelle doit pouvoir accepter les requetes de ces clients locaux:
INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24 --sport 123
--jump ACCEPT
la passerelle doit pouvoir repondre à ses clients locaux:
cette règle existe indépendemment de ntp,
OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Les regles tcp ne sont pas utilent, tu devrais les supprimés. Si ta passerelle a une adresse ip public, tu devrais limiter les possibilités d'acces a ton port 123 aux seules clients de ton réseau : avec la 2eme et la 4eme lignes, un client qui utilise le port 123 en source (comportement par defaut de ntpdate) peut interroger ton serveur depuis n'importe où. Utilise pour cela le module de suivi de connexion (-m state) pour pouvoir differencier les regles client (ta passerelle interroge un serveur sur internet) des regles serveur (tes clients interrogent ta passerelle).
PC B (client de A): ###################### iptables --append INPUT --match tcp --protocol tcp --source 192.168.0.1 --sport 123 --jump ACCEPT
Idem que pour PC A pour ce qui est de TCP. L'utilisation du suivi de connexion n'est pas aussi utile dans ce cas, car le fait que le serveur puisse interroger ses clients ne devraient pas poser de probleme dans la mesure ou tu controles les 2.
A+
Bonjour,
Bien, voilà ce que j'ai fait:
Passerelle en tant que client de serveur horaire externe (internet) ##################################################################### la passerelle doit pouvoir contacter un serveur ntp donc: OUTPUT --match udp --protocol udp --destination 0/0 --dport 123 --jump ACCEPT
la passerelle doit laisser entrer les réponses aux requetes faites aux serveurs ntp: cette règle existe indépendemment de ntp INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
La passerelle en tant que serveur du réseau local 192.0.0.0/24 ################################################################### la passerelle doit pouvoir accepter les requetes de ces clients locaux: INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24 --sport 123 --jump ACCEPT
la passerelle doit pouvoir repondre à ses clients locaux: cette règle existe indépendemment de ntp, OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Merci à tous Bayrouni
-- Pensez
Pascal
Salut,
Bayrouni a écrit :
Bien, voilà ce que j'ai fait:
[...]
La passerelle en tant que serveur du réseau local 192.0.0.0/24 ################################################################### la passerelle doit pouvoir accepter les requetes de ces clients locaux: INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24 --sport 123 --jump ACCEPT
^^^^^ Plutôt --dport, non ?
Quid des paquets entrants suivants qui ne sont plus dans l'état NEW mais ESTABLISHED ?
la passerelle doit pouvoir repondre à ses clients locaux: cette règle existe indépendemment de ntp, OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Tu peux spécifier les interfaces d'entrée (-i) des règles INPUT et de sortie (-o) des règles OUTPUT. Eventuellement restreindre les adresses IP des serveurs NTP joignables (mais c'est du vice).
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
Bayrouni a écrit :
Bien, voilà ce que j'ai fait:
[...]
La passerelle en tant que serveur du réseau local 192.0.0.0/24
###################################################################
la passerelle doit pouvoir accepter les requetes de ces clients locaux:
INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24
--sport 123 --jump ACCEPT
^^^^^
Plutôt --dport, non ?
Quid des paquets entrants suivants qui ne sont plus dans l'état NEW mais
ESTABLISHED ?
la passerelle doit pouvoir repondre à ses clients locaux:
cette règle existe indépendemment de ntp,
OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Tu peux spécifier les interfaces d'entrée (-i) des règles INPUT et de
sortie (-o) des règles OUTPUT. Eventuellement restreindre les adresses
IP des serveurs NTP joignables (mais c'est du vice).
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
La passerelle en tant que serveur du réseau local 192.0.0.0/24 ################################################################### la passerelle doit pouvoir accepter les requetes de ces clients locaux: INPUT --match state --state NEW --protocol udp --source 192.168.0.0/24 --sport 123 --jump ACCEPT
^^^^^ Plutôt --dport, non ?
Quid des paquets entrants suivants qui ne sont plus dans l'état NEW mais ESTABLISHED ?
la passerelle doit pouvoir repondre à ses clients locaux: cette règle existe indépendemment de ntp, OUTPUT 1 --match state --state RELATED,ESTABLISHED --jump ACCEPT
Quelqu'un voit encore quelque chose de trop permissible?
Tu peux spécifier les interfaces d'entrée (-i) des règles INPUT et de sortie (-o) des règles OUTPUT. Eventuellement restreindre les adresses IP des serveurs NTP joignables (mais c'est du vice).
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
