Iptables/Debian désignation par ethX ne fonctionne pas

Iptables/Debian désignation par ethX ne fonctionne pas - Logiciels - Linux et OS Alternatifs

Marsh Posté le 26-08-2006 à 17:18:50    

Salut à tous,
 
Je me suis pas mal documenté sur Netfilter et je commence à y voir un peu plus clair.
N'arrivant pas à mettre en place un pare-feu sur ma passerelle internet, j'ai tout essayé...(sauf la bonne solution visiblement  :??: ).
 
*** Ma configuration ***
Je suis sous Debian Sarge / Iptables 1.3.3
1 réseau LAN 192.168.0.0/255.255.255.0 avec pour passerelle vers internet 192.168.1.1(qui possède donc un second interface réseau  d'adresse celle fournie par le FAI).
Mes interfaces réseaux sont les suivants:
  eth0 -> Internet
  eth1 -> LAN
****************************
 
Le problème est très/trop simple:
Si j'ajoute la règle suivante:
mamachine:# /sbin/iptables -A INPUT --in-interface eth0 -j DROP
plus rien ne devrait rentrer par mon interface réseau connectée à internet...pourtant ce n'est nullement le cas puisqu'un  
mamachine:# nmap -sS <mon addresse publique>
affiche une liste d'une vingtaine de ports ouverts dont des services que je ne veux surtout pas accessible par le net, samba par exemple.... c'est plutôt facheux comme situation car je me sens vraiment à découvert :whistle:  
 
Je ne sais vraiment plus quoi tenter et je ne vois vraiment pas ce que j'ai mal fait...peut-être pourrez-vous m'éclairer...?
 
Merci à tous ceux qui essaieront en tout cas  
 :hello:


Message édité par kryzantem le 26-08-2006 à 17:27:49
Reply

Marsh Posté le 26-08-2006 à 17:18:50   

Reply

Marsh Posté le 26-08-2006 à 19:03:22    

iptables -P INPUT DROP
iptables -P OUTPUT DROP
ca va definir une politique restrictive par defaut et ensuite tu autorise ce que tu veux.
Enfin c'est pas tout non plus, il faut faire la meme chose pour les autres tables et chaines.


---------------
BOFH excuse #400:We are Microsoft.  What you are experiencing is not a problem; it is an undocumented feature.
Reply

Marsh Posté le 26-08-2006 à 19:42:30    

met tout ca dans un fichier ou fait voir ton fichier de conf si tu l a deja creer

Reply

Marsh Posté le 26-08-2006 à 20:05:19    

sebchap a écrit :

iptables -P INPUT DROP
iptables -P OUTPUT DROP
ca va definir une politique restrictive par defaut et ensuite tu autorise ce que tu veux.
Enfin c'est pas tout non plus, il faut faire la meme chose pour les autres tables et chaines.


J'ai oublier de préciser: c'est justement ces mêmes politiques restrictives qui sont en application, c'est à n'y rien comprendre  :??:  
 

krifur a écrit :


met tout ca dans un fichier ou fait voir ton fichier de conf si tu l a deja creer


Tu as raison, c'est par là que j'aurai dû commencer.
Mon fichier de conf est en fait un script tout beau tout propre que j'avais écrit avec amour  :love: avant de m'apercevoir que rien ne marchait.. :cry:  
 
Pour simplifier ce script, il suffit que je tape 2 commandes et j'aboutis au même résultat/déception:
 
Avec des politiques permissives PARTOUT dans la table filter, si je tape:
# /sbin/iptables -A INPUT --in-interface eth1 -j ACCEPT
# /sbin/iptables -P INPUT DROP
 
alors, si j'ai bien compris, je devrais pouvoir faire tout ce que je veux sur le serveur à partir de mon LAN (eth1) et ne rien faire du tout à partir d'INTERNET(eth0) pourtant ces deux commandes ne changent absolument rien et un scan de l'une ou l'autre des adresses IP des deux interfaces affiche rigoureusement la même chose c'est à dire une vingtaine de services que l'on ne veut surtout pas accessibles via INTERNET :sweat:  
 
P.S.: Attention à l'ordre dans lequel on tape ces commandes, surtout si on accède via ssh ( heureusement que le serveur n'est qu'à quelques mètres dans mon placard  :p )
 
Merci pour vos réponses ++


Message édité par kryzantem le 26-08-2006 à 20:08:55
Reply

Marsh Posté le 26-08-2006 à 22:36:04    

J ai pas tout compris a ton probleme mais deja avec ce bout de code tu doit pouvoir scanner ta passerelle cote LAN et ne rien avoir cote eth0
 
 

Citation :

#!/bin/sh
 
 
# Activation du forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
 
# Chargement des modules du suivi de connexion
modprobe ip_conntrack        ; # Module principal du suivi de connexion
modprobe ip_conntrack_ftp    ; # Module du suivi de connexion FTP
modprobe ip_conntrack_irc    ; # Module du suivi de connexion IRC
 
# Suppression de toutes les chaines prédéfinit de la table FILTER
iptables -t filter -F
 
# Suppression de toutes les chaines utilisateur de la table FILTER
iptables -t filter -X
 
# Par defaut, toute les paquets sont détruits
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP
 
# Autorise l'interface loopback a dialoguer avec elle-meme
iptables -t filter -A OUTPUT -o lo -j ACCEPT
iptables -t filter -A INPUT  -i lo -j ACCEPT
 
 
# Autorise les connexions avec le réseau 192.168.0.0/24 connecté a  l'interface eth1
iptables -t filter -A OUTPUT -o eth1 -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -t filter -A INPUT  -i eth1 -s 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT


 
sinon
 

Citation :

plus rien ne devrait rentrer par mon interface réseau connectée à internet...pourtant ce n'est nullement le cas puisqu'un  
mamachine:# nmap -sS <mon addresse publique> ...


 
si tu scannes ta machine depuis ton LAN que ce soit avec le nom de ton domaine ou ton adresse ip tu scannes l interface eth1 de ton reseau, si tu veut scanner ton interface internet il faut le faire depuis l exterieur sur un site genre: http://www.grc.com/default.htm (clique sur shields up apres) sinon je peut te scanner si tu veut :hello:  (je suis loin d etre un hackerz)


Message édité par krifur le 27-08-2006 à 06:01:27
Reply

Marsh Posté le 27-08-2006 à 14:29:35    

Mais je ne doute pas un seul instants de ta noble intention  :) !
En tout cas, tu as trouvé la raison de tout ceci ce qui m'aide vraiment!  
Comme tu l'as dit, si je scanne à partir de l'extérieur, j'ai bien les résultats attendus...et donc plus de problème. :D  
 
Quand j'y réfléchis, c'est tout à fait logique car l'accès à eth0 depuis le LAN ne passe pas par ce dernier, d'où le "..-i eth0 -j DROP" qui semblait ne pas être pris en compte..
Par contre un en remplaçant "-i eth0" par "-d <mon_addresse_ip_pub>", là, effectivement le résultat est le même avec un scan interne ou externe, ce qui me permet de bien faire la différence entre ces deux options.
 
Merci beaucoup de ton aide   :hello:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed