« 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.
