Mise en place IPTABLES plus de connexions !

chris38 · Février 20, 2016, 5:27pm

nmap me donne maintenant ceci :

[code]server:/home/serveur# nmap 192.168.1.2 -g 80 -P0

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-04-17 21:47 CEST
Interesting ports on server.srv_debian.org (192.168.1.2):
Not shown: 1675 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
113/tcp open auth
631/tcp open ipp
768/tcp open unknown
2049/tcp open nfs

Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds
[/code]

Bizarre le port 768 non ? il faut que je le ferme via iptables par une règle spécifique celui-là ? il ne correspond à rien visiblement !!

PascalHambourg · Février 20, 2016, 5:27pm

Pour voir quel processus a ouvert un port, tu peux utiliser l’option -p de netstat :

Pourquoi devrais-tu le bloquer avec une règle spécifique ? Tu as demandé :

autoriser seulement HTTP et FTP en entrée depuis internet, donc l’accès à ce port est déjà bloqué depuis internet ;
autoriser tout en entrée depuis le LAN, ce qui inclut ce port quel qu’il soit.

Si tu ne voulais pas donner accès à tous les ports depuis le LAN, il fallait le dire !

chris38 · Février 20, 2016, 5:27pm

Difficile de savoir tout, tout de suite, je vais éssayé comme suit et je verrai avec l’utilisation du serveur, merci pour le script.

PascalHambourg · Février 20, 2016, 5:27pm

Il ne s’agit pas de tout savoir mais de cohérence générale. Tu conviendras que l’option “on bloque un port particulier” n’est cohérente ni avec la politique générale côté LAN “on accepte tout” (qui n’est pas aberrante dans le mesure ou si un service tourne, c’est pour qu’il soit utilisé), ni avec celle côté internet “on bloque tout sauf des ports particuliers”. A la limite elle serait cohérente avec une politique “on accepte tout sauf des ports particuliers”, mais cette politique manque elle-même de cohérence : si on veut bloquer l’accès à un service autant arrêter le service lui-même dans la mesure du possible plutôt que bloquer le port. Dans le cas particulier d’un service à usage interne, par exemple une base de données utilisée exclusivement par le serveur web qui tourne sur la machine, il est généralement possible de le configurer pour qu’il n’écoute que sur l’adresse de loopback ou une socket Unix.

A part ça, c’était quoi ce port 768 ?

chris38 · Février 20, 2016, 5:27pm

[quote=“PascalHambourg”]…
A part ça, c’était quoi ce port 768 ? [/quote]

Eh bien je ne sais pas, car en plus je m’apperçois àl’instant que mon partage nfs ne fonctionne pas ,donc je dois règler ce probleme car quand je désactive iptables il fonctionne, mais en plus, le simple fait de rebooter, le port 768 devient 778 cf ce qui suit :

[code]server:/home/serveur# nmap 192.168.1.2 -g 80 -P0

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-04-18 02:57 CEST
Interesting ports on server.srv_debian.org (192.168.1.2):
Not shown: 1675 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
113/tcp open auth
631/tcp open ipp
778/tcp open unknown
2049/tcp open nfs
[/code]

[code]server:/home/serveur# nmap 192.168.1.2 -g 80 -P0

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-04-18 02:57 CEST
Interesting ports on server.srv_debian.org (192.168.1.2):
Not shown: 1675 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
113/tcp open auth
631/tcp open ipp
778/tcp open unknown
2049/tcp open nfs
[/code]
Dois-je créer une ligne pour NFS en ouvrant le port 2049 sur INPUT ?

Ces 2 lignes sont elles corrects en rapport de mon reseau et puis-je les ajoutés ?

iptables -A OUTPUT -o eth0 -s 192.168.1.2 -d 0.0.0.0/0 -p all -m state --state ! INVALID-j ACCEPT iptables -A OUTPUT -i eth0 -s 0.0.0.0/0 -d 192.168.1.2 -p all -m state --state ! RELATED,ESTABLISHED -j ACCEPT
tout en supprimant celle-ci : # autoriser les connexions sortantes vers internet iptables -A OUTPUT -o eth0 -j ACCEPT

PascalHambourg · Février 20, 2016, 5:27pm

C’est peut-être un service RPC enregistré via le portmapper. Tu peux voir la liste avec rpcinfo -p. Je rappelle qu’ont peut voir le process associé avec netstat -anp ou lsof -i.

Tu veux faire du NFS sur l’interface internet (eth0) ? Sinon a priori les règles autorisent déjà toutes les connexions entrantes sur l’interface LAN (eth1).

