block an IP at the kernel level?

[unusualevent]

Is it possible to block an IP at the kernel level (vs doing this at the infrastructure level, I know I know...)

vs having to block it / check it in the application code?

[francescolavra]

Yes, it is possible: Nanos has a klib that implements a network firewall: see https://docs.ops.city/ops/klibs (at the "Firewall" section) for documentation and usage examples.

[unusualevent]

@francescolavra cool! https://docs.ops.city/ops/klibs#firewall but that's a static one. I don't see an API call that would allow me to edit it?

[eyberg]

can you describe a bit more what your usecase is?

[unusualevent]

Say I have an adaptive rule in app that decides something's being abusive. I'd like to block it earlier on in the network call stack, rather than at the golang level.

[eyberg]

if you're trying to block something before it even touches your instance the easiest/most straight-forward thing to do would be to apply a new fw rule via your cloud

[unusualevent]

That only slightly works depending on the cloud provider - I was curious about a host based middle ground similar to iptables

For example:

• vultr: only accept rules allowed (all other traffic blocked)
• google cloud: supported
• AWS: supported in NACLs, not in SGs
• digitalocean: only accept rules allowed (all other traffic blocked)
• upcloud: supported
• linode: supported
• openstack: depends on version
• IBM: reeeally depends
• azure: supported

"supported" is relative as there's a maximum size limit to many of their rulesets.

[eyberg]

i understand what you want but need some more context around your specific use-case

specifically how are you identifying abusive traffic? and how would you flag/block it? if it's something like a fail2ban filter that is automated that logic needs to live somewhere and that could be quite extensive/different depending on use-case (eg: spotting credential stuffing would be very different than say a syn flood); if it's not automated and you are just spotting stuff manually setting a {"ip": {"src": "10.0.2.2"}, "action": "drop"} would be equivalent to a iptables -A INPUT -s 10.0.2.2 -j DROP , both are manual and both would take roughly the same amount of time except w/the latter it's now codified as iac

[unusualevent]

Isn't that on the read only system partition that the user code can't modify?

[eyberg]

you would set it in your config and re-deploy which should only take few tens of seconds; really this comes back to whether this is a manual process or automatic

[unusualevent]

That fits more for ephemeral nodes, but if you've got quite a lot happening on the node it would take time to shed load, finish jobs, and transfer storage.