q-feeds/nftables-iptables-integration-scriptScript pour implémenter Q-Feeds directement sur NFtables ou IPtables
Liste de blocage automatisée des IP malveillantes pour serveurs Linux — prend en charge nftables et iptables+ipset
Obtenez une clé d'API gratuite sur tip.qfeeds.com.
git clone https://github.com/Q-Feeds/NFtables-IPtables-integration-script.git
cd NFtables-IPtables-integration-script
chmod +x qfeeds-installer.sh qfeeds-uninstaller.sh
sudo ./qfeeds-installer.sh
L'installateur va :
Votre serveur est désormais protégé. La tâche cron vérifie les mises à jour toutes les 20 minutes (configurable), et les appels API réels n'ont lieu que lorsque votre licence le permet.
Cette solution télécharge périodiquement le dernier flux de renseignements sur les menaces depuis Q-Feeds et l'applique sous forme de règles de pare-feu (guide étape par étape : Configuration NFtables/IPtables), ce qui vous permet de :
L'installateur détecte automatiquement quel backend de pare-feu est disponible :
| Priorité | Détection | Backend |
|---|---|---|
| 1er | Commande nft trouvée | nftables |
| 2e | Commande iptables trouvée | iptables+ipset |
| — | Aucune trouvée | Erreur (sortie) |
Le backend détecté est stocké dans le fichier de configuration. Les scripts de mise à jour et de désinstallation l'utilisent pour exécuter les bonnes commandes de pare-feu.
Les deux backends utilisent la même stratégie de division en ensembles pour des performances maximales :
Backend nftables :
┌─────────────────────────────────────────────────────────┐
│ table ip qfeeds │
│ │
│ ┌─────────────────────────┐ ┌───────────────────────┐ │
│ │ qfeeds_blacklist_v4 │ │ qfeeds_blacklist_v4 │ │
│ │ (hash set) │ │ _nets (interval set) │ │
│ │ │ │ │ │
│ │ Individual IPs │ │ CIDR ranges │ │
│ │ ~99% of entries │ │ ~1% of entries │ │
│ │ O(1) lookup & insert │ │ O(log n) lookup │ │
│ └─────────────────────────┘ └───────────────────────┘ │
│ │
│ ┌─────────────────────────┐ │
│ │ qfeeds_whitelist_v4 │ │
│ │ (interval set) │ │
│ │ Your allowed IPs/CIDRs │ │
│ └─────────────────────────┘ │
│ │
│ chain input-chain (hook input, priority 0, accept) │
│ → ip saddr @qfeeds_whitelist_v4 accept │
│ → ip saddr @qfeeds_blacklist_v4 drop │
│ → ip saddr @qfeeds_blacklist_v4_nets drop │
│ │
│ chain output-chain (if enabled) │
│ → ip daddr @qfeeds_whitelist_v4 accept │
│ → ip daddr @qfeeds_blacklist_v4 drop │
│ → ip daddr @qfeeds_blacklist_v4_nets drop │
└─────────────────────────────────────────────────────────┘
Backend iptables+ipset :
┌──────────────────────────────────────────────────────────┐
│ ipset sets │
│ │
│ ┌─────────────────────────┐ ┌────────────────────────┐ │
│ │ qfeeds_blacklist_v4 │ │ qfeeds_blacklist_v4 │ │
│ │ (hash:ip) │ │ _nets (hash:net) │ │
│ │ maxelem 1000000 │ │ maxelem 65536 │ │
│ │ │ │ │ │
│ │ Individual IPs │ │ CIDR ranges │ │
│ └─────────────────────────┘ └────────────────────────┘ │
│ │
│ ┌─────────────────────────┐ │
│ │ qfeeds_whitelist_v4 │ │
│ │ (hash:net) │ │
│ └─────────────────────────┘ │
│ │
│ iptables: INPUT/OUTPUT jump to a dedicated chain │
│ (jump rule tagged -m comment "qfeeds"): │
│ │
│ chain QFEEDS_INPUT (rebuilt each run, in order): │
│ -m set --match-set whitelist_v4 src -j ACCEPT │
│ -m set --match-set blacklist_v4 src -j DROP │
│ -m set --match-set blacklist_v4_nets src -j DROP │
│ (QFEEDS_OUTPUT mirrors this with dst, if enabled) │
└──────────────────────────────────────────────────────────┘
La même structure existe pour IPv6 (table ip6 qfeeds ou ip6tables + ipsets family inet6).
Pourquoi deux types d'ensembles ?