J'essaye de comprendre comment configurer un peu proprement mes machines
chez moi, et c'est pas gagné... Donc, j'essaye de vous présenter ce que
j'ai comme machines, et ce que je voudrais obtenir comme résultat.
J'ai chez moi un modem ADSL, branché sur cable ethernet. J'ai aussi un
certain nombre de machines, dont l'une en particulier a pour vocation de
servir de passerelle, filtre, serveur de fichiers, ... pour les autres (et
donc de rester allumée en permanence). Mes machines, et en particulier ce
serveur, tournent sous Linux (Debian/testing pour être précis).
Du fait que mon modem sort en ethernet (j'ai pas de ports USB sur mon
serveur !), j'ai des branchements un peu bizarres : le modem est branché
sur le téléphone d'un côté, et sur un hub de l'autre ; mon serveur est
branché sur ce hub ; les autres machines du réseau sont aussi branchées
sur le hub (ou sur un autre hub qui est lui-même branché sur le premier
hub, mais on s'en fiche).
Les machines sont toutes configurées sur un réseau local (avec des IPs en
10.* -- que ce soit statiques ou par DHCP), et tous les adresses
nécessaires à la configuration réseau (DNS, gateway, ...) pointent sur
10.0.0.1, cad le serveur.
Le serveur, lui, démarre la connexion ADSL (par pppoe). Il est le seul à
avoir quelque part mon login/password ADSL.
Est-ce qu'avec une telle config, je peux raisonnablement espérer que
toutes les connexions allant d'une machine à l'extérieur passeront par le
serveur ? Cad que mon réseau soit équivalent à une géométrie de type :
_________ ___________ _______ ______________
téléphone----| modem |====| serveur |====| hub |===| machine(s) |
--------- ----------- ------- --------------
Si c'est bien le cas, il ne me reste plus qu'à configurer le firewall
proprement sur mon serveur. Sinon, euh, je suis mal.
Passons au firewall. Dans un premier temps et pour une config de base (et
pour vérifier que j'ai bien compris comment ça marche !), je voudrais
obtenir, tout simplement, que mes machines puissent se connecter n'importe
où, n'importe comment, mais que personne ne puisse se connecter sur mes
machines depuis l'extérieur, excepté en ssh sur le serveur. Comme
j'utilise iptables, ben je vais causer avec le vocabulaire iptables (c'est
le seul que je comprends vaguement...).
Je me propose donc d'obtenir (pour ce qui est de taper les règles après,
ça va, je pense que j'arriverais à me débrouiller), dans la table FILTER :
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 10.0.0.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
LOG all -- anywhere anywhere
DROP all -- anywhere anywhere
[j'accepte tout ce qui rentre sur le serveur en provenance du réseau
interne, ou d'une connexion déjà établie, ou sur le port 22 (ssh), et je
rejette, en le logguant, tout le reste.]
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- 10.0.0.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere
DROP all -- anywhere anywhere
[je laisse passer tout ce qui vient de l'intérieur, ou d'une connexion
déjà établie, et je loggue puis rejette le reste.]
[en précisant que ça ne s'applique qu'aux paquets qui sortent par ppp0,
cad la connexion vers le modem.]
Est-ce que ça vous semble raisonnable, comme principe ? Faut-il absolument
que je filtre plus siouxement en fonction de l'interface concernée
(sachant que l'exterieur doit correspondre en gros à ppp0, et l'intérieur
à eth0) ? Faut-il aussi que je dise explicitement que j'accepte toujours
tout ce qui vient (ou qui est destiné à) la boucle locale lo, ou est-ce
que ça sera inclus dans les autres règles ?
Ou est-ce que je me plante complet et que je ferais mieux de retourner
cultiver des moutons sur le Larzac ?
Merci de vos commentaires/aides !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Remi Moyen wrote in message :
Est-ce qu'avec une telle config, je peux raisonnablement espérer que toutes les connexions allant d'une machine à l'extérieur passeront par le serveur ? Cad que mon réseau soit équivalent à une géométrie de type : _________ ___________ _______ ______________ téléphone----| modem |====| serveur |====| hub |===| machine(s) | --------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il, sont plus transparents, et risquent de propager des paquets censés locaux sur la ligne ADSL. Si le hub est en fait un switch, même rudimentaire, ce ne seront que les paquets de broadcast, essentiellement l'ARP, donc ce n'est pas forcément grave. J'ai déjà fait ça avec une freebox (qui se comporte comme un lien ethernet, et pas PPPoE, mais c'est pareil), et ça ne pose pas de problème. Ça laisse filtrer un peu d'information au FAI, mais fondamentalement il s'en fiche.
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer des ping de broadcast, et surveiller les voyants du modem.
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Ça me semble raisonnable.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que ça peut apporter, à part une possibilité pour un attaquant de saturer les disques durs en plus de la bande passante.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT. Il y a bien des cas particulier où DROP s'impose, mais la plupart du temps, il fait perdre de la bande passante (un ICMP de rejet d'upload, c'est certainement plus petit qu'une dizaine de paquets de ré-essai), et du temps à quelqu'un qui est là par erreur. Et comme de toutes façons il y a un serveur SSH qui répond, il est illusoire d'espérer être totalement furtif.
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 10.0.0.0/24 anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED LOG all -- anywhere anywhere DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque les REJECT sont déjà envoyés).
Si l'IP de la connexion ADSL est fixe, c'est SNAT qu'il faut utiliser. Si elle n'est pas fixe... je n'ai pas l'habitude, je cède la parole à d'autres.
Remi Moyen wrote in message
<Pine.LNX.4.61.0411081146250.1463@pbeanf.raft.vacy-anapl.se>:
Est-ce qu'avec une telle config, je peux raisonnablement espérer que
toutes les connexions allant d'une machine à l'extérieur passeront par le
serveur ? Cad que mon réseau soit équivalent à une géométrie de type :
_________ ___________ _______ ______________
téléphone----| modem |====| serveur |====| hub |===| machine(s) |
--------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les
paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça
marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il,
sont plus transparents, et risquent de propager des paquets censés locaux
sur la ligne ADSL. Si le hub est en fait un switch, même rudimentaire, ce ne
seront que les paquets de broadcast, essentiellement l'ARP, donc ce n'est
pas forcément grave. J'ai déjà fait ça avec une freebox (qui se comporte
comme un lien ethernet, et pas PPPoE, mais c'est pareil), et ça ne pose pas
de problème. Ça laisse filtrer un peu d'information au FAI, mais
fondamentalement il s'en fiche.
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer
des ping de broadcast, et surveiller les voyants du modem.
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces
paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de
devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Ça me semble raisonnable.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que
ça peut apporter, à part une possibilité pour un attaquant de saturer les
disques durs en plus de la bande passante.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT. Il y a bien des cas particulier
où DROP s'impose, mais la plupart du temps, il fait perdre de la bande
passante (un ICMP de rejet d'upload, c'est certainement plus petit qu'une
dizaine de paquets de ré-essai), et du temps à quelqu'un qui est là par
erreur. Et comme de toutes façons il y a un serveur SSH qui répond, il est
illusoire d'espérer être totalement furtif.
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- 10.0.0.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere
DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque
les REJECT sont déjà envoyés).
Est-ce qu'avec une telle config, je peux raisonnablement espérer que toutes les connexions allant d'une machine à l'extérieur passeront par le serveur ? Cad que mon réseau soit équivalent à une géométrie de type : _________ ___________ _______ ______________ téléphone----| modem |====| serveur |====| hub |===| machine(s) | --------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il, sont plus transparents, et risquent de propager des paquets censés locaux sur la ligne ADSL. Si le hub est en fait un switch, même rudimentaire, ce ne seront que les paquets de broadcast, essentiellement l'ARP, donc ce n'est pas forcément grave. J'ai déjà fait ça avec une freebox (qui se comporte comme un lien ethernet, et pas PPPoE, mais c'est pareil), et ça ne pose pas de problème. Ça laisse filtrer un peu d'information au FAI, mais fondamentalement il s'en fiche.
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer des ping de broadcast, et surveiller les voyants du modem.
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Ça me semble raisonnable.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que ça peut apporter, à part une possibilité pour un attaquant de saturer les disques durs en plus de la bande passante.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT. Il y a bien des cas particulier où DROP s'impose, mais la plupart du temps, il fait perdre de la bande passante (un ICMP de rejet d'upload, c'est certainement plus petit qu'une dizaine de paquets de ré-essai), et du temps à quelqu'un qui est là par erreur. Et comme de toutes façons il y a un serveur SSH qui répond, il est illusoire d'espérer être totalement furtif.
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 10.0.0.0/24 anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED LOG all -- anywhere anywhere DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque les REJECT sont déjà envoyés).
Si l'IP de la connexion ADSL est fixe, c'est SNAT qu'il faut utiliser. Si elle n'est pas fixe... je n'ai pas l'habitude, je cède la parole à d'autres.
Remi Moyen
On Tue, 9 Nov 2004, Nicolas George wrote:
Est-ce qu'avec une telle config, je peux raisonnablement espérer que toutes les connexions allant d'une machine à l'extérieur passeront par le serveur ? Cad que mon réseau soit équivalent à une géométrie de type : _________ ___________ _______ ______________ téléphone----| modem |====| serveur |====| hub |==| machine(s) | --------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il, sont plus transparents, et risquent de propager des paquets censés locaux sur la ligne ADSL.
Ah, d'accord. Je ne pensais pas que ça dépendait du type de modem.
Si le hub est en fait un switch, même rudimentaire,
Ce n'est pas le cas, du moins à ma connaissance. C'est vraiment le hub bas de gamme, le moins cher, donc je serais très surpris qu'il ait la moindre fonction de switch...
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer des ping de broadcast, et surveiller les voyants du modem.
Oui, je vois. Bon, je testerais.
Au passage, il est possible que je change de modem pour un modem-routeur avec sorties wifi (et ethernet). Outre les questions de configuration du wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je peux espérer reproduire le même comportement qu'actuellement (cad tout router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou est-ce qu'il faudra absolument que je configure le firewall directement sur le modem (si il en a un !) ?
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les connexions sur autre chose que ssh, venant de l'intérieur comme de l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
Note que je peux aussi ouvrir spécifiquement le port du serveur nfs (ou autre serveur interne) pour les IPs en 10.*, et c'est tout.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que ça peut apporter, à part une possibilité pour un attaquant de saturer les disques durs en plus de la bande passante.
Euh, oui. Une habitude que j'ai prise de logguer tout ce que je rejette. Mais effectivement, peut-être un peu abusif dans ce cas.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début) les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Ah non, j'avais mal cherché. Y'a bien un target REJECT, mais qui est dans les targets inclus dans d'autres modules (mais standards...). Bon, d'accord. Si j'avais eu lu correctement, j'aurais mis REJECT dès le début.
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 10.0.0.0/24 anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED LOG all -- anywhere anywhere DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque les REJECT sont déjà envoyés).
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD ?
[Euh, je vois pas trop quoi filtrer dans ce qui sort du serveur, donc j'accepte tout. Dans ce cas, une policy ACCEPT serait équivalente, je suppose.]
Oui, une policy ACCEPT ferait la même chose, et peut-être un peu plus efficacement.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère demander.
Si l'IP de la connexion ADSL est fixe, c'est SNAT qu'il faut utiliser. Si elle n'est pas fixe... je n'ai pas l'habitude, je cède la parole à d'autres.
Oui, c'est une IP variable (par 24h). Note que je ne pige pas du tout la différence entre MASQUERADE et SNAT, à part que c'est marqué dans le man que je dois utiliser l'un en IP variable et l'autre en IP fixe...
Merci pour tes commentaires ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Tue, 9 Nov 2004, Nicolas George wrote:
Est-ce qu'avec une telle config, je peux raisonnablement espérer que
toutes les connexions allant d'une machine à l'extérieur passeront par le
serveur ? Cad que mon réseau soit équivalent à une géométrie de type :
_________ ___________ _______ ______________
téléphone----| modem |====| serveur |====| hub |==| machine(s) |
--------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les
paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça
marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il,
sont plus transparents, et risquent de propager des paquets censés locaux
sur la ligne ADSL.
Ah, d'accord. Je ne pensais pas que ça dépendait du type de modem.
Si le hub est en fait un switch, même rudimentaire,
Ce n'est pas le cas, du moins à ma connaissance. C'est vraiment le hub bas
de gamme, le moins cher, donc je serais très surpris qu'il ait la moindre
fonction de switch...
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer
des ping de broadcast, et surveiller les voyants du modem.
Oui, je vois. Bon, je testerais.
Au passage, il est possible que je change de modem pour un modem-routeur
avec sorties wifi (et ethernet). Outre les questions de configuration du
wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je
peux espérer reproduire le même comportement qu'actuellement (cad tout
router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou
est-ce qu'il faudra absolument que je configure le firewall directement
sur le modem (si il en a un !) ?
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces
paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de
devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les
connexions sur autre chose que ssh, venant de l'intérieur comme de
l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
Note que je peux aussi ouvrir spécifiquement le port du serveur nfs (ou
autre serveur interne) pour les IPs en 10.*, et c'est tout.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que
ça peut apporter, à part une possibilité pour un attaquant de saturer les
disques durs en plus de la bande passante.
Euh, oui. Une habitude que j'ai prise de logguer tout ce que je rejette.
Mais effectivement, peut-être un peu abusif dans ce cas.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y
a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de
fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début)
les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Ah non, j'avais mal cherché. Y'a bien un target REJECT, mais qui est dans
les targets inclus dans d'autres modules (mais standards...). Bon,
d'accord. Si j'avais eu lu correctement, j'aurais mis REJECT dès le début.
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- 10.0.0.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere
DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque
les REJECT sont déjà envoyés).
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au
travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD
?
[Euh, je vois pas trop quoi filtrer dans ce qui sort du serveur, donc
j'accepte tout. Dans ce cas, une policy ACCEPT serait équivalente, je
suppose.]
Oui, une policy ACCEPT ferait la même chose, et peut-être un peu plus
efficacement.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas
comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère
demander.
Si l'IP de la connexion ADSL est fixe, c'est SNAT qu'il faut utiliser. Si
elle n'est pas fixe... je n'ai pas l'habitude, je cède la parole à d'autres.
Oui, c'est une IP variable (par 24h). Note que je ne pige pas du tout la
différence entre MASQUERADE et SNAT, à part que c'est marqué dans le man
que je dois utiliser l'un en IP variable et l'autre en IP fixe...
Merci pour tes commentaires !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Est-ce qu'avec une telle config, je peux raisonnablement espérer que toutes les connexions allant d'une machine à l'extérieur passeront par le serveur ? Cad que mon réseau soit équivalent à une géométrie de type : _________ ___________ _______ ______________ téléphone----| modem |====| serveur |====| hub |==| machine(s) | --------- ----------- ------- --------------
Ça dépend du type de modem. Certains ne se sentent concernés que par les paquets dont le type ethernet correspond à du PPPoE, et dans ce cas ça marche parfaitement (c'est ce que j'ai actuellement). D'autres, paraît-il, sont plus transparents, et risquent de propager des paquets censés locaux sur la ligne ADSL.
Ah, d'accord. Je ne pensais pas que ça dépendait du type de modem.
Si le hub est en fait un switch, même rudimentaire,
Ce n'est pas le cas, du moins à ma connaissance. C'est vraiment le hub bas de gamme, le moins cher, donc je serais très surpris qu'il ait la moindre fonction de switch...
Le mieux serait d'essayer : brancher le modem et deux ordinateurs, lancer des ping de broadcast, et surveiller les voyants du modem.
Oui, je vois. Bon, je testerais.
Au passage, il est possible que je change de modem pour un modem-routeur avec sorties wifi (et ethernet). Outre les questions de configuration du wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je peux espérer reproduire le même comportement qu'actuellement (cad tout router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou est-ce qu'il faudra absolument que je configure le firewall directement sur le modem (si il en a un !) ?
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les connexions sur autre chose que ssh, venant de l'intérieur comme de l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
Note que je peux aussi ouvrir spécifiquement le port du serveur nfs (ou autre serveur interne) pour les IPs en 10.*, et c'est tout.
LOG all -- anywhere anywhere
Est-il vraiment nécessaire de tout loguer ? Je ne vois pas vraiment ce que ça peut apporter, à part une possibilité pour un attaquant de saturer les disques durs en plus de la bande passante.
Euh, oui. Une habitude que j'ai prise de logguer tout ce que je rejette. Mais effectivement, peut-être un peu abusif dans ce cas.
DROP all -- anywhere anywhere
En général, il vaut mieux utiliser REJECT.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début) les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Ah non, j'avais mal cherché. Y'a bien un target REJECT, mais qui est dans les targets inclus dans d'autres modules (mais standards...). Bon, d'accord. Si j'avais eu lu correctement, j'aurais mis REJECT dès le début.
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 10.0.0.0/24 anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED LOG all -- anywhere anywhere DROP all -- anywhere anywhere
Je pense que c'est bon. Là, DROP ne pose pas vraiment de problèmes (puisque les REJECT sont déjà envoyés).
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD ?
[Euh, je vois pas trop quoi filtrer dans ce qui sort du serveur, donc j'accepte tout. Dans ce cas, une policy ACCEPT serait équivalente, je suppose.]
Oui, une policy ACCEPT ferait la même chose, et peut-être un peu plus efficacement.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère demander.
Si l'IP de la connexion ADSL est fixe, c'est SNAT qu'il faut utiliser. Si elle n'est pas fixe... je n'ai pas l'habitude, je cède la parole à d'autres.
Oui, c'est une IP variable (par 24h). Note que je ne pige pas du tout la différence entre MASQUERADE et SNAT, à part que c'est marqué dans le man que je dois utiliser l'un en IP variable et l'autre en IP fixe...
Merci pour tes commentaires ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Remi Moyen
On Tue, 9 Nov 2004, Nicolas George wrote:
Je pense que j'avais mal compris ta réponse, je me corrige (au fait, on peut faire des supersedes dans un forum modéré ?) :
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Par "interface locale", tu voulais dire "l'interface connectée au réseau interne", et pas la boucle locale (lo), n'est-ce pas ?
Si c'est bien ça, ne tiens pas compte de ma réponse précédente (où j'avais compris "interface locale" = lo), je comprends ce que tu voulais dire, et je suis d'accord avec ta remarque. -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Tue, 9 Nov 2004, Nicolas George wrote:
Je pense que j'avais mal compris ta réponse, je me corrige (au fait, on
peut faire des supersedes dans un forum modéré ?) :
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces
paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de
devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Par "interface locale", tu voulais dire "l'interface connectée au réseau
interne", et pas la boucle locale (lo), n'est-ce pas ?
Si c'est bien ça, ne tiens pas compte de ma réponse précédente (où j'avais
compris "interface locale" = lo), je comprends ce que tu voulais dire, et
je suis d'accord avec ta remarque.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Il serait bon, à mon avis, de n'accepter que sur l'interface locale ces paquets-là. C'est quelques caractères en plus dans la règle, et ça évite de devoir faire confiance au FAI pour ne pas router de paquets en 10.0.0.0/24.
Par "interface locale", tu voulais dire "l'interface connectée au réseau interne", et pas la boucle locale (lo), n'est-ce pas ?
Si c'est bien ça, ne tiens pas compte de ma réponse précédente (où j'avais compris "interface locale" = lo), je comprends ce que tu voulais dire, et je suis d'accord avec ta remarque. -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Nicolas George
Remi Moyen wrote in message :
Au passage, il est possible que je change de modem pour un modem-routeur avec sorties wifi (et ethernet). Outre les questions de configuration du wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je peux espérer reproduire le même comportement qu'actuellement (cad tout router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou est-ce qu'il faudra absolument que je configure le firewall directement sur le modem (si il en a un !) ?
J'ai bien peur qu'il faille faire tout sur le modem-routeur. Il doit être possible de faire ça en deux fois pour les ports ethernet, avec un réseau virtuellement de la forme (machines locales) -> (routeur) -> (modem routeur), mais ça risque de ne pas marcher pour le wifi. Cependant, avec un bon choix du modem-routeur, il n'y a pas forcément à se faire de soucis.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les connexions sur autre chose que ssh, venant de l'intérieur comme de l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
C'était bien de l'interface réseau du LAN que je parlais, le malentendu est dissipé dans le message cousin.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début) les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Si je me souviens bien, ce qui avait été dit, c'est que REJECT n'est disponible que sur les noyaux assez récents (de l'ordre du milieu des 2.3, quand même), et si l'option a été correctement cochée. Et ce n'est pas disponible non plus comme politique par défaut.
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD ?
Hum, je me suis trompé, effectivement. Oublier ce paragraphe.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère demander.
Le filtrage sur la chaîne OUTPUT, c'est vraiment atypique. Mais surtout, entre interdire par défaut et tout autoriser d'une part, et autoriser par défaut, il n'y a au final aucune différence.
Remi Moyen wrote in message
<Pine.LNX.4.61.0411090953160.1463@pbeanf.raft.vacy-anapl.se>:
Au passage, il est possible que je change de modem pour un modem-routeur
avec sorties wifi (et ethernet). Outre les questions de configuration du
wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je
peux espérer reproduire le même comportement qu'actuellement (cad tout
router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou
est-ce qu'il faudra absolument que je configure le firewall directement
sur le modem (si il en a un !) ?
J'ai bien peur qu'il faille faire tout sur le modem-routeur. Il doit être
possible de faire ça en deux fois pour les ports ethernet, avec un réseau
virtuellement de la forme (machines locales) -> (routeur) -> (modem
routeur), mais ça risque de ne pas marcher pour le wifi. Cependant, avec un
bon choix du modem-routeur, il n'y a pas forcément à se faire de soucis.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les
connexions sur autre chose que ssh, venant de l'intérieur comme de
l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
C'était bien de l'interface réseau du LAN que je parlais, le malentendu est
dissipé dans le message cousin.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y
a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de
fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début)
les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Si je me souviens bien, ce qui avait été dit, c'est que REJECT n'est
disponible que sur les noyaux assez récents (de l'ordre du milieu des 2.3,
quand même), et si l'option a été correctement cochée. Et ce n'est pas
disponible non plus comme politique par défaut.
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au
travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD
?
Hum, je me suis trompé, effectivement. Oublier ce paragraphe.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas
comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère
demander.
Le filtrage sur la chaîne OUTPUT, c'est vraiment atypique. Mais surtout,
entre interdire par défaut et tout autoriser d'une part, et autoriser par
défaut, il n'y a au final aucune différence.
Au passage, il est possible que je change de modem pour un modem-routeur avec sorties wifi (et ethernet). Outre les questions de configuration du wifi (pour pas que mon réseau soit ouvert dans la rue...), est-ce que je peux espérer reproduire le même comportement qu'actuellement (cad tout router vers le serveur, qui filtre et ré-envoye ensuite vers le modem), ou est-ce qu'il faudra absolument que je configure le firewall directement sur le modem (si il en a un !) ?
J'ai bien peur qu'il faille faire tout sur le modem-routeur. Il doit être possible de faire ça en deux fois pour les ports ethernet, avec un réseau virtuellement de la forme (machines locales) -> (routeur) -> (modem routeur), mais ça risque de ne pas marcher pour le wifi. Cependant, avec un bon choix du modem-routeur, il n'y a pas forcément à se faire de soucis.
Oui, mais ça veut dire aussi que mon serveur n'acceptera plus les connexions sur autre chose que ssh, venant de l'intérieur comme de l'exterieur. Par exemple, fini mon serveur nfs (intérieur). Non ?
C'était bien de l'interface réseau du LAN que je parlais, le malentendu est dissipé dans le message cousin.
J'avais cru lire dans un message (sur fr.comp.os.linux.configuration, il y a de ça plusieurs mois) que REJECT n'existait pas/plus sur iptables. Et de fait, le man de iptables mentionne (dans la rubrique "TARGETS", au début) les cibles "ACCEPT, DROP, QUEUE, or RETURN", et c'est tout.
Si je me souviens bien, ce qui avait été dit, c'est que REJECT n'est disponible que sur les noyaux assez récents (de l'ordre du milieu des 2.3, quand même), et si l'option a été correctement cochée. Et ce n'est pas disponible non plus comme politique par défaut.
Uh ? Pourquoi ? Un paquet qui passe au travers de FORWARD passe d'abord au travers de INPUT ? Je croyais qu'il ne passait *que* au travers de FORWARD ?
Hum, je me suis trompé, effectivement. Oublier ce paragraphe.
Et ça n'est pas une grave erreur que de tout accepter ici ? Je ne vois pas comment ça serait le cas, mais bon, vu que je connais pas trop, je préfère demander.
Le filtrage sur la chaîne OUTPUT, c'est vraiment atypique. Mais surtout, entre interdire par défaut et tout autoriser d'une part, et autoriser par défaut, il n'y a au final aucune différence.
