
Skript zur Implementierung von Q-Feeds direkt auf NFtables oder IPtables
Automatisierte Malware-IP-Blocklist für Linux-Server – unterstützt nftables und iptables+ipset
Holen Sie sich einen kostenlosen API-Schlüssel unter 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
### Schritt 3: Führen Sie das Installationsprogramm als root aus```bash
sudo ./qfeeds-installer.sh
Der Installateur wird:
Dein Server ist nun geschützt. Der Cron-Job prüft alle 20 Minuten auf Aktualisierungen (konfigurierbar), und tatsächliche API-Aufrufe erfolgen nur, wenn es deine Lizenz zulässt.
Diese Lösung lädt regelmäßig den neuesten Bedrohungsinformations-Feed von Q-Feeds herunter und wendet ihn als Firewall-Regeln an, sodass du:
Der Installateur erkennt automatisch, welches Firewall-Backend verfügbar ist:
| Priorität | Erkennung | Backend |
|---|---|---|
| 1. | nft-Befehl gefunden | nftables |
| 2. | iptables-Befehl gefunden | iptables+ipset |
| — | Keines gefunden | Fehler (Abbruch) |
Das erkannte Backend wird in der Konfigurationsdatei gespeichert. Die Aktualisierungs- und Deinstallationsskripte verwenden es, um die korrekten Firewall-Befehle auszuführen.
Beide Backends verwenden dieselbe Split-Set-Strategie für maximale Leistung:
nftables-Backend:``` ┌─────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────┘
**iptables+ipset Backend:**```
┌──────────────────────────────────────────────────────────┐
│ 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) │
└──────────────────────────────────────────────────────────┘
Die gleiche Struktur existiert für IPv6 (ip6 qfeeds table oder ip6tables + family inet6 ipsets).
Warum zwei Set-Typen?