GuiGui's Show

« ipset is used to set up, maintain and inspect so called IP sets in the Linux kernel. Depending on the type of the set, an IP set may store IP(v4/v6) addresses, (TCP/UDP) port numbers, IP and MAC address pairs, IP address and port number pairs, etc. See the set type definitions below.

Iptables matches and targets referring to sets create references, which protect the given sets in the kernel. A set cannot be destroyed while there is a single reference pointing to it. »

« ipset help :
Supported set types:
    list:set
    hash:net,iface
    hash:net,iface
    hash:net,port
    hash:net,port
    hash:net,port
    hash:net
    hash:net
    hash:net
    hash:ip,port,net
    hash:ip,port,net
    hash:ip,port,net
    hash:ip,port,ip
    hash:ip,port
    hash:ip
    bitmap:port
    bitmap:ip,mac
    bitmap:ip »


Sous Debian, c'est dans le package ipset. :D

Exemple d'usage basique : on ouvre le port SSH pour les admins
ipset create trustedAdminsIP hash:ip
ipset add trustedAdminsIP 192.0.2.1
ipset add trustedAdminsIP 192.0.2.2
ipset list trustedAdminsIP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state ---state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m set --match-set trustedAdminsIP src -p tcp -m tcp --dport 22 -j ACCEPT
ipset del trustedAdminsIP 192.0.2.2
ipset flush trustedAdminsIP
ipset destroy trustedAdminsIP -> échec car une règles iptables pointe encore sur ce set ;)

Le man du module « set » d'iptables n'est pas clair mais il peut matcher sur port source et port destination, pas juste sur IP source et IP destination : ipset create lala bitmap:port range 1024-2048 ; iptables -A OUTPUT -m set --set portsconnus dst -j DROP . Je n'y trouve pas beaucoup d'intérêt compte-tenu que --dport/sport et multiport permettent déjà de passer des plages de ports.

Mon avis sur les ip set :
    * Globalement bien foutu et syntaxe de l'userland similaire à iptables, y compris ipset save et ipset restore ;

    * Ces sets seront indéniablement plus rapides que x règles iptables plus le nombre d'IP augmentera compte-tenu des structures de donnée sutilisées (hashmap). Sans compter la lisibilité d'une seule règle iptables versus x :

    * Tout comme iptables, c'est chiant de load les set au boot, chaque adminsys va avoir sa façon de faire, ses scripts d'init homemade potentiellement foireux, ... Des scripts comme ipset-persistent (équivalent d'iptables-persistent) existent mais quid de leur maturité (il n'y a qu'à voir iptables-persistent sous Squeeze uhuhuhu) ? C'est là où on se dit "pf.conf > *"

    * Je pense que l'intérêt des sets apparaît quand on les utilise pour mitiger une attaque (D)DoS, c'est à dire quand on ne peut pas utiliser le suivi des connexions. Exemple concret (et scripts) : https://www.octopuce.fr/ipset-filtrages-des-attaques-sur-les-serveurs/ . Dans le cas contraire (autoriser une liste de machines, par exemple), je ne pense pas que x règles iptables pénalisent le système : seul le premier paquet d'une connexion devra parcourir l'ensemble des règles, les paquets suivants seront capturés par une règle "-m state --state RELATED,ESTABLISHED" positionnée en amont.

Une implémentation d'arbre radix/PATRICIA (https://en.wikipedia.org/wiki/Radix_tree) en python, orienté vers le stockage et la recherche de réseaux IPv4/IPv6. Permet de "représenter" la nature arborescente de l'adressage IP.

python-radix sous Debian. ;)

Je me mets ça sous le coude pour quand la version d'OpenDNSSEC (enfin la lib ldns sous-jacente) qui supporte le RRtype TLSA sera packagée dans Debian stable (Jessie).

