SIEM-videresendelse
Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.
fremforge skriver alle administrative handlinger, der ændrer tilstand, til en revisionslog pr. organisation med integritet sikret af en hashkæde (se Audit chain integrity). De samme hændelser kan sendes videre til din SIEM, så snart de er skrevet, så dine detektionsregler ser dem efter få sekunder og ikke først ved næste CSV-eksport.
Denne side beskriver videresendelsens opbygning, kontrakten for det, der sendes over linjen, så du kan verificere det, og hvordan de udbredte SIEM-systemer tager imod det.
Sådan foregår leveringen
audit-emit skriver rækken i kæden og sætter i samme databasetransaktion hændelsen i kø til alle aktiverede endpoints, hvis præfikser for handlinger matcher. En leveringsproces sender hvert endpoints kø i rækkefølge, med en eller flere hændelser pr. request afhængigt af endpointets format. En hændelse fjernes først fra køen, når din modtager svarer 2xx.
Indstillingerne ligger under Organisationsadministration → Integration → SIEM-videresendelse (/<org>/_admin/siem), og de samme indstillinger findes i REST API’et (/_app/api/v1/orgs/<org>/siem/endpoints).
Siden SIEM-videresendelse har formularen Tilføj et endpoint og listen over endpoints: navn, URL (legitimationsoplysninger maskeret), status, seneste levering og antal ventende hændelser. Hvert endpoints navn åbner endpointets egen side (/<org>/_admin/siem/<endpoint id>) med ét kort pr. indstilling:
- Overblik: status, årsagen til seneste fejl, filteret på handlingspræfikser, Deaktivér/Aktivér og Send test.
- Auth-header: angiv, rotér eller fjern den.
- Signatur: hvad HMAC’en dækker.
- Levering: ventende hændelser, den ældste af dem, næste forsøg, antal leverede og kasserede samt indstillingerne for format og samling i batches.
- Send igen: send tidligere hændelser igen.
- Slet endpoint: skriv endpointets navn for at bekræfte.
Konfigurér et endpoint
- Gå til Organisationsadministration → SIEM-videresendelse → Tilføj et endpoint.
- Angiv et Navn (fritekst, unikt i organisationen) og URL’en til din modtager:
https://…ellersyslog+tls://host:porttil syslog over TLS.http://,localhost, RFC1918- og metadataadresser afvises; brug en modtager, der kan nås offentligt. - Vælg Format (se Formater og batches). De øvrige trin ligger under Avancerede indstillinger og kan også ændres senere på endpointets side.
- Indsnævr eventuelt allowlisten med præfikser for handlinger (fx
forgejo.push, billing.). Tom betyder, at alt sendes videre. Hvert præfiks matches medaction.startsWith(prefix). - Slå eventuelt Medtag adgangsloggen for registret til for også at modtage én hændelse pr. request til pakke- eller container-registryet (
registry.access.*). Det er slået fra som standard; se Registry access log. Image-gates’ afgørelser ved pull,registry.pull.blockedogregistry.pull.would_block, er revisionshændelser og ikke adgangshændelser, så de sendes videre uden denne indstilling, én pr. image-digest, gate og afgørelse pr. time; se Container pull gates. - Angiv eventuelt en Auth-header: et headernavn og en hemmelig værdi, der sendes med hver request (for eksempel
AuthorizationogSplunk <token>). Se Autentificering. - Vælg, hvad signaturen dækker (tidsstempel og body som standard, eller kun body).
- Angiv batchstørrelse, request-størrelse og ventetid.
- Klik på Opret endpoint. Den delte HMAC-secret vises én gang på næste skærmbillede; kopiér den ind i modtagerens konfiguration. fremforge viser den aldrig igen. Mister du den, så slet endpointet og tilføj det igen.
Endpointet er aktivt med det samme, og bekræftelsen linker til dets side. Send test sender en syntetisk fremforge.siem.test-hændelse i endpointets format, med dets headers og signatur, og viser svarets status og de første 200 bytes af modtagerens svar.
Legitimationsoplysninger i URL’en. Nogle collectors tager deres legitimationsoplysninger i URL’en (?token=, ?key=&secret= eller user:password@). fremforge gemmer URL’en, som den er indtastet, krypteret, og viser den alle andre steder (administrationssiden, API’et, testresultatet, revisionsloggen) med alle query-værdier og brugeroplysningerne erstattet af ***. Kun selve leveringen bruger den fulde URL.
Autentificering
To mekanismer, som kan bruges sammen:
- Auth-header. Én header pr. endpoint, med et navn og en værdi efter eget valg. Værdien er krypteret i hvile og kan kun skrives: ingen side, intet API-svar, ingen loglinje og ingen revisionshændelse indeholder den. Revisionsloggen registrerer headerens navn og hvornår den blev angivet. Når du roterer, gemmer du en ny værdi; den gamle holder op med at blive sendt med det samme, så tilføj den nye nøgle i din collector først. Headernavne, der ville ødelægge requesten, afvises:
Host,Content-Length,Content-Type,Content-Encoding,Transfer-Encoding,Connection,Keep-Alive,Upgrade,TE,Trailer,Expect,Accept-Encoding,User-Agent,Cookie,Proxy-*ogX-Fremforge-*. Værdier er printbar ASCII på op til 4096 tegn. - HMAC-signatur. Hver request har
X-Fremforge-Signature: sha256=<hex>, nøglet med endpointets HMAC-secret. Som standard dækker den<timestamp>.<body>, så din modtager kan afvise en gammel request ud fra tidsstemplet. Med Signaturen dækker: kun body dækker den alene den rå body, og det er det, modtagere med indbygget verifikation af body (Elastics HTTP endpoint-input) tjekker. En modtager, der kun verificerer body, kan ikke afvise en genafspillet request ud fra alder; deduplikér i stedet på hændelsensid.
Kontrakten over linjen
Hver levering over HTTPS er en POST:
| Header | Værdi |
|---|---|
Content-Type | application/json (json, json_array), application/x-ndjson (ndjson), text/plain; charset=utf-8 (cef) |
User-Agent | fremforge-siem-forwarder/1 |
X-Fremforge-Timestamp | Unix-sekunder (streng) for, hvornår fremforge byggede requesten |
X-Fremforge-Signature | sha256=<hex> over <timestamp>.<body>, eller over <body>, når kun body er valgt |
Idempotency-Key | Hændelsens id for en enkelt hændelse; for en batch en SHA-256 af batchens hændelses-id’er i rækkefølge |
X-Fremforge-Event-Count | Antal hændelser i body |
| din auth-header | Når den er angivet |
Hver hændelse har denne form (nøglerne på øverste niveau i denne rækkefølge; nøglerne under fields.* sorteret alfabetisk, så bytes er stabile):
{
"id": "00000000-0000-0000-0000-000000000000",
"tenant_id": "11111111-1111-1111-1111-111111111111",
"actor": "alice",
"action": "policy.update.api",
"fields": { "...": "..." },
"created_at": "2026-05-15T13:42:11.123Z",
"hash_chain": {
"prev_hash": "ab12...",
"this_hash": "cd34..."
}
}id er revisionshændelsens id. Det er det samme ved hvert genforsøg og hver genafsendelse af hændelsen: brug det til at deduplikere.
actor er et rent Forgejo-brugernavn for en handling udført af en person (i webkonsollen og ved mange API-kald den bruger, der udstedte tokenet), token:<id> for andre API-kald, operator:<email> for en handling udført af en medarbejder hos fremverk og andre former af typen <kind>:<id> for systemkomponenter.
hash_chain.this_hash er den samme hash, som forankres i OBS Object Lock, så din SIEM kan bevise, at en hændelse er ældre end en kendt forankring.
En adgangshændelse fra registryet (kun på et endpoint med include_access_log) har samme form, med action registry.access.<action> og "hash_chain": null: adgangshændelser er ikke en del af revisionsloggens hashkæde. Dens fields er hændelsen, som adgangslog-API’et returnerer den.
Formater og batches
| Format | Body | Hændelser pr. request |
|---|---|---|
json (standard) | Ét hændelsesobjekt | 1 |
ndjson | Ét hændelsesobjekt pr. linje, hver linje afsluttet med \n | Op til maks. hændelser |
json_array | Et JSON-array af hændelsesobjekter | Op til maks. hændelser |
cef | Én CEF-linje pr. hændelse, hver afsluttet med \n | Op til maks. hændelser |
For formaterne med batches:
- Maks. hændelser pr. request: 1 til 1000 (100, når du skifter til et batchformat uden at vælge).
- Maks. størrelse pr. request: 1 KiB til 4 MiB (standard 1 MiB). En batch lukkes, før den ville overskride grænsen; en enkelt hændelse sendes altid.
- Maks. ventetid: 0 til 60.000 ms (standard 0). Hvor længe en delvist fyldt batch venter på flere hændelser, før den sendes.
Hændelserne leveres i den rækkefølge, de blev skrevet.
Felttilknytning i CEF
CEF:0|fremverk|fremforge|1|<action>|<action>|<severity>|<extension>
| CEF | Værdi |
|---|---|
| Signature ID, Name | action |
| Severity | 9, når hash_chain.this_hash er chain-broken; 7, når action indeholder fail, denied, deny, blocked, violation, malware, secret, breach eller tamper; 5, når den indeholder delete, revoke, disable, remove, bypass, suspend eller dismiss; ellers 3 |
rt | created_at, millisekunder siden epoch |
externalId | id (nøglen til deduplikering) |
suser | actor |
act | action |
cat | action til og med første . (ikke medregnet) |
cs1Label=tenantId, cs1 | tenant_id |
cs2Label=fields, cs2 | fields som JSON |
cs3Label=hashChainThis, cs3 | hash_chain.this_hash |
cs4Label=hashChainPrev, cs4 | hash_chain.prev_hash, tom, når der ikke er nogen |
dvchost | frem.sh |
Headerfelter escaper \ og |; extension-værdier escaper \, = og linjeskift (\n, \r). En værdi fra en revisionshændelse kan derfor ikke starte et nyt felt eller en ny linje.
Syslog over TLS
En endpoint-URL på formen syslog+tls://host[:port] (standardport 6514) leverer via syslog i stedet for HTTPS:
- Transport: TCP med TLS 1.2 eller nyere, indrammet med octet counting (RFC 5425). fremforge verificerer modtagerens certifikat mod det offentlige sæt af CA’er for værtsnavnet i URL’en, så modtageren skal have et offentligt betroet certifikat. Brug port 6514 eller 443; andre porte kan ikke nås fra fremforge.
- Besked: én RFC 5424-besked pr. hændelse,
<PRI>1 TIMESTAMP frem.sh fremforge - MSGID - MSG. PRI er facility 13 (log audit) × 8 + severity: 2 for CEF-severity 9, 4 for 7, 5 for 5, ellers 6. MSGID eraction(op til 32 tegn). MSG er et UTF-8-byte-order-mark efterfulgt af CEF-linjen (formatcef) eller JSON-hændelsen (alle andre formater). - Batches: op til maks. hændelser beskeder inden for maks. størrelse pr. request deler én forbindelse.
- Ingen kvittering. Syslog har intet svar på applikationsniveau. En batch regnes for leveret, når alle beskeder er skrevet, og din modtager har lukket forbindelsen pænt. En afvist forbindelse, en TLS-fejl eller en modtager, der lukker, før batchen er skrevet, får batchen til at fejle, og den forsøges så igen i sin helhed. En modtager, der accepterer forbindelsen og derefter smider det læste væk, ser ud som leveret. Deduplikér på
externalId(CEF) ellerid(JSON). - Auth-headeren og HMAC-signaturen findes kun over HTTPS. Begræns din listener til fremforge med TLS og om nødvendigt en allowlist over kildeadresser.
Verificér signaturen
HMAC’en beregnes over de præcise bytes i body, i den rækkefølge de ankommer. Parse og serialisér ikke igen, før du verificerer.
Modtager i Node.js (tidsstempel og body):
import { createHmac, timingSafeEqual } from 'node:crypto';
function verify(req, body) {
const sig = req.headers['x-fremforge-signature'];
const ts = req.headers['x-fremforge-timestamp'];
if (!sig?.startsWith('sha256=') || !ts) throw new Error('missing headers');
// 5-minute replay window. Adjust to your tolerance.
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) throw new Error('stale');
const expected = createHmac('sha256', SHARED_SECRET)
.update(`${ts}.${body}`)
.digest('hex');
const got = sig.slice(7); // strip "sha256="
if (expected.length !== got.length) throw new Error('bad sig');
if (!timingSafeEqual(Buffer.from(expected, 'hex'), Buffer.from(got, 'hex'))) {
throw new Error('bad sig');
}
}Modtager i Python (tidsstempel og body):
import hmac, hashlib, time
def verify(headers, raw_body: bytes) -> None:
sig = headers.get('X-Fremforge-Signature', '')
ts = headers.get('X-Fremforge-Timestamp', '')
if not sig.startswith('sha256=') or not ts:
raise ValueError('missing headers')
if abs(time.time() - int(ts)) > 300:
raise ValueError('stale')
expected = hmac.new(
SHARED_SECRET.encode(),
f'{ts}.'.encode() + raw_body,
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(expected, sig[7:]):
raise ValueError('bad sig')Når kun body er valgt, udelader du tidsstemplet: HMAC-SHA256 over raw_body.
Fejlhåndtering, genforsøg og genafsendelse
- Hver request har en timeout på 10 sekunder.
- Et svar, der ikke er
2xx, en timeout eller en forbindelsesfejl efterlader hændelserne i køen. Endpointet venter med næste forsøg: 5 sekunder, fordoblet ved hver fejl i træk, højst 10 minutter, med ±20 % jitter. Når din modtager svarer igen, tømmes køen i rækkefølge. - Efter 5 fejl i træk viser endpointet
failingmed årsagen til seneste fejl. Leveringen bliver ved med at forsøge igen; du behøver ikke slå noget til eller fra. Deaktiverer du et endpoint, sættes nye hændelser ikke længere i kø til det; aktiverer du det igen, genoptages leveringen med det samme. - En
413halverer batchen. En enkelt hændelse, som din modtager stadig afviser som for stor, kasseres og tælles. - Ikke-leverede hændelser gemmes i din organisations opbevaringsperiode for revisionsloggen (Organisationsadministration → Godkendelsespolitik; 90 dage som standard) og højst 200.000 pr. endpoint. Ældre hændelser kasseres og tælles.
- Kortet Levering på endpointets side (og API’ets
delivery-blok,dropped_total) viser antallet af ventende hændelser, den ældste af dem, næste forsøg og antal leverede og kasserede (vist som “Kasseret” i den danske konsol). En hændelse kasseres, og leveres aldrig til det endpoint, medmindre du sender den igen, kun i disse tilfælde: din modtager svarede413på netop den hændelse alene; den ventede stadig, da den blev ældre end din opbevaringsperiode for revisionsloggen; endpointet havde allerede 200.000 ventende hændelser, og i så fald ryger de ældste først; eller selve revisionshændelsen findes ikke længere, hvilket ikke sker inden for opbevaringsperioden. Intet andet kasserer en hændelse: en modtager, der fejler eller er deaktiveret, får kun hændelserne til at vente. - Send igen sætter dine revisionshændelser i kø igen fra et bestemt tidspunkt: Send igen fra (UTC) på endpointets side eller
POST /_app/api/v1/orgs/<org>/siem/endpoints/<id>/replaymed{"since": "<ISO 8601>", "until": "<ISO 8601, optional>"}.sincemå højst ligge din opbevaringsperiode for revisionsloggen tilbage. Én request sætter højst 100.000 hændelser i kø og returnerernext_since, når der er flere tilbage. Hændelser, der stadig venter, sættes ikke i kø to gange; genafsendte hændelser beholder deresid.
Leveringen sker mindst én gang: et genforsøg efter et mistet svar eller en genafsendelse sender en hændelse igen. Deduplikér på id.
Udbredte SIEM-systemer
| SIEM | Modtager over HTTPS via | Indstillinger i fremforge | Direkte fra fremforge? |
|---|---|---|---|
| Cortex XSIAM | HTTP log collector | Auth-header Authorization: <API key>, format json | Ja |
| Splunk | HTTP Event Collector, /services/collector/raw | Auth-header Authorization: Splunk <token>, format ndjson | Ja |
| Microsoft Sentinel | Azure Monitor Logs Ingestion API | Kræver et kortlivet Entra ID-token | Nej, via relay |
| Elastic | Elastic Agent / Filebeat HTTP endpoint-input | Signaturen dækker kun body, eventuelt en hemmelig header | Ja |
| IBM QRadar | HTTP Receiver-logkilde eller en TLS Syslog-logkilde | Format cef | Ja, hvis listeneren kan nås offentligt |
| Google SecOps | Webhook-feed | URL med ?key=&secret=, format ndjson | Ja |
Cortex XSIAM
Modtager JSON fra tredjepart via en HTTP log collector (Settings → Data Sources & Integrations → + Add New → HTTP). Vælg Log Format: JSON; den Vendor og det Product, du angiver, giver datasættet navnet <vendor>_<product>_raw. Collectorens URL har formen https://api-<tenant external URL>/logs/v1/event og tager sin API-nøgle i Authorization (Palo Alto docs).
Opsætning: URL = collectorens URL; auth-header Authorization = collectorens API-nøgle; format json.
Eksempel på parsing- og datamodelregler for fremforge_audit_raw
Parsingregel (Settings → Configurations → Data Management → Parsing Rules), så _time er fremforges hændelsestidspunkt og ikke ankomsttidspunktet. created_at har altid tre decimaler og et Z:
[INGEST:vendor="fremforge", product="audit", target_dataset="fremforge_audit_raw", no_hit=keep]
alter _time = parse_timestamp("%Y-%m-%dT%H:%M:%E3SZ", created_at);Datamodelregel (Settings → Configurations → Data Management → Data Model Rules):
[MODEL: dataset="fremforge_audit_raw"]
filter action != "fremforge.siem.test"
| alter
xdm.event.id = id,
xdm.event.type = "fremforge_audit",
xdm.event.original_event_type = action,
xdm.event.operation_sub_type = action,
xdm.event.description = to_json_string(fields),
xdm.observer.vendor = "fremforge",
xdm.observer.product = "fremforge",
xdm.observer.unique_identifier = tenant_id,
xdm.source.user.identifier = actor;Begge forudsætter, at XSIAM gemmer JSON-nøglerne på øverste niveau som kolonner. Viser dit datasæt kun _raw_log, så læs værdierne med json_extract_scalar(_raw_log, "$.created_at") og så videre.
Splunk
Modtager via HTTP Event Collector. /services/collector/raw tager body, som den er; sæt sourcetype=_json på URL’en, så hver linje bliver én hændelse. Tokenet sendes i Authorization: Splunk <token>. Med indexer acknowledgement slået til kræver raw-endpointet også et kanal-GUID; sæt det på URL’en som channel=<GUID> (Splunk docs).
Opsætning: URL https://<hec-host>:8088/services/collector/raw?sourcetype=_json; auth-header Authorization = Splunk <token>; format ndjson.
Microsoft Sentinel
Modtager egen JSON via Azure Monitors Logs Ingestion API i en brugerdefineret _CL-tabel, der er defineret af en data collection rule (DCR). Requesten går til {endpoint}/dataCollectionRules/{dcrImmutableId}/streams/{streamName}?api-version=2023-01-01 med et Entra ID-bearer-token fra client credentials-flowet (scope https://monitor.azure.com/.default), og body skal være et JSON-array (Microsoft docs). Det ældre HTTP Data Collector API nåede end of support den 14. september 2026; byg ikke på det.
Opsætning: tokenet udløber efter cirka en time, så en statisk auth-header kan ikke bære det. Sæt relayet ind imellem: det henter og cacher tokenet og sender body videre. Brug format json_array, så body allerede er det array, API’et vil have. Tilknyt created_at til TimeGenerated i DCR-transformationen.
Elastic
Modtager via HTTP endpoint-inputtet i Elastic Agent (integrationen Custom HTTP Endpoint Logs) eller Filebeat. Det lytter på sin egen port (standard 8000), kan terminere TLS og kan tjekke en HMAC over body (Elastic docs).
Opsætning: signaturen dækker kun body; sæt i inputtet hmac.header: X-Fremforge-Signature, hmac.key: <the endpoint's HMAC secret>, hmac.type: sha256 og hmac.prefix: "sha256=". Vil du også bruge inputtets mulighed for en hemmelig header, så angiv samme headernavn og -værdi som endpointets auth-header. Format json, eller ndjson til batches. Indeksér actor, action og tenant_id som keyword.
IBM QRadar
Modtager bodies fra HTTP POST via en logkilde, der bruger protokollen HTTP Receiver. QRadar kører en HTTP- eller HTTPS-server på en Event Collector (standardport 12469); HTTPS kræver et certifikat udstedt af en CA, og mutual TLS er valgfrit (IBM docs). CEF-linjer parses af QRadars Universal CEF DSM.
Opsætning: URL = modtagerens offentlige HTTPS-URL eller syslog+tls://<collector>:6514 til en TLS Syslog-logkilde; format cef. fremforge kan ikke præsentere et klientcertifikat, så lad mutual TLS være slået fra. Kan Event Collectoren ikke nås fra internettet, sender en reverse proxy eller et syslog-relay i din kant videre til den.
Google SecOps (Chronicle)
Modtager via et webhook-feed (Settings → Feeds → Add new, kildetypen Webhook, vælg derefter en logtype). Requests går til feedets ...:importPushLogs-endpoint med en API-nøgle og feedets secret, enten som headerne X-goog-api-key og X-Webhook-Access-Key eller som ?key=<API key>&secret=<secret>. Flere JSON-objekter adskilt af linjeskift kan dele én request, op til 4 MB (Google docs). Der findes ingen færdig parser til fremforge; du skal bruge en logtype og en parser til disse hændelser.
Opsætning: URL = feedets endpoint med ?key=<API key>&secret=<secret> (gemmes krypteret og vises med ***); format ndjson; maks. størrelse pr. request højst 4096 KiB.
Et relay, der verificerer signaturen
Sentinel og alle modtagere, der kræver mere end én header eller et kortlivet token, bruger en lille tjeneste: verificér fremforges signatur, og send derefter body uændret videre med SIEM’ens legitimationsoplysninger. Denne version bruger kun Pythons standardbibliotek; sæt TARGET_URL og TARGET_AUTH til din SIEM. Til Sentinel tilføjer du hentning af token; med format json_array er body allerede det array, den vil have. MAX_BODY svarer til standardstørrelsen pr. request på 1 MiB. Relayet sender en korrekt signeret hændelse videre med legitimationsoplysningerne, svarer 401 på en forkert signatur eller et tidsstempel, der er mere end fem minutter gammelt, og 502, når målet ikke kan nås.
"""fremforge SIEM forwarder -> SIEM relay: verify the signature, forward with the SIEM's credential."""
import hashlib
import hmac
import os
import time
import urllib.error
import urllib.request
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
SECRET = os.environ["FREMFORGE_SIEM_SECRET"].encode()
TARGET_URL = os.environ["TARGET_URL"] # e.g. https://api-<tenant>/logs/v1/event
TARGET_AUTH = os.environ["TARGET_AUTH"] # e.g. "<XSIAM API key>" or "Splunk <HEC token>"
MAX_SKEW_S = 300
MAX_BODY = 1024 * 1024
class Relay(BaseHTTPRequestHandler):
def do_POST(self):
length = int(self.headers.get("Content-Length") or 0)
if length <= 0 or length > MAX_BODY:
return self.reply(413)
body = self.rfile.read(length)
sig = self.headers.get("X-Fremforge-Signature", "")
ts = self.headers.get("X-Fremforge-Timestamp", "")
if not sig.startswith("sha256=") or not ts.isdigit():
return self.reply(401)
if abs(time.time() - int(ts)) > MAX_SKEW_S:
return self.reply(401)
expected = hmac.new(SECRET, ts.encode() + b"." + body, hashlib.sha256).hexdigest()
if not hmac.compare_digest(expected, sig[7:]):
return self.reply(401)
req = urllib.request.Request(
TARGET_URL,
data=body,
method="POST",
headers={"Authorization": TARGET_AUTH, "Content-Type": "application/json"},
)
try:
# fremforge gives up after 10 s; answer before that.
with urllib.request.urlopen(req, timeout=4) as res:
status = res.status
except urllib.error.HTTPError as e:
status = e.code
except OSError:
status = 0
# Pass failure back, so fremforge keeps the event and retries it.
self.reply(200 if 200 <= status < 300 else 502)
def reply(self, code):
self.send_response(code)
self.send_header("Content-Length", "0")
self.end_headers()
def log_message(self, fmt, *args):
pass
if __name__ == "__main__":
ThreadingHTTPServer(("0.0.0.0", int(os.environ.get("PORT", "8080"))), Relay).serve_forever()Kør det bag din sædvanlige TLS-terminering: fremforge leverer kun til offentlige https://-URL’er. Hold relayets svartid under 10 sekunder, og returnér et svar, der ikke er 2xx, når SIEM’en har afvist hændelsen. Et relay, der altid svarer 200, mister hændelser: fremforge betragter et 2xx som leveret og fjerner hændelsen fra køen.
Generisk webhook
Ethvert HTTPS-endpoint, der returnerer 2xx, når det har accepteret requesten. Verificér med kodeeksemplerne ovenfor. Det passer til selvhostede SIEM-systemer (Wazuh, Graylog, …) og HTTP-indtag som Logflare eller Datadog.
Overvågning hos operatøren
fremverks operatører ser hvert endpoints tilstand på SIEM-sundhedssiden i operatørportalen. Der udløses en alarm, når et endpoints ældste ikke-leverede hændelse er mere end 24 timer gammel, og vi kontakter din organisations ejere. Sæt også en alarm op i din SIEM, hvis der udebliver hændelser fra fremforge.
Hvad der ikke sendes over linjen
- Syslog over UDP eller ukrypteret TCP. Syslog sendes kun over TLS.
- Klientcertifikater (mutual TLS) over for din modtager.
- Mere end én egen header pr. endpoint.
- Udsendelse på tværs af organisationer. Hvert endpoint er bundet til én organisation. Der findes intet spejl hos operatøren; hændelser fra din organisation forlader aldrig organisationens egen kæde.
Relateret
- Audit chain integrity: hvad hændelserne faktisk indeholder, og hvordan du verificerer kæden fra ende til anden.
- Webhooks: samme semantik over linjen for hændelser fra repositories og organisationen, signeret og leveret på samme måde.
- Hosted runner model: hvor hændelser fra runnere kommer fra i kæden.