Forum Linux.général Iptables et restrictions horaires

Posté par  .
Étiquettes : aucune
0
13
avr.
2010
Bonjour,

J'ai un petit réseau local perso, avec un serveur/passerelle/pare-feu (debian 4.0, iptables 1.3.6) qui fonctionne parfaitement depuis pas mal de temps déjà.
J'ai un script iptables qui fonctionne très bien lui aussi depuis longtemps (accès web/mail/ssh/ftp, partage connexion).

J'ai voulu mettre en place un contrôle de l'utilisation du net par 2 de mes pc locaux, en coupant l'accès à certaines heures, mais cela ne fonctionne pas.

Mon pare-feu est composé de 2 interfaces:

[Internet] --- [eth1]<==>[passerelle]<===>[eth0]---[mon réseau local]

J'ai pas mal cherché sur le net, et j'ai d'abord tenté une restrictions sur les IP, de cette façon:

# coupure IP 1
$IPTABLES -I INPUT -p all -s 192.168.0.100 -j DROP
$IPTABLES -I OUTPUT -p all -d 192.168.0.100 -j DROP
$IPTABLES -I FORWARD -p all -d 192.168.0.100 -j DROP

# coupure IP 2
$IPTABLES -I INPUT -p all -s 192.168.0.115 -j DROP
$IPTABLES -I OUTPUT -p all -d 192.168.0.115 -j DROP
$IPTABLES -I FORWARD -p all -d 192.168.0.115 -j DROP


Les règles sont bien mises en premier, mais apparament cela n'empêche pas les 2 PC de continuer à surfer ...

Voyant que cela ne fonctionnait pas, j'ai ensuite tenté une restriction sur l'adresse MAC de cette façon:

# coupure pc 1
$IPTABLES -I INPUT -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP
$IPTABLES -I FORWARD -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP
$IPTABLES -t nat -I PREROUTING -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP

# coupure pc 2
$IPTABLES -I INPUT -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP
$IPTABLES -I FORWARD -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP
$IPTABLES -t nat -I PREROUTING -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP


(les adresses mac sont correctes, je me permet de les masquer ici)

La aussi, les règles sont correctement insérées en première position dans les diverses tables d'iptables, mais la aussi cela ne fonctionne pas, les PC continuent à surfer malgré cela.

J'avoue que je sèche un peu la, j'en appelle à votre expertise,

