Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[résolu] Iptables Vs DHCP Relay

penthium2

voila la configuration Réseaux :

########################################################################################################
#                              PLAN DU RESEAU DE PCP.LOCAL                                             #
########################################################################################################
#      reseau local :                                                                                  #
#      192.168.0.0/24            eth0:192.168.0.254/24 ___ eth1:88.44.22.111/24          reseau FAI :  #
#      _______________________________________________|$> |______________________________88.44.22.0/24 #
#                |                                    |   |server name :                               #
#                |                                    |   |srv-fw.pcp.local                            #
#                |   __ server name :                 |___|SERVER PROXI,NTP,relayDHCP,DNS primaire     #
#                |  |$>|srv-lan.pcp.local               |eth2:192.168.1.254/24                         #
#                |  |  |SERVER NIS Primaire             |                                              #
#                |__|__|SERVER NFS,SAMBA                |                                              #
#                |  eth0:192.168.0.1/24                 |  __ server name:                             #
#                |                                      | |$>|srv-dmz.pcp.local                        #
#                |                                      | |  |SERVER DNS,NIS secondaire                #
#                |                                      |_|__|SERVER DHCP,WEB,FTP anonyme              #
#                |                                      | eth0:192.168.1.1/24                          #
#    ____________|____________                          |                                              #
#      _|_               _|_                            | reseau DMZ :                                 #
#     |c:\|             |$> |                           | 192.168.1.0/24                               #
#     |___|             |___|                                                                          #
#    /____/            /____/                                                                          #
# pc-windows           pc-linux                                                                        #
# eth0:ClientDHCP      eth0:ClientDHCP                                                                 #
#                                                                                                      #
########################################################################################################