[quote=“chris38”]Ces 2 lignes sont elles corrects en rapport de mon reseau et puis-je les ajoutés ?

iptables -A OUTPUT -o eth0 -s 192.168.1.2 -d 0.0.0.0/0 -p all -m state --state ! INVALID-j ACCEPT iptables -A OUTPUT -i eth0 -s 0.0.0.0/0 -d 192.168.1.2 -p all -m state --state ! RELATED,ESTABLISHED -j ACCEPT
tout en supprimant celle-ci :

# autoriser les connexions sortantes vers internet iptables -A OUTPUT -o eth0 -j ACCEPT[/quote]
Oui, pourquoi pas, sauf l’espace manquant entre INVALID et -j dans la première règle et OUTPUT au lieu de INPUT dans la seconde. La première règle est juste un peu plus restrictive puisqu’elle bloque les paquets sortants dans l’état INVALID ou avec une adresse source différente de 192.168.1.2. Les options -p all et -s|-p 0.0.0.0/0 ne servent à rien, elles ne font que surcharger l’écriture. Quant à la seconde, elle est redondante puisqu’il y a déjà une règle générale qui accepte les paquets dans l’état ESTABLISHED ou RELATED en entrée.

chris38 · Février 20, 2016, 5:27pm

C’est peut-être un service RPC enregistré via le portmapper. Tu peux voir la liste avec rpcinfo -p. Je rappelle qu’ont peut voir le process associé avec netstat -anp ou lsof -i.

Tu veux faire du NFS sur l’interface internet (eth0) ? Sinon a priori les règles autorisent déjà toutes les connexions entrantes sur l’interface LAN (eth1).
…[/quote]

Non non, c’est bien sur l’interface LAN eth1 que je souhaite faire du nfs, et avec iptables activé ca ne marche pas, désactivé pas de problèmes !

Un rpcinfo -p me donne :
Et cette fois ci c’est les ports 732 et 735

server:/home/serveur# rpcinfo -p program no_version protocole no_port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 32770 nlockmgr 100021 3 udp 32770 nlockmgr 100021 4 udp 32770 nlockmgr 100021 1 tcp 45852 nlockmgr 100021 3 tcp 45852 nlockmgr 100021 4 tcp 45852 nlockmgr 100005 1 udp 732 mountd 100005 1 tcp 735 mountd 100005 2 udp 732 mountd 100005 2 tcp 735 mountd 100005 3 udp 732 mountd 100005 3 tcp 735 mountd 100024 1 udp 32771 status 100024 1 tcp 49981 status

Suivi de :

server:/home/serveur# lsof -i COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME portmap 2507 daemon 3u IPv4 6971 UDP *:sunrpc portmap 2507 daemon 4u IPv4 6974 TCP *:sunrpc (LISTEN) hpiod 2806 root 0u IPv4 7524 TCP localhost:2208 (LISTEN) python 2809 hplip 4u IPv4 7537 TCP localhost:37315 (LISTEN)cupsd 2918 root 2u IPv6 7688 TCP *:ipp (LISTEN) cupsd 2918 root 3u IPv4 7689 TCP *:ipp (LISTEN) cupsd 2918 root 5u IPv4 7692 UDP *:ipp avahi-dae 2997 avahi 13u IPv4 9032 UDP *:mdns avahi-dae 2997 avahi 14u IPv4 9033 UDP *:32768 exim4 3052 Debian-exim 3u IPv4 9119 TCP localhost:smtp (LISTEN) rpc.mount 3100 root 6u IPv4 9296 UDP *:732 rpc.mount 3100 root 7u IPv4 9299 TCP *:735 (LISTEN) inetd 3110 root 4u IPv4 9325 TCP *:auth (LISTEN) rpc.statd 3164 statd 3u IPv4 9444 UDP *:32771 rpc.statd 3164 statd 6u IPv4 9422 UDP *:796 rpc.statd 3164 statd 7u IPv4 9447 TCP *:49981 (LISTEN)

chris38 · Février 20, 2016, 5:28pm

Je viens de faire des essais avec une connexion SSH du client vers le serveur, j’ai le même problème, si le FW est activé je n’ai pas de connexion, si je le désactive, la connexion est active.

[EDIT] Je dois avoir un probleme en local, car iptables activé et les ping des clients sur eth0 ou eth1 ne donnent rien, que des paquets perdues…

PascalHambourg · Février 20, 2016, 5:28pm

Le port qui change est bien enregistré par portmapper, et est lié au service rpc.mountd qui fait partie de nfs-server.

