think
This commit is contained in:
parent
be03e9e8c8
commit
3673804b93
161
THOUGHTS.txt
161
THOUGHTS.txt
@ -7196,3 +7196,164 @@ we may still need to template the rest of the firewall if we want to have
|
||||
other variables (rate limits) in it, because the rules for that need to be
|
||||
inserted ahead of the rules for accepting icmp, and there's no way to
|
||||
do that without
|
||||
|
||||
Sun Mar 9 21:46:30 GMT 2025
|
||||
|
||||
OK, we have updating firewall zones that are good neough to pass the test
|
||||
(and may even work ...). We need
|
||||
|
||||
* to write a rule with a rate limit for incoming icmp6 for each interface,
|
||||
capping it to 5% of the interface bandwidth
|
||||
|
||||
* some place to say what the bandwidth is, which I am thinking we could do with
|
||||
a passthru attribute of some kind on services
|
||||
|
||||
{
|
||||
run = "mdcnvdfngkj";
|
||||
name = "dtret";
|
||||
properties.bandwidthKbps = 80000;
|
||||
}
|
||||
|
||||
and insert logic in the up/run commands to copy the properties to
|
||||
outputs. Or we could use `data` or `env` directories, which means
|
||||
that the properties would be there even while the service is down, if
|
||||
that's a concern, but would need a different way to look them up. And
|
||||
also, would we allow them to change? What if there's some kind of interface
|
||||
where we _can_ interrogate the bandwidth at runtime?
|
||||
|
||||
Mon Mar 10 21:00:17 GMT 2025
|
||||
|
||||
The idea that occured to me at lunchtime is "what if we made the
|
||||
(svc:output ) method fall back to properties if no output was present".
|
||||
To do this, we'd have to
|
||||
|
||||
(1) arrange for /nix/store/eeee-service/.properties to exist
|
||||
|
||||
- add properties attribute to service functions
|
||||
- write them to .properties in liminix-tools/services/builder.sh
|
||||
- make sure they get passed through whne provided to all the service
|
||||
builder functions
|
||||
|
||||
[done] (2) pass the store directory to svc.open instead of ..../.outputs
|
||||
|
||||
(3) make service:output look in both places
|
||||
|
||||
(4) write the damn firewall rule
|
||||
|
||||
Mon Mar 17 21:13:36 GMT 2025
|
||||
|
||||
Argh why is it never simple?
|
||||
|
||||
We need to write a rate-limiting firewall rule for each interface to
|
||||
restrict icmp on that interface. This is not easy to reconcile with
|
||||
putting them in default-rules because how do we generate multiple
|
||||
array elements by config file templating?
|
||||
|
||||
There are two things in my mind now:
|
||||
|
||||
1) could we have some better way of manipulating the firewall rules
|
||||
such that the rules from different modules are composable
|
||||
|
||||
this is complicated somewhat by ordering: if every rule in a chain is
|
||||
"drop" or "accept" then it's easy to add another, but if the same
|
||||
chain does first one then the other, doing the other and then the one
|
||||
will not work
|
||||
|
||||
today we do e.g.
|
||||
|
||||
input-ip6
|
||||
-> reject-bogons
|
||||
-> accept non-bogus-icmp
|
||||
-> process per-zone allowlist
|
||||
-> allow established,related on wan
|
||||
-> allow all on lan (so why did we need an allowlist?)
|
||||
|
||||
could we express this in a less sequential form? the
|
||||
specification of what's allowed
|
||||
|
||||
|
||||
input-ip6 for wan: is input-ip6 with the wan allowlist
|
||||
input-ip6 for lan: is input-ip6 with the lan allowlist
|
||||
|
||||
|
||||
input-ip6 for ppp0: is input-ip6 with the wan allowlist with a rate
|
||||
limit for icmp
|
||||
|
||||
ssh module wishes to modify the allowlist for lan/wan/both so that
|
||||
it includes port 22
|
||||
|
||||
am wondering if we could do default deny and _all_ the rules
|
||||
(except for bogons) are allows
|
||||
|
||||
maybe we have the concept of "subtraction": a rule can be an allow
|
||||
preceded by some number of drops which (at least by convention; this is
|
||||
probably hard to enforce) are "carve outs" of the packets that are
|
||||
being allowed.
|
||||
|
||||
... it's hard to express the forward-ipv6 in these terms, though.
|
||||
we end up with "some drops and then multiple accepts"
|
||||
|
||||
we have
|
||||
(and (not (or drop1 drop2 ...)) (or accept1 accept2 ...))
|
||||
|
||||
and to add ssh we need to break into the second clause instead of
|
||||
composing at the top level
|
||||
|
||||
(and (not (or drop1 drop2 ...))
|
||||
(or accept1 accept2 accept-ssh...))
|
||||
|
||||
|
||||
then the icmp bogons composite rule is "drop weird icmp and then
|
||||
allow what's left"
|
||||
|
||||
(side note: maybe we could use a map to do interface name -> bandwidth
|
||||
for rate limiting)
|
||||
|
||||
|
||||
|
||||
|
||||
a composite rule might be a bunch of denies and then an allow
|
||||
for anything the
|
||||
|
||||
2) some kinda syntax for referencing outputs (or properties) that's not
|
||||
just string interpolation
|
||||
|
||||
|
||||
----
|
||||
|
||||
I think we could address the immediate problem by writing a rule for
|
||||
rate-limiting that looks up the rate in a map, and some maps (with
|
||||
extraText) that get the rates from service properties? And that would
|
||||
suffice for addressing the RoS audit, at least
|
||||
|
||||
Tue Mar 18 18:48:22 GMT 2025
|
||||
|
||||
Unless the interface exists, we do not (at least, may not) know its
|
||||
name because that's an output. So the fact that it has a permanent
|
||||
property is not per se terribly useful
|
||||
|
||||
limit rate 50000 bytes / minute accept
|
||||
|
||||
|
||||
nft add rule ip nat postrouting snat to ip saddr map { 192.168.1.0/24 : 10.0.0.1, 192.168.2.0/24 : 10.0.0.2 }
|
||||
|
||||
nft add rule table-ip input-ip4 ip daddr 2.2.2.3/32 limit rate iifname map { "eth0": 10, "ppp0": 20 } kbytes/second accept
|
||||
|
||||
nft add map 'table-ip intf-limits { typeof 5000000 ; elements = { lan: 50000000, ppp0: 3500000 } ; }'
|
||||
|
||||
OK, we can't do rate lookup in a map because the nftables grammar only
|
||||
supports a numeric literal for limit_rate_bytes. so we're back to writing
|
||||
a collection of rules, one for each interface with an ifname output,
|
||||
that sets the limit for that interface
|
||||
|
||||
* we could do this all in one element of a rules list, with newlines
|
||||
between each actual rule
|
||||
|
||||
* we could add extraText to the ruleset syntax - but does it go at the
|
||||
start of the rules or the end or somewhere in the middle? this is
|
||||
almost worse
|
||||
|
||||
* we could pick up where we left off on march 17 and redesign the
|
||||
firewall module
|
||||
|
||||
gonna be option 1 isn't it?
|
||||
|
Loading…
Reference in New Issue
Block a user