#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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)
#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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)
#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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)
bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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 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.
bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...
#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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 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.
bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport
123 -d 0/0 --dport 123 -j ACCEPT
fin de citation
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 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.
Jean-Michel OLTRA wrote:bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport 123 -d 0/0 --dport
123 -j ACCEPT
fin de citation
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
iptables --append INPUT --match udp --protocol udp --source 0/0
--sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination 0/0
--dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination 0/0
--dport 123 --jump ACCEPT
PC B (client de A):
######################
iptables --append INPUT --match tcp --protocol tcp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 123 --jump ACCEPT
#######################################################"
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
Jean-Michel OLTRA wrote:
bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...
#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport 123 -d 0/0 --dport
123 -j ACCEPT
fin de citation
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
iptables --append INPUT --match udp --protocol udp --source 0/0
--sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination 0/0
--dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination 0/0
--dport 123 --jump ACCEPT
PC B (client de A):
######################
iptables --append INPUT --match tcp --protocol tcp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 123 --jump ACCEPT
#######################################################"
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
Jean-Michel OLTRA wrote:bonjour,
Le dimanche 18 décembre 2005, Bayrouni a écrit...#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport 123 -d 0/0 --dport
123 -j ACCEPT
fin de citation
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
iptables --append INPUT --match udp --protocol udp --source 0/0
--sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination 0/0
--dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination 0/0
--dport 123 --jump ACCEPT
PC B (client de A):
######################
iptables --append INPUT --match tcp --protocol tcp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 123 --jump ACCEPT
#######################################################"
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
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
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 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 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
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 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 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
iptables --append INPUT --match udp --protocol udp --source
192.168.0.1 --sport 123 --jump ACCEPT
iptables --append OUTPUT --match tcp --protocol tcp --destination
192.168.0.1 --dport 123 --jump ACCEPT
iptables --append OUTPUT --match udp --protocol udp --destination
192.168.0.1 --dport 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+
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
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?
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
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?
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
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?