Re: [HS] Help pour débuter avec iptables
Le 14/09/2010 23:41, giggz a écrit : Le 14/09/2010 15:46, Pascal Hambourg a écrit : Pascal Hambourg a écrit : giggz a écrit : -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT Utile pour un routeur seulement. Oups, j'ai confondu avec router-solicitation. Ok. -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT Ok. Il faut aussi accepter le type neighbour-solicitation. ok super j'ai fait les modifs. je vais voir à l'usage. Y a des règles pour définir les limites avec -m limit --limit ? ou alors c'est au pif ? Merci pour tout! J'ai trouvé un tuto en anglais vraiment bien expliqué sur iptables (c'est pas spécifique debian), je colle l'adresse: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables Bon les règles iptables étant bien fonctionnelles, je m'intéresse aux variables modifiables via sysctl: Pour l'instant les variables redirects sont à 1 : net.ipv4.conf.all.send_redirects net.ipv4.conf.default.send_redirects net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.secure_redirects net.ipv4.conf.default.accept_redirects net.ipv4.conf.default.secure_redirects est ce intéressant de les mettre à 0 ? Bonne journée Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6pu4g$9q...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
giggzounet a écrit : Y a des règles pour définir les limites avec -m limit --limit ? ou alors c'est au pif ? Non, ce n'est pas au pif. Elles doivent être adaptées aux capacités de la machine, du réseau... Bon les règles iptables étant bien fonctionnelles, je m'intéresse aux variables modifiables via sysctl: Pour l'instant les variables redirects sont à 1 : net.ipv4.conf.all.send_redirects net.ipv4.conf.default.send_redirects net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.secure_redirects net.ipv4.conf.default.accept_redirects net.ipv4.conf.default.secure_redirects est ce intéressant de les mettre à 0 ? Déjà, seule une machine fonctionnant en routeur (ip_forward=1, conf.ipv4.*.forwarding=1) peut envoyer des ICMP redirect. Et elle-même ignore les ICMP redirect reçus. Pour une machine fonctionnant en simple hôte ce n'est pas catastrophique d'ignorer les ICMP redirect, c'est juste sous-optimal. De toute façon il est rare qu'un réseau contienne plusieurs passerelles, donc la probabilité d'en recevoir est réduite. Comme les ICMP redirect peuvent être exploités par une machine du réseau local pour détourner du trafic, il peut être intéressant d'un point de vue sécurité de les ignorer. Néanmoins il y a d'autre moyens de détourner du trafic dans un réseau local, notamment avec les attaques basées sur ARP qu'iptables ignore complètement. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c90d8ab.7050...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 15/09/2010 16:31, Pascal Hambourg a écrit : giggzounet a écrit : Y a des règles pour définir les limites avec -m limit --limit ? ou alors c'est au pif ? Non, ce n'est pas au pif. Elles doivent être adaptées aux capacités de la machine, du réseau... je vouslais dire: j'en teste une première (600/min) et si ça passe je laisse sinon je mets 300/min... Bon les règles iptables étant bien fonctionnelles, je m'intéresse aux variables modifiables via sysctl: Pour l'instant les variables redirects sont à 1 : net.ipv4.conf.all.send_redirects net.ipv4.conf.default.send_redirects net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.secure_redirects net.ipv4.conf.default.accept_redirects net.ipv4.conf.default.secure_redirects est ce intéressant de les mettre à 0 ? Déjà, seule une machine fonctionnant en routeur (ip_forward=1, conf.ipv4.*.forwarding=1) peut envoyer des ICMP redirect. Et elle-même ignore les ICMP redirect reçus. Pour une machine fonctionnant en simple hôte ce n'est pas catastrophique d'ignorer les ICMP redirect, c'est juste sous-optimal. De toute façon il est rare qu'un réseau contienne plusieurs passerelles, donc la probabilité d'en recevoir est réduite. Comme les ICMP redirect peuvent être exploités par une machine du réseau local pour détourner du trafic, il peut être intéressant d'un point de vue sécurité de les ignorer. Néanmoins il y a d'autre moyens de détourner du trafic dans un réseau local, notamment avec les attaques basées sur ARP qu'iptables ignore complètement. ok. merci pour l'explication. donc j'ai mis: net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 Bonne soirée, Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6qoq6$61...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
Pascal Hambourg a écrit : giggz a écrit : Le 11/09/2010 12:48, Pascal Hambourg a écrit : [...] Oui, même si le traitement d'ICMPv6 pourrait être affiné un poil. ok. j'ai mis ça: -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Euh, là ça devient un peu trop restrictif. Je pensais plutôt à autoriser les types ICMPv6 impliqués dans le protocole Neighbour Discovery (NDP) : neighbour-solicitation, neighbour-advertisement (équivalents d'ARP request et reply) et, pour les interfaces en auto-configuration sans état, router-advertisement ou au contraire router-solicitation pour une machine fonctionnant en routeur IPv6 avec radvd dessus. Les paquets de type redirect sont normalement classés RELATED donc pas besoin de s'en occuper spécifiquement. ok. j'ai lu un peu de doc: pour l'instant j'ai ça: -A INPUT -i eth1 -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type echo-request -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type echo-reply -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT mais sur un site j'ai vu des règles plus fines: # Allow some ICMPv6 types in the INPUT chain # Using ICMPv6 type names to be clear. ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT # Allow some other types in the INPUT chain, but rate limit. ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m limit --limit 600/min -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply -m limit --limit 600/min -j ACCEPT # Allow others ICMPv6 types but only if the hop limit field is 255. ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type redirect -m hl --hl-eq 255 -j ACCEPT qu'en penses tu ? Pour répondre à ta question: est ce qu'on utilise ipv6 ? je crois bien que non en ce moment. mais bon un jour ou l'autre ça va nous tomber dessus. donc je prépare un peu le terrain ;) Bon j'ai lu encore un peu de doc sur iptables. On peut paufiner les règles avec --match limit. Je suppose qu'il faut que j'attende un peu avant de me lancer dedans non ? Comme la correspondance recent, c'est à manier avec précaution et il faut regarder si c'est vraiment utile. ok. pour l'instant je me renseigne juste sur la chose. merci! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6nfjs$le...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : pour l'instant j'ai ça: -A INPUT -i eth1 -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT -A INPUT -i eth1 -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT Les paquets de ces types (types d'erreurs) sont normalement classés dans l'état RELATED lorsqu'ils sont liés à une connexion existante et INVALID dans le cas contraire, donc pas besoin de les traiter spécifiquement. -A INPUT -i eth1 -p icmpv6 --icmpv6-type echo-request -j ACCEPT Ok pour autoriser le ping en entrée. -A INPUT -i eth1 -p icmpv6 --icmpv6-type echo-reply -j ACCEPT Normalement classé ESTABLISHED si correspond à une requête émise et INVALID sinon, donc pas besoin de traiter spécifiquement. -A INPUT -i eth1 -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT Utile pour une interface d'hôte en autoconf, mais pas pour un routeur. -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT Utile pour un routeur seulement. -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT Ok. Il faut aussi accepter le type neighbour-solicitation. mais sur un site j'ai vu des règles plus fines: [...] # Allow some other types in the INPUT chain, but rate limit. ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m limit --limit 600/min -j ACCEPT Ça se défend, notamment dans le cas d'une liaison à débits asymétriques de type ADSL. ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply -m limit --limit 600/min -j ACCEPT Là par contre, je ne vois pas l'intérêt. Si on reçoit des réponses, c'est normalement qu'on a envoyé les requêtes et donc qu'on attend ces réponses. La correspondance avec l'état ESTABLISHED me semble plus pertinente pour vérifier que ce sont bien des réponses attendues. # Allow others ICMPv6 types but only if the hop limit field is 255. ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type redirect -m hl --hl-eq 255 -j ACCEPT La vérification du champ HL (hop limit, équivalent au TTL d'IPv4) à 255 pour les types NDP de portée limitée au lien est une bonne mesure pour vérifier que ces messages viennent bien d'un voisin du réseau local et pas de plus loin, même si tout routeur bien constitué ne devrait jamais retransmettre ces messages. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8f5df5.6050...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Pascal Hambourg a écrit : giggz a écrit : -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT Utile pour un routeur seulement. Oups, j'ai confondu avec router-solicitation. Ok. -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT Ok. Il faut aussi accepter le type neighbour-solicitation. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8f7cc2.1040...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 14/09/2010 15:46, Pascal Hambourg a écrit : Pascal Hambourg a écrit : giggz a écrit : -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT Utile pour un routeur seulement. Oups, j'ai confondu avec router-solicitation. Ok. -A INPUT -i eth1 -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT Ok. Il faut aussi accepter le type neighbour-solicitation. ok super j'ai fait les modifs. je vais voir à l'usage. Y a des règles pour définir les limites avec -m limit --limit ? ou alors c'est au pif ? Merci pour tout! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6oq5h$gt...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
Pascal Hambourg a écrit : giggz a écrit : ok. j'ai mis ça: -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT [...] bon apparemment ça l'air de bien fonctionner avec les règles que vous m'avez donné. merci bcp! Même en IPv6 ? Si les types ICMPv6 NDP sont bloqués, j'ai un doute. entre temps j'ai un doute sur un autre point. Pour limiter les ip qui se connectent sur le port 80, je tente de restreindre au max: tous nos ordinateurs ont des ip commençant par 139.11.215.* . comme on est par énormément j'ai mis: 139.11.215.0/24 ça a l'air de marcher mais j'ai un doute sur le /24. C'est trop restrictif ? merci PS je suis en train de regarder pour l'icmpv6...ça prend du temps. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6kpbt$lr...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : entre temps j'ai un doute sur un autre point. Pour limiter les ip qui se connectent sur le port 80, je tente de restreindre au max: tous nos ordinateurs ont des ip commençant par 139.11.215.* . comme on est par énormément j'ai mis: 139.11.215.0/24 ça a l'air de marcher mais j'ai un doute sur le /24. C'est trop restrictif ? Non, 24 bits de préfixe, cela correspond bien à 3 octets, soit 139.11.215.*. PS je suis en train de regarder pour l'icmpv6...ça prend du temps. Vérifie d'abord que ton bazar a bien une connectivité IPv6 globale, et pas seulement des adresses link-local. Sinon, pas la peine de s'embêter à faire du filtrage IPv6. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8deb65.4080...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 11/09/2010 00:21, Serge Cavailles a écrit : Bonjour, Je me permets d'intervenir, j'adore me faire reprendre par Pascal. ;) Le Friday 10 September 2010 22:25:20 giggz, vous avez écrit : *filter :INPUT ACCEPT [0:0] La politique par défaut devrait être DROP. alors là ya un truc que je ne pige pas: si c'est à DROP tout ce qui rentre va être droppé non ? La politique par _defaut_ s'applique en fin de chaîne aux paquets restants (comprendre qui n'auront pas été acceptés par une règle). ah ok. j'avais pas saisi. Donc si je comprends bien, en mettant :INPUT DROP au début je n'ai plus besoin d'avoir: -A INPUT -j DROP juste avant le commit, non ? Dans quel ordre iptables lit il les règles ? Dans l'ordre ou elles apparaissent dans les tables. Chaque ajout (-A) à lieu à la suite des règles existantes, d'où la remarque de Pascal (plus loin dans le même message) de placer les règles concernant les paquets ESTABLISHED/RELATED en début de table, pour éviter que ces paquets ne doivent tout d'abord passer par les autres règles. ok. je saisis. Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou après anti-spoofing ? ## Allow previously established connections -A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Cette règle devrait se trouver en début de chaîne car c'est elle qui traite normalement le plus de paquets. Plus globalement, une politique de DROP par défaut me paraît beaucoup plus sûre; si on oublie d'ouvrir un port ça se remarque généralement assez rapidement, ce qui n'est pas forcément le cas de ceux que l'on oublie de fermer. De plus AMA c'est plus facile à lire et à comprendre, on n'a que des règles ACCEPT au lieu d'un mélange de règles ACCEPT (pour récupérer les paquets sans traverser toute la chaîne) et de règles DROP dans le cas d'une politique par défaut en ACCEPT. ok . merci de tes explications. BOn en combinant vos 2 réponses. J'ai pour l'instant: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # ## Allow all traffic on localhost -A INPUT -i lo -j ACCEPT # ## Allow previously established connections -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # # IP DROP SPOOF -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP # IP DROP link-local -A INPUT -i eth1 -s 169.254.0.0/16 -j DROP # IP DROP -A INPUT -i eth1 -s 0.0.0.0/8 -j DROP -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP # # begin: allowed networks # ## Allow all traffic from the nodes -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT -A INPUT -i ib0 -s 192.168.100.0/24 -j ACCEPT -A INPUT -s 192.168.200.0/24 -j ACCEPT # end: allowed networks # ## SSH + test brute force -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix SSH_brute_force -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j DROP # ## Allow icmp echo-request -A INPUT -i eth1 -p icmp -m icmp --icmp-type 8 -j ACCEPT # ## Allow WWW http port 80 for PFS IP -A INPUT -i eth1 -s 139.11.215.0/17 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT ## Packets are DROPPED -A INPUT -j DROP COMMIT Donc les points qui restent obscurent pour le moment ce sont: - peut on mettre -A INPUT -eth0 -s 192.168.200.0/24 -j ACCEPT ? ou alors -A INPUT -eth0:2 -s 192.168.200.0/24 -j ACCEPT ? - la ligne -A INPUT -j DROP est elle nécessaire ? si j'ai bien compris la réponse de Serge, je suppose que je peux la supprimer. - les règles de spoof doivent être en premier ou alors lo et related/established ? - si je veux permettre à mes noeuds d'avoir internet, il suffit que je fasse : iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE -s 192.168.0.0/16 sysctl -w net.ipv4.ip_forward=1 non ? Merci de votre aide! je commence à entrevoir la chose... Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6fbpn$8a...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : Le 11/09/2010 00:21, Serge Cavailles a écrit : La politique par _defaut_ s'applique en fin de chaîne aux paquets restants (comprendre qui n'auront pas été acceptés par une règle). Pas seulement acceptés. La politique par défaut est appliquée aux paquets qui atteignent la fin de la chaîne sans avoir rencontré de cible dite terminale : DROP, ACCEPT, REJECT, DNAT, SNAT, MASQUERADE... ah ok. j'avais pas saisi. Donc si je comprends bien, en mettant :INPUT DROP au début je n'ai plus besoin d'avoir: -A INPUT -j DROP juste avant le commit, non ? En effet. Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou après anti-spoofing ? Pour lo, tu peux la mettre avant sauf si tu soupçonnes ta machine de faire du spoofing lorsqu'elle se cause à elle-même (ce qui traduirait de graves troubles de la personnalité). Pour RELATED,ESTABLISHED, en toute rigueur il faudrait la mettre après. En effet le suivi de connexion ne tient pas compte de l'interface d'arrivée des paquets (après tout, le routage sur internet est asymétrique par nature et une machine multihomée peut recevoir un paquet légitime par n'importe quelle interface). On pourrait imaginer une situation où la machine communique avec une machine A sur l'interface interne, et une machine B extérieure profite de la connexion établie pour injecter des paquets par l'interface externe en se faisant passer pour A. Mais cette situation a autant sinon plus de chances de se produire si la machine usurpée et la machine usurpatrice sont du même côté, et là le filtrage anti-spoofing n'y peut rien. ok . merci de tes explications. BOn en combinant vos 2 réponses. J'ai pour l'instant: [...] -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP [...] -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP Doublon. Donc les points qui restent obscurent pour le moment ce sont: - peut on mettre -A INPUT -eth0 -s 192.168.200.0/24 -j ACCEPT ? Plutôt -i eth0. ou alors -A INPUT -eth0:2 -s 192.168.200.0/24 -j ACCEPT ? Encore moins, eth0:2 n'est pas une interface. - la ligne -A INPUT -j DROP est elle nécessaire ? si j'ai bien compris la réponse de Serge, je suppose que je peux la supprimer. En effet, puisque la politique par défaut de la chaîne est DROP. - si je veux permettre à mes noeuds d'avoir internet, il suffit que je fasse : iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE -s 192.168.0.0/16 sysctl -w net.ipv4.ip_forward=1 non ? Il faudra aussi des règles dans FORWARD pour accepter les connexions routées arrivant par eth0 puisque la politique par défaut est DROP. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT A précéder par des règles anti-spoofing sur eth1 si tu y tiens. Elles peuvent être factorisées dans une chaîne utilisateur appelée depuis INPUT et FORWARD. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8b43c6.7050...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : Le 10/09/2010 20:11, Pascal Hambourg a écrit : eth0:2 n'est pas une interface mais un alias IP, une façon obsolète d'affecter une adresse IP supplémentaire à l'interface eth0. oui. d'ailleurs je suppose que je ne peux pas faire: -A Firewall-1-INPUT -i eth0:2 -s 192.168.200.0/255.255.255.0 -j ACCEPT non ? Tu peux, même si iptables affiche un avertissement. Mais ça ne fera pas ce que tu attends. Cette règle n'accrochera jamais aucun paquet puisque l'interface eth0:2 n'existe pas. :Firewall-1-INPUT - [0:0] Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT. mais via cette chaine je traite INPUT et FORWARD en même temps, non ? Justement, il y a de forte chances que les besoins de filtrage dans INPUT et FORWARD soient très différents. Seules les règles communes sont susceptibles d'être factorisées dans une chaîne utilisateur. -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP Ah, voilà la bonne longueur de préfixe. -A INPUT -i eth1 -s 255.255.255.255/32 -j DROP Déjà inclus dans le préfixe précédent. donc à virer ? Oui, cette règle n'accrochera aucun paquet puisque tous les paquets qu'elle pourrait accrocher auront déjà été bloqués par la règle précédente plus large. -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP Pourquoi, tu as quelque chose contre les écoles publiques du comté de Hillsborough en Floride ? ben je les aime po :p C'est toi qui vois. ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2, je met eth0 ? Oui. iptables ne connaît que les interfaces et les adresses, pas les alias. c'est encore un reste. j'ai tenté de logguer mais il y a tellement de tentative...que je me suis retrouvé avec un fichier message de 10 mo en 30 minutes...donc encore un reste. Trop de log tue le log... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8b4683.2070...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 11/09/2010 10:54, Pascal Hambourg a écrit : giggz a écrit : Le 11/09/2010 00:21, Serge Cavailles a écrit : La politique par _defaut_ s'applique en fin de chaîne aux paquets restants (comprendre qui n'auront pas été acceptés par une règle). Pas seulement acceptés. La politique par défaut est appliquée aux paquets qui atteignent la fin de la chaîne sans avoir rencontré de cible dite terminale : DROP, ACCEPT, REJECT, DNAT, SNAT, MASQUERADE... ah ok. j'avais pas saisi. Donc si je comprends bien, en mettant :INPUT DROP au début je n'ai plus besoin d'avoir: -A INPUT -j DROP juste avant le commit, non ? En effet. Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou après anti-spoofing ? Pour lo, tu peux la mettre avant sauf si tu soupçonnes ta machine de faire du spoofing lorsqu'elle se cause à elle-même (ce qui traduirait de graves troubles de la personnalité). Pour RELATED,ESTABLISHED, en toute rigueur il faudrait la mettre après. En effet le suivi de connexion ne tient pas compte de l'interface d'arrivée des paquets (après tout, le routage sur internet est asymétrique par nature et une machine multihomée peut recevoir un paquet légitime par n'importe quelle interface). On pourrait imaginer une situation où la machine communique avec une machine A sur l'interface interne, et une machine B extérieure profite de la connexion établie pour injecter des paquets par l'interface externe en se faisant passer pour A. Mais cette situation a autant sinon plus de chances de se produire si la machine usurpée et la machine usurpatrice sont du même côté, et là le filtrage anti-spoofing n'y peut rien. ok. donc # ## Allow all traffic on localhost -A INPUT -i lo -j ACCEPT # # IP DROP SPOOF -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP # IP DROP link-local -A INPUT -i eth1 -s 169.254.0.0/16 -j DROP # IP DROP -A INPUT -i eth1 -s 0.0.0.0/8 -j DROP -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP # ## Allow previously established connections -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # ok . merci de tes explications. BOn en combinant vos 2 réponses. J'ai pour l'instant: [...] -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP [...] -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP Doublon. damned. j'ai pas les yeux en face des trous... Donc les points qui restent obscurent pour le moment ce sont: - peut on mettre -A INPUT -eth0 -s 192.168.200.0/24 -j ACCEPT ? Plutôt -i eth0. redamned. bon j'ai mis -i eth0. c'est difficile de voir si ça fonctionne...mais ipmitool a l'air de discuter avec le switch donc ça a l'air de fonctionner. ou alors -A INPUT -eth0:2 -s 192.168.200.0/24 -j ACCEPT ? Encore moins, eth0:2 n'est pas une interface. - la ligne -A INPUT -j DROP est elle nécessaire ? si j'ai bien compris la réponse de Serge, je suppose que je peux la supprimer. En effet, puisque la politique par défaut de la chaîne est DROP. - si je veux permettre à mes noeuds d'avoir internet, il suffit que je fasse : iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE -s 192.168.0.0/16 sysctl -w net.ipv4.ip_forward=1 non ? Il faudra aussi des règles dans FORWARD pour accepter les connexions routées arrivant par eth0 puisque la politique par défaut est DROP. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT bon ben l'internet sur les noeuds marche! en gros j'ajoute ces lignes qd je veux avoir internet sur les noeuds. sinon je les vire. A précéder par des règles anti-spoofing sur eth1 si tu y tiens. Elles peuvent être factorisées dans une chaîne utilisateur appelée depuis INPUT et FORWARD. bah je pense que ce n'est pas vraiment nécessaire. j'ai besoin d'internet sur les noeuds de manière ponctuelle (genre 5 à 10 minutes pour télécharger un paquet). ensuite FORWARD est vide et à DROP. bon pour ip6tables j'ai mis ça : *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # ## Allow all traffic on localhost -A INPUT -i lo -j ACCEPT # ## Allow previously established connections -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # # begin: allowed networks # ## Allow all traffic from the nodes -A INPUT -i eth0 -j ACCEPT -A INPUT -i ib0 -j ACCEPT # # end: allowed networks # ## Allow icmp -A INPUT -p icmpv6 -j ACCEPT ## Allow mdns (avahi) #-A INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT ## Allow WWW http port 80 #-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT ## Allow SSH -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT # #-A INPUT -j LOG COMMIT c'est pas exactement la même chose...mais ça devrait suffire pour l'instant. et pour le moment je ne comprends rien au ip ipv6. faut encore que je lise des docs... Merci beaucoup à tous les 2! si vous avez encore des commentaires je suis à l'écoute. Guillaume -- Lisez la
Re: [HS] Help pour débuter avec iptables
giggz a écrit : iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT bon ben l'internet sur les noeuds marche! en gros j'ajoute ces lignes qd je veux avoir internet sur les noeuds. sinon je les vire. Tu peux aussi laisser la première et ne supprimer que la seconde. Ainsi les connexions en cours pourront continuer jusqu'à ce qu'elles se terminent et les nouvelles connexion seront bloquées. bon pour ip6tables j'ai mis ça : [...] c'est pas exactement la même chose...mais ça devrait suffire pour l'instant. Oui, même si le traitement d'ICMPv6 pourrait être affiné un poil. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8b5e80.8070...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 11/09/2010 12:48, Pascal Hambourg a écrit : giggz a écrit : iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT bon ben l'internet sur les noeuds marche! en gros j'ajoute ces lignes qd je veux avoir internet sur les noeuds. sinon je les vire. Tu peux aussi laisser la première et ne supprimer que la seconde. Ainsi les connexions en cours pourront continuer jusqu'à ce qu'elles se terminent et les nouvelles connexion seront bloquées. ok. modifié. bon pour ip6tables j'ai mis ça : [...] c'est pas exactement la même chose...mais ça devrait suffire pour l'instant. Oui, même si le traitement d'ICMPv6 pourrait être affiné un poil. ok. j'ai mis ça: -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Bon j'ai lu encore un peu de doc sur iptables. On peut paufiner les règles avec --match limit. Je suppose qu'il faut que j'attende un peu avant de me lancer dedans non ? bon apparemment ça l'air de bien fonctionner avec les règles que vous m'avez donné. merci bcp! Bon week-end! Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6fuq0$7d...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : Le 11/09/2010 12:48, Pascal Hambourg a écrit : [...] Oui, même si le traitement d'ICMPv6 pourrait être affiné un poil. ok. j'ai mis ça: -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Euh, là ça devient un peu trop restrictif. Je pensais plutôt à autoriser les types ICMPv6 impliqués dans le protocole Neighbour Discovery (NDP) : neighbour-solicitation, neighbour-advertisement (équivalents d'ARP request et reply) et, pour les interfaces en auto-configuration sans état, router-advertisement ou au contraire router-solicitation pour une machine fonctionnant en routeur IPv6 avec radvd dessus. Les paquets de type redirect sont normalement classés RELATED donc pas besoin de s'en occuper spécifiquement. Bon j'ai lu encore un peu de doc sur iptables. On peut paufiner les règles avec --match limit. Je suppose qu'il faut que j'attende un peu avant de me lancer dedans non ? Comme la correspondance recent, c'est à manier avec précaution et il faut regarder si c'est vraiment utile. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8c02d3.4090...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
giggz a écrit : ok. j'ai mis ça: -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT [...] bon apparemment ça l'air de bien fonctionner avec les règles que vous m'avez donné. merci bcp! Même en IPv6 ? Si les types ICMPv6 NDP sont bloqués, j'ai un doute. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8c0313.5000...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le Fri, 10 Sep 2010 09:00:02 +0200, giggzounet a écrit : suite à des problèmes avec la surcouche firewall apportée par firestarter, je me décide à m'intéresser à iptables. Mais je suis un peu perdu. Et la doc d'iptables est plus que conséquente. donc j'ai besoin d'aide pour débuter. J'ai tenté ma chance sur la list de netfilter...mais bon pas eu de réponse...alors je me tourne vers vous. c'est vieux mais ça m'a bien dépanné pour comprendre http://olivieraj.free.fr/fr/linux/information/firewall/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8a27fd$0$23401$426a3...@news.free.fr
Re: [HS] Help pour débuter avec iptables
Le 10/09/2010 14:43, moi-meme a écrit : Le Fri, 10 Sep 2010 09:00:02 +0200, giggzounet a écrit : suite à des problèmes avec la surcouche firewall apportée par firestarter, je me décide à m'intéresser à iptables. Mais je suis un peu perdu. Et la doc d'iptables est plus que conséquente. donc j'ai besoin d'aide pour débuter. J'ai tenté ma chance sur la list de netfilter...mais bon pas eu de réponse...alors je me tourne vers vous. c'est vieux mais ça m'a bien dépanné pour comprendre http://olivieraj.free.fr/fr/linux/information/firewall/ merci. je vais regarder ça. GiGGz -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i6db4n$4p...@dough.gmane.org
Re: [HS] Help pour débuter avec iptables
Salut, giggzounet a écrit : suite à des problèmes avec la surcouche firewall apportée par firestarter, je me décide à m'intéresser à iptables. Bravo ! J'ai tenté ma chance sur la list de netfilter...mais bon pas eu de réponse... J'ai vu cluster dans le sujet alors j'ai passé en me disant houla, j'y connais rien et ça doit être compliqué. j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un parefeu sur le master node. Naturellement le master doit accepter tout ce que vient des noeuds. Et j'aimerais que tout ce que vienne de l'extérieur soit filtré à part qqs services comme ssh et http. Le master se comporte comme un genre de load balancer ? Il fonctionne plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ? pour l'instant j'ai ça: *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :Firewall-1-INPUT - [0:0] -A INPUT -j Firewall-1-INPUT -A FORWARD -j Firewall-1-INPUT C'est pas la peine de virer la surcouche si c'est pour faire pareil... # # -A INPUT -j Firewall-1-INPUT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix SSH_brute_force -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j DROP Mon conseil : quand on débute, commencer par des choses simples et basiques : suivi de connexion, filtrage des flux par interface d'entrée et/ou de sortie, protocole et port. Pour les trucs subtils à base de recent (susceptible de provoquer un auto-DoS si mal maîtrisé), on verra plus tard. couic le reste Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez des idées...je suis preneur. Ben en fait, c'est difficile à dire car je vois pas trop le rapport avec le cahier des charges mentionné plus haut. Faut dire qu'il est tellement vague... UNe autre question: si je mets ces règles pour iptables. Qu'en est il pour ip6tables ? C'est indépendant. ip6tables n'est utile que si la machine a une connectivité IPv6. dois je mettre les mêmes rêgles ? Tu ne pourras pas forcément : les adresses et les types ICMP sont spécifiques à chacun des deux protocole. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8a3508.5090...@plouf.fr.eu.org
Re: [HS] Help pour débuter avec iptables
Le 10/09/2010 15:39, Pascal Hambourg a écrit : Salut, giggzounet a écrit : suite à des problèmes avec la surcouche firewall apportée par firestarter, je me décide à m'intéresser à iptables. Bravo ! merci. mais j'ai un de ces mal de tête maintenant!!! J'ai tenté ma chance sur la list de netfilter...mais bon pas eu de réponse... J'ai vu cluster dans le sujet alors j'ai passé en me disant houla, j'y connais rien et ça doit être compliqué. j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un parefeu sur le master node. Naturellement le master doit accepter tout ce que vient des noeuds. Et j'aimerais que tout ce que vienne de l'extérieur soit filtré à part qqs services comme ssh et http. Le master se comporte comme un genre de load balancer ? Il fonctionne plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ? le master se charge de distribuer les jobs sur les noeuds. C'est via le master que tout le monde se connecte. En gros j'ai 5 interfaces: lo locahost eth0 interface ethernet vers les noeuds eth0:2 interface de controle/monitoring des noeuds (ipmi) ib0 interface infiniband vers les noeuds eth1 interface ethernet vers l'extérieur. En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie sur eth1 je peux laissé ouvert. pour l'instant j'ai ça: *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :Firewall-1-INPUT - [0:0] -A INPUT -j Firewall-1-INPUT -A FORWARD -j Firewall-1-INPUT C'est pas la peine de virer la surcouche si c'est pour faire pareil... # # -A INPUT -j Firewall-1-INPUT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix SSH_brute_force -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j DROP Mon conseil : quand on débute, commencer par des choses simples et basiques : suivi de connexion, filtrage des flux par interface d'entrée et/ou de sortie, protocole et port. Pour les trucs subtils à base de recent (susceptible de provoquer un auto-DoS si mal maîtrisé), on verra plus tard. ben pour l'instant ça a l'air de marcher. en gros si je me connecte normal ça va. par contre si je lance un nmap par exemple il gueule. couic le reste Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez des idées...je suis preneur. Ben en fait, c'est difficile à dire car je vois pas trop le rapport avec le cahier des charges mentionné plus haut. Faut dire qu'il est tellement vague... cf plus haut. UNe autre question: si je mets ces règles pour iptables. Qu'en est il pour ip6tables ? C'est indépendant. ip6tables n'est utile que si la machine a une connectivité IPv6. ok. bon je suis sur le réseau interne d'une uni...alors je suppose que oui. dois je mettre les mêmes rêgles ? Tu ne pourras pas forcément : les adresses et les types ICMP sont spécifiques à chacun des deux protocole. oui ça j'ai vu. et j'ai modifié. Merci. pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ? *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :Firewall-1-INPUT - [0:0] # ## SSH (test brute force) -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix SSH_brute_force -A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j DROP # # IP DROP SPOOF -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP -A INPUT -i eth1 -s 240.0.0.0/5 -j DROP # IP DROP MULTICAST -A INPUT -i eth1 -s 224.0.0.0/4 -j DROP -A INPUT -i eth1 -s 169.254.0.0/16 -j DROP # IP DROP LOOPBACK -A INPUT -i eth1 -d 127.0.0.0/8 -j DROP # IP DROP -A INPUT -i eth1 -s 0.0.0.0/8 -j DROP -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP -A INPUT -i eth1 -s 255.255.255.255/32 -j DROP -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP -A INPUT -i eth1 -s 248.0.0.0/5 -j DROP # ## -A INPUT -j Firewall-1-INPUT -A FORWARD -j Firewall-1-INPUT # ## Allow all traffic on localhost -A Firewall-1-INPUT -i lo -j ACCEPT # # begin: allowed networks # ## Allow all traffic from the nodes -A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT # end: allowed networks # ## Allow icmp -A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT ## Allow IPsec
Re: [HS] Help pour débuter avec iptables
giggzounet a écrit : Le 10/09/2010 15:39, Pascal Hambourg a écrit : giggzounet a écrit : j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un parefeu sur le master node. Naturellement le master doit accepter tout ce que vient des noeuds. Et j'aimerais que tout ce que vienne de l'extérieur soit filtré à part qqs services comme ssh et http. Le master se comporte comme un genre de load balancer ? Il fonctionne plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ? le master se charge de distribuer les jobs sur les noeuds. C'est via le master que tout le monde se connecte. Via, ça reste vague. Ça peut être via routage et redirection de ports, ou via un programme. Je suppose que c'est via un programme, donc le master ne fonctionne pas en routeur et dans ce cas il n'est pas censé y avoir de trafic dans la chaîne FORWARD. En gros j'ai 5 interfaces: lo locahost eth0 interface ethernet vers les noeuds eth0:2 interface de controle/monitoring des noeuds (ipmi) eth0:2 n'est pas une interface mais un alias IP, une façon obsolète d'affecter une adresse IP supplémentaire à l'interface eth0. ib0 interface infiniband vers les noeuds eth1 interface ethernet vers l'extérieur. En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie sur eth1 je peux laissé ouvert. Ça, c'est facile. Ton jeu de règles va déjà plus loin. ben pour l'instant ça a l'air de marcher. en gros si je me connecte normal ça va. par contre si je lance un nmap par exemple il gueule. C'est important qu'il gueule ? pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ? *filter :INPUT ACCEPT [0:0] La politique par défaut devrait être DROP. :FORWARD ACCEPT [0:0] Même chose, si la machine n'est pas routeur rien ne doit traverser cette chaîne. :OUTPUT ACCEPT [0:0] :Firewall-1-INPUT - [0:0] Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT. ## SSH (test brute force) Ces règles devraient arriver après les règles anti-spoof. # IP DROP SPOOF -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP Je suppose que tu sais ce que tu fais et que personne n'est censé communiquer avec ta machine par cette interface depuis ces adresses. -A INPUT -i eth1 -s 240.0.0.0/5 -j DROP Pourquoi /5 et pas /4 ? # IP DROP MULTICAST -A INPUT -i eth1 -s 224.0.0.0/4 -j DROP Pas absolument nécessaire, la plage multicast est invalide en tant que source donc ces paquets sont de toute façon écartés par la pile IP du noyau. -A INPUT -i eth1 -s 169.254.0.0/16 -j DROP Ce n'est pas du multicast, c'est la plage link-local IPv4. # IP DROP LOOPBACK -A INPUT -i eth1 -d 127.0.0.0/8 -j DROP Pas absolument nécessaire, la plage de loopback est invalide en tant que source ou destination à l'extérieur de la machine donc ces paquets sont de toute façon écartés par la pile IP du noyau. Accessoirement tu n'as pas mis de règle pour bloquer la plage de loopback en source. -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP Ah, voilà la bonne longueur de préfixe. -A INPUT -i eth1 -s 255.255.255.255/32 -j DROP Déjà inclus dans le préfixe précédent. -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP Pourquoi, tu as quelque chose contre les écoles publiques du comté de Hillsborough en Floride ? -A INPUT -i eth1 -s 248.0.0.0/5 -j DROP Déjà inclus dans 240.0.0.0/4. -A INPUT -j Firewall-1-INPUT Comme déjà dit, autant mettre les règles directement dans INPUT. -A FORWARD -j Firewall-1-INPUT Comme déjà dit, aucun paquet ne traverse cette chaîne si la machine n'est pas routeur. ## Allow all traffic from the nodes -A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT Toujours vérifier l'interface d'entrée. Note : spécifier la longueur de préfixe plutôt que le masque est AMA plus lisible. ## Allow icmp -A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT Bof. Le ping (echo-request), c'est suffisant. ## Allow IPsec (ESP port 50 and AH port 51) Protocoles 50 et 51, pas ports. -A Firewall-1-INPUT -p esp -j ACCEPT -A Firewall-1-INPUT -p ah -j ACCEPT C'est utile ? ## Allow previously established connections -A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Cette règle devrait se trouver en début de chaîne car c'est elle qui traite normalement le plus de paquets. ## Allow SSH -A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT Déjà traité plus haut avec le bazar recent, non ? ## Do not log smb/windows sharing packets - too much logging -A Firewall-1-INPUT -p tcp -i eth1 --dport 137:139 -j REJECT -A Firewall-1-INPUT -p udp -i eth1
Re: [HS] Help pour débuter avec iptables
Le 10/09/2010 20:11, Pascal Hambourg a écrit : giggzounet a écrit : Le 10/09/2010 15:39, Pascal Hambourg a écrit : giggzounet a écrit : j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un parefeu sur le master node. Naturellement le master doit accepter tout ce que vient des noeuds. Et j'aimerais que tout ce que vienne de l'extérieur soit filtré à part qqs services comme ssh et http. Le master se comporte comme un genre de load balancer ? Il fonctionne plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ? le master se charge de distribuer les jobs sur les noeuds. C'est via le master que tout le monde se connecte. Via, ça reste vague. Ça peut être via routage et redirection de ports, ou via un programme. Je suppose que c'est via un programme, donc le master ne fonctionne pas en routeur et dans ce cas il n'est pas censé y avoir de trafic dans la chaîne FORWARD. disons que normalement il n'agit pas en routeur. mais si les noeuds ont besoin d'internet j'active temporairement l'ip forwarding. En gros j'ai 5 interfaces: lo locahost eth0 interface ethernet vers les noeuds eth0:2 interface de controle/monitoring des noeuds (ipmi) eth0:2 n'est pas une interface mais un alias IP, une façon obsolète d'affecter une adresse IP supplémentaire à l'interface eth0. oui. d'ailleurs je suppose que je ne peux pas faire: -A Firewall-1-INPUT -i eth0:2 -s 192.168.200.0/255.255.255.0 -j ACCEPT non ? ib0 interface infiniband vers les noeuds eth1 interface ethernet vers l'extérieur. En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie sur eth1 je peux laissé ouvert. Ça, c'est facile. Ton jeu de règles va déjà plus loin. ok. donc c'est correct. ben pour l'instant ça a l'air de marcher. en gros si je me connecte normal ça va. par contre si je lance un nmap par exemple il gueule. C'est important qu'il gueule ? ben non :) pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ? *filter :INPUT ACCEPT [0:0] La politique par défaut devrait être DROP. alors là ya un truc que je ne pige pas: si c'est à DROP tout ce qui rentre va être droppé non ? Dans quel ordre iptables lit il les règles ? pourquoi si :INPUT est à DROP j'arrive tout de même à avoir une connection ssh avec l'autre règle ? :FORWARD ACCEPT [0:0] Même chose, si la machine n'est pas routeur rien ne doit traverser cette chaîne. ok. sauf si j'active temporairement l'ip forwarding, non ? :OUTPUT ACCEPT [0:0] :Firewall-1-INPUT - [0:0] Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT. mais via cette chaine je traite INPUT et FORWARD en même temps, non ? ## SSH (test brute force) Ces règles devraient arriver après les règles anti-spoof. ok. je corrige # IP DROP SPOOF -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP Je suppose que tu sais ce que tu fais et que personne n'est censé communiquer avec ta machine par cette interface depuis ces adresses. oui. c'est voulu. -A INPUT -i eth1 -s 240.0.0.0/5 -j DROP Pourquoi /5 et pas /4 ? aucune idée...le mal de tête :D # IP DROP MULTICAST -A INPUT -i eth1 -s 224.0.0.0/4 -j DROP Pas absolument nécessaire, la plage multicast est invalide en tant que source donc ces paquets sont de toute façon écartés par la pile IP du noyau. ok. donc à virer. -A INPUT -i eth1 -s 169.254.0.0/16 -j DROP Ce n'est pas du multicast, c'est la plage link-local IPv4. ok. # IP DROP LOOPBACK -A INPUT -i eth1 -d 127.0.0.0/8 -j DROP Pas absolument nécessaire, la plage de loopback est invalide en tant que source ou destination à l'extérieur de la machine donc ces paquets sont de toute façon écartés par la pile IP du noyau. Accessoirement tu n'as pas mis de règle pour bloquer la plage de loopback en source. ok. -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP Ah, voilà la bonne longueur de préfixe. -A INPUT -i eth1 -s 255.255.255.255/32 -j DROP Déjà inclus dans le préfixe précédent. donc à virer ? -A INPUT -i eth1 -s 168.254.0.0/16 -j DROP Pourquoi, tu as quelque chose contre les écoles publiques du comté de Hillsborough en Floride ? ben je les aime po :p -A INPUT -i eth1 -s 248.0.0.0/5 -j DROP Déjà inclus dans 240.0.0.0/4. ok. donc je vire. -A INPUT -j Firewall-1-INPUT Comme déjà dit, autant mettre les règles directement dans INPUT. -A FORWARD -j Firewall-1-INPUT Comme déjà dit, aucun paquet ne traverse cette chaîne si la machine n'est pas routeur. ## Allow all traffic from the nodes -A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT -A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0
Re: [HS] Help pour débuter avec iptables
Bonjour, Je me permets d'intervenir, j'adore me faire reprendre par Pascal. ;) Le Friday 10 September 2010 22:25:20 giggz, vous avez écrit : *filter :INPUT ACCEPT [0:0] La politique par défaut devrait être DROP. alors là ya un truc que je ne pige pas: si c'est à DROP tout ce qui rentre va être droppé non ? La politique par _defaut_ s'applique en fin de chaîne aux paquets restants (comprendre qui n'auront pas été acceptés par une règle). Dans quel ordre iptables lit il les règles ? Dans l'ordre ou elles apparaissent dans les tables. Chaque ajout (-A) à lieu à la suite des règles existantes, d'où la remarque de Pascal (plus loin dans le même message) de placer les règles concernant les paquets ESTABLISHED/RELATED en début de table, pour éviter que ces paquets ne doivent tout d'abord passer par les autres règles. ## Allow previously established connections -A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Cette règle devrait se trouver en début de chaîne car c'est elle qui traite normalement le plus de paquets. Plus globalement, une politique de DROP par défaut me paraît beaucoup plus sûre; si on oublie d'ouvrir un port ça se remarque généralement assez rapidement, ce qui n'est pas forcément le cas de ceux que l'on oublie de fermer. De plus AMA c'est plus facile à lire et à comprendre, on n'a que des règles ACCEPT au lieu d'un mélange de règles ACCEPT (pour récupérer les paquets sans traverser toute la chaîne) et de règles DROP dans le cas d'une politique par défaut en ACCEPT. mes 2cts. -- Serge -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009110021.43607.debse...@free.fr
