Ereshkigal
view release on metacpan or search on metacpan
docs/kurs/akamai.md view on Meta::CPAN
client_secret = "..."
access_token = "akab-..."
network_list_id = "12345_KURWEB"
```
## The activation caveat â read this first
Network list edits land in the API immediately but are **not live on
the edge until the list is activated** to the production network.
This kur appends and removes elements; it does not call the
activation endpoint. That makes it suitable for lists on
fast-activation setups or where something else handles activation
(automation, or lists configured to auto-activate via other
tooling) â and unsuitable as a standalone rapid-response ban path.
Know your activation story before relying on it.
## Akamai-side setup â required first
- An **IP-type network list**, created in Control Center or via the
API; the option takes its ID.
- A security configuration (App & API Protector or similar) whose
docs/kurs/cloudflare.md view on Meta::CPAN
`mode` is what Cloudflare does with matching requests â `block`
refuses outright, the challenge modes interpose a CAPTCHA / JS proof
/ managed challenge instead, useful when you would rather turn back than
banish.
## What each operation does
| operation | API traffic |
|------------|------------------------------------------------------------------------------|
| `init` | `GET <endpoint>?per_page=5` â verifies credentials and endpoint |
| `ban` | `POST <endpoint>` with mode/configuration/notes |
| `unban` | `GET <endpoint>?mode=..¬es=..&configuration.target=..&configuration.value=..` to find the rule ID, then `DELETE <endpoint>/<id>` |
| `list` | no API call â the kur's own ban book |
| `check` | same probe as init |
| `flush` | the unban lookup+DELETE per banned IP |
| `re_init` | teardown (best effort), init, re-POST every banned IP |
| `teardown` | the unban lookup+DELETE per banned IP (ban book kept for re_init) |
`<endpoint>` is
`.../zones/<zone>/firewall/access_rules/rules` or
`.../user/firewall/access_rules/rules`.
API-level failures die with the HTTP status and Cloudflare's error
codes/messages included, which is what lands in the kur's error
responses and log.
## self_heal and remote drift
`check` verifies the endpoint and credentials still answer â it does
**not** verify individual rules still exist, so a rule someone
deleted in the dashboard stays deleted until `re_init`. The converse
is handled: unbanning an IP whose rule is already gone is treated as
already-unbanned, not an error.
## Gotchas
- **Every kur ban is an API round trip**, and Cloudflare rate-limits
the API (per-account request budgets). A hostile flood of
ban-worthy IPs turns into a flood of API calls â consider longer
docs/kurs/netscaler.md view on Meta::CPAN
expression, vserver or global binding â is your design; the kur only
manages the membership.
A dedicated API user with just the permissions to manage dataset
bindings is preferable to `nsroot`.
## Requirements
- `LWP::UserAgent` installed, plus `LWP::Protocol::https` when
`scheme` is https (the default) â loaded only at runtime.
- Network reach to the appliance's NITRO endpoint.
## Settings
- `ports` / `protocols` â **not supported**; specifying either is a
fatal error at kur startup. Scoping lives in the policies consuming
the dataset.
- `enable_cidr` â this backend can **not** carry ranges (dataset
values are single IPs); a kur with it set logs a warning at startup
and answers range commands per `cidr_silent_drop`.
- `prefix` â only used in the default `dataset` name.
docs/kurs/openwrt.md view on Meta::CPAN
server; `rpcd-mod-file` provides the `file` object every `nft` and
`fw4` call rides on.
```shell
apk add uhttpd-mod-ubus rpcd-mod-file
# on releases still using opkg
opkg update && opkg install uhttpd-mod-ubus rpcd-mod-file
```
- Confirm uhttpd serves the ubus endpoint, which is the path the kur
posts to. Installing `uhttpd-mod-ubus` sets it, so this is a check
rather than a step: `uci get uhttpd.main.ubus_prefix` should answer
`/ubus`.
- Install the ACL as
`/usr/share/rpcd/acl.d/net-firewall-blockerhelper.json`, then
`/etc/init.d/rpcd reload`. Nothing grants `file` `exec` by default,
so without it every `nft` and `fw4` call comes back as ubus
permission denied.
docs/kurs/pfsense.md view on Meta::CPAN
[kur.sshd.options]
host = "fw.example.org"
key = "the-api-key"
```
## pfSense-side setup â required first
- Install the **pfSense-API package** (it is not stock pfSense) and
create an API key for a user whose privileges cover the firewall
alias and apply endpoints.
- Create the host-type alias (*Firewall â Aliases*, type Host(s)),
named per the `alias` option (default `<prefix>_<name>`).
- Create a firewall rule blocking traffic whose source is the alias.
## Requirements
- `LWP::UserAgent` (plus `LWP::Protocol::https`) â loaded only at
runtime.
## Settings
docs/kurs/routeros_api.md view on Meta::CPAN
| `check` | same probe as init |
| `flush` | the lookup+DELETE per banned IP |
| `re_init` | teardown (best effort), init, re-PUT every banned IP |
| `teardown` | the lookup+DELETE per banned IP (ban book kept) |
An entry already removed on the router by hand is treated as already
unbanned, not an error.
## self_heal
`check`/init probe only the IPv4 list endpoint â reachability and
credentials, not list contents, not the IPv6 side, and never whether
any rule consumes the lists. As with [npf](npf.md), the kur will
happily manage a list nothing reads; if bans don't bite, check the
rules first.
## Gotchas
- `insecure = 1` disables certificate verification â encrypted but
unauthenticated, so credentials are exposed to an on-path
attacker. Give the router a real cert if the path matters.
( run in 1.292 second using v1.01-cache-2.11-cpan-16aabcbfbcb )