Cookbook/Firewalling Notes

From Kx Wiki
Jump to: navigation, search

The wiki is moving to a new format and this page is no longer maintained. You can find the new page at code.kx.com/q/cookbook/firewalling.

The wiki will remain in place until the migration is complete. If you prefer the wiki to the new format, please tell the Librarian why.

Run KDB as a separate (non-root) user. If you need it to run on port 80, use authbind or iptables redirect

Do not allow that user to write to any directory or files: If you need file access, arbitrate it via IPC with another KDB process. Pay attention to how that process will return values via .z.pg or .z.ps or similar.

Firewall ALL ports inbound/outbound except ones explicitly used (hint: use iptables owner match). For any backend KDB processes, restrict them to localhost or a protected network (e.g. iptables --pol ipsec)

Set process limits with ulimit no larger than you need them

Restrict input by defining at least:

If you want to allow certain IPC calls, implement only the ones you want: Trying to blacklist functions is tricky because some otherwise useful functions may have a mode that accesses the disk which may cause information leak (e.g. key). It is much easier to use a whitelist approach. The Q for Gods Whitepaper (ยง6) has some suggested guidance here.

As IPC functions either receive a parse tree or a string (that you could parse yourself), make sure you check the type of the input e.g. x:$[10h=type x;parse x;x]

If you use websockets, define:

When handling untrusted input, consider designing your application to wrap public entrypoints with reval.

Pay attention to the fact that each websocket client can open up a lot (200 on Mozilla, 256 for Chrome) of websocket connections, so limit using .z.a

Log connections and consider using fail2ban to block suspicious traffic.

Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox