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
Voici ma dernière version qui pose moins de soucis. Vos avis? [...]
/sbin/modprobe ip_conntrack_ftp ports!,6438
Aucune règle n'accepte de connexion entrante ni sortante sur le port 6438, je me demande à quoi il sert ici.
[...]
# 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
Le ping est bloqué dans les deux sens, c'est mal, surtout pour un serveur. Et comme dit par d'autres, le DROP systématique de tout ce qui n'est pas accepté, c'est pas terrible question respect des standards.
Je suggère : proto ICMP type echo -> ACCEPT, éventuellement avec une limite raisonnable sur la taille (-m length) et la quantité (-m limit) proto TCP state NEW -> REJECT avec tcp-reset proto UDP state NEW -> REJECT avec icmp-port-unreachable proto ICMP state NEW -> DROP autre proto state NEW -> REJECT avec icmp-proto-unreachable state INVALID -> DROP
Voici ma dernière version qui pose moins de soucis. Vos avis?
[...]
/sbin/modprobe ip_conntrack_ftp ports!,6438
Aucune règle n'accepte de connexion entrante ni sortante sur le port
6438, je me demande à quoi il sert ici.
[...]
# 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
Le ping est bloqué dans les deux sens, c'est mal, surtout pour un
serveur. Et comme dit par d'autres, le DROP systématique de tout ce qui
n'est pas accepté, c'est pas terrible question respect des standards.
Je suggère :
proto ICMP type echo -> ACCEPT, éventuellement avec une limite
raisonnable sur la taille (-m length) et la quantité (-m limit)
proto TCP state NEW -> REJECT avec tcp-reset
proto UDP state NEW -> REJECT avec icmp-port-unreachable
proto ICMP state NEW -> DROP
autre proto state NEW -> REJECT avec icmp-proto-unreachable
state INVALID -> DROP
Voici ma dernière version qui pose moins de soucis. Vos avis? [...]
/sbin/modprobe ip_conntrack_ftp ports!,6438
Aucune règle n'accepte de connexion entrante ni sortante sur le port 6438, je me demande à quoi il sert ici.
[...]
# 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
Le ping est bloqué dans les deux sens, c'est mal, surtout pour un serveur. Et comme dit par d'autres, le DROP systématique de tout ce qui n'est pas accepté, c'est pas terrible question respect des standards.
Je suggère : proto ICMP type echo -> ACCEPT, éventuellement avec une limite raisonnable sur la taille (-m length) et la quantité (-m limit) proto TCP state NEW -> REJECT avec tcp-reset proto UDP state NEW -> REJECT avec icmp-port-unreachable proto ICMP state NEW -> DROP autre proto state NEW -> REJECT avec icmp-proto-unreachable state INVALID -> DROP
octane
[firewall qui est une passoire]
un adepte de Jericho Forum? ;)
Désolé, pas compris. :-
un groupement qui plaide pour la suppression des firewalls.
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.
oui mais dans ces regles de connexions entrantes, cela n'apparait pas (sauf le 2222)
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.
et le ip_conntrack_ftp ?
ok pour la "tentative erronee"
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é.
oui, mais si la machine vient chercher des paquets chez moi,
je peux les signer.
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,
un lien? c'est en general pour tout ce qui est owner, ou l'uid-owner?
et que l'accès au réseau devrait plutôt être contrôlé au niveau de la création des sockets.
idem, un lien? ca m'interesse.
[firewall qui est une passoire]
un adepte de Jericho Forum? ;)
Désolé, pas compris. :-
un groupement qui plaide pour la suppression des firewalls.
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.
oui mais dans ces regles de connexions entrantes, cela n'apparait
pas (sauf le 2222)
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.
et le ip_conntrack_ftp ?
ok pour la "tentative erronee"
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é.
oui, mais si la machine vient chercher des paquets chez moi,
je peux les signer.
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,
un lien? c'est en general pour tout ce qui est owner, ou l'uid-owner?
et que l'accès au réseau devrait plutôt être contrôlé
au niveau de la création des sockets.
un groupement qui plaide pour la suppression des firewalls.
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.
oui mais dans ces regles de connexions entrantes, cela n'apparait pas (sauf le 2222)
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.
et le ip_conntrack_ftp ?
ok pour la "tentative erronee"
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é.
oui, mais si la machine vient chercher des paquets chez moi,
je peux les signer.
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,
un lien? c'est en general pour tout ce qui est owner, ou l'uid-owner?
et que l'accès au réseau devrait plutôt être contrôlé au niveau de la création des sockets.
idem, un lien? ca m'interesse.
Vincent Bernat
OoO En ce doux début de matinée du jeudi 01 juin 2006, vers 08:45, disait:
C'est une possibilité. Mais une bonne distribution devrait signer ses mises à jour avec une clé.
oui, mais si la machine vient chercher des paquets chez moi,
je peux les signer.
Sans doute pas avec la bonne clef... -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)
OoO En ce doux début de matinée du jeudi 01 juin 2006, vers 08:45,
octane@alinto.com disait:
C'est une possibilité. Mais une bonne distribution devrait signer ses
mises à jour avec une clé.
oui, mais si la machine vient chercher des paquets chez moi,
je peux les signer.
Sans doute pas avec la bonne clef...
--
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)