« "L'agilité du protocole TLS souffre du gonflement de son héritage : après 20 années d'évolutions du standard, celui-ci comporte de nombreuses versions, extensions, et suites de chiffrement, dont certaines ne sont plus utilisées ou connues pour être non-sécurisées" écrivent les chercheurs dans le rapport consacrés aux attaques FREAK. Et cet héritage est justement une des causes de ce nouveau risque de sécurité identifié sur Internet.

En effet, la multiplication des versions du protocole, des modes d'authentification et des méthodes d'échange de clé permettant d'établir une connexion sécurisée entre un client et un serveur a engendré des "bugs" et "plusieurs vulnérabilités de sécurité critiques". Et ces failles sont demeurées cachées dans "ces libraires pendant des années".

[...]

Freak est particulièrement intéressante puisque cette vulnérabilité a pour origine les restrictions à l’export qui ont été mises en place sur la cryptographie dans les années 90. Ces familles d’algorithmes dédiés à l’export étaient plus faibles que les versions classiques aujourd’hui communément utilisées. L’attaque repose sur cela : à cause d’un bug, un attaquant peut exploiter cela et modifier les messages entre le client et le serveur pour forcer l’utilisation de ces familles de chiffrement, initialement destinées à l’export et qui ne garantissent pas une sécurité suffisante. Du côté client, celui-ci croit accepter une connexion sécurisée, mais celle-ci ne l’est pas, en tout cas pas aussi solide que ce qu’il croit.

Deux conditions sont nécessaires pour que l’attaque soit mise en place : il faut que l’attaquant parvienne à se placer dans un schéma d’attaque de type "Man in the middle", afin d’intercepter les messages échangés entre le client et le serveur, et côté serveur, il faut que celui-ci supporte les familles export d’algorithmes. Cette attaque reste assez délicate à mettre en œuvre puisqu’elle demande des moyens relativement importants : il parait difficile pour un individu visant une entreprise par exemple, d’envisager utiliser une attaque de ce type. C’est en revanche beaucoup plus envisageable pour un attaquant soutenu par un Etat.

[...]

