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

Posté par philippe G. le 13 avril 2010 à 13:21.

Étiquettes : aucune

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 Kerro le 13 avril 2010 à 13:55. É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 NeoX le 13 avril 2010 à 14:48. É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 benoar le 13 avril 2010 à 20:36. É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 philippe G. le 14 avril 2010 à 09:53. É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 philippe G. le 15 avril 2010 à 09:46. É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 benoar le 15 avril 2010 à 20:20. É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 philippe G. le 16 avril 2010 à 10:22. É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 benoar le 16 avril 2010 à 17:22. É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 philippe G. le 19 avril 2010 à 11:04. É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 benoar le 19 avril 2010 à 20:05. Évalué à 2.
        
        Comme je disais plus haut, pour diagnostiquer, un coup de tcpdump serait pas mal.
- [^] # Re: Pas mieux ...
  
  Posté par philippe G. le 30 avril 2010 à 11:23. É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.