Le dimanche 6 mai 2007 12:01, Pascal Hambourg a écrit :
> Steve a écrit :
> >>Curieux que l'absence de cette option empêche le démarrage de BIN D. Que
> >>contient l'option 'listen-on' ?
> >
> > l'adresse du réseau local : 192.168.20.0/24
>
> En général on met plutôt l'adresse de la machine, mais pourquoi p as.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l' adresse
de la machine (peut-être parce que j'ai plusieurs interfaces) en tout c as
ça marche..
> > /etc/bind/named.conf.options:26: '}' expected near ';'
> > loading configuration: unexpected token
> > exiting (due to fatal error)
>
> Une erreur de syntaxe, donc, pas une erreur liée directement à la
> présence ou l'absence de l'option. Il y a quoi autour de la ligne 26 ?
avant :
auth-nxdomain yes; # conform to RFC1035
qui est à no par default, ça aussi je ne sais plus trop je l'ai mis à yes,
d'ailleurs je vais le modifié pour voir
et après :
allow-transfer {
192.168.20.0/24;
};
car j'avais un slave sur ce réseau, mais bon c'était il y a longtemps,
j'imagine que je peux virer ça maintenant.
> > et en décommentant, ça a marché.
>
> Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commen té non ?
Le dimanche 6 mai 2007 12:01, Pascal Hambourg a écrit :
> Steve a écrit :
> >>Curieux que l'absence de cette option empêche le démarrage de BIN D. Que
> >>contient l'option 'listen-on' ?
> >
> > l'adresse du réseau local : 192.168.20.0/24
>
> En général on met plutôt l'adresse de la machine, mais pourquoi p as.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l' adresse
de la machine (peut-être parce que j'ai plusieurs interfaces) en tout c as
ça marche..
> > /etc/bind/named.conf.options:26: '}' expected near ';'
> > loading configuration: unexpected token
> > exiting (due to fatal error)
>
> Une erreur de syntaxe, donc, pas une erreur liée directement à la
> présence ou l'absence de l'option. Il y a quoi autour de la ligne 26 ?
avant :
auth-nxdomain yes; # conform to RFC1035
qui est à no par default, ça aussi je ne sais plus trop je l'ai mis à yes,
d'ailleurs je vais le modifié pour voir
et après :
allow-transfer {
192.168.20.0/24;
};
car j'avais un slave sur ce réseau, mais bon c'était il y a longtemps,
j'imagine que je peux virer ça maintenant.
> > et en décommentant, ça a marché.
>
> Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commen té non ?
Le dimanche 6 mai 2007 12:01, Pascal Hambourg a écrit :
> Steve a écrit :
> >>Curieux que l'absence de cette option empêche le démarrage de BIN D. Que
> >>contient l'option 'listen-on' ?
> >
> > l'adresse du réseau local : 192.168.20.0/24
>
> En général on met plutôt l'adresse de la machine, mais pourquoi p as.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l' adresse
de la machine (peut-être parce que j'ai plusieurs interfaces) en tout c as
ça marche..
> > /etc/bind/named.conf.options:26: '}' expected near ';'
> > loading configuration: unexpected token
> > exiting (due to fatal error)
>
> Une erreur de syntaxe, donc, pas une erreur liée directement à la
> présence ou l'absence de l'option. Il y a quoi autour de la ligne 26 ?
avant :
auth-nxdomain yes; # conform to RFC1035
qui est à no par default, ça aussi je ne sais plus trop je l'ai mis à yes,
d'ailleurs je vais le modifié pour voir
et après :
allow-transfer {
192.168.20.0/24;
};
car j'avais un slave sur ce réseau, mais bon c'était il y a longtemps,
j'imagine que je peux virer ça maintenant.
> > et en décommentant, ça a marché.
>
> Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commen té non ?
Franck Joncourt a écrit :
>
>Chez moi, je fonctionne comme cela :
>
>listen-on-v6 { none; };
Quel dommage. ;-)
>listen-on {
> 127.0.0.1;
> 192.168.0.1;
>};
>
>On specifie "les resseaux" (c'est pas forcement le meilleur mot mais
>interface cela convient encore moins) sur lesquel on ecoute plutot que
>d'etre ouvert a tout.
En fait l'option 'listen-on' spécifie sur quelles adresses locales B IND
écoute, et non de quels réseaux il accepte des requêtes.
Pour ça, il y
a les options 'allow-query', 'allow-recursion', 'allow-transfer'...
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'acce pte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
et normalement le réseau amont ne
route pas les adresses privées vers ta connexion (sauf dans quelques
vieux réseaux câblés, hé hé).
Franck Joncourt a écrit :
>
>Chez moi, je fonctionne comme cela :
>
>listen-on-v6 { none; };
Quel dommage. ;-)
>listen-on {
> 127.0.0.1;
> 192.168.0.1;
>};
>
>On specifie "les resseaux" (c'est pas forcement le meilleur mot mais
>interface cela convient encore moins) sur lesquel on ecoute plutot que
>d'etre ouvert a tout.
En fait l'option 'listen-on' spécifie sur quelles adresses locales B IND
écoute, et non de quels réseaux il accepte des requêtes.
Pour ça, il y
a les options 'allow-query', 'allow-recursion', 'allow-transfer'...
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'acce pte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
et normalement le réseau amont ne
route pas les adresses privées vers ta connexion (sauf dans quelques
vieux réseaux câblés, hé hé).
Franck Joncourt a écrit :
>
>Chez moi, je fonctionne comme cela :
>
>listen-on-v6 { none; };
Quel dommage. ;-)
>listen-on {
> 127.0.0.1;
> 192.168.0.1;
>};
>
>On specifie "les resseaux" (c'est pas forcement le meilleur mot mais
>interface cela convient encore moins) sur lesquel on ecoute plutot que
>d'etre ouvert a tout.
En fait l'option 'listen-on' spécifie sur quelles adresses locales B IND
écoute, et non de quels réseaux il accepte des requêtes.
Pour ça, il y
a les options 'allow-query', 'allow-recursion', 'allow-transfer'...
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'acce pte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
et normalement le réseau amont ne
route pas les adresses privées vers ta connexion (sauf dans quelques
vieux réseaux câblés, hé hé).
>>Je verrais bien une coquille dans la façon de commenter l'option.
>
> je crois que tu as raison; le « ; » c'est bien la manière de comm enter
> non ?
Dans les fichiers de zone oui, mais pas dans les fichiers d'options de
BIND où il sert de séparateur. Les commentaires dans les fichiers
d'options peuvent être sous les formes suivantes :
/* This is a BIND comment as in C */
// This is a BIND comment as in C++
# This is a BIND comment as in common UNIX shells and perl
>>Je verrais bien une coquille dans la façon de commenter l'option.
>
> je crois que tu as raison; le « ; » c'est bien la manière de comm enter
> non ?
Dans les fichiers de zone oui, mais pas dans les fichiers d'options de
BIND où il sert de séparateur. Les commentaires dans les fichiers
d'options peuvent être sous les formes suivantes :
/* This is a BIND comment as in C */
// This is a BIND comment as in C++
# This is a BIND comment as in common UNIX shells and perl
>>Je verrais bien une coquille dans la façon de commenter l'option.
>
> je crois que tu as raison; le « ; » c'est bien la manière de comm enter
> non ?
Dans les fichiers de zone oui, mais pas dans les fichiers d'options de
BIND où il sert de séparateur. Les commentaires dans les fichiers
d'options peuvent être sous les formes suivantes :
/* This is a BIND comment as in C */
// This is a BIND comment as in C++
# This is a BIND comment as in common UNIX shells and perl
Que contient l'option 'listen-on' ?
l'adresse du réseau local : 192.168.20.0/24
En général on met plutôt l'adresse de la machine, mais pourquoi pas.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l'adresse de
la machine (peut-être parce que j'ai plusieurs interfaces) en tout cas ça
marche..
/etc/bind/named.conf.options:26: '}' expected near ';'
loading configuration: unexpected token
exiting (due to fatal error)
Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commenter non ?
Que contient l'option 'listen-on' ?
l'adresse du réseau local : 192.168.20.0/24
En général on met plutôt l'adresse de la machine, mais pourquoi pas.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l'adresse de
la machine (peut-être parce que j'ai plusieurs interfaces) en tout cas ça
marche..
/etc/bind/named.conf.options:26: '}' expected near ';'
loading configuration: unexpected token
exiting (due to fatal error)
Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commenter non ?
Que contient l'option 'listen-on' ?
l'adresse du réseau local : 192.168.20.0/24
En général on met plutôt l'adresse de la machine, mais pourquoi pas.
je ne me rappelle plus très bien pourquoi l'ai mis ça plutôt que l'adresse de
la machine (peut-être parce que j'ai plusieurs interfaces) en tout cas ça
marche..
/etc/bind/named.conf.options:26: '}' expected near ';'
loading configuration: unexpected token
exiting (due to fatal error)
Je verrais bien une coquille dans la façon de commenter l'option.
je crois que tu as raison; le « ; » c'est bien la manière de commenter non ?
A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Du coup, je me rends compte que cela serait plus judicieux de mettre
quelque chose du genre.
listen-on { any; };
allow-query { 127.0.0.0/8; 192.168.0.0/24; };
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'accepte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
loopback ne dialogue qu'avec loopback
Mais, vu que je fonctionne sur deux reseaux :
- 192.168.1.0/24 pourl'internet
- 192.168.0.0/24 pour le reseau prive
dans la théorie rien n'empeche quelqu'un d'interroger le serveur DNS
192.168.0.1 via l'interface presente sur le reseau 192.168.1.0/24.
A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Du coup, je me rends compte que cela serait plus judicieux de mettre
quelque chose du genre.
listen-on { any; };
allow-query { 127.0.0.0/8; 192.168.0.0/24; };
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'accepte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
loopback ne dialogue qu'avec loopback
Mais, vu que je fonctionne sur deux reseaux :
- 192.168.1.0/24 pourl'internet
- 192.168.0.0/24 pour le reseau prive
dans la théorie rien n'empeche quelqu'un d'interroger le serveur DNS
192.168.0.1 via l'interface presente sur le reseau 192.168.1.0/24.
A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Du coup, je me rends compte que cela serait plus judicieux de mettre
quelque chose du genre.
listen-on { any; };
allow-query { 127.0.0.0/8; 192.168.0.0/24; };
En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
adresse de loopback et une adresse privée a des chances d'aboutir au
même résultat, mais c'est par effet de bord : la pile IP n'accepte pas
les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
interface que l'inteface de loopback,
loopback ne dialogue qu'avec loopback
Mais, vu que je fonctionne sur deux reseaux :
- 192.168.1.0/24 pourl'internet
- 192.168.0.0/24 pour le reseau prive
dans la théorie rien n'empeche quelqu'un d'interroger le serveur DNS
192.168.0.1 via l'interface presente sur le reseau 192.168.1.0/24.
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
<troll type="dimanche">Ce ne sont pas des adresses légales, il aurait
fallu dire dead::beef ou cafe:deca::fade.</troll>
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
<troll type="dimanche">Ce ne sont pas des adresses légales, il aurait
fallu dire dead::beef ou cafe:deca::fade.</troll>
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
<troll type="dimanche">Ce ne sont pas des adresses légales, il aurait
fallu dire dead::beef ou cafe:deca::fade.</troll>
>A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
>fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Dans les grandes lignes ça fonctionne à peu près pareil, s auf que les
adresses sont plus longues - en contrepartie il y en a davantage - et
moins "jolies". Quoique, l'hexa permet de créer des adresses rigolot tes
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
[...]
>Du coup, je me rends compte que cela serait plus judicieux de mettre
>quelque chose du genre.
>
>listen-on { any; };
>allow-query { 127.0.0.0/8; 192.168.0.0/24; };
Par exemple. L'option 'allow-query' n'empêche pas de limiter le
'listen-on' aux adresses locales utiles, ça peut économiser que lques
sockets puisque BIND ouvre deux sockets (TCP et UDP) par adresse IPv4.
Autrement, on peut aussi restreindre l'accès avec des règles ip tables.
>>En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
>>adresse de loopback et une adresse privée a des chances d'aboutir au
>>même résultat, mais c'est par effet de bord : la pile IP n'ac cepte pas
>>les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
>>interface que l'inteface de loopback,
>
>loopback ne dialogue qu'avec loopback
Oui, mais il faut distinguer l'interface de loopback (lo) du bloc
d'adresses de loopback (127.0.0.0/8). On pourrait imaginer qu'un petit
malin trafique sa table de routage pour envoyer des requêtes à ta
machine à destination d'une adresse de loopback. Mais la pile IP de
Linux les rejettera car la restriction des adresses de loopback Ã
l'interface de loopback est codée en dur. Ce genre d'attaque a dà ©jÃ
servi contre des OS n'ayant pas cette restriction.
>A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
>fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Dans les grandes lignes ça fonctionne à peu près pareil, s auf que les
adresses sont plus longues - en contrepartie il y en a davantage - et
moins "jolies". Quoique, l'hexa permet de créer des adresses rigolot tes
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
[...]
>Du coup, je me rends compte que cela serait plus judicieux de mettre
>quelque chose du genre.
>
>listen-on { any; };
>allow-query { 127.0.0.0/8; 192.168.0.0/24; };
Par exemple. L'option 'allow-query' n'empêche pas de limiter le
'listen-on' aux adresses locales utiles, ça peut économiser que lques
sockets puisque BIND ouvre deux sockets (TCP et UDP) par adresse IPv4.
Autrement, on peut aussi restreindre l'accès avec des règles ip tables.
>>En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
>>adresse de loopback et une adresse privée a des chances d'aboutir au
>>même résultat, mais c'est par effet de bord : la pile IP n'ac cepte pas
>>les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
>>interface que l'inteface de loopback,
>
>loopback ne dialogue qu'avec loopback
Oui, mais il faut distinguer l'interface de loopback (lo) du bloc
d'adresses de loopback (127.0.0.0/8). On pourrait imaginer qu'un petit
malin trafique sa table de routage pour envoyer des requêtes à ta
machine à destination d'une adresse de loopback. Mais la pile IP de
Linux les rejettera car la restriction des adresses de loopback Ã
l'interface de loopback est codée en dur. Ce genre d'attaque a dà ©jÃ
servi contre des OS n'ayant pas cette restriction.
>A vrai dire je n'ai jamais regarde de pres l'ipv6 et comment cela
>fonctionnait par rapport a l'ipv4. (Aie, Aie !!)
Dans les grandes lignes ça fonctionne à peu près pareil, s auf que les
adresses sont plus longues - en contrepartie il y en a davantage - et
moins "jolies". Quoique, l'hexa permet de créer des adresses rigolot tes
comme le bien connu dead:beef ou cafe:deca:fade. ;-)
[...]
>Du coup, je me rends compte que cela serait plus judicieux de mettre
>quelque chose du genre.
>
>listen-on { any; };
>allow-query { 127.0.0.0/8; 192.168.0.0/24; };
Par exemple. L'option 'allow-query' n'empêche pas de limiter le
'listen-on' aux adresses locales utiles, ça peut économiser que lques
sockets puisque BIND ouvre deux sockets (TCP et UDP) par adresse IPv4.
Autrement, on peut aussi restreindre l'accès avec des règles ip tables.
>>En pratique, le fait de ne mettre dans l'option 'listen-on' qu'une
>>adresse de loopback et une adresse privée a des chances d'aboutir au
>>même résultat, mais c'est par effet de bord : la pile IP n'ac cepte pas
>>les communications depuis ou vers 127.0.0.0/8 qui passent par une autre
>>interface que l'inteface de loopback,
>
>loopback ne dialogue qu'avec loopback
Oui, mais il faut distinguer l'interface de loopback (lo) du bloc
d'adresses de loopback (127.0.0.0/8). On pourrait imaginer qu'un petit
malin trafique sa table de routage pour envoyer des requêtes à ta
machine à destination d'une adresse de loopback. Mais la pile IP de
Linux les rejettera car la restriction des adresses de loopback Ã
l'interface de loopback est codée en dur. Ce genre d'attaque a dà ©jÃ
servi contre des OS n'ayant pas cette restriction.