Je ne comprends pas pourquoi les connexions depuis le LAN sont bloquées avec les règles que j’ai données. Tu as vérifié avec iptables-save que les règles en place correspondent bien au script ? Tu peux éventuellement ajouter des règles LOG à la fin des chaînes INPUT et OUTPUT pour voir quels paquets reçus ou émis n’ont pas été acceptés (avec dmesg ou dans /var/log/kern.log) :

iptables -A INPUT -j LOG --log-prefix "DROP_IN " iptables -A OUTPUT -j LOG --log-prefix "DROP_OUT "

Sur les interfaces ou sur les adresses des interfaces, depuis le LAN donc par l’interface eth1 ? J’ai expliqué la différence plus haut. Le ping sur eth0 est bloqué, alors que le ping sur eth1 devrait être accepté, quelle que soit l’adresse de destination.

ripat · Février 20, 2016, 5:28pm

Établir un firewall pour NFS n’est pas simple en raison de ce qui est expliqué plus haut. Quand un deamon RPC de NFS (statd, mountd) démarre il demande un port libre à portmapper. Ce port flottant change à chaque démarrage ce qui rend les règles ipatbles moins ciblées. J’ai résolu ce problème en définissant la fourchette les ports NFS:

[code]# fichier /etc/default/nfs-common
STATDOPTS="–port 32765 --outgoing-port 32766"

fichier /etc/default/nfs-kernel-server

RPCMOUNTDOPTS="-p 32767"
[/code]

Mes règles pour NFS:

# variables
MON_LAN="xxx.xxx.xxx.xxx/24"                # ici le masque de ton réseau LAN
MON_SERVEUR="xxx.xxx.xxx.xxx"               # l'IP de ton serveur

iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p tcp --dport 111 -j ACCEPT
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p udp --dport 111 -j ACCEPT
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p tcp --dport 2049 -j ACCEPT
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p udp --dport 2049 -j ACCEPT
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p tcp --dport 32765:32767 -j ACCEPT
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p udp --dport 32765:32767 -j ACCEPT

Plus de détails:
wiki.debian.org/?SecuringNFS
tldp.org/HOWTO/NFS-HOWTO/sec … #FIREWALLS

chris38 · Février 20, 2016, 5:29pm

[quote=“PascalHambourg”]…
Je ne comprends pas pourquoi les connexions depuis le LAN sont bloquées avec les règles que j’ai données. Tu as vérifié avec iptables-save que les règles en place correspondent bien au script ? Tu peux éventuellement ajouter des règles LOG à la fin des chaînes INPUT et OUTPUT pour voir quels paquets reçus ou émis n’ont pas été acceptés (avec dmesg ou dans /var/log/kern.log) :

iptables -A INPUT -j LOG --log-prefix "DROP_IN " iptables -A OUTPUT -j LOG --log-prefix "DROP_OUT "…[/quote]
Sur les interfaces ou sur les adresses des interfaces, depuis le LAN donc par l’interface eth1 ? J’ai expliqué la différence plus haut. Le ping sur eth0 est bloqué, alors que le ping sur eth1 devrait être accepté, quelle que soit l’adresse de destination.[/quote]

Je ne sais pas si c’est ce que vous attendiez, mais voiçi le résultat d’un log au cours d’un essai de connexion SSH entre un client de mon reseau et mon serveur sur le LAN, le client a pour IP: 192.168.30.12 Le LAN du serveur est sur 192.168.30.1 la commande employée (par nautilus…) est : ssh://sabrina@192.168.30.12 :