D’après des tests réalisés par des experts de l’université du Michigan, un tiers des sites utilisant du chiffrement s’avèrent vulnérables à des attaques FREAK. C’est en particulier le cas de ceux utilisant OpenSSL (un correctif existe) et des clients TLS/SSL d’Apple. D’ailleurs le navigateur Safari de l’éditeur est vulnérable, tout comme celui intégré dans Android. Chrome, Firefox et Internet Explorer ne sont en revanche pas concernés. [ÉDIT du 06/03/2015 à 10h23 : sisi IE est aussi concerné : http://arstechnica.com/security/2015/03/stop-the-presses-https-crippling-freak-bug-affects-windows-after-all/ FIN DE L'ÉDIT.]

[...]

l’attaque Freak mais il faut bien comprendre que celle-ci appartient à une famille d’attaques, que nous avons regroupées sous le nom de State Machine Attacks. Toutes ont pour point commun la façon dont les implémentations de TLS gèrent les algorithmes de chiffrement. On a ainsi détaillé sur le site smacktls une autre attaque, qui vise cette fois l’implémentation de TLS au sein de Java, JSSE, et qui repose sur les mêmes principes.  [...] A l’origine, il y a eu un précurseur à cette attaque, nommé Early CCS. C’est cette attaque qui a montré que les messages envoyés au serveur TLS pouvaient être acceptés dans un ordre incorrect. Nous avons donc cherché comment savoir si les states machines étaient implémentées correctement. Pour tester cette hypothèse, Nous avons développé un outil afin de tester des séquences de messages volontairement incorrectes : si l’implémentation est correcte, alors un message d’erreur doit être renvoyé. Nous avons constaté beaucoup de cas ou aucune alerte n’était remontée et nous nous sommes donc interrogés sur l’interprétation à donner. C'est donc en étudiant le code source d’implémentations Open Source de TLS que nous avons découvert ces attaques. »

Bref, FREAK c'est mort côté client si pas Apple/Android ou en appliquant les patchs si c'est le cas et côté serveur en virant les suites cryptos destinées à l'export (regroupées dans le groupe EXP dans OpenSSL), ce qui devrait être fait depuis longtemps.

Via http://seenthis.net/messages/348012

« Le Gouvernement a fait publier au Journal Officiel le décret qui autorise ses services de police à demander à Google et d'autres moteurs de recherche ou annuaires le déréférencement de sites accusés de faire l'apologie du terrorisme. Les sites devront être supprimés des index dans les 48 heures, sans possibilités de recours.

Un mois après le décret autorisant le blocage administratif des sites sur ordre du ministère de l'intérieur, le Gouvernement a fait publier jeudi au Journal Officiel le décret "relatif au déréférencement des sites provoquant à des actes de terrorisme ou en faisant l'apologie et des sites diffusant des images et représentations de mineurs à caractère pornographique".

Le texte permet à l'Office central de lutte contre la criminalité liée aux technologies de l'information et de la communication (OCLCTIC) de notifier aux moteurs de recherche les sites accusés de relayer la propagande de terroristes, afin qu'ils soient déréférencés sur le champ, sans qu'un juge ne vérifier l'illégalité des sites en cause. Google et ses concurrents auront 48 heures pour prendre "toute mesure utile destinée à faire cesser le référencement de ces adresses", et devront le faire en respectant scrupuleusement "la confidentialité des données qui leur sont ainsi confiées". Pas question, donc, de publier les ordres de censure.

[...]

En revanche, alors que le blocage s'accompagne d'une redirection vers un site du ministère de l'intérieur qui fait explique le blocage et indique des voies de recours, rien n'est prévu pour s'opposer au déréférencement, à l'effet dévastateur.

[...]

Le déréférencement sur ordre policier des sites de propagande terroriste avait été introduit par un amendement surprise du Gouvernement présenté à la dernière minute, lors des débats sur la loi anti-terrorisme de 2014. Le ministre de l'intérieur Bernard Cazeneuve avait alors expliqué en séance que le dispositif proposé était identique à celui déjà prévu pour les sites d'argent en ligne, ce qui était mensonger. La loi sur les jeux d'argent en ligne prévoit que le déréférencement peut être ordonné par un magistrat, le président du TGI de Paris, et non directement par l'exécutif.

[...]

Le terrorisme n'est pas une notion simple à appréhender juridiquement, et n'a d'ailleurs jamais fait l'objet d'un consensus au niveau international. [...] Hélas, les événements récents consécutifs aux attentats de janvier 2015 à Paris ont rappelé que l'Etat avait une vision très large de l'apologie du terrorisme, au mépris de la liberté d'expression. »

« Ce nouveau RFC résume l'état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l'état de l'art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l'information (les routes) reçues et transmises. [...] Ce genre de compilation aurait plutôt due être faite dans le cadre du project BCOP mais celui-ci semble mort.

[...]

La section 2 de ce RFC rappelle qu'il n'a pas de caractère obligatoire : il expose des pratiques de sécurité générales, et il est toujours permis de faire des exceptions, en fonction des caractéristiques spécifiques du réseau qu'on gère.

Donc, au début (sections 4 et 5 du RFC), la protection de la discussion entre deux routeurs, deux pairs BGP qui communiquent (sécurité du canal). Ensuite (sections 6 à 11), la protection des informations de routage échangées, le contrôle de ce qui est distribué (sécurité des données).

Commençons par sécuriser le routeur (section 4). Il devrait idéalement être protégé par des ACL qui interdisent les connexions vers le port 179, celui de BGP, sauf depuis les pairs connus. Les protections de TCP ne suffisent pas forcément, la mise en œuvre de TCP dans les routeurs est parfois faite de telle façon qu'on peut planter le routeur juste en envoyant plein de demandes de connexion. Il faut donc les jeter avant même que TCP ne les voit.

[...]

Certains routeurs permettent également de mettre en place un limiteur de trafic, pour éviter du trafic excessif, même en provenance de pairs connus.

[...]

Ensuite (section 5 du RFC), la protection des sessions BGP avec les pairs légitimes (cf. RFC 6952). Si les deux routeurs ne prennent aucune précaution, un attaquant pourrait, par exemple, couper leur session BGP en envoyant de faux paquets TCP de type RST (cf. RFC 5961). Pire, il pourrait, avec des techniques comme l'usurpation ARP, injecter de faux paquets dans une session BGP existante. Pour se protéger contre les attaques TCP, il faut utiliser une authentification TCP, comme la traditionnelle (et bien dépassée) TCP-MD5 du RFC 2385. [...] En outre, MD5 étant désormais bien affaibli (RFC 6151), il faudrait désormais utiliser le mécanisme AO du RFC 5925. Le RFC note que, malgré le caractère antédiluvien de TCP-MD5, c'est toujours la solution la plus utilisée par les opérateurs.

[...]

Autre précaution, filtrer les paquets IP en entrée du réseau de l'opérateur pour interdire les paquets prétendant avoir une adresse IP source située dans le réseau de l'opérateur. Sans cette précaution, même les sessions iBGP pourraient être attaquées.

[...]

Dernière protection des sessions BGP, GTSM (RFC 5082) qui consiste à tester que le TTL des paquets entrants est à la valeur maximale (255), et que le paquet vient donc bien du réseau local (s'il était passé par, ne serait-ce qu'un seul routeur, le TTL aurait été décrémenté).

[...]

Sécuriser la session ne sert à rien si le pair légitime et authentifié nous envoie des informations fausses. La section 6 de notre RFC se consacre donc au filtrage des préfixes annoncés. D'abord, les préfixes non routables (ceux marqués Global: false dans le registre des adresses spéciales IPv4 ou son équivalent IPv6) devraient évidemment être rejetés. Mais il est également recommandé de ne pas accepter les préfixes non alloués (par le système d'allocation d'adresses IP IANA->RIR->LIR). Comme la liste de ces préfixes change tout le temps, les filtres doivent être mis à jour automatiquement, à partir de la liste à l'IANA.

[...]

Tester auprès de l'IANA ne permet que des filtres grossiers, éliminant les annonces de préfixes non alloués à un RIR, ce qui ne sert que pour IPv6, ne vérifie pas les préfixes plus spécifiques que ce que l'IANA alloue, et n'empêche pas un malveillant ou un maladroit d'annoncer les préfixes d'un autre AS. Il peut donc être intéressant de filtrer de manière plus précise, en regardant les IRR. [...] Des outils existent pour produire automatiquement des filtres sur le routeur à partir du RPSL (comme IRRToolSet). Malheureusement, aucun IRR n'est parfait (et certains sont vraiment imparfaits) : préfixes absents (surtout les plus spécifiques, en cas de dés-agrégation des annonces), information dépassée, etc. Les IRR des RIR sont proches des opérateurs et donc a priori ont une information fiable mais ce n'est que théorique (les préfixes IP « du marais », alloués avant l'existence des RIR, sont une source particulièrement importante de problèmes). En outre, l'IRR d'un RIR ne couvre que la région de ce RIR, et on peut donc avoir besoin d'en consulter plusieurs (on a un pair états-unien, on regarde la base de l'ARIN, mais ce pair a des clients sud-américains et on doit donc aussi regarder la base de LACNIC...), ce qui justifie les IRR privés, comme RADB, qui essaient de consolider l'information des RIR.

