Je voudrais filtrer les connexions entrantes sur le port 8000 à
l'exception de la machine ayant pour IP 91.121.207.XX, avec iptable j'ai
exécuté les commandes suivantes :
sudo iptables -A INPUT -s 91.121.207.XX -p tcp --destination-port 8000 -m
state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -d 91.121.207.XX -p tcp --source-port 8000 -m state
--state ESTABLISHED -j ACCEPT
Mais le port 8000 reste accessible depuis n'importe quelle machine, quelle
en est la cause ?
Pour plus de sécurité je voudrais que le service n'écoute que sur l'ip
127.0.0.1, comment faire dans ce cas pour rediriger les connexions de
91.121.207.XX sur 127.0.0.1:8000 ?
--
Ce message a été posté avec Nemo : <http://news2.nemoweb.net/?Jid=8757681ccf3ac9ed24f1b2dd22fc4b34a9e3debe@news2.nemoweb.net>
Le Sun, 31 Aug 2014 09:37:18 +0000, Julien Arlandis a écrit :
Autre question, les règles persisteront elles après un redémarrage ?
Non. Sous Debian, il faut installer 'iptables-persistent'. Ça installe un service au démarrage qui appliquera les règles sauvegardées avant le réseau. On l'invoque avec "service iptables-persistent". On lui spécifie "save" pour sauvegarder l'état courant du pare-feu. Ce sera ensuite remis au démarrage suivant.
Si tu as peur de bloquer l'accès distant, voici plusieurs solutions.
1/ Tu programmes un redémarrage (crontab) un peu plus tard. Comme ça, tu es sur que ça reviendra à la normale. Tu es cuit si tu as sauvegardé l'état actuel avec iptables-persistent...
2/ À chaque connexion SSH, tu modifies l'état du système. Par exemple, un touch sur un fichier dans /tmp. Un processus en tâche de fond surveille ça et vide les règles du pare-feu en cas de doute.
3/ Un processus en tâche de fond vérifie une adresse web sur un serveur extérieur que tu contrôles. S'il ne peut plus se connecter il vide le pare-feu. Si l'adresse web n'est plus disponible (404...), c'est que tu l'as voulu. Dans ce cas, vidage du pare-feu....
4/ Trouver un collègue qui passait par là et l'accuser.
Important à savoir : si tu bloques les connexion entrantes (sans ESTABLISHED), la connexion SSH est coupée d'office... Attention à positionner les règles IPv4 (avec 'iptables') et les règles IPv6 (avec 'ip6tables'.
-- Christophe HENRY FR EO EN - http://sbgodin.fr
Le Sun, 31 Aug 2014 09:37:18 +0000, Julien Arlandis a écrit :
Autre question, les règles persisteront elles après un redémarrage ?
Non. Sous Debian, il faut installer 'iptables-persistent'. Ça installe un
service au démarrage qui appliquera les règles sauvegardées avant le
réseau.
On l'invoque avec "service iptables-persistent". On lui spécifie "save"
pour sauvegarder l'état courant du pare-feu. Ce sera ensuite remis au
démarrage suivant.
Si tu as peur de bloquer l'accès distant, voici plusieurs solutions.
1/ Tu programmes un redémarrage (crontab) un peu plus tard. Comme ça, tu
es sur que ça reviendra à la normale. Tu es cuit si tu as sauvegardé
l'état actuel avec iptables-persistent...
2/ À chaque connexion SSH, tu modifies l'état du système. Par exemple, un
touch sur un fichier dans /tmp. Un processus en tâche de fond surveille
ça et vide les règles du pare-feu en cas de doute.
3/ Un processus en tâche de fond vérifie une adresse web sur un serveur
extérieur que tu contrôles. S'il ne peut plus se connecter il vide le
pare-feu. Si l'adresse web n'est plus disponible (404...), c'est que tu
l'as voulu. Dans ce cas, vidage du pare-feu....
4/ Trouver un collègue qui passait par là et l'accuser.
Important à savoir : si tu bloques les connexion entrantes (sans
ESTABLISHED), la connexion SSH est coupée d'office... Attention à
positionner les règles IPv4 (avec 'iptables') et les règles IPv6 (avec
'ip6tables'.
Le Sun, 31 Aug 2014 09:37:18 +0000, Julien Arlandis a écrit :
Autre question, les règles persisteront elles après un redémarrage ?
Non. Sous Debian, il faut installer 'iptables-persistent'. Ça installe un service au démarrage qui appliquera les règles sauvegardées avant le réseau. On l'invoque avec "service iptables-persistent". On lui spécifie "save" pour sauvegarder l'état courant du pare-feu. Ce sera ensuite remis au démarrage suivant.
Si tu as peur de bloquer l'accès distant, voici plusieurs solutions.
1/ Tu programmes un redémarrage (crontab) un peu plus tard. Comme ça, tu es sur que ça reviendra à la normale. Tu es cuit si tu as sauvegardé l'état actuel avec iptables-persistent...
2/ À chaque connexion SSH, tu modifies l'état du système. Par exemple, un touch sur un fichier dans /tmp. Un processus en tâche de fond surveille ça et vide les règles du pare-feu en cas de doute.
3/ Un processus en tâche de fond vérifie une adresse web sur un serveur extérieur que tu contrôles. S'il ne peut plus se connecter il vide le pare-feu. Si l'adresse web n'est plus disponible (404...), c'est que tu l'as voulu. Dans ce cas, vidage du pare-feu....
4/ Trouver un collègue qui passait par là et l'accuser.
Important à savoir : si tu bloques les connexion entrantes (sans ESTABLISHED), la connexion SSH est coupée d'office... Attention à positionner les règles IPv4 (avec 'iptables') et les règles IPv6 (avec 'ip6tables'.
-- Christophe HENRY FR EO EN - http://sbgodin.fr
Pascal Hambourg
Julien Arlandis a écrit :
sudo iptables -A INPUT -p tcp --destination-port 27017 -j DROP
Ce n'était pas le port 8000 ?
Mais maintenant je ne parviens plus à me connecter en local sur le port 8000.
J'ai pourtant rajouté
sudo iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT
où me plantais-je ?
Le filtrage des communications locales est particulier. Lors d'une communication avec une machine distante, les paquets entrants traversent la chaîne INPUT et les paquets sortant la chaîne OUTPUT. Lors d'une communication de la machine avec elle-même, chaque paquet est à la fois sortant et entrant, il traverse donc successivement les deux chaînes OUTPUT et INPUT et doit être accepté dans les deux.
La solution classique et simple consiste à autoriser tout le trafic sur l'interface de loopback avec les règles suivantes en début de chaînes (avant les règles qui bloquent) :
iptables - A INPUT -i lo -j ACCEPT iptables - A OUTPUT -o lo -j ACCEPT
Si tu veux appliquer la même restriction qu'avec les connexions entrantes, il faut dupliquer chaque règle dans les chaînes INPUT et OUTPUT.
iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT
Julien Arlandis a écrit :
sudo iptables -A INPUT -p tcp --destination-port 27017 -j DROP
Ce n'était pas le port 8000 ?
Mais maintenant je ne parviens plus à me connecter en local sur le port
8000.
J'ai pourtant rajouté
sudo iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port
8000 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000
-m state --state ESTABLISHED -j ACCEPT
où me plantais-je ?
Le filtrage des communications locales est particulier. Lors d'une
communication avec une machine distante, les paquets entrants traversent
la chaîne INPUT et les paquets sortant la chaîne OUTPUT. Lors d'une
communication de la machine avec elle-même, chaque paquet est à la fois
sortant et entrant, il traverse donc successivement les deux chaînes
OUTPUT et INPUT et doit être accepté dans les deux.
La solution classique et simple consiste à autoriser tout le trafic sur
l'interface de loopback avec les règles suivantes en début de chaînes
(avant les règles qui bloquent) :
iptables - A INPUT -i lo -j ACCEPT
iptables - A OUTPUT -o lo -j ACCEPT
Si tu veux appliquer la même restriction qu'avec les connexions
entrantes, il faut dupliquer chaque règle dans les chaînes INPUT et OUTPUT.
iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state
--state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state
--state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state
--state ESTABLISHED -j ACCEPT
iptables -A INPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state
--state ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p tcp --destination-port 27017 -j DROP
Ce n'était pas le port 8000 ?
Mais maintenant je ne parviens plus à me connecter en local sur le port 8000.
J'ai pourtant rajouté
sudo iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT
où me plantais-je ?
Le filtrage des communications locales est particulier. Lors d'une communication avec une machine distante, les paquets entrants traversent la chaîne INPUT et les paquets sortant la chaîne OUTPUT. Lors d'une communication de la machine avec elle-même, chaque paquet est à la fois sortant et entrant, il traverse donc successivement les deux chaînes OUTPUT et INPUT et doit être accepté dans les deux.
La solution classique et simple consiste à autoriser tout le trafic sur l'interface de loopback avec les règles suivantes en début de chaînes (avant les règles qui bloquent) :
iptables - A INPUT -i lo -j ACCEPT iptables - A OUTPUT -o lo -j ACCEPT
Si tu veux appliquer la même restriction qu'avec les connexions entrantes, il faut dupliquer chaque règle dans les chaînes INPUT et OUTPUT.
iptables -A INPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -s 127.0.0.1 -p tcp --destination-port 8000 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -d 127.0.0.1 -p tcp --source-port 8000 -m state --state ESTABLISHED -j ACCEPT
