TiChou m'a fait le délicieux honneur de me consacrer quelques minutes de
son précieux temps :
> > Je voulais juste savoir ce que vous pensiez de mes règles pour
> > iptables. Je ne suis pas certain que tout soit fonctionnel mais
> > globalement ça marche :)
>
> Pas comme vous le souhaitiez à priori, voir mes remarques.
L'avis d'un expert est toujours le bienvenu et la demande ne fut pas vaine :)
> Ok mais serait plus efficace en ajoutant le matche limit afin d'éviter
> une inondation des logs en cas de scans ou d'attaques qui peuvent alors
> conduire, selon les performances de la machine, à un déni de service
> du à la surcharge sur gestionnaire de log.
Est-ce que cette ligne vous semble adaptée ?
$IPT -A LOG_DROP -m limit --limit 5/s -j LOG --log-prefix '[DROP] : '
--log-level info
> Si on est puriste et dans un soucis de sécurité maximale, il est
> judicieux de placer les règles qui définissent les polices par défaut
> au tout début, avant toutes autres règles. On évite ainsi durant
> l'initialisation du firewall tout paquet non autorisé.
Soyons puriste... Mais dois-je me soucier de le mettre avant la
définition de LOG_DROP ou bien est-ce inutile ?
> Vous n'avez pas à vous occuper des connexions ftp-data. Il faut laisser
> le module ip_conntrack_ftp suivre les connexions ftp et marquer les
> paquets des connexions ftp-data à l'état RELATED, paquets qui seront
> alors autorisés comme il faut.
Dois-je donc comprendre que seule les deux premières lignes étaient
utiles (sous réserve de modifier le ESTABLISHED plus haut)
> Une remarque supplémentaire tout de même au niveau scripting. Vos deux
> boucles 'for' font la même chose seul les valeurs de départ sont
> différentes.
Merci de m'initier au plaisir du scripting, je débutais
> Sont déjà autorisés précédemment les paquets à l'état ESTABLISHED
> et donc ici vous autorisez les paquets NEW, RELATED mais aussi INVALID.
> Il serait donc préférable d'introduire le matche state dans vos
> règles, comme vous le faisiez plus ou moins dans vos précédentes
> règles :
OK
> bla bla bla
> La majorité de vos règles ne servent à rien
> bla bla bla
> Changez certains trucs
> bla bla bla
En effet, la moitié de ce beau script est inutile :(
> Ici même remarque que Nicolas George ! Je déconseille fortement de
> tout « droper ».
> Je me permets de faire référence à une discussion sur le sujet que
> j'avais eu sur un autre groupe :
Si j'ai bien compris du délicieux lien ci dessus :
il faut utiliser la cible REJECT, l'option --reject-with et le match
limit et l'option --limit ====> L'histoire de reject-with, je ne connais
pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man
iptables :(
Pour finir, puis-je me permettre de vous faire passer à nouveau mon
script dans quelques jours, une fois que ce dernier sera mis à jour afin
d'obtenir à nouveau vos judicieux conseilles ?
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
[Pan s'est foutu dedans avec les références, j'essaie de réparer.]
Non Compos Mentis wrote in message :
Soyons puriste... Mais dois-je me soucier de le mettre avant la définition de LOG_DROP ou bien est-ce inutile ?
Il me semble qu'iptables est prévu pour permettre de mettre des filtres sur des interfaces qui n'existent pas ou ne sont pas encore configurées, de manière à ce que les filtres puissent être en place avant l'activation du réseau.
Si les règles iptables sont définies avant l'activation du réseau, l'ordre dans lequel les règles sont définies ne va rien changer à la sécurité.
il faut utiliser la cible REJECT, l'option --reject-with et le match limit et l'option --limit ====> L'histoire de reject-with, je ne connais pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man iptables :(
Dans la page de man que j'ai (Debian Sarge à jour), ça y est. Mais en général, -j REJECT fait par défaut ce qu'il faut, l'option --reject-with n'est elle-même utile que dans des cas particuliers.
Ceci dit, dans ce thread, mon intervention préférée reste celle de Raphit : un firewall, c'est bien, mais la première chose à faire, c'est s'assurer que les services soient correctement sécurisés.
[Pan s'est foutu dedans avec les références, j'essaie de réparer.]
Non Compos Mentis wrote in message
<pan.2004.07.18.08.32.23.814736@spam.free.fr>:
Soyons puriste... Mais dois-je me soucier de le mettre avant la
définition de LOG_DROP ou bien est-ce inutile ?
Il me semble qu'iptables est prévu pour permettre de mettre des filtres
sur des interfaces qui n'existent pas ou ne sont pas encore configurées,
de manière à ce que les filtres puissent être en place avant
l'activation du réseau.
Si les règles iptables sont définies avant l'activation du réseau,
l'ordre dans lequel les règles sont définies ne va rien changer à la
sécurité.
il faut utiliser la cible REJECT, l'option --reject-with et le match
limit et l'option --limit ====> L'histoire de reject-with, je ne connais
pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man
iptables :(
Dans la page de man que j'ai (Debian Sarge à jour), ça y est. Mais en
général, -j REJECT fait par défaut ce qu'il faut, l'option --reject-with
n'est elle-même utile que dans des cas particuliers.
Ceci dit, dans ce thread, mon intervention préférée reste celle de
Raphit : un firewall, c'est bien, mais la première chose à faire, c'est
s'assurer que les services soient correctement sécurisés.
[Pan s'est foutu dedans avec les références, j'essaie de réparer.]
Non Compos Mentis wrote in message :
Soyons puriste... Mais dois-je me soucier de le mettre avant la définition de LOG_DROP ou bien est-ce inutile ?
Il me semble qu'iptables est prévu pour permettre de mettre des filtres sur des interfaces qui n'existent pas ou ne sont pas encore configurées, de manière à ce que les filtres puissent être en place avant l'activation du réseau.
Si les règles iptables sont définies avant l'activation du réseau, l'ordre dans lequel les règles sont définies ne va rien changer à la sécurité.
il faut utiliser la cible REJECT, l'option --reject-with et le match limit et l'option --limit ====> L'histoire de reject-with, je ne connais pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man iptables :(
Dans la page de man que j'ai (Debian Sarge à jour), ça y est. Mais en général, -j REJECT fait par défaut ce qu'il faut, l'option --reject-with n'est elle-même utile que dans des cas particuliers.
Ceci dit, dans ce thread, mon intervention préférée reste celle de Raphit : un firewall, c'est bien, mais la première chose à faire, c'est s'assurer que les services soient correctement sécurisés.
TiChou
Dans le message <news:, *Non Compos Mentis* tapota sur f.c.o.l.configuration :
Ok mais serait plus efficace en ajoutant le matche limit afin d'éviter une inondation des logs en cas de scans ou d'attaques qui peuvent alors conduire, selon les performances de la machine, à un déni de service du à la surcharge sur gestionnaire de log.
Est-ce que cette ligne vous semble adaptée ? $IPT -A LOG_DROP -m limit --limit 5/s -j LOG --log-prefix '[DROP] : ' --log-level info
Oui, très bien.
Si on est puriste et dans un soucis de sécurité maximale, il est judicieux de placer les règles qui définissent les polices par défaut au tout début, avant toutes autres règles. On évite ainsi durant l'initialisation du firewall tout paquet non autorisé.
Soyons puriste... Mais dois-je me soucier de le mettre avant la définition de LOG_DROP ou bien est-ce inutile ?
Le plus tôt possible, donc avant. Mais comprenez bien que c'est purement théorique et qu'en pratique vous risquez ne jamais rencontrer de problèmes si vos polices par défaut sont définies un peu plus tard dans votre script.
Vous n'avez pas à vous occuper des connexions ftp-data. Il faut laisser le module ip_conntrack_ftp suivre les connexions ftp et marquer les paquets des connexions ftp-data à l'état RELATED, paquets qui seront alors autorisés comme il faut.
Dois-je donc comprendre que seule les deux premières lignes étaient utiles (sous réserve de modifier le ESTABLISHED plus haut)
Seule cette règle devrait suffir :
$IPT -A OUTPUT -o $EXT -p tcp -d $d --dport 21 -m state --state NEW -j ACCEPT
http://groups.google.fr/groups?threadm=
Si j'ai bien compris du délicieux lien ci dessus : il faut utiliser la cible REJECT,
Oui.
Il faut préciser que la cible REJECT n'est pas forcément disponible sur votre système puisqu'il s'agit d'une option du noyau Linux et qui de plus n'était pas disponible dans les premières versions des noyaux 2.4.x.
l'option --reject-with et le match limit et l'option --limit ====> L'histoire de reject-with, je ne connais pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man iptables :(
Comme l'a souligné Nicolas George, la cible REJECT sans l'option --reject-with suffit pour rejeter les connexions TCP et UDP. On peut alors utiliser l'option --reject-with pour rejeter certains types de paquet (par exemple pour rejeter les paquets IPv6, GRE, etc), pour rejeter certains types de connexions (routage par exemple) ou tout simplement pour rejeter des hôtes ou des réseaux.
Pour obtenir la liste des types de rejet :
$ iptables -j REJECT -h
Pour finir, puis-je me permettre de vous faire passer à nouveau mon script dans quelques jours, une fois que ce dernier sera mis à jour afin d'obtenir à nouveau vos judicieux conseilles ?
Oui bien sûr.
Merci pour votre temps,
Avec plaisir.
-- TiChou
Dans le message <news:pan.2004.07.18.08.32.23.814736@spam.free.fr>,
*Non Compos Mentis* tapota sur f.c.o.l.configuration :
Ok mais serait plus efficace en ajoutant le matche limit afin d'éviter
une inondation des logs en cas de scans ou d'attaques qui peuvent alors
conduire, selon les performances de la machine, à un déni de service
du à la surcharge sur gestionnaire de log.
Est-ce que cette ligne vous semble adaptée ?
$IPT -A LOG_DROP -m limit --limit 5/s -j LOG --log-prefix '[DROP] : '
--log-level info
Oui, très bien.
Si on est puriste et dans un soucis de sécurité maximale, il est
judicieux de placer les règles qui définissent les polices par défaut
au tout début, avant toutes autres règles. On évite ainsi durant
l'initialisation du firewall tout paquet non autorisé.
Soyons puriste... Mais dois-je me soucier de le mettre avant la
définition de LOG_DROP ou bien est-ce inutile ?
Le plus tôt possible, donc avant. Mais comprenez bien que c'est purement
théorique et qu'en pratique vous risquez ne jamais rencontrer de problèmes
si vos polices par défaut sont définies un peu plus tard dans votre script.
Vous n'avez pas à vous occuper des connexions ftp-data. Il faut laisser
le module ip_conntrack_ftp suivre les connexions ftp et marquer les
paquets des connexions ftp-data à l'état RELATED, paquets qui seront
alors autorisés comme il faut.
Dois-je donc comprendre que seule les deux premières lignes étaient
utiles (sous réserve de modifier le ESTABLISHED plus haut)
Seule cette règle devrait suffir :
$IPT -A OUTPUT -o $EXT -p tcp -d $d --dport 21 -m state --state NEW
-j ACCEPT
Si j'ai bien compris du délicieux lien ci dessus :
il faut utiliser la cible REJECT,
Oui.
Il faut préciser que la cible REJECT n'est pas forcément disponible sur
votre système puisqu'il s'agit d'une option du noyau Linux et qui de plus
n'était pas disponible dans les premières versions des noyaux 2.4.x.
l'option --reject-with et le match limit et l'option --limit ====>
L'histoire de reject-with, je ne connais pas bien et sauf erreur de ma
part, il n'y a rien sur ce sujet dans man iptables :(
Comme l'a souligné Nicolas George, la cible REJECT sans
l'option --reject-with suffit pour rejeter les connexions TCP et UDP. On
peut alors utiliser l'option --reject-with pour rejeter certains types de
paquet (par exemple pour rejeter les paquets IPv6, GRE, etc), pour rejeter
certains types de connexions (routage par exemple) ou tout simplement pour
rejeter des hôtes ou des réseaux.
Pour obtenir la liste des types de rejet :
$ iptables -j REJECT -h
Pour finir, puis-je me permettre de vous faire passer à nouveau mon
script dans quelques jours, une fois que ce dernier sera mis à jour afin
d'obtenir à nouveau vos judicieux conseilles ?
Dans le message <news:, *Non Compos Mentis* tapota sur f.c.o.l.configuration :
Ok mais serait plus efficace en ajoutant le matche limit afin d'éviter une inondation des logs en cas de scans ou d'attaques qui peuvent alors conduire, selon les performances de la machine, à un déni de service du à la surcharge sur gestionnaire de log.
Est-ce que cette ligne vous semble adaptée ? $IPT -A LOG_DROP -m limit --limit 5/s -j LOG --log-prefix '[DROP] : ' --log-level info
Oui, très bien.
Si on est puriste et dans un soucis de sécurité maximale, il est judicieux de placer les règles qui définissent les polices par défaut au tout début, avant toutes autres règles. On évite ainsi durant l'initialisation du firewall tout paquet non autorisé.
Soyons puriste... Mais dois-je me soucier de le mettre avant la définition de LOG_DROP ou bien est-ce inutile ?
Le plus tôt possible, donc avant. Mais comprenez bien que c'est purement théorique et qu'en pratique vous risquez ne jamais rencontrer de problèmes si vos polices par défaut sont définies un peu plus tard dans votre script.
Vous n'avez pas à vous occuper des connexions ftp-data. Il faut laisser le module ip_conntrack_ftp suivre les connexions ftp et marquer les paquets des connexions ftp-data à l'état RELATED, paquets qui seront alors autorisés comme il faut.
Dois-je donc comprendre que seule les deux premières lignes étaient utiles (sous réserve de modifier le ESTABLISHED plus haut)
Seule cette règle devrait suffir :
$IPT -A OUTPUT -o $EXT -p tcp -d $d --dport 21 -m state --state NEW -j ACCEPT
http://groups.google.fr/groups?threadm=
Si j'ai bien compris du délicieux lien ci dessus : il faut utiliser la cible REJECT,
Oui.
Il faut préciser que la cible REJECT n'est pas forcément disponible sur votre système puisqu'il s'agit d'une option du noyau Linux et qui de plus n'était pas disponible dans les premières versions des noyaux 2.4.x.
l'option --reject-with et le match limit et l'option --limit ====> L'histoire de reject-with, je ne connais pas bien et sauf erreur de ma part, il n'y a rien sur ce sujet dans man iptables :(
Comme l'a souligné Nicolas George, la cible REJECT sans l'option --reject-with suffit pour rejeter les connexions TCP et UDP. On peut alors utiliser l'option --reject-with pour rejeter certains types de paquet (par exemple pour rejeter les paquets IPv6, GRE, etc), pour rejeter certains types de connexions (routage par exemple) ou tout simplement pour rejeter des hôtes ou des réseaux.
Pour obtenir la liste des types de rejet :
$ iptables -j REJECT -h
Pour finir, puis-je me permettre de vous faire passer à nouveau mon script dans quelques jours, une fois que ce dernier sera mis à jour afin d'obtenir à nouveau vos judicieux conseilles ?
