Wichtige Module:

| Modul | Verantwortlichkeit |
|--------|---------------|
| `ioc2rpz.erl` | TCP/TLS DNS Worker — akzeptiert, parst, validiert, antwortet |
| `ioc2rpz_udp.erl` | UDP-DNS-Listener — SOA-Abfragen |
| `ioc2rpz_conn.erl` | IOC-Quellenabruf (HTTP/HTTPS/Datei/Shell) |
| `ioc2rpz_db.erl` | ETS-basierter Zonen- und Paket-Cache |
| `ioc2rpz_sup.erl` | Haupt-Supervisor, Konfigurationsladung, Zonenplanung |
| `ioc2rpz_rest.erl` | REST-Management-API (Cowboy) |
| `ioc2rpz_doh.erl` | DNS-over-HTTPS-Handler |

## Verwendung von ioc2rpz™
Sie können ioc2rpz™ mit jedem DNS-Server verwenden, der Response Policy Zones unterstützt, z.B. aktuelle Versionen von ISC BIND, PowerDNS und alle kommerziellen DNS-Server, die auf diesen Produkten basieren (z.B. Infoblox, Blue Cat, Efficient IP). Eine Beispiel-Konfigurationsdatei für BIND (named.conf) wird im Ordner cfg bereitgestellt.
<p align="center"><a href="http://www.youtube.com/watch?feature=player_embedded&v=bvhyMFa_mBM" target="_blank"><img src="https://raw.githubusercontent.com/Homas/ioc2rpz/master/ioc2rpz_demo.png"></a></p>

## ioc2rpz™ Weboberfläche
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) ist eine Management-Weboberfläche, die als separates Projekt entwickelt wird. Sie ist nicht erforderlich, um ioc2rpz™ auszuführen.

## Protokollunterstützung

ioc2rpz™ hört auf mehreren Transportprotokollen. Alle Transporte teilen sich dieselbe Abfrageverarbeitungspipeline: Ratenbegrenzung, TSIG-Validierung, Zonensuche und Antwortgenerierung. Siehe [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/protocols.md) für die vollständige Protokolldokumentation.

### Port-Übersicht

| Port | Protokoll | Dienst | Bedingung |
|------|----------|---------|-----------|
| 53 | UDP | DNS-Abfragen (nur SOA) | Immer |
| 53 | TCP | DNS-Abfragen, AXFR/IXFR-Zonentransfers, Management | Immer |
| 853 | TCP+TLS | DoT — wie TCP, aber verschlüsselt | Erfordert `cert`-Konfiguration |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) und REST-API | Erfordert `cert`-Konfiguration |

### UDP (Port 53)

UDP wird für leichte DNS-Abfragen verwendet, hauptsächlich für SOA-Abfragen. Antworten, die 512 Bytes (oder die von EDNS0 angekündigte Puffergröße) überschreiten, setzen das TC-Bit (Truncation) gemäß RFC 1035 §4.2.1, was Clients dazu veranlasst, es über TCP erneut zu versuchen. Management-Befehle werden über UDP nicht unterstützt.```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

### DNS über TLS / DoT (Port 853)

ioc2rpz™ unterstützt die RPZ-Verteilung über DoT. Der TLS-Listener startet automatisch auf Port 853, wenn ein `cert`-Eintrag in der Konfiguration vorhanden ist. DoT unterstützt dieselben Operationen wie TCP (AXFR, IXFR, SOA, Verwaltung).

- Unterstützte TLS-Versionen: 1.2 und 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- Wiederverwendung von Verbindungen gemäß RFC 7858 §3.4 unterstützt (mehrere Abfragen pro TLS-Sitzung, 30-Sekunden-Leerlauf-Timeout)
- TLS-PIN wird nicht unterstützt
- DNS-NOTIFY-Nachrichten werden unverschlüsselt gesendet (einfaches UDP)
- Zertifikate aktualisieren sich automatisch, wenn Dateien auf der Festplatte ersetzt werden (bis zu ~2 Minuten Verzögerung aufgrund von Erlang-SSL-Caching)

Informationen zur Zertifikatseinrichtung finden Sie unter [Zertifikatseinrichtung](#certificate-setup).```bash
# SOA query over DoT
kdig @127.0.0.1 -p 853 zone.ioc2rpz SOA +tls -y hmac-sha256:keyname:base64key

