Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
|>>>> D'autre part, je vois le plus souvent dans la même règle |>>>> l'acceptation des paquets ESTABLISHED et RELATED. Or les paquets |>>>> RELATED peuvent contenir diverses choses, comme des messages ICMP, |>>>> qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes souhaits :) |>>
|>> Vi, mais du coup ça rajoute des règles inutiles avant le traitement des |>> paquets ESTABLISHED.
Pourquoi inutile ?
Il me semble que filtrer les "mauvaises choses" avant la règle d'acceptation des paquets des connexions établies est inutile, puisque ces choses ont déjà été vérifiées lors de l'établissement de la connexion (dans l'état NEW). Non ?
Schématiquement, je verrais bien une séquence de ce genre : - vérifier la cohérence adresses-interfaces - accepter les paquets ESTABLISHED - jeter les vilains paquets - filtrer les ICMP - filtrer les paquets RELATED
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
- filtrer les paquets NEW
-- TiChou
Dans le message <news:40B51AE2.CA5F715B@free.fr>,
*Annie D.* tapota sur f.c.o.l.configuration :
|>>>> D'autre part, je vois le plus souvent dans la même règle
|>>>> l'acceptation des paquets ESTABLISHED et RELATED. Or les paquets
|>>>> RELATED peuvent contenir diverses choses, comme des messages ICMP,
|>>>> qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
souhaits :)
|>>
|>> Vi, mais du coup ça rajoute des règles inutiles avant le traitement des
|>> paquets ESTABLISHED.
Pourquoi inutile ?
Il me semble que filtrer les "mauvaises choses" avant la règle
d'acceptation des paquets des connexions établies est inutile, puisque
ces choses ont déjà été vérifiées lors de l'établissement de la
connexion (dans l'état NEW). Non ?
Schématiquement, je verrais bien une séquence de ce genre :
- vérifier la cohérence adresses-interfaces
- accepter les paquets ESTABLISHED
- jeter les vilains paquets
- filtrer les ICMP
- filtrer les paquets RELATED
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets
RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je
qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne
le fil complet, vous sembliez dire que ces icmp RELATED pouvait être
néfastes.
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
|>>>> D'autre part, je vois le plus souvent dans la même règle |>>>> l'acceptation des paquets ESTABLISHED et RELATED. Or les paquets |>>>> RELATED peuvent contenir diverses choses, comme des messages ICMP, |>>>> qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes souhaits :) |>>
|>> Vi, mais du coup ça rajoute des règles inutiles avant le traitement des |>> paquets ESTABLISHED.
Pourquoi inutile ?
Il me semble que filtrer les "mauvaises choses" avant la règle d'acceptation des paquets des connexions établies est inutile, puisque ces choses ont déjà été vérifiées lors de l'établissement de la connexion (dans l'état NEW). Non ?
Schématiquement, je verrais bien une séquence de ce genre : - vérifier la cohérence adresses-interfaces - accepter les paquets ESTABLISHED - jeter les vilains paquets - filtrer les ICMP - filtrer les paquets RELATED
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
- filtrer les paquets NEW
-- TiChou
Annie D.
TiChou wrote:
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ? Et apparemment ce n'est pas une bonne idée de les accepter de n'importe où. Certes on peut configurer une interface pour les ignorer, mais je préfère prendre ceinture+bretelles, comme pour le filtrage anti-spoofing.
TiChou wrote:
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets
RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je
qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne
le fil complet, vous sembliez dire que ces icmp RELATED pouvait être
néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED,
non ? Et apparemment ce n'est pas une bonne idée de les accepter de
n'importe où. Certes on peut configurer une interface pour les ignorer,
mais je préfère prendre ceinture+bretelles, comme pour le filtrage
anti-spoofing.
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ? Et apparemment ce n'est pas une bonne idée de les accepter de n'importe où. Certes on peut configurer une interface pour les ignorer, mais je préfère prendre ceinture+bretelles, comme pour le filtrage anti-spoofing.
TiChou
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem). Et, si je ne dis pas de bêtise, les éventuels icmp redirect qui pourraient être reçus et valides ne peuvent provenir que des passerelles configurées sur la machine.
Et apparemment ce n'est pas une bonne idée de les accepter de n'importe où.
Oui et c'est pourquoi les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
mais je préfère prendre ceinture+bretelles, comme pour le filtrage anti-spoofing.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
-- TiChou
Dans le message <news:40B522FD.88B9CC3D@free.fr>,
*Annie D.* tapota sur f.c.o.l.configuration :
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets
RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je
qualifie d'habitude comme étant des icmp utiles). Faudrait que je
reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait
être néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED,
non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie.
Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème
(destination unreachable, source quench, redirect, time exceeded, parameter
problem).
Et, si je ne dis pas de bêtise, les éventuels icmp redirect qui pourraient
être reçus et valides ne peuvent provenir que des passerelles configurées
sur la machine.
Et apparemment ce n'est pas une bonne idée de les accepter de n'importe
où.
Oui et c'est pourquoi les icmp redirect reçus par le noyau sont par défaut
ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par
Netfilter. Sauf si on prenait la décision de les accepter.
Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de
configurer cela.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
mais je préfère prendre ceinture+bretelles, comme pour le filtrage
anti-spoofing.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels
problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité
(c'était d'ailleurs votre préoccupation première à l'origine) il est donc
inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Ce que je ne comprends pas c'est pourquoi vouloir filtrer les paquets RELATED au lieu de les accepter, même quand ceux ci sont des icmp (que je qualifie d'habitude comme étant des icmp utiles). Faudrait que je reprenne le fil complet, vous sembliez dire que ces icmp RELATED pouvait être néfastes.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem). Et, si je ne dis pas de bêtise, les éventuels icmp redirect qui pourraient être reçus et valides ne peuvent provenir que des passerelles configurées sur la machine.
Et apparemment ce n'est pas une bonne idée de les accepter de n'importe où.
Oui et c'est pourquoi les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
mais je préfère prendre ceinture+bretelles, comme pour le filtrage anti-spoofing.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
-- TiChou
Annie D.
TiChou wrote:
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème. On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP ("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me HACKER !"), mais en fait il y en a seulement quelques-uns dont il faille se méfier.
les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Va falloir que je me plonge dans la doc du noyau pour voir comment se combinent ces deux paramètres. Et à quel niveau de la pile IP ils agissent, parce que vous avez peut-être remarqué qu'il n'y a pas que des machines avec Linux chez moi.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
Oui.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime. Par exemple, j'interdis aussi tout trafic entrant comme sortant avec certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN et VPN. Vous allez peut-être me trouver parano, mais je trouve logique que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
TiChou wrote:
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED,
non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie.
Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème
(destination unreachable, source quench, redirect, time exceeded, parameter
problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème.
On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP
("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me
HACKER !"), mais en fait il y en a seulement quelques-uns dont il faille
se méfier.
les icmp redirect reçus par le noyau sont par défaut
ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par
Netfilter. Sauf si on prenait la décision de les accepter.
Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de
configurer cela.
Va falloir que je me plonge dans la doc du noyau pour voir comment se
combinent ces deux paramètres. Et à quel niveau de la pile IP ils
agissent, parce que vous avez peut-être remarqué qu'il n'y a pas que des
machines avec Linux chez moi.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
Oui.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels
problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité
(c'était d'ailleurs votre préoccupation première à l'origine) il est donc
inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime.
Par exemple, j'interdis aussi tout trafic entrant comme sortant avec
certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par
certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN
et VPN. Vous allez peut-être me trouver parano, mais je trouve logique
que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème. On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP ("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me HACKER !"), mais en fait il y en a seulement quelques-uns dont il faille se méfier.
les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Va falloir que je me plonge dans la doc du noyau pour voir comment se combinent ces deux paramètres. Et à quel niveau de la pile IP ils agissent, parce que vous avez peut-être remarqué qu'il n'y a pas que des machines avec Linux chez moi.
Certes on peut configurer une interface pour les ignorer,
Comment ça ? Vous faites référence justement à ce qui précède ?
Oui.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime. Par exemple, j'interdis aussi tout trafic entrant comme sortant avec certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN et VPN. Vous allez peut-être me trouver parano, mais je trouve logique que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
TiChou
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème. On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP
Tout à fait alors qu'au contraire les ICMP sont généralement bienfaisants.
("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me HACKER !"),
:-)
mais en fait il y en a seulement quelques-uns dont il faille se méfier.
Les ICMP reply qui ne sont pas RELATED et que s'il sont filtrés, ils ne faut pas systématiquement les bloqués mais plutôt limité leur nombre dans le temps et limité leur taille. Et les éventuels ICMP redirect pouvant venir de différentes sources, mais je vois mal comment ils pourraient se retrouver dans l'état RELATED.
les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Donc par défaut, sur toutes les nouvelles interfaces créées, les ICMP redirect sont acceptés. Mais...
Va falloir que je me plonge dans la doc du noyau pour voir comment se combinent ces deux paramètres.
...mais reste à savoir lequel de ces paramètres prédominent. Si le paramètre all/accept_redirects l'emporte sur le paramètre interfaceX/accept_redirects. Je n'ai pour l'instant rien trouvé d'intéressant sur le sujet. Va falloir se pencher sur le code source du noyau.
Et à quel niveau de la pile IP ils agissent, parce que vous avez peut-être remarqué qu'il n'y a pas que des machines avec Linux chez moi.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime. Par exemple, j'interdis aussi tout trafic entrant comme sortant avec certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN et VPN. Vous allez peut-être me trouver parano, mais je trouve logique que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
Je trouve ça illogique. :) Votre remarque sur les icmp redirect RELATED portait à discussion et reste à être exploré. Mais concernant les paquets TCP ou UDP, je ne comprends pas l'intérêt de les filtrer à partir du moment où on a autorisé à initier les connexions dont ils sont en rapport. Un paquet RELATED n'est le résultat que d'une connexion précédemment autorisée, donc voulue dans un firewall correctement construit. Il fut une époque où je faisais de même (je me considérais comme parano et comme je dis souvent, la parano en matière de sécurité est la première des qualités à avoir :) ), filtrer les paquets avant de tester leur état RELATED pour me rendre compte qu'au final ça n'apportait rien. A moins de ne pas avoir confiance au mécanisme conntrack de Netfilter, mais jusqu'à présent je n'ai rien vu qui pouvait le remettre en cause.
-- TiChou
Dans le message <news:40B596E4.85BBD801@free.fr>,
*Annie D.* tapota sur f.c.o.l.configuration :
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED,
non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà
établie. Il en est de même de tous les icmp qui informe d'une erreur ou
d'un problème (destination unreachable, source quench, redirect, time
exceeded, parameter problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème.
On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP
Tout à fait alors qu'au contraire les ICMP sont généralement bienfaisants.
("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me
HACKER !"),
:-)
mais en fait il y en a seulement quelques-uns dont il faille se méfier.
Les ICMP reply qui ne sont pas RELATED et que s'il sont filtrés, ils ne faut
pas systématiquement les bloqués mais plutôt limité leur nombre dans le
temps et limité leur taille.
Et les éventuels ICMP redirect pouvant venir de différentes sources, mais je
vois mal comment ils pourraient se retrouver dans l'état RELATED.
les icmp redirect reçus par le noyau sont par défaut
ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par
Netfilter. Sauf si on prenait la décision de les accepter.
Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet
de configurer cela.
Donc par défaut, sur toutes les nouvelles interfaces créées, les ICMP
redirect sont acceptés. Mais...
Va falloir que je me plonge dans la doc du noyau pour voir comment se
combinent ces deux paramètres.
...mais reste à savoir lequel de ces paramètres prédominent. Si le paramètre
all/accept_redirects l'emporte sur le paramètre interfaceX/accept_redirects.
Je n'ai pour l'instant rien trouvé d'intéressant sur le sujet. Va falloir se
pencher sur le code source du noyau.
Et à quel niveau de la pile IP ils agissent, parce que vous avez peut-être
remarqué qu'il n'y a pas que des machines avec Linux chez moi.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels
problème de sécurité, sont ignorés par défaut et dans un soucis
d'efficacité (c'était d'ailleurs votre préoccupation première à
l'origine) il est donc inutile de traiter séparément les icmp RELATED des
autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime.
Par exemple, j'interdis aussi tout trafic entrant comme sortant avec
certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par
certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN
et VPN. Vous allez peut-être me trouver parano, mais je trouve logique
que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
Je trouve ça illogique. :) Votre remarque sur les icmp redirect RELATED
portait à discussion et reste à être exploré. Mais concernant les paquets
TCP ou UDP, je ne comprends pas l'intérêt de les filtrer à partir du moment
où on a autorisé à initier les connexions dont ils sont en rapport.
Un paquet RELATED n'est le résultat que d'une connexion précédemment
autorisée, donc voulue dans un firewall correctement construit.
Il fut une époque où je faisais de même (je me considérais comme parano et
comme je dis souvent, la parano en matière de sécurité est la première des
qualités à avoir :) ), filtrer les paquets avant de tester leur état RELATED
pour me rendre compte qu'au final ça n'apportait rien. A moins de ne pas
avoir confiance au mécanisme conntrack de Netfilter, mais jusqu'à présent je
n'ai rien vu qui pouvait le remettre en cause.
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Les ICMP "redirect", par exemple, ils peuvent être vus comme RELATED, non ?
Oui et seulement ceux qui sont en rapport avec une connexion déjà établie. Il en est de même de tous les icmp qui informe d'une erreur ou d'un problème (destination unreachable, source quench, redirect, time exceeded, parameter problem).
Ces 4 là sont acceptés si RELATED. Seul le "redirect" me pose problème. On voit beaucoup de paranoïa au sujet de la prétendue nocivité des ICMP
Tout à fait alors qu'au contraire les ICMP sont généralement bienfaisants.
("argh, mon super-firewall a bloqué un vilain ICMP type 8, on veut me HACKER !"),
:-)
mais en fait il y en a seulement quelques-uns dont il faille se méfier.
Les ICMP reply qui ne sont pas RELATED et que s'il sont filtrés, ils ne faut pas systématiquement les bloqués mais plutôt limité leur nombre dans le temps et limité leur taille. Et les éventuels ICMP redirect pouvant venir de différentes sources, mais je vois mal comment ils pourraient se retrouver dans l'état RELATED.
les icmp redirect reçus par le noyau sont par défaut ignorés. Ils ne nécessitent donc pas d'un filtrage particulier par Netfilter. Sauf si on prenait la décision de les accepter. Le paramètre kernel /proc/sys/net/ipv4/conf/all/accept_redirects permet de configurer cela.
Donc par défaut, sur toutes les nouvelles interfaces créées, les ICMP redirect sont acceptés. Mais...
Va falloir que je me plonge dans la doc du noyau pour voir comment se combinent ces deux paramètres.
...mais reste à savoir lequel de ces paramètres prédominent. Si le paramètre all/accept_redirects l'emporte sur le paramètre interfaceX/accept_redirects. Je n'ai pour l'instant rien trouvé d'intéressant sur le sujet. Va falloir se pencher sur le code source du noyau.
Et à quel niveau de la pile IP ils agissent, parce que vous avez peut-être remarqué qu'il n'y a pas que des machines avec Linux chez moi.
A partir du moment où les seuls icmp qui pourraient poser d'éventuels problème de sécurité, sont ignorés par défaut et dans un soucis d'efficacité (c'était d'ailleurs votre préoccupation première à l'origine) il est donc inutile de traiter séparément les icmp RELATED des autres paquets RELATED.
Mais je n'ai pas dit qu'il n'y avait que des ICMP soumis à ce régime. Par exemple, j'interdis aussi tout trafic entrant comme sortant avec certaines plages d'adresses ou avec les ports TCP ou UDP utilisés par certains services comme Netbios, SMB, RPC, etc. sur les interfaces WAN et VPN. Vous allez peut-être me trouver parano, mais je trouve logique que ce filtrage s'applique aussi aux connexions TCP ou UDP RELATED.
Je trouve ça illogique. :) Votre remarque sur les icmp redirect RELATED portait à discussion et reste à être exploré. Mais concernant les paquets TCP ou UDP, je ne comprends pas l'intérêt de les filtrer à partir du moment où on a autorisé à initier les connexions dont ils sont en rapport. Un paquet RELATED n'est le résultat que d'une connexion précédemment autorisée, donc voulue dans un firewall correctement construit. Il fut une époque où je faisais de même (je me considérais comme parano et comme je dis souvent, la parano en matière de sécurité est la première des qualités à avoir :) ), filtrer les paquets avant de tester leur état RELATED pour me rendre compte qu'au final ça n'apportait rien. A moins de ne pas avoir confiance au mécanisme conntrack de Netfilter, mais jusqu'à présent je n'ai rien vu qui pouvait le remettre en cause.