[...]

Dans le futur, il est possible qu'un système plus fiable soit adopté et déployé, le couple RPKI+ROA, alias SIDR pour Secure Inter-Domain Routing. SIDR repose sur une infrastructure de certification, la RPKI (RFC 6480), et sur des objets signés, les ROA (RFC 6482), annonçant quel AS peut annoncer tel préfixe.

[...]

D'autres filtrages sont possibles en entrée. Par exemple, les opérateurs filtrent les annonces trop spécifiques, afin notamment d'éviter la croissance indéfinie de leurs bases de données et tables de routage. Chacun choisit les valeurs quantitatives précises et il n'y a pas de consensus documenté sur ce point (on peut consulter les documents RIPE-399 et RIPE-532) mais on peut observer qu'un préfixe plus long que /24 en IPv4 et /48 en IPv6 a très peu de chances d'être accepté dans l'Internet.

Typiquement, on filtre aussi en entrée les annonces portant sur les préfixes internes. Normalement, ce n'est pas à nos voisins d'annoncer nos routes ! Autres préfixes souvent filtrés, les routes par défaut, 0.0.0.0/0 en IPv4 et ::0/0 en IPv6. Naturellement, les recommandations de filtrage dépendent du type d'appairage BGP : on ne filtre pas pareil selon qu'on parle à un pair, à un client ou à un transitaire (voir la section 6 du RFC pour tous les détails). Ainsi, pour reprendre le paragraphe précédent, sur la route par défaut, certains clients d'un opérateur demandent à recevoir une telle route et c'est tout à fait acceptable.