# AXFR over DoT
dig @127.0.0.1 -p 853 zone.ioc2rpz AXFR +tls +tcp -y hmac-sha256:keyname:base64key

### Ratenbegrenzung

DNS-Abfragen werden mithilfe eines intelligenten (hybriden) Schlüssels ratenbegrenzt, sodass legitime Multi-Zonen-Clients nicht bestraft werden, während Missbrauch durch Variation des Abfragenamens blockiert wird:

- **Bereitgestellte Zone + unterstützter QTYPE** (`SOA`/`AXFR`/`IXFR`, Klasse `IN`) und **erkannte Verwaltungsbefehle** (Klasse `CHAOS`/`TXT`) werden pro `{Client_IP, Abfragename, Abfragetyp}` verfolgt – so wird ein Sekundärserver, der mehrere Zonen abfragt/überträgt (z. B. `rpz1`, `rpz2`, `rpz3`) plus Verwaltung von einer IP, pro Zone+Typ unabhängig gezählt.
- **Alles andere** (unbekannte/nicht bereitgestellte Zone, nicht unterstützter Abfragetyp, falsche Klasse oder ein nicht erkannter Verwaltungsname) wird pro `{Client_IP}` aggregiert, sodass ein Angreifer die Begrenzung nicht durch Variation des Abfragenamens umgehen kann.

Wenn das Limit überschritten wird, gibt der Server eine DNS-`REFUSED`-Antwort zurück.

| Parameter | Standard | Makro |
|-----------|----------|-------|
| Fenster | 10 Sekunden | `?RATE_LIMIT_WINDOW` (10000 ms) |
| Maximale Anfragen pro Fenster (granular: bekannte Zone+Typ / Verwaltung) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| Maximale Anfragen pro Fenster (aggregiert: unbekannte Zone / nicht unterstützter Typ) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

Die Ratenbegrenzung gilt für alle DNS-Abfragetransporte (UDP, TCP, TLS, DoH). Das Fenster und der Schwellenwert sind über Makros in `include/ioc2rpz.hrl` konfigurierbar.

### DNS NOTIFY