Pour information les serveurs sont en Linux/GNU ( symbole "$>" ) et le test DHCP est effectué sur le pc-windows ("c:\").
C'est une maquette sous WMware Player utilisant des VMNET ( équivalent des VLAN pour WMware ).
Le service DHCP est bien entendu stoppé sur srv-lan.pcp.local.

voila les regles IPTABLES que j'ai mis pour tester le relay DHCP :

# Restriction total du reseau sauf loopback

#destruction des tables
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -F

#interdiction des flux
iptables -P INPUT    DROP
iptables -P OUTPUT    DROP
iptables -P FORWARD    DROP

#autorisation des flux loopback
iptables -A INPUT    -i lo    -j ACCEPT
iptables -A OUTPUT    -o lo    -j ACCEPT

et voici la règle pour le flux entre le relais dhcp et le serveur DHCP dans la dmz :

iptables -A OUTPUT -o eth2 -p udp --sport 67 -j ACCEPT

ET le relay marche !!!

Je ne comprends pas comment cela fonctionne puisque je n'ai pas mis de regles INPUT sur eth2 !!!

quelqu'un a t il une explication ?

madko

Tout d'abord un grand merci/bravo pour ton schema, si ça pouvait toujours être aussi clair les questions reseaux ce serait le pied :p

Donne nous le résultat de la commande "iptables -L -v" sur srv-fw.pcp.local pour vraiment voir les règles actuellement chargées plutôt qu'un script de conf. Parce que là je vois pas comment avec des policy par défaut à DROP, en ajoutant juste une règle pour autoriser un flux sortant, que ça puisse faire marcher le dhcrelay.

ps: Si tu ne connais pas shorewall je te le conseille, c'est niquel pour gérer des DMZ.

jlmas

Peut être parce que les IPtables filtrent des IP (niveau 3 de OSI) et que le DHCP fonctionne au niveau des mac address (niveau 2 de OSI), non ?

Pfff, c'est bien loin tout ça...

madko

non dhcp c'est pas niveau 2, ça confirme que c'est très loin 😉

jlmas

madko wrote:non dhcp c'est pas niveau 2, ça confirme que c'est très loin 😉

Effectivement, après verif, c'est bien du niveau 3. Je cours m'enterrer sous une pile de commutateurs en panne pour les 8 prochains mois (avec la RFC 2131) :-P

penthium2

voila :

Chain INPUT (policy DROP 16 packets, 1731 bytes)
pkts    bytes    target    prot    opt    in    out        source            destination
0        0        ACCEPT    all        --    lo    any        anywhere        anywhere

Chain FORWARD (policy DROP 10 packets, 956 bytes)
pkts    bytes    target    prot    opt    in    out        source            destination

Chain OUTPUT (policy DROP 16 packets, 1731 bytes)
pkts    bytes    target    prot    opt    in    out        source            destination
0        0        ACCEPT    all        --    any    lo        anywhere        anywhere
5        1656    ACCEPT    udp        --    any    eth2    anywhere        anywhere        
        udp        dpt:bootps

Et je suis d'accord avec toi madko, je vois pas pourquoi ça marche !!

cette configuration est un exercice que je donne à mes stagiaires, et pour moi ( et mes collègues formateur) ça devrais pas passer... et pourtant si.. et j'ai testé sur 5 maquettes de 5 postes physiques différents..

jlmas

Bon c'est vendredi le jour des suppositions à la con (et des grandes fatigues).

Si le client fait un broadcast en 255.255.255.255 à priori toutes les machines de ton réseau local doivent le recevoir, puisqu'elles sont toute derrière le même routeur. Hormis si la machine srv-fw.pcp.local est un routeur (Tu parles de VMNET, mais sans davantage de précisions)

Je suppose que c'est donc srv-dmz.pcp.local qui lui répond directement sans passer dans srv-fw.pcp.local (et ses filtres). Peut être pourra tu voir quelque chose passer dans les tables mangle (prerouting et postrouting) option -t mangle d'iptables

La solution ultime serait d'installer wireshark sur ton poste client linux et là en épluchant les paquets tu aura la réponse à tes interrogations

penthium2

VMNET = VLAN facon WMware en gros ! donc non ! le trafic passe bien pas le router srv-fw via le service DHCP relay installer sur le routeur.

j'ai sniffé les paquet via TCPdump sur l'interface eth0 et eth2 du router ainsi que sur eth0 de srv-dmz !et oui les paquet sont bien transmit par le relay dhcp au server dhcp dans la dmz, qui donne une ip au client qui est dans le reseau lan via le relay dhcp.

madko

iptables -A OUTPUT -o eth2 -p udp --sport 67 -j ACCEPT

ce n'est pas cohérent avec

Chain INPUT (policy DROP 16 packets, 1731 bytes)
pkts    bytes    target    prot    opt    in    out        source            destination
0        0        ACCEPT    all        --    any    lo        anywhere        anywhere
5        1656    ACCEPT    udp        --    any    eth2    anywhere        anywhere        
        udp        dpt:bootps

Comment une ligne pour l'OUTPUT se retrouve dans INPUT? En tout cas je comprendrais mieux du coup que ça marche avec ça. Quoi que...

Par contre la remarque de jlmas sur l'étanchéité des VMNET n'est pas bête, t'es sûr que c'est si étanche que ça?

sur srv-dmz.pcp.local:

tcpdump -i eth0 -ne port bootps

Lance ensuite une requete dhcp depuis un de tes clients.

penthium2

madko wrote:
Comment une ligne pour l'OUTPUT se retrouve dans INPUT? En tout cas je comprendrais mieux du coup que ça marche avec ça. Quoi que...

Par contre la remarque de jlmas sur l'étanchéité des VMNET n'est pas bête, t'es sûr que c'est si étanche que ça?

sur srv-dmz.pcp.local:
tcpdump -i eth0 -ne port bootps
Lance ensuite une requete dhcp depuis un de tes clients.

Désoler c'est moi qui avais mal refais ce qu'il y avais a l'ecra nde la VM ( mode console = pas de copier coller ) donc la règle est bien dans la table OUTPUT !

niveau etanchéité c'est une piste en effet. mais normalement oui cela l'est..

Je tenterais lundi ( et oui je suis enfin en WE donc j'ai plus les vm sous la main). mais des sniff que j'ai déjà fais, il y a bien un dialogue udp 67 entre srv-fw ( eth2) vers srv-dmz ( eth0 ).

penthium2

voila le resultat de la commande :

tcpdump -i eth0 -ne port bootps

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:48:30.459723 00:0c:29:5b:02:ef > 00:0C:29:0b:4f:56, ethertpye IPv4 (0x0800), length 342: 192.168.1.254.67 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 300
09:48:31.000987 00:0c:29:0b:4f:56 > 00:0C:29:5b:02:ef, ethertpye IPv4 (0x0800), length 342: 192.168.1.1.67 > 192.168.1.254.67: BOOTP/DHCP, Reply, length 300
09:48:31.003035 00:0c:29:5b:02:ef > 00:0C:29:0b:4f:56, ethertpye IPv4 (0x0800), length 358: 192.168.1.254.67 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 316
09:48:31.005740 00:0c:29:0b:4f:56 > 00:0C:29:5b:02:ef, ethertpye IPv4 (0x0800), length 360: 192.168.1.1.67 > 192.168.1.254.67: BOOTP/DHCP, Reply, length 318
4 packets captured
4 packets received by filter
0 packets dropped by kernel

il y a donc bien un dialogue entre le DHCP relay et le serveur DHCP dans la DMZ. On peut donc penser que les VMNETs sont fiable et étanche.

question débile : le service DHCP relay travaillerait pas "avant iptable" donc iptable n'arriverait pas à filtrer les requetes DHCP ?

madko

Non un démon/service ne peut pas travailler avant iptables, sinon ça renderait le parefeu un peu inutile. En tout cas sur mes serveur dhcrelay si je n'ouvre pas les ports 67:68 je n'ai plus de relay.

Fait nous le même genre de tcpdump sur ton srv-fw.pcp.local, mais déjà vu celui que t'as fait sur ton serveur dhcp c'est clair qu'ya du relayage. Mais est-ce que ça serait pas du NAT?

Peux tu nous faire aussi un "iptables -L -v -t nat" sur ton serveur parefeu?

penthium2

iptables -L -v -t nat :

Chain PREROUTING (policy ACCEPT 15676 packets, 2217K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

Chain POSTROUTING (policy ACCEPT 528 packets, 134K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

Chain OUTPUT (policy ACCEPT 1141 packets, 287K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

tcpdumt -i eth2 -ne port bootps :

listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
11:09:09.048784 00:0c:29:5b:02:ef > 00:0C:29:0b:4f:56, ethertpye IPv4 (0x0800), length 342: 192.168.1.254.67 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 300
11:09:13.455159 00:0c:29:5b:02:ef > 00:0C:29:0b:4f:56, ethertpye IPv4 (0x0800), length 342: 192.168.1.254.67 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 300
11:09:13.806712 00:0c:29:0b:4f:56 > 00:0C:29:5b:02:ef, ethertpye IPv4 (0x0800), length 342: 192.168.1.1.67 > 192.168.1.254.67: BOOTP/DHCP, Reply, length 300
11:09:13.807986 00:0c:29:5b:02:ef > 00:0C:29:0b:4f:56, ethertpye IPv4 (0x0800), length 358: 192.168.1.254.67 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 316
11:09:14.812194 00:0c:29:0b:4f:56 > 00:0C:29:5b:02:ef, ethertpye IPv4 (0x0800), length 360: 192.168.1.1.67 > 192.168.1.254.67: BOOTP/DHCP, Reply, length 318
5 packets captured
5 packets received by filter
0 packets dropped by kernel

tcpdump -i eth0 -ne port bootps :

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:09:09.047918 00:0c:29:76:70:ca > 00:0C:29:5b:02:db, ethertpye IPv4 (0x0800), length 342: 192.168.1.150.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 300
11:09:13.454767 00:0c:29:76:70:ca > ff:ff:ff:ff:ff:ff, ethertpye IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 300
11:09:13.806954 00:0C:29:5b:02:db > 00:0c:29:76:70:ca, ethertpye IPv4 (0x0800), length 342: 192.168.0.254.67 > 192.168.0.150.68: BOOTP/DHCP, Reply, length 300
11:09:13.807901 00:0c:29:76:70:ca > ff:ff:ff:ff:ff:ff, ethertpye IPv4 (0x0800), length 358: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:76:70:ca, length 316
11:09:14.812418 00:0C:29:5b:02:db > 00:0c:29:76:70:ca, ethertpye IPv4 (0x0800), length 360: 192.168.0.254.67 > 192.168.0.150.68: BOOTP/DHCP, Reply, length 318
5 packets captured
5 packets received by filter
0 packets dropped by kernel

madko

Là c'est clair qu'il y a du relai. J'ai une plateforme identique pour justement tester du dhcrelay, je ferais un tcpdump tout à l'heure, on pourra comparer mais en effet c'est très étrange.

Mais bon en cherchant sur le net (vu que ça me tracasse aussi cette histoire), il semblerait que vu que les 1er paquets pour la demande dhcp sont en broadcast, et donc pas en destination de ton serveur, dhcp serait bien en fait l'exception (qui confirme la règles) à savoir que le service utilise des raw sockets (pour intercepter tout type de trafic y compris les broadcast) et donc serait en dessous d'iptables. Je cite la doc shorewall que j'utilise justement:

For most operations, DHCP software interfaces to the Linux IP stack at a level below Netfilter. 
Hence, Netfilter (and therefore Shorewall) cannot be used effectively to police DHCP.

Source: http://www.shorewall.net/dhcp.htm

Mais bon shorewall arrive bien à les filtrer, c'est pour ça que je suis pas tombé sur le même problème que toi car je n'ai pas utilisé des règles simples d'iptables.

penthium2

Hum, hum, la c'est net je commence à mieux comprendre le comportement.

Mille merci Madko, travail bien fait.

Je pense que je peux passer ce post en résolut. On a tout de même une explication cohérente.

jlmas

Personnellement je vois aussi ça

Chain PREROUTING (policy ACCEPT 15676 packets, 2217K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

Chain POSTROUTING (policy ACCEPT 528 packets, 134K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

Tu as un gros traffic qui passe sur en PREROUTING et POSTROUTING, et que tu n'as que les règles par défaut, c'est à dire ACCEPT, vu que tu ne filtres que sur INPUT OUTPUT et FORWARD ben le traffic passe...

penthium2

jlmas wrote:Personnellement je vois surtout ça
Chain PREROUTING (policy ACCEPT 15676 packets, 2217K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination

Chain POSTROUTING (policy ACCEPT 528 packets, 134K bytes)
pkts    bytes    target        prot    opt    in    out    source        destination
Tu as un gros traffic qui passe sur en PREROUTING et POSTROUTING, et que tu n'as que les règles par défaut, c'est à dire ACCEPT, vu que tu ne filtres que sur INPUT OUTPUT et FORWARD ben le traffic passe...

je referais le test avec les tables NATs préalablement vidé. pour voir sur y a du NAT durant la phase DHCP.

Mais bon je pense que l'explication de Madko est la bonne..

affaire à suivre après manger

jlmas

Tu as 3 tables en plus de la classique, nat mangle et raw. Après te dire, quel est le rôle de chacune, je ne suis pas assez calé, et le man d'iptables n'est pas très bavard sur le sujet. Il doit y avoir plus de choses sur le site de netfilter.

Regarde ce qu'il passe sur chacune d'entres elles, à titre de curiosité. J'avoue que savoir par ou passe le traffic DHCP m'intrigue aussi 🙂

penthium2

la mangle c'est pour la "tagguage" de trame ( QoS) la raw je sais pas non plus..
mais comme le lien de madko parle de sockets raw, je vais aussi regarder par la.