[...]

La section 7 est consacrée à une pratique très utilisée et très discutée, l'amortissement (damping). Lorsqu'une route vers un préfixe IP donné passe son temps à être annoncée et retirée, on finit par l'ignorer, pour éviter que le routeur ne passe son temps à recalculer ses bases de données. Pour réaliser cela, à chaque changement d'une route, on lui inflige une pénalité, et au bout d'un certain nombre de pénalités, on retire la route. Malheureusement, cette technique mène parfois à supprimer des routes et à couper un accès (voir RIPE-378). Avec de meilleurs paramètres numériques, comme recommandé par le RFC 7196 et RIPE-580, l'amortissement redevient utilisable et recommandable.

[...]

Autre technique de filtrage des erreurs, décrite en section 8, l'imposition d'un nombre maximum de préfixes annoncés par un pair BGP. S'il en annonce davantage, on coupe la session BGP. Un dépassement du nombre maximal est en effet en général le résultat d'une fuite, où, suite à une erreur de configuration, le routeur ré-annonce des routes reçues d'un autre. Parfois, c'est toute la DFZ qui est ainsi annoncée par accident aux pairs ! Notre RFC demande donc instamment qu'on limite le nombre de préfixes accepté pour une session BGP. Pour un pair sur un point d'échange, le seuil devrait être inférieur au nombre de routes de la DFZ (dans les 530 000 en IPv4 aujourd'hui, et 21 000 en IPv6), pour détecter les annonces accidentelles de toute la DFZ. On peut aussi avoir des seuils par pair, fondés sur le nombre de routes qu'ils sont censés annoncer. Pour un transitaire, par contre, le seuil doit être plus élevé que le nombre de routes dans la DFZ, puisqu'on s'attend à tout recevoir d'eux (mais une valeur maximale est quand même utile en cas de désagrégation intensive). Comme l'Internet change tout le temps, il faut réviser ces limites, et suivre les alertes [...]

Voyons d'abord le filtrage par chemin d'AS. Par exemple, un client d'un opérateur ne devrait pas annoncer des routes avec n'importe quels AS mais seulement avec un chemin comportant uniquement son propre AS (et, si le client a lui-même des clients, avec l'AS de ces clients secondaires). Si l'opérateur n'arrive pas à avoir une liste complète des AS qui peuvent se retrouver dans les chemins de ses clients, au moins peut-il limiter la longueur de ces chemins, pour éviter la ré-annonce accidentelle de routes. D'autre part, on n'accepte pas, dans le cas normal, de routes où un AS privé (64512 à 65534 et 4200000000 à 4294967294, voir RFC 6996) apparait dans le chemin. Conséquence logique, on n'annonce pas à ses voisins de routes avec des chemins d'AS qui incluent un AS privé, sauf arrangement spécifique. Et le chemin d'AS dans une annonce BGP doit toujours commencer par l'AS du voisin (sauf si on parle à un serveur de routes).

[...]

Quant au filtrage sur le routeur suivant (section 10 du RFC), il consiste à refuser une route si l'attribut BGP NEXT_HOP (RFC 4271, section 5.1.3) n'est pas l'adresse du voisin. Attention, ce test doit être débrayé si on parle à un serveur de routes, celui-ci ne souhaitant pas traiter les paquets IP. Idem (débrayage du test) si on fait du RTBH (RFC 6666). »

« Fin avril 2015, la directive « secret des affaires » sera débattue au Parlement européen. Après avoir cédé à la pression des journalistes pour retirer l'article correspondant de la loi Macron, La Quadrature du Net, Pila, et de nombreuses autres organisations appellent le président François Hollande et les élus européens à défendre les lanceurs d'alerte, à définir et protéger leur statut, et à assurer les moyens nécessaires à un réel suivi judiciaire des crimes et délits révélés. La situation souvent dramatique des lanceurs d'alertes, tels Edward Snowden ou Chelsea Manning, doit être protégée et sécurisée pour la sauvegarde des libertés fondamentales.

Le 30 janvier dernier, devant la forte mobilisation des journalistes français, François Hollande demandait le retrait de l'article sur le secret des affaires de la loi Macron. Malgré cette victoire pour la liberté d'informer et de dénoncer les agissements illégaux de sociétés privées, les lanceurs d'alerte restent menacés. En effet, une directive européenne sera débattue fin avril au Parlement européen, dont le texte actuel criminalise l'atteinte au secret des affaires en Europe, sans protection effective des lanceurs d'alertes. Afin d'alerter sur les dangers pesant sur la liberté d'informer, La Quadrature du Net cosigne aujourd'hui une tribune dans Libération et une lettre ouverte envoyée au Président de la République française.

[...]

« Grâce aux révélations d'Edward Snowden sur la surveillance des communications, à celles de Swissleaks sur l'abus du secret bancaire, ou encore de Luxleaks sur les arrangements des grandes sociétés avec l'impôt en Europe, l'Union européenne découvre l'importance des lanceurs d'alerte et de la possibilité de dénoncer les crimes, délits et absences de limites morales des sociétés privées et structures publiques. Il est inadmissible que ces mêmes lanceurs d'alertes soient menacés de sanctions par les membres du Parlement européen au nom de la protection d'intérêts privés ! Au contraire, il est urgent de contribuer à leur protection et d'enfin mettre en place de réelles procédures d'investigation une fois ces crimes et délits révélés au public » s'indigne Benjamin Sonntag, co-fondateur de La Quadrature du Net. »

Il faut lire cette entrevue avec le directeur général d'Alcatel-Lucent car c'est magique : du bullshit (digitalisation/digitale, tsunami de data, éco-efficacité des réseaux,...), de l'auto-promo (« Encore faut-il en avoir la capacité. A l’avenir, il n’y aura pas de souveraineté possible sans une maîtrise certaine des couches applicatives et technologiques. » / « Aujourd’hui, 10 % à 15 % des brevets qu’Alcatel-Lucent dépose portent sur l’éco-efficacité des réseaux. »), des propos pour nous endormir et des propos inquiétants...

Propos pour endormir le bon couillon :
« Avec la fibre, on a comme agrandi les voies. Mais cela ne suffit plus. C’est maintenant l’architecture même des réseaux qu’il faut revoir. Il va falloir les remplacer par des architectures distribuées, beaucoup moins centralisées, permettant d’amener les infrastructures à haut débit au plus près des clients finaux. Ce qui suppose d’installer un peu partout d’énormes data centers, avec à la clé des nouvelles problématiques de sécurité. »
=> Il a tout compris à l'acentricité du réseau et à la production locale et autonorme d'électricité, lui. :)

« Des problèmes de résilience, d’abord. Il faut être d’autant plus en mesure d’éviter la panne que l’ensemble de l’économie devient numérique, et donc passe par les réseaux, de la gestion des feux tricolores dans les rues jusqu’aux capteurs dans le domaine de la santé, par exemple. Or il reste des points de vulnérabilité, comme l’ont récemment montré les pannes de bases de données de réseaux mobiles, qu’il faudra à l’avenir décentraliser. »

Les propos inquiétants :
« Se posent, ensuite, des problèmes de cybersécurité. Il faut repérer les points de vulnérabilité et regarder quels équipements doivent être installés sur les réseaux pour en renforcer la sécurité. La problématique est que 50 % du trafic qui circule sur les réseaux des opérateurs est crypté. Il ne serait pas illogique de permettre aux pouvoirs publics de savoir ce qui se passe sur les réseaux, dans un cadre juridique approprié, ce qui suppose de mettre en place des outils grâce auxquels les opérateurs pourront accéder aux informations transitant par leurs infrastructures. »
=> crypté = L-O-L ; cadre juridique approprié = mais bien sûr, endors-nous ! Tu les sens mes middleboxes DPI et mon MITM actif ? No way !

Un petit résumé des différents modes de NAT IPv4 possibles sous Linux avec les commandes iptables kivontbien pour les mettre en pratique.

NAT 1:1 pour une seule IP (on veut mapper une seule adresse IP privée sur une seule adresse IP publique) :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_ip> -j SNAT --to-source <public_ip>

    Pour pouvoir initier des connexions depuis l'extérieur (usage serveur, par exemple) :
    iptables -t nat -A PREROUTING -i <public_interface> -d <public_ip> -j DNAT --to-destination <private_ip>


NAT 1:1 pour un réseau entier (on veut mapper une plage d'adresses IP privées sur une plage d'adresses IP publiques. Il faut donc autant d'IP publiques que d'IP privées. ) :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j NETMAP --to <public_subnet>

    Pour pouvoir initier des connexions depuis l'extérieur :
    iptables -t nat -A PREROUTING -i <public_interface> -d <public_subnet> -j NETMAP --to <private_subnet>

    Le numéro de machine est conservé, seule la partie réseau est réécrite. Exemple : 198.18.0.1/24 deviendra 198.18.1.1/24. 198.18.0.42/24 deviendra 198.18.1.42/24.
    Source : https://capcorne.wordpress.com/2009/03/24/natting-a-network-range-with-netmapiptables/


NAPT (on veut mapper plusieurs IP privées sur une seule IP publique statique/invariante/connue) :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j SNAT --to-source <public_range (exemple : 192.0.2.1-192.0.2.4,192.0.2.10)>

    Évidemment, il est possible d'avoir un seul couple IP_publique/protocole de transport(UDP/TCP/SCTP)/port associé à un couple IP_privée/protocole de transport/port en utilisant la cible DNAT (voir ci-dessus). Redirection de port/ouverture de port habituelle.


NAPT dynamiquee (on veut mapper plusieurs IP privées sur une seule IP publique obtenue dynamiquement et pouvant varier dans le temps (ex. : DHCP)) :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j MASQUERADE

    Évidemment, il est possible d'avoir un couple IP_publique/protocole de transport(UDP/TCP/SCTP)/port associé à un couple IP_privée/protocole de transport/port en utilisant la cible DNAT (voir ci-dessus). Redirection de port/ouverture de port habituelle.


NAPT  (on veut mapper plusieurs IP privées sur plusieurs IP publiques mais on n'a pas le même nombre d'IP privées que de publiques) :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j SNAT --to-source <public_range (exemple 192.0.>
    => Cette méthode a disparue depuis Linux v2.6.11 - http://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017468.html

    OU

    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j SAME --to <public_range (exemple : 192.0.2.1-192.0.2.4,192.0.2.10)>
    => Le man nous indique « N.B.: The DNAT target's --persistent option replaced the SAME target. » et la cible SAME n'est plus reconnue actuellement (testé avec un noyau 3.2 et noyau 3.16). L'option « persistent » de la cible DNAT ne convient pas à notre besoin.

    Source : http://serverfault.com/questions/647343/load-balancing-iptables-postrouting-rules

    OU

    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -m statistic --mode nth --every 2 --packet 0 -j SNAT --to-source <public_IP1>
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j SNAT --to-source <public_IP2>

    Même exemple mais avec 4 IP publiques :
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -m statistic --mode nth --every 4 --packet 0 -j SNAT --to-source <public_IP1>
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -m statistic --mode nth --every 3 --packet 0 -j SNAT --to-source <public_IP2>
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -m statistic --mode nth --every 2 --packet 0 -j SNAT --to-source <public_IP3>
    iptables -t nat -A POSTROUTING -o <public_interface> -s <private_subnet> -j SNAT --to-source <public_IP4>
   
    Source : http://serverfault.com/questions/647343/load-balancing-iptables-postrouting-rules

    Ainsi, toutes les « -- every » connexions (dans l'exemple précédent : à chaque nouvelle connexion), l'IP de sortie change, round-robin style comme l'ancien comportement de la cible SNAT avec plusieurs IP. Évidemment, il n'y a pas d'associations entre IPs donc une même machine pourra sortir avec deux IP différentes à un même instant T dans deux applications différentes. Encore plus impressionnant : l'IP peut différer au sein d'une même application. Exemple typique : le chargement d'une page web moderne se décompose en : contenu principal sur serveur avec l'IP1, images sur CDN dont un des serveurs à l'IP2, font chez Google donc IP3, ajax chez Google donc IP4,... C'est tout autant de connexions différentes qui sont effectuées par le navigateur web et qui seront réparties sur plusieurs IP par la passerelle NAT.

Cela complique les debug puisqu'un test sur un site externe de type "quelle est mon IP ?" ne reflétera pas l'IP source de toutes les connexions initiées depuis la machine. ;)

Ce comportement ne semble pas perturber les sites web bien codés, même les plus nazis sur l'origine des connexions comme Google dans GMail. Par contre, attention aux sites web qui matchent l'IP source actuelle avec celle contenue dans un cookie pour vérifier que vous êtes bien autorisé à vous connecter à une partie sécurisée du site web et qui vous déconnectent le cas échéant. Pour éviter ce type de problème, on peut aussi écrire un script pour ajouter X règles iptables avec la cible SNAT et un filtre par source (« -s ») qui réparti les IP sources privées sur les IP publiques. Ainsi une même IP source privée aura toujours la même IP source publique. On peut aussi segmenter le réseau interne en plusieurs sous-réseau. Chaque plage d'IP aura sa propre IP publique de sortie.

Malgré ce que dit le man, le module « statistic » réparti bien les connexions, pas les paquets. Le contraire forcerait des retransmissions et donc latence voir perte si UDP + aucun mécanisme de récup' des erreurs au niveau applicatif. Une même connexion aura un état dans la table NAT et l'adresse IP de chacun des paquets qui la compose sera donc réécrit avec la même adresse IP ! Pour visualiser les états du suivi des connexions Netfilter, on peut utiliser l'outil userland « conntrack » : voir http://shaarli.guiguishow.info/?WI9cXg .


Ci-dessus, je parle d'adresses IPv4 publiques mais les commandes et le principe de fonctionnement reste identiques s'il on n'a pas d'IPv4 publiques mais uniquement plusieurs plages d'IP privées.

Un petit schéma avec les interactions entre les différents composants (modules) de Postfix et les différentes maps (aliases, transport, virtual, ...) utilisées à tel moment.