Nach einer Zonenaktualisierung (AXFR oder IXFR) sendet ioc2rpz™ DNS-NOTIFY-Nachrichten ([RFC 1996](https://tools.ietf.org/html/rfc1996)) über UDP an die in der RPZ-`NotifyList` konfigurierten IP-Adressen. Dies veranlasst sekundäre DNS-Server, die SOA-Seriennummer der Zone zu prüfen und eine Übertragung einzuleiten, falls sich die Seriennummer geändert hat.```erlang
%% NotifyList in RPZ config — last field before whitelists
{rpz, {"zone.ioc2rpz", ..., ["source1"], ["10.0.0.1", "10.0.0.2"], []}}.

where die Verzeichnisse /home/ioc2rpz/cfg, /home/ioc2rpz/db auf einem Hostsystem liegen.  
Sie können einen benutzerdefinierten Konfigurationsdateinamen über den Parameter `-e` übergeben. Z.B. `-e CONF=./cfg/ioc2rpz2.conf`

## Umgebungsvariablen

Die folgenden Umgebungsvariablen werden von ioc2rpz™ verwendet, hauptsächlich relevant für Docker-Bereitstellungen. Sie sind in `config/sys.config.src` und `config/vm.args` definiert.

| Variable | Standard | Beschreibung |
|----------|---------|-------------|
| `IPv4` | — | IPv4-Bindeadresse |
| `IPv6` | — | IPv6-Bindeadresse |
| `CONF` | — | Pfad zur Konfigurationsdatei (z.B. `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | Datenbankverzeichnis für ETS-Persistenz |
| `CD` | `/opt/ioc2rpz` | Arbeitsverzeichnis |
| `NODE_NAME` | `ioc2rpz` | Kurzer Erlang-Knotenname |
| `IO2Cookie` | `ioc2rpz` | Erlang-Cookie für verteilte Kommunikation |

Übergib Umgebungsvariablen an Docker mit `-e`:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Aktualisieren Sie Ihre `ioc2rpz.conf`, um auf den gemounteten Zertifikatspfad zu verweisen:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

### Let's Encrypt (Produktion)```bash
# Obtain certificate
sudo certbot certonly --standalone -d ns1.rpz-proxy.com

# Copy to ioc2rpz cfg directory
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/fullchain.pem cfg/ioc2rpz_dot.crt
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/privkey.pem cfg/ioc2rpz_dot.key

Certificates are also reloaded explicitly during a configuration reload (`ioc2rpz-reload-cfg`): when ioc2rpz detects that the certificate files changed, it restarts the TLS listeners with the new certificate immediately, instead of waiting for the ~2 minute Erlang SSL cache. Add an `ioc2rpz-reload-cfg` step to your renewal hook to apply new certificates without downtime.

### Docker Volume Mounting

When running in Docker, mount the certificate directory from the host:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

Erlang erkennt ersetzte Zertifikatsdateien automatisch innerhalb von etwa 2 Minuten. Zertifikate werden auch bei einem erneuten Laden der Konfiguration (`ioc2rpz-reload-cfg`) explizit neu geladen. Lassen Sie keine Zertifikate ablaufen – erneuern Sie sie vor Ablauf, um einen unterbrechungsfreien Betrieb zu gewährleisten.

## Aus dem Quellcode erstellen

> **Hinweis:** Das Erstellen aus dem Quellcode ist für **Entwicklung und Tests** gedacht. Für die Produktion ist **Docker die empfohlene Bereitstellungsmethode** – siehe [Docker Compose](#docker-compose) und das Repository [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc).

### Voraussetzungen

- **Erlang/OTP 24 oder neuer** (`erl -version` zur Überprüfung) und ein passendes [rebar3](https://www.rebar3.org).
- Ein C-Toolkit (zum Erstellen von Abhängigkeiten) und `git`.

### Erstellen & Ausführen```bash
# 1. Clone the repository
git clone https://github.com/Homas/ioc2rpz.git
cd ioc2rpz

# 2. Build a release
rebar3 release

# 3. Edit the configuration (see the minimal example below)
$EDITOR cfg/ioc2rpz.conf

# 4. Start the server (foreground console, or 'start' for background)
_build/default/rel/ioc2rpz/bin/ioc2rpz console
# or: _build/default/rel/ioc2rpz/bin/ioc2rpz start

Siehe [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md) für die maßgebliche Feld-für-Feld-Referenz (source/RPZ tuple layout, SOA timers, key groups, certificates, etc.). Um DoT (port 853), DoH und die HTTPS-REST-API zu aktivieren, fügen Sie einen `{cert,{...}}`-Eintrag hinzu — siehe [Certificate Setup](#certificate-setup).

### Entwicklungsshell (nur für Entwicklung/Tests)

Die folgenden Befehle sind für die lokale Entwicklung und Tests gedacht — nicht für den Produktionseinsatz:```bash
# Compile only (no release)
rebar3 compile

# Run the EUnit test suite
rebar3 eunit
# Run tests for a single module
rebar3 eunit --module=ioc2rpz_fun

# Start an interactive shell with the application and all deps loaded
rebar3 shell

## ioc2rpz™-Verwaltung
### über DNS
ioc2rpz™ unterstützt die Verwaltung über DNS/TCP oder DoT. Es wird empfohlen, DoT oder die REST-API über DNS/TCP zu verwenden. Die aktuelle Version von ioc2rpz™ unterstützt keine separate Verwaltungs-IP/Schnittstelle. In jedem Fall wird dringend empfohlen, einen dedizierten TSIG-Schlüssel (oder Schlüssel) zu erstellen, der nur für die Verwaltung verwendet wird. Sie können die Verwaltung über DNS deaktivieren.  
Unterstützte Aktionen:
- Aktueller Status von ioc2rpz™. Anfrage ``ioc2rpz-status``, Klasse ``CHAOS``, Eintrag ``TXT``. z.B.:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

- Stoppe ioc2rpz™. RR-Name ``ioc2rpz-terminate``, RR-Klasse ``CHAOS``, RR-Typ ``TXT``
- Fordere eine Beispielzone an. RR-Name ``sample-zone.ioc2rpz``, RR-Klasse ``IN``, RR-Typ ``AXFR``
### über REST
Die REST-API (Port 8443/tcp) ist die bevorzugte Verwaltungsschnittstelle. Aus Sicherheitsgründen muss der gesamte Verwaltungsverkehr verschlüsselt sein und die REST-API wird nicht gestartet, wenn kein SSL-Zertifikat vorhanden ist. Alle Endpunkte akzeptieren sowohl GET- als auch POST-Methoden.

Zur Authentifizierung von Anfragen wird die einfache HTTP-Authentifizierung verwendet. TSIG-Verwaltungsschlüssel dienen der Anfrageauthentifizierung. Der Name des TSIG-Schlüssels wird als HTTP-Benutzername und der TSIG-Schlüssel als Passwort verwendet. Der Zugriff auf die REST-API ist durch die im `srv`-Eintrag definierte ACL eingeschränkt.

Das API-Versionssegment unterstützt sowohl `v1` als auch `v1.0` (z. B. `/api/v1/stats/serv` oder `/api/v1.0/stats/serv`).

Die REST-API unterstützt basierend auf dem `Accept`-Header JSON (Standard) und Plain-Text-Ausgabe:
- `application/json` — JSON-Ausgabe (Standard)
- `text/plain` — Plain-Text-Ausgabe```bash
# Example: plain text output
curl -u "keyname:base64key==" -k -H "Accept: text/plain" https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

#### Pfadparameter

| Parameter | Beschreibung |
|-----------|-------------|
| `:rpz_name` | RPZ-Zonenname (z. B. `dga.ioc2rpz`) |
| `:source_name` | IOC-Quellenname (z. B. `sample_fqdn`) |
| `:ioc` | Indikator zum Nachschlagen (FQDN oder IP, z. B. `baddomain.com`) |

#### Statistik-Endpunkte

`/api/v1/stats/serv` — Serverstatistiken (Knotenname, Gesamtregeln, Speichernutzung)```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/stats/serv

{
  "srv": {
    "node_name": "ioc2rpz@hostname",
    "srv_total_rules": 15000,
    "hot_cache_mem": "12.5 Mb",
    "axfr_table_mem": "45.2 Mb",
    "ixfr_table_mem": "8.1 Mb"
  },
  "rpz": [...],
  "sources": [...]
}

```json
{
  "rpz": [
    {
      "name": "malware.ioc2rpz",
      "status": "ready",
      "rule_count": 5000,
      "ioc_count": 4500,
      "serial": 1709000000,
      "serial_ixfr": 1708990000,
      "update_time": 1709000000,
      "ixfr_update_time": 1708995000,
      "ixfr_nz_update_time": 1708995000
    }
  ]
}

```json
{
  "sources": [
    {"name": "sample_fqdn", "ioc_count": 150}
  ]
}

Success: `{"status":"ok","msg":"Configuration reloaded"}`
Error (HTTP 520): `{"status":"error","msg":"Configuration reload error"}`

`/api/v1/mgmt/update_tkeys` — TSIG-Schlüssel aus der Konfiguration neu laden```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

Success: `{"status":"ok","msg":"Terminating"}`

#### Zone Update Endpunkte

`/api/v1/update/all_rpz` — Erzwinge vollständige Aktualisierung aller RPZ-Zonen```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

Success: `{"status":"ok","msg":"RPZ dga.ioc2rpz will be updated"}`
Error (HTTP 520): `{"status":"error","msg":"RPZ dga.ioc2rpz not found"}`

#### Cache-Verwaltungs-Endpunkte

`/api/v1/cache/sources/clear/all` — Alle Quellen aus dem Hot-Cache entfernen```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

Success: `{"status":"ok","msg":"sample_fqdn source was removed from the hot cache"}`

`/api/v1/cache/sources/load/all` — Alle Quellen in den Hot-Cache neu laden```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

Erfolg:```json
{
  "status": "ok",
  "rpz": "malware.ioc2rpz",
  "iocs": ["baddomain.com", "evil.example.org"]
}

Erfolg:```json
{
  "ioc": "baddomain.com",
  "tkey": "dnsproxykey_1",
  "data": [
    {
      "ioc": "baddomain.com",
      "feeds": [
        {
          "feed": "malware.ioc2rpz",
          "wildcard": "true",
          "type": "fqdn",
          "rpz_serial": 1709000000,
          "ioc_expiration": 0,
          "sources": ["abuse-ch", "internal-list"]
        }
      ]
    }
  ]
}

## Überwachung & Health Checks

### REST API Statistiken```bash
# Server statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/serv

# RPZ zone statistics (indicator counts, serials, update times)
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/rpz

# Source statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/source

### DNS-Integritätsprüfungen```bash
# SOA query over UDP
dig @localhost -p 53 your-zone.rpz SOA +short

# Zone transfer over TCP
dig @localhost -p 53 your-zone.rpz AXFR +tcp -y hmac-sha256:keyname:base64key

# DoT query
dig @localhost -p 853 +tls your-zone.rpz SOA

# Sample zone (built-in test zone)
dig @localhost sample-zone.ioc2rpz AXFR +tcp

Das 4-Feld-Formular bleibt gültig und setzt `TrackSources` standardmäßig auf `off`.
### **cert**-Eintrag
Der **cert**-Eintrag wird verwendet, um ein Zertifikat und einen privaten Schlüssel für DNS over TLS, REST API und DoH-Kommunikation zu definieren. Für die Zertifikatserstellung und -verwaltung siehe [Zertifikatseinrichtung](#certificate-setup).

Er besteht aus:
- Pfad zu einer Datei, die ein Zertifikat enthält;
- Pfad zu einer Datei, die einen privaten PEM-codierten Schlüssel enthält;
- Pfad zu einer Datei mit PEM-codierten CA-Zertifikaten.  

Beispiel für einen **cert**-Eintrag:```
{cert,{"cfg/cert.pem", "cfg/key.pem",	"cfg/cacerts.pem"}}.

### **key** record
TSIG-Schlüssel werden für Authentifizierung und Autorisierung verwendet. Es wird empfohlen, unterschiedliche TSIG-Schlüssel für ioc2rpz™-Verwaltung und Zonentransfers zu verwenden.  
**key**-Eintrag besteht aus:
- TSIG-Schlüsselname;
- Algorithmus. ``md5``, ``sha256`` und ``sha512`` werden unterstützt;
- der Schlüssel;
- (optional) Liste der Schlüsselgruppen, zu denen er gehört.

Beispiel für **key**-Einträge:```
{key,{"key_name_1","md5","ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA=="}}.
{key,{"key_name_2","sha256","5Yvt70eJnf95+LJeI8H3TgKGeVparmMB7udA0pv/JRE="}}.
{key,{"key_name_3","sha512","03uuaGl9kqfenjRgIeCv6e29lVvMwviB1+cDX1I0jcVOcTU4jWFwRkfo3ULRMD+NGDfwzYvXkJ94FNEaAW4vzw==",["customers","public"]}}.

Bitte beachten Sie die Dokumentation von "dnssec-keygen" für Details. Schlüssel können Gruppen zugewiesen werden, um eine gruppenbasierte Autorisierung in der RPZ-Zonen-Zugriffskontrolle zu ermöglichen.

### **key_group** Datensatz
Schlüsselgruppen bieten gruppenbasierte Autorisierung für Zonentransfers und -verwaltung. Anstatt einzelne Schlüssel in `rpz`- oder `srv`-Datensätzen aufzulisten, können Sie Schlüssel benannten Gruppen zuweisen und die Gruppe referenzieren.

Es gibt zwei Möglichkeiten, Schlüssel Gruppen zuzuweisen:
1. Inline über das optionale 4. Feld des `key`-Datensatzes: `{key, {Name, Alg, Secret, [Groups]}}`
2. Explizit über einen `key_group`-Datensatz (unten gezeigt)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

Gruppen werden in `rpz`- und `srv`-Datensätzen unter Verwendung des Tupels `{groups, ["group1", "group2"]}` in der Schlüsselliste referenziert:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

### **source** record
Eine Quelle ist ein Feed mit bösartigen Indikatoren. FQDNs, IPv4- und IPv6-Adressen werden unterstützt. Eine Quelle ist eine Textdatei oder ein Feed mit Textdaten. Indikatoren sollten durch Zeilenumbruch-/Wagenrücklaufzeichen (/n, /r oder beide /r/n) getrennt sein. ioc2rpz™ unterstützt eine unbegrenzte Anzahl von Indikatoren.  
Ein **source**-Eintrag besteht aus:
- Quellenname;
- Quellenpfad für den vollständigen Quellentransfer (AXFR). URLs (http/https/ftp), lokale Dateien und Skripte werden unterstützt. Das Präfix **file:** wird für lokale Dateien verwendet. Das Präfix **shell:** wird verwendet, um ein lokales Skript/Kommando auf einem Host/Container auszuführen, das Indikatoren und optional ein Ablaufdatum an STDOUT zurückgeben soll;
- Quellenpfad für den inkrementellen Quellentransfer (IXFR). AXFR-, IXFR-Pfade unterstützen Schlüsselwörter zur Verkürzung von URLs und zur Bereitstellung von Zeitzonen-Aktualisierungszeitstempeln:
  - **[:AXFR:]** – vollständiger AXFR-Pfad. Kann nur in IXFR-Pfaden verwendet werden;
  - **[:FTimestamp:]** – Zeitstempel der letzten Aktualisierung der Quelle (z. B. 1507946281)
  - **[:ToTimestamp:]** – aktueller Zeitstempel;
- REGEX, mit dem Indikatoren und ihre Ablaufzeit extrahiert werden. Der erste Treffer ist ein Indikator, der zweite Treffer ist eine Ablaufzeit. Die Ablaufzeit ist ein optionaler Parameter. Ein regulärer Ausdruck muss in doppelte Anführungszeichen eingeschlossen werden. Wenn Sie eine leere REGEX (`""`) angeben, wird eine Standard-REGEX verwendet (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). `none` wird verwendet, wenn keine REGEX erforderlich ist (die Quelle liefert bereits Daten im erforderlichen Format).
Optionale Parameter (alle oder keines müssen verwendet werden):
- Benutzer-ID (intern verwendet).
- Maximale Anzahl von IoCs.
- Vollständige Quellenaktualisierung, Hot-Cache-Zeit (in Sekunden).
- Inkrementelle Quellenaktualisierung, Hot-Cache-Zeit (in Sekunden).

HTTPS-Quellendownloads überprüfen das TLS-Zertifikat des entfernten Servers. Quellen mit ungültigen oder selbstsignierten Zertifikaten können nicht heruntergeladen werden. Verwenden Sie für selbstsignierte Zertifikate eine `shell:`-Quelle mit `curl --insecure`.

**Einschränkungen bei lokalen Dateien:** `file:`-Pfade, die `..` (Elternverzeichnis-Durchlauf) enthalten, werden aus Sicherheitsgründen abgelehnt; verwenden Sie einen Pfad ohne `..` (innerhalb des Arbeits-/Datenverzeichnisses).

**Einschränkungen bei Shell-Befehlen:** Das ausführbare Programm jedes Pipeline-Segments muss ein absoluter Pfad (z. B. `/usr/bin/curl`) oder ein Bare-Name-Safe-Text-Dienstprogramm (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk` usw.) sein; destruktive Befehle und Shells (`rm`, `bash`, `sh` usw.) werden blockiert, und Befehlssubstitution (`$(...)`, Backticks) sowie Ausgabeumleitung (`>`, `>>`) werden abgelehnt. Abgelehnte Befehle werden nicht ausgeführt und über CEF-Ereignis 151 protokolliert (ausgeführte Befehle über 150). Siehe [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md#shell-command-restrictions) für den vollständigen Regelsatz.

Wenn eine Quelle weniger als 50 % ihrer vorherigen Indikatoranzahl zurückgibt, wird die Aktualisierung abgelehnt und die vorherigen Daten bleiben erhalten. Dies verhindert, dass degradierte Feeds die RPZ-Abdeckung reduzieren. Konfigurierbar über das Makro `?SOURCE_MIN_IOC_RATIO`.

Beispiel für einen **source**-Eintrag:```
%% Local file source — indicators without expiration
{source,{"sample_fqdn","file:cfg/sample_ioc_fqdn.txt","[:AXFR:]",none}}.

%% Local file source — indicators with expiration timestamps (tab-separated)
{source,{"sample_expire","file:cfg/sample_ioc_expire.txt","[:AXFR:]","^([A-Za-z0-9][A-Za-z0-9\-\._]+)\t([0-9TZ:\-]+)$"}}.

%% Shell source — fetch RPZ via AXFR and extract CNAMEs
{source,{"base.rpz1","shell:/usr/bin/dig -y KEYNAME:TSIGKEY @127.0.0.1 base.rpz.ioc2rpz.local axfr | /bin/grep -e CNAME | /bin/grep -v '*.' | /usr/bin/awk -F '.base.rpz' '{print $1}'","",none}}.

### IOC-Quellenattribution
Ein RPZ-Feed wird durch das Zusammenführen von Indikatoren aus mehreren Quellen erstellt. Die Quellenattribution ermöglicht es der IOC-Lookup-API zu melden, **welche Quelle(n) innerhalb eines Feeds** zu einem Indikator beigetragen haben – nützlich für das Triage eines gemeldeten Fehlalarms. Die Nachverfolgung ist **standardmäßig deaktiviert** und wird pro Feed mit einer optionalen serverweiten Standardeinstellung gesteuert.

**Konfiguration**

- Pro Feed: das optionale abschließende (16.) `TrackSources`-Element des Tupels `{rpz,{...}}` – `auto | true | false`.
- Serverweite Standardeinstellung: das optionale abschließende (5.) `TrackSources`-Element des Tupels `{srv,{...}}` – `off | auto | on` (Standard `off`).

Beide sind optional und abwärtskompatibel: vorhandene Konfigurationsdateien (15-Feld-`rpz`, 4-Feld-`srv`) werden unverändert geladen und verhalten sich wie `off`.

**Auflösungsreihenfolge** – der effektive Zustand für einen Feed wird wie folgt aufgelöst:
1. der explizite `track_sources`-Wert des Feeds, falls gesetzt;
2. andernfalls die serverweite Standardeinstellung;
3. andernfalls der integrierte Standard `off`.

`auto` bedeutet: nur **Multi-Source**-Feeds nachverfolgen. Single-Source-Feeds werden nie maskiert – ihr einziger Quellenname wird direkt zurückgegeben (keine Nachverfolgungskosten).

**API – das additive Feld `sources`**

Die Antwort von `/api/v1/ioc/:ioc` erhält ein neues Feld `sources` in jedem Feed-Objekt. Es ist **additiv und abwärtskompatibel**: alle vorhandenen Felder bleiben unverändert, sodass alte Clients, die es ignorieren, weiterhin funktionieren.

- Nachverfolgter Multi-Source-Feed: ein JSON-Array der beitragenden Quellennamen.
- Single-Source-Feed: ein Array mit einem Element, das den einen Quellennamen enthält.
- Nachverfolgung deaktiviert oder Attribution unbekannt (z. B. eine vor dem Upgrade zwischengespeicherte Zeile vor ihrem einmaligen AXFR-Neuaufbau): `null` (JSON) / `(disabled)` oder `(unavailable)` (TXT).```json
{
  "feed": "mixed.ioc2rpz",
  "wildcard": "true",
  "type": "fqdn",
  "rpz_serial": 1709000000,
  "ioc_expiration": 0,
  "sources": ["abuse-ch", "internal-list"]
}