Merci d'avance de vos avis.
  • # Améliorations

    Posté par  . Évalué à 3.

    Cela ne va pas résoudre ton problème mais tu devrais utiliser la table NAT au lieu de la table FILTER, ce qui te permet d'avoir une règle pour tout bloquer: http://jengelh.medozas.de/images/nf-packet-flow.png

    iptables -t NAT -I PREROUTING -s 192.168.0.100 -j DROP

    Pour être _certain_ que tes règles sont bonnes, tu supprimes toutes les règles de ton pare-feu, puis tu ajoutes tes règles à tester. Dès qu'on a un paquet de règles, on oublie toujours que telle ou telle règle interfère sérieusement avec celles qu'on vient d'ajouter.
  • # utiliser timestart

    Posté par  . Évalué à 9.

    d'apres un vieux forum, https://linuxfr.org//forums/15/28122.html
    il y a une option timestart/timestop qui permet d'appliquer des regles en fonctions de l'heure.

    dans cet exemple il s'agissait d'autorisé le port entrant 8983 entre 20h30 et 23h30
    iptables -A INPUT -i eth0 -p tcp --dport 8983 --sport 1024:65535 --m time --timestart 20:30 --timestop 23:30 -m state --state NEW,ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -o eth0 -p tcp --dport 1024:65535 --sport 8983 --m time --timestart 20:30 --timestop 23:30 -m state --state ESTABLISHED -j ACCEPT


    mais ca doit pouvoir s'adapter à ton besoin.
  • # Peut-être que le NAT fait chier

    Posté par  . Évalué à 2.

    J'avoue qu'avec les règles de NAT, ça change peut-être quelques trucs. Et je n'aime pas trop ta solution de mettre des règles partout si ça ne marche pas : si tu ne comprends pas d'où ça vient, ce n'est généralement pas en bourrinant que ça va passer.

    Déjà, en restant sur le filtrage IP, je mettrai ça :

    $IPTABLES -I FORWARD -p all -s 192.168.0.100 -j REJECT

    Pour bloquer "à la source" (pas au retour), et proprement histoire que les bécanes n'attendent pas le timeout. Comme le NAT est fait au moment du postrouting, ce filtrage est fait avant la traduction d'adresse, donc tu es déjà plus sûr que ça va marcher.

    Après, pour diagnostiquer, tu peux utiliser iptables -vL pour voir les stats des paquets par règle, voir si ta règle est effective. Et puis aussi tcpdump.
    • [^] # Re: Peut-être que le NAT fait chier

      Posté par  . Évalué à 1.

      Bonjour, Tout d'abord, je n'ai pas mis des règles partout comme tu le pense ;), quand j'ai constaté que les premières ne fonctionnaient pas, je les ai enlevées, puis j'ai testé les suivantes. Je ne sais pas si c'est important, mais pour INPUT et FORWARD j'ai une chaîne personnelle:
      $IPTABLES -N SuiviCnx
      $IPTABLES -A SuiviCnx -m state --state NEW -i ! $INET_IFACE -j ACCEPT
      $IPTABLES -A SuiviCnx -m state --state ESTABLISHED,RELATED -j ACCEPT
      # On fait pointer la chaine SuiviCnx sur INPUT et FORWARD
      $IPTABLES -A INPUT -j SuiviCnx
      $IPTABLES -A FORWARD -j SuiviCnx
      Mes règles de restrictions sont insérées avant avec le -I. Je vais tester ta proposition, je vous tiens au courant. Merci de vos avis.
  • # Pas mieux ...

    Posté par  . Évalué à 1.

    Bonjour, Bon j'ai testé ta proposition @benoar, apparament cela ne fonctionne pas mieux ...
    iptables -nvL
    
    ...
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 DROP       0    --  *      *       192.168.0.115        0.0.0.0/0           
        0     0 DROP       0    --  *      *       192.168.0.100        0.0.0.0/0           
     855M  479G SuiviCnx   0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    
    Je continue à chercher ...
    • [^] # Re: Pas mieux ...

      Posté par  . Évalué à 2.

      Je viens de comparer à chez moi, je pense que le protocole (-p) est foireux : chez moi c'est marqué "all" (même avec -n). C'est vrai que j'avais gardé cette option car tu l'avais mise, mais en général je ne l'utilise pas. Essaye sans.

      PS: bon après vérif, c'est l'iptables de busybox qui renvoit all quand même, alors qu'un iptables classique renvoit bien 0. Donc le problème n'est pas là.

      Tu pourrais nous donner la description détaillée de tes tables ?
      iptables -vL
      iptables -t nat -vL
      iptables -t mangle -vL
      • [^] # Re: Pas mieux ...

        Posté par  . Évalué à 1.

        Bonjour,

        Voilà ce que ça donne:

        iptables -vL
        Chain INPUT (policy DROP 1067K packets, 265M bytes)
        pkts bytes target prot opt in out source destination
        719M 767G SuiviCnx 0 -- any any anywhere anywhere
        1075K 62M ACCEPT tcp -- any any anywhere anywhere tcp dpt:www
        414 22076 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https
        112K 5444K ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
        445K 26M ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
        1108 46448 ACCEPT tcp -- any any anywhere anywhere tcp dpt:domain
        108K 7016K ACCEPT udp -- any any anywhere anywhere udp dpt:domain
        0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply
        0 0 ACCEPT icmp -- any any anywhere anywhere icmp destination-unreachable
        0 0 ACCEPT icmp -- any any anywhere anywhere icmp redirect
        17092 1109K ACCEPT icmp -- any any anywhere anywhere icmp echo-request
        0 0 ACCEPT icmp -- any any anywhere anywhere icmp time-exceeded
        134K 8002K ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp
        9 428 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ftp-data
        175 11546 ACCEPT tcp -- any any anywhere anywhere tcp dpts:60000:60500 state NEW,RELATED,ESTABLISHED
        0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:4661
        0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:4662
        0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:4665
        339 17664 ACCEPT tcp -- any any anywhere anywhere tcp spt:4661
        406 24852 ACCEPT tcp -- any any anywhere anywhere tcp spt:4662
        251 14556 ACCEPT udp -- any any anywhere anywhere udp spt:4665
        246 51168 ACCEPT udp -- any any anywhere anywhere udp dpt:8767
        498K 29M DROP tcp -- any any anywhere anywhere tcp dpt:loc-srv
        32 4978 DROP udp -- any any anywhere anywhere udp dpt:loc-srv
        24 1152 DROP tcp -- any any anywhere anywhere tcp dpt:netbios-ns
        9248 721K DROP udp -- any any anywhere anywhere udp dpt:netbios-ns
        13 616 DROP tcp -- any any anywhere anywhere tcp dpt:netbios-dgm
        1 32 DROP udp -- any any anywhere anywhere udp dpt:netbios-dgm
        99846 5975K DROP tcp -- any any anywhere anywhere tcp dpt:netbios-ssn
        0 0 DROP udp -- any any anywhere anywhere udp dpt:netbios-ssn
        362K 19M DROP tcp -- any any anywhere anywhere tcp dpt:microsoft-ds
        0 0 DROP udp -- any any anywhere anywhere udp dpt:microsoft-ds
        508K 46M LOG 0 -- any any anywhere anywhere limit: avg 1/sec burst 5 LOG level warning prefix `Packet log:'

        Chain FORWARD (policy DROP 0 packets, 0 bytes)
        pkts bytes target prot opt in out source destination
        0 0 DROP 0 -- any any pc1.maison.home anywhere
        0 0 DROP 0 -- any any pc2.maison.home anywhere
        857M 480G SuiviCnx 0 -- any any anywhere anywhere
        17 6568 ACCEPT tcp -- eth1 eth0 anywhere phil-linux.maison.home tcp dpt:4661
        230K 12M ACCEPT tcp -- eth1 eth0 anywhere phil-linux.maison.home tcp dpt:4662
        10344 978K ACCEPT udp -- eth1 eth0 anywhere phil-linux.maison.home udp dpt:4665

        Chain OUTPUT (policy ACCEPT 534M packets, 154G bytes)
        pkts bytes target prot opt in out source destination

        Chain SuiviCnx (2 references)
        pkts bytes target prot opt in out source destination
        8360K 571M ACCEPT 0 -- !eth1 any anywhere anywhere state NEW
        1564M 1246G ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED


        iptables -t nat -vL
        Chain PREROUTING (policy ACCEPT 9120K packets, 721M bytes)
        pkts bytes target prot opt in out source destination
        0 0 LOG 0 -- any any anywhere anywhere state INVALID limit: avg 1/sec burst 5 LOG level warning prefix `Invalid Packet (NAT):'
        0 0 DROP 0 -- any any anywhere anywhere state INVALID
        7 4628 DNAT tcp -- eth1 any anywhere anywhere tcp dpt:4661 to:192.168.0.60:4661
        230K 12M DNAT tcp -- eth1 any anywhere anywhere tcp dpt:4662 to:192.168.0.60:4662
        548 63858 DNAT udp -- eth1 any anywhere anywhere udp dpt:4665 to:192.168.0.60:4665

        Chain POSTROUTING (policy ACCEPT 2060K packets, 142M bytes)
        pkts bytes target prot opt in out source destination
        6858K 465M MASQUERADE 0 -- any eth1 anywhere anywhere

        Chain OUTPUT (policy ACCEPT 4163K packets, 363M bytes)
        pkts bytes target prot opt in out source destination


        iptables -t mangle -vL
        Chain PREROUTING (policy ACCEPT 1576M packets, 1247G bytes)
        pkts bytes target prot opt in out source destination
        1003K 47M LOG 0 -- any any anywhere anywhere state INVALID limit: avg 1/sec burst 5 LOG level warning prefix `Invalid Packet (MANGLE):'
        1227K 57M DROP 0 -- any any anywhere anywhere state INVALID
        11704 4990K TOS tcp -- any any anywhere anywhere tcp spt:ssh TOS set Minimize-Delay

        Chain INPUT (policy ACCEPT 719M packets, 767G bytes)
        pkts bytes target prot opt in out source destination

        Chain FORWARD (policy ACCEPT 857M packets, 480G bytes)
        pkts bytes target prot opt in out source destination

        Chain OUTPUT (policy ACCEPT 534M packets, 154G bytes)
        pkts bytes target prot opt in out source destination

        Chain POSTROUTING (policy ACCEPT 1392M packets, 634G bytes)
        pkts bytes target prot opt in out source destination


        'maison.home' est mon domaine local (géré par bind), pc1 et pc2 sont les 2 pc en question.
        • [^] # Re: Pas mieux ...

          Posté par  . Évalué à 2.

          J'avoue que là je ne vois pas grand chose qui cloche .... Et quelle est ta table de routage ? Je suppose qu'elle est classique, mais je ne vois pas d'autre chose qui pourrait poser problème ... À part un classique : un truc auquel tu as touché, qui n'a "rien à voir" mais en fait si ...
          • [^] # Re: Pas mieux ...

            Posté par  . Évalué à 1.

            Bonjour,

            Moi non plus je ne vois pas pourquoi cela ne fonctionne pas, les règles ajoutées ne sont pas très compliquées, à moins qu'il ne faille 'relancer' iptables à chaque modification, mais je ne pense pas ... et cela 'compliquerai' un peu mes modifications.

            Ma table de routage est on ne peut plus classique:

            route -n
            Table de routage IP du noyau
            Destination Passerelle Genmask Indic Metric Ref Use Iface
            82.243.150.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
            192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
            0.0.0.0 82.243.150.254 0.0.0.0 UG 0 0 0 eth1


            Peut-être ai-je oublié un paramètre à initialiser dans /proc, ou un modprobe quelconque ... je continue à chercher.

            Merci de ton aide.
            • [^] # Re: Pas mieux ...

              Posté par  . Évalué à 2.

              Comme je disais plus haut, pour diagnostiquer, un coup de tcpdump serait pas mal.
    • [^] # Re: Pas mieux ...

      Posté par  . Évalué à 1.

      Bonjour,

      Bon, j'ai tenté une autre approche, en voulant désactiver le masquerading pour les 2 pc concernés, mais même résultat, cela ne fonctionne pas

      $IPTABLES -t nat -I POSTROUTING -o eth1 -s 192.168.0.100 -j DROP
      $IPTABLES -t nat -I POSTROUTING -o eth1 -s 192.168.0.115 -j DROP

      Les règles sont pourtant bien insérées au début, mais les compteurs restent à zéro et les PC continuent de surfer ...

      J'ai l'impression que quoi que je fasse, rien ne marche, c'est quand même étrange ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.