1/ un message d'erreur
iptables v1.2.11: Can't use -P with -A
2/ Si vous voyez des choses a ameliorer
3/ comment faire pour que si la machine reboot le chier soit automatiquement
executé ?
Voici le fichier:
#!/bin/sh
iptables -F
/sbin/modprobe ip_conntrack_ftp ports=21,6438
# default policy : DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback
iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx
#iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
1/ un message d'erreur iptables v1.2.11: Can't use -P with -A
2/ Si vous voyez des choses a ameliorer
3/ comment faire pour que si la machine reboot le chier soit automatiquement executé ?
Voici le fichier:
#!/bin/sh iptables -F
/sbin/modprobe ip_conntrack_ftp ports!,6438
# default policy : DROP iptables -P INPUT DROP iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback iptables -A INPUT -i lo -m state --state NEW -j ACCEPT iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour) iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
Cherche un peu plus avant de poser des questions. Car c'est pas les docs qui manquent sur le sujet ...
clesnews wrote:
Bon pardonnez le fait que je debute.
j'ai crée un fichier nomé firewall.sh
Soucis:
1/ un message d'erreur
iptables v1.2.11: Can't use -P with -A
2/ Si vous voyez des choses a ameliorer
3/ comment faire pour que si la machine reboot le chier soit automatiquement
executé ?
Voici le fichier:
#!/bin/sh
iptables -F
/sbin/modprobe ip_conntrack_ftp ports!,6438
# default policy : DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback
iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx
#iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
1/ un message d'erreur iptables v1.2.11: Can't use -P with -A
2/ Si vous voyez des choses a ameliorer
3/ comment faire pour que si la machine reboot le chier soit automatiquement executé ?
Voici le fichier:
#!/bin/sh iptables -F
/sbin/modprobe ip_conntrack_ftp ports!,6438
# default policy : DROP iptables -P INPUT DROP iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback iptables -A INPUT -i lo -m state --state NEW -j ACCEPT iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
Cherche un peu plus avant de poser des questions. Car c'est pas les docs qui manquent sur le sujet ...
Et toi, tu pourrais apprendre à ne pas citer en entier sans raisons, et à ne pas poster pour ne rien dire.
octane
/sbin/modprobe ip_conntrack_ftp ports!,6438
pourquoi ce parametre ports, et ces chiffres?
Cela suppose que la machine héberge un serveur FTP ou est susceptible de se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438.
oui je sais, mais:
je ne vois pas de règle autorisant explicitement à se connecter sur le port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y reviendrai plus loin.
bah il y a bien eun port 2222 qui parait etrange, mais 2222 != 6438
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:6553 5 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:655 35 -m state --state ESTABLISHED,RELATED -j ACCEPT
en debut de script tu as les memes regles, et ici, tu limite le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état N EW,
ah oui, ca m'avait echappe..
ce qui est pour le moins surprenant (vous avez dit passoire ?). En
un adepte de Jericho Forum? ;)
revanche la seconde règle, pour OUTPUT, est effectivement redondante avec la règle en début de script.
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie,
donc la machine peut renvoyer des paquets dont le port source est superieur a 1024 (clients de la machine?), mais sur un port > 1024. Quel service ecoute sur un port > 1024 sur cette machine?
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour)
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la, une compromission DNS, et hop, la machine va se mettre a jour la ou on le souhaite, avec les paquets que l'on souhaite.
De plus, cela veut dire qu'a tout moment un assaillant potentiel peut effectuer des requetes DNS, et sortir en http, et ftp. Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner, verifie la mise a jour, la charge, et supprime la regle.
/sbin/modprobe ip_conntrack_ftp ports=21,6438
pourquoi ce parametre ports, et ces chiffres?
Cela suppose que la machine héberge un serveur FTP ou est susceptible de
se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438.
oui je sais, mais:
je ne vois pas de règle autorisant explicitement à se connecter sur le
port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y
reviendrai plus loin.
bah il y a bien eun port 2222 qui parait etrange, mais 2222 != 6438
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:6553 5 -m
state --state NEW,ESTABLISHED -j ACCEPT
iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:655 35 -m
state --state ESTABLISHED,RELATED -j ACCEPT
en debut de script tu as les memes regles, et ici, tu limite
le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état N EW,
ah oui, ca m'avait echappe..
ce qui est pour le moins surprenant (vous avez dit passoire ?). En
un adepte de Jericho Forum? ;)
revanche la seconde règle, pour OUTPUT, est effectivement redondante
avec la règle en début de script.
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie,
donc la machine peut renvoyer des paquets dont le port source est
superieur a 1024 (clients de la machine?), mais sur un port > 1024.
Quel service ecoute sur un port > 1024 sur cette machine?
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour)
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la,
une compromission DNS, et hop, la machine va se mettre a jour
la ou on le souhaite, avec les paquets que l'on souhaite.
De plus, cela veut dire qu'a tout moment un assaillant potentiel
peut effectuer des requetes DNS, et sortir en http, et ftp.
Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner,
verifie la mise a jour, la charge, et supprime la regle.
Cela suppose que la machine héberge un serveur FTP ou est susceptible de se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438.
oui je sais, mais:
je ne vois pas de règle autorisant explicitement à se connecter sur le port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y reviendrai plus loin.
bah il y a bien eun port 2222 qui parait etrange, mais 2222 != 6438
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:6553 5 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:655 35 -m state --state ESTABLISHED,RELATED -j ACCEPT
en debut de script tu as les memes regles, et ici, tu limite le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état N EW,
ah oui, ca m'avait echappe..
ce qui est pour le moins surprenant (vous avez dit passoire ?). En
un adepte de Jericho Forum? ;)
revanche la seconde règle, pour OUTPUT, est effectivement redondante avec la règle en début de script.
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie,
donc la machine peut renvoyer des paquets dont le port source est superieur a 1024 (clients de la machine?), mais sur un port > 1024. Quel service ecoute sur un port > 1024 sur cette machine?
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour)
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la, une compromission DNS, et hop, la machine va se mettre a jour la ou on le souhaite, avec les paquets que l'on souhaite.
De plus, cela veut dire qu'a tout moment un assaillant potentiel peut effectuer des requetes DNS, et sortir en http, et ftp. Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner, verifie la mise a jour, la charge, et supprime la regle.
R12y
On Wed, 31 May 2006 05:24:23 -0700, octane wrote:
pourquoi ne pas mettre les IP en dur, dans ce cas la?
Certaines distributions, ou mêmes cerains sites miroirs utilisent un round robin.
# default policy : DROP iptables -P INPUT DROP iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback iptables -A INPUT -i lo -m state --state NEW -j ACCEPT iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
# default policy : DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback
iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx
#iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
# default policy : DROP iptables -P INPUT DROP iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# accepte tout ce qui concerne l'interface loopback iptables -A INPUT -i lo -m state --state NEW -j ACCEPT iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour) iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
R12y
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains préconisent de REJECTer. Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour finir je te déconseille de l'activer par défaut au démarrage. D'une part, en cas de plantage quelconque, le technicien dans le datacenter a besoin de faire des tests et l'activation par défaut de ton script peut fausser ses tests. D'autre part,...
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains
préconisent de REJECTer.
Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour
finir je te déconseille de l'activer par défaut au démarrage. D'une part,
en cas de plantage quelconque, le technicien dans le datacenter a besoin
de faire des tests et l'activation par défaut de ton script peut fausser
ses tests. D'autre part,...
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains préconisent de REJECTer. Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour finir je te déconseille de l'activer par défaut au démarrage. D'une part, en cas de plantage quelconque, le technicien dans le datacenter a besoin de faire des tests et l'activation par défaut de ton script peut fausser ses tests. D'autre part,...
Cela suppose que la machine héberge un serveur FTP ou est susceptible de se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438. Mais je ne vois pas de règle autorisant explicitement à se connecter sur le port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y reviendrai plus loin.
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
qui est cette adresse?
Une adresse "de confiance" pour l'administration, je suppose. De toute façon la ligne est en commentaire.
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
gni?
Oui, pareil. ;-)
en debut de script tu as les memes regles, et ici, tu limite le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état NEW, ce qui est pour le moins surprenant (vous avez dit passoire ?). En revanche la seconde règle, pour OUTPUT, est effectivement redondante avec la règle en début de script.
De toute façon, ces deux règles sont aberrantes. Si c'est pour autoriser les connexions de données FTP, non seulement ça ne marchera pas mais en plus c'est inutile, le module ip_conntrack_ftp et les deux règles acceptant les paquets dans l'état ESTABLISHED ou RELATED sont déjà là pour ça.
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour) iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
Salut,
/sbin/modprobe ip_conntrack_ftp ports!,6438
pourquoi ce parametre ports, et ces chiffres?
Cela suppose que la machine héberge un serveur FTP ou est susceptible de
se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438. Mais
je ne vois pas de règle autorisant explicitement à se connecter sur le
port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y
reviendrai plus loin.
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx
#iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
qui est cette adresse?
Une adresse "de confiance" pour l'administration, je suppose.
De toute façon la ligne est en commentaire.
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m
state --state NEW,ESTABLISHED -j ACCEPT
iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:65535 -m
state --state ESTABLISHED,RELATED -j ACCEPT
gni?
Oui, pareil. ;-)
en debut de script tu as les memes regles, et ici, tu limite
le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état NEW,
ce qui est pour le moins surprenant (vous avez dit passoire ?). En
revanche la seconde règle, pour OUTPUT, est effectivement redondante
avec la règle en début de script.
De toute façon, ces deux règles sont aberrantes. Si c'est pour autoriser
les connexions de données FTP, non seulement ça ne marchera pas mais en
plus c'est inutile, le module ip_conntrack_ftp et les deux règles
acceptant les paquets dans l'état ESTABLISHED ou RELATED sont déjà là
pour ça.
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour)
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
Cela suppose que la machine héberge un serveur FTP ou est susceptible de se connecter à un serveur FTP écoutant sur les ports 21 et/ou 6438. Mais je ne vois pas de règle autorisant explicitement à se connecter sur le port 6438, en entrée comme en sortie. En fait en entrée si, mais j'y reviendrai plus loin.
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx #iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
qui est cette adresse?
Une adresse "de confiance" pour l'administration, je suppose. De toute façon la ligne est en commentaire.
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -t filter -A OUTPUT -P tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
gni?
Oui, pareil. ;-)
en debut de script tu as les memes regles, et ici, tu limite le nombre de port et le protocole?
Regarde mieux la première règle, pour INPUT : elle accepte l'état NEW, ce qui est pour le moins surprenant (vous avez dit passoire ?). En revanche la seconde règle, pour OUTPUT, est effectivement redondante avec la règle en début de script.
De toute façon, ces deux règles sont aberrantes. Si c'est pour autoriser les connexions de données FTP, non seulement ça ne marchera pas mais en plus c'est inutile, le module ip_conntrack_ftp et les deux règles acceptant les paquets dans l'état ESTABLISHED ou RELATED sont déjà là pour ça.
# autoriser les requetes DNS, FTP, HTTP (pour les mises a jour) iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
news
d'autre part?
"R12y" a écrit dans le message de news:
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains préconisent de REJECTer. Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour finir je te déconseille de l'activer par défaut au démarrage. D'une part, en cas de plantage quelconque, le technicien dans le datacenter a besoin de faire des tests et l'activation par défaut de ton script peut fausser ses tests. D'autre part,...
"R12y" <mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit dans le message
de news: pan.2006.05.31.13.01.28.449848@etu.univ-orleans.fr...
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains
préconisent de REJECTer.
Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour
finir je te déconseille de l'activer par défaut au démarrage. D'une part,
en cas de plantage quelconque, le technicien dans le datacenter a besoin
de faire des tests et l'activation par défaut de ton script peut fausser
ses tests. D'autre part,...
On Wed, 31 May 2006 14:49:04 +0200, clesnews wrote:
Voici ma dernière version qui pose moins de soucis.
Quels sont les soucis restants?
Vos avis?
Les paquets qui ne sont donc pas ecceptés sont DROPpés. Certains préconisent de REJECTer. Il y a un vaste débat à ce sujet.
Pour REJECTer, il te suffit d'ajouter une règle en fin de fichier. et pour finir je te déconseille de l'activer par défaut au démarrage. D'une part, en cas de plantage quelconque, le technicien dans le datacenter a besoin de faire des tests et l'activation par défaut de ton script peut fausser ses tests. D'autre part,...
- on répond par en-dessous. - la première raison est suffisante pour un serveur dédié, ce qui est le cas. Mais justement en cas de règles qui ont enfermé le serveur sur lui-même, l'activation au boot n'arrange pas les choses.
- on répond par en-dessous.
- la première raison est suffisante pour un serveur dédié, ce qui est le
cas. Mais justement en cas de règles qui ont enfermé le serveur sur
lui-même, l'activation au boot n'arrange pas les choses.
- on répond par en-dessous. - la première raison est suffisante pour un serveur dédié, ce qui est le cas. Mais justement en cas de règles qui ont enfermé le serveur sur lui-même, l'activation au boot n'arrange pas les choses.
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie, donc la machine peut renvoyer des paquets dont le port source est superieur a 1024 (clients de la machine?), mais sur un port > 1024. Quel service ecoute sur un port > 1024 sur cette machine?
Les exmples de services écoutant sur des ports non privilégiés ne manquent pas. Il suffit de jeter un coup d'oeil à /etc/services. Mais je pense pour ma part que c'était une tentative erronée pour autoriser les connexions de données FTP qui utilisent des ports non privilégiés des deux côtés en mode passif.
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la, une compromission DNS, et hop, la machine va se mettre a jour la ou on le souhaite, avec les paquets que l'on souhaite.
C'est une possibilité. Mais une bonne distribution devrait signer ses mises à jour avec une clé.
De plus, cela veut dire qu'a tout moment un assaillant potentiel peut effectuer des requetes DNS, et sortir en http, et ftp. Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner, verifie la mise a jour, la charge, et supprime la regle.
Je me suis laissé dire que la correspondance 'owner' n'était pas jugée totalement fiable, et que l'accès au réseau devrait plutôt être contrôlé au niveau de la création des sockets.
un adepte de Jericho Forum? ;)
Désolé, pas compris. :-
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie,
donc la machine peut renvoyer des paquets dont le port source est
superieur a 1024 (clients de la machine?), mais sur un port > 1024.
Quel service ecoute sur un port > 1024 sur cette machine?
Les exmples de services écoutant sur des ports non privilégiés ne
manquent pas. Il suffit de jeter un coup d'oeil à /etc/services.
Mais je pense pour ma part que c'était une tentative erronée pour
autoriser les connexions de données FTP qui utilisent des ports non
privilégiés des deux côtés en mode passif.
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la,
une compromission DNS, et hop, la machine va se mettre a jour
la ou on le souhaite, avec les paquets que l'on souhaite.
C'est une possibilité. Mais une bonne distribution devrait signer ses
mises à jour avec une clé.
De plus, cela veut dire qu'a tout moment un assaillant potentiel
peut effectuer des requetes DNS, et sortir en http, et ftp.
Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner,
verifie la mise a jour, la charge, et supprime la regle.
Je me suis laissé dire que la correspondance 'owner' n'était pas jugée
totalement fiable, et que l'accès au réseau devrait plutôt être contrôlé
au niveau de la création des sockets.
le sport et le dport > a 1024, c'est ca qui m'etonne. C'est en sortie, donc la machine peut renvoyer des paquets dont le port source est superieur a 1024 (clients de la machine?), mais sur un port > 1024. Quel service ecoute sur un port > 1024 sur cette machine?
Les exmples de services écoutant sur des ports non privilégiés ne manquent pas. Il suffit de jeter un coup d'oeil à /etc/services. Mais je pense pour ma part que c'était une tentative erronée pour autoriser les connexions de données FTP qui utilisent des ports non privilégiés des deux côtés en mode passif.
mises a jour de quoi?
De la distribution, je suppose, à partir d'un miroir HTTP ou FTP.
pourquoi ne pas mettre les IP en dur, dans ce cas la? Parceque la, une compromission DNS, et hop, la machine va se mettre a jour la ou on le souhaite, avec les paquets que l'on souhaite.
C'est une possibilité. Mais une bonne distribution devrait signer ses mises à jour avec une clé.
De plus, cela veut dire qu'a tout moment un assaillant potentiel peut effectuer des requetes DNS, et sortir en http, et ftp. Je mettrais plutot un cron qui charge la regle avec un -m --uid-owner, verifie la mise a jour, la charge, et supprime la regle.
Je me suis laissé dire que la correspondance 'owner' n'était pas jugée totalement fiable, et que l'accès au réseau devrait plutôt être contrôlé au niveau de la création des sockets.