8000 Apr 24 03:56:22 srv kernel: DROP_OUT IN= OUT=eth0 SRC=192.168.1.2 DST=213.41.240.205 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=27340 DF PROTO=TCP SPT=38941 DPT=80 WINDOW=4862 RES=0x00 ACK URGP=0 8001 Apr 24 03:56:24 srv kernel: DROP_OUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.255 LEN=206 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=186 8002 Apr 24 03:56:24 srv kernel: DROP_IN IN=eth0 OUT= MAC= SRC=192.168.1.2 DST=192.168.1.255 LEN=206 TOS=0x00 PREC=0 x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=186 8003 Apr 24 03:56:24 srv kernel: DROP_OUT IN= OUT=eth1 SRC=192.168.30.1 DST=192.168.30.255 LEN=200 TOS=0x00 PREC=0x0 0 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=180 8004 Apr 24 03:56:25 srv kernel: DROP_IN IN=eth0 OUT= MAC=00:19:66:63:36:8b:00:16:38:4e:1d:df:08:00 SRC=82.253.168.2 40 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=31135 DF PROTO=TCP SPT=3724 DPT=58400 WINDOW=65535 RES=0 x00 SYN URGP=0 8005 Apr 24 03:56:25 srv kernel: DROP_OUT IN= OUT=eth0 SRC=192.168.1.2 DST=82.253.168.240 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=58400 DPT=3724 WINDOW=0 RES=0x00 ACK RST URGP=0 8006 Apr 24 03:56:26 srv kernel: DROP_IN IN=eth0 OUT= MAC=00:19:66:63:36:8b:00:16:38:4e:1d:df:08:00 SRC=82.253.168.2 40 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=31157 DF PROTO=TCP SPT=3724 DPT=58400 WINDOW=65535 RES=0 x00 SYN URGP=0 8007 Apr 24 03:56:26 srv kernel: DROP_OUT IN= OUT=eth0 SRC=192.168.1.2 DST=82.253.168.240 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=58400 DPT=3724 WINDOW=0 RES=0x00 ACK RST URGP=0 8008 Apr 24 03:56:26 srv kernel: DROP_IN IN=eth0 OUT= MAC=00:19:66:63:36:8b:00:16:38:4e:1d:df:08:00 SRC=89.87.214.17 6 DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=44385 DF PROTO=TCP SPT=4981 DPT=58400 WINDOW=65535 RES=0 x00 SYN URGP=0 8009 Apr 24 03:56:26 srv kernel: DROP_OUT IN= OUT=eth0 SRC=192.168.1.2 DST=89.87.214.176 LEN=40 TOS=0x00 PREC=0x00 T TL=64 ID=0 DF PROTO=TCP SPT=58400 DPT=4981 WINDOW=0 RES=0x00 ACK RST URGP=0
Paradoxalement, vnc fonctionne très bien.

[code]srv:/home/serveur# iptables-save

Generated by iptables-save v1.3.6 on Thu Apr 24 04:18:24 2008

*mangle
:PREROUTING ACCEPT [386902:236764705]
:INPUT ACCEPT [198111]
:FORWARD ACCEPT [188791:147278744]
:OUTPUT ACCEPT [195712]
:POSTROUTING ACCEPT [384497:159482806]
COMMIT

Completed on Thu Apr 24 04:18:24 2008

Generated by iptables-save v1.3.6 on Thu Apr 24 04:18:24 2008

*nat
:PREROUTING ACCEPT [2167:126078]
:POSTROUTING ACCEPT [120:14187]
:OUTPUT ACCEPT [173:23947]
-A POSTROUTING -s 192.168.30.0/255.255.255.0 -o eth0 -j MASQUERADE
COMMIT

Completed on Thu Apr 24 04:18:24 2008

Generated by iptables-save v1.3.6 on Thu Apr 24 04:18:24 2008

*filter
:INPUT DROP [48:9730]
:FORWARD DROP [0:0]
:OUTPUT DROP [53:9760]
-A INPUT -i lo -j ACCEPT
-A INPUT -j LOG --log-prefix "DROP_IN "
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 58400 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 58410 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j LOG --log-prefix "DROP_OUT "
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -o eth1 -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT
COMMIT

Completed on Thu Apr 24 04:18:24 2008

Generated by iptables-save v1.3.6 on Thu Apr 24 04:18:24 2008

*raw
:PREROUTING ACCEPT [387006:236828097]
:OUTPUT ACCEPT [195719]
COMMIT

Completed on Thu Apr 24 04:18:24 2008

[/code]

PascalHambourg · Février 20, 2016, 5:29pm

Les deux règles LOG doivent être placées à la fin de leurs chaînes respectives et non au début, afin de ne voir que les paquets qui n’ont pas été acceptés.
En tout cas ces logs ne montrent aucun trafic SSH ni avec l’adresse 192.168.30.12. On y voit une connexion HTTP avec le serveur de debian-fr, des broadcasts IPP (cups), et des tentatives de connexion refusées sur le port 58400 en provenance de plusieurs adresses sur internet.

Edit : Tu veux ouvrir une session SSH depuis le serveur vers 192.168.30.12 ? Si je ne m’abuse il n’était question d’autoriser que les connexions sortantes VNC sur l’interface LAN, non ? Pour autoriser aussi les connexions SSH vers le LAN il faut ajouter la même règle que pour VNC mais avec le port 22 au lieu de 5900.

chris38 · Février 20, 2016, 5:31pm

Merçi…