
Script para implementar Q-Feeds directamente en NFtables o IPtables
Lista de bloqueo automatizada de IP de malware para servidores Linux — compatible con nftables e iptables+ipset
Obtén una clave de API gratuita en 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
El instalador hará lo siguiente:
Tu servidor ahora está protegido. La tarea cron busca actualizaciones cada 20 minutos (configurable), y las llamadas reales a la API solo ocurren cuando tu licencia lo permite.
Esta solución descarga periódicamente el feed de inteligencia de amenazas más reciente desde Q-Feeds y lo aplica como reglas de firewall (guía paso a paso: Configuración de NFtables/IPtables), lo que te permite:
El instalador detecta automáticamente qué backend de firewall está disponible:
| Prioridad | Detección | Backend |
|---|---|---|
| 1.ª | Comando nft encontrado | nftables |
| 2.ª | Comando iptables encontrado | iptables+ipset |
| — | Ninguno encontrado | Error (salir) |
El backend detectado se almacena en el archivo de configuración. Los scripts de actualización y desinstalación lo usan para ejecutar los comandos de firewall correctos.
Ambos backends usan la misma estrategia de conjuntos divididos para un rendimiento máximo:
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 de 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 misma estructura existe para IPv6 (tabla ip6 qfeeds o ip6tables + ipsets con family inet6).
¿Por qué dos tipos de conjuntos?