Oninit® Snooper — Install

Requirements

Component	Notes
Linux x86-64	Any kernel 3.2 or later. Other architectures on request.
POSIX threads	Linked statically into the binary — no system libpthread required at runtime.
OpenSSL 1.1.1 or later	v4.0 and later only, and only when a TLS option is used. The TLS-capable binary links the system libssl / libcrypto dynamically (the hybrid-link model), so the host needs OpenSSL 1.1.1+ — present by default on RHEL / Rocky 8+, Ubuntu 18+, Debian 10+, and Alpine 3.8+. The plaintext passthrough still runs with no TLS configuration. The earlier v3.0 binary is fully static and has no OpenSSL dependency at all.
IBM Informix CSDK	Not required. The snoop talks SQLI on the wire directly via the embedded Oninit® SQLI library; no libifsql.so, no setcsdk, no INFORMIXDIR at the deployment host.
IBM Informix server	Reachable from the snoop host on its TCP port. Any IDS version that speaks SQLI 9.0342 or later (most modern IDS releases).
tcpdump / wireshark	Not required. The snoop reads its own forwarded byte stream — no packet capture, no CAP_NET_RAW, no privileged interfaces.

Install

oni_snoop is a single stripped ELF binary. There is no package and no config file — drop it on the host, mark it executable, run it.

sudo install -m 0755 oni_snoop /usr/local/bin/
oni_snoop --help

The v3.0 binary is fully static and links nothing at runtime:

$ ldd /usr/local/bin/oni_snoop      # v3.0
        not a dynamic executable

From v4.0 the binary uses the hybrid-link model so that TLS can call the system OpenSSL: libgcc helpers are static, while libssl, libcrypto, libz, and libc are resolved from the host (all present by default on any modern distribution). There is still no Informix CSDK, no libifsql.so, and no config file:

$ ldd /usr/local/bin/oni_snoop      # v4.0
        linux-vdso.so.1
        libssl.so.3 => /lib64/libssl.so.3
        libcrypto.so.3 => /lib64/libcrypto.so.3
        libz.so.1 => /lib64/libz.so.1
        libc.so.6 => /lib64/libc.so.6
        /lib64/ld-linux-x86-64.so.2

Build the shipping binary on the oldest glibc you need to support (Rocky 8 / glibc 2.28 covers RHEL / Rocky 8+, Ubuntu 18+, Debian 10+, Alpine 3.8+); a binary built against a newer glibc will not start on an older host.

Where to run it

The snoop runs on whatever host the operator wants to observe traffic on — typically the same host as the IDS server, or a dedicated proxy host that sits between the application tier and the database tier. There are three common deployments:

Deployment	Use case
Same host as IDS	Loopback observation. Move IDS to an alternate port (or bind it to 127.0.0.1 on a different interface alias) and bind oni_snoop --listen to the original IDS port. Apps reach the well-known port unchanged. Lowest setup cost.
Dedicated proxy host	Separate machine in front of IDS. Apps point at the snoop host; the snoop forwards to the real IDS. Useful when IDS reconfiguration is undesirable or when the snoop output benefits from isolation.
Per-environment debug	Spin the snoop up only when an issue needs investigating. Run for a few minutes, capture the log, kill the snoop. Apps continue talking to IDS directly the rest of the time via the original sqlhosts entry.

Insert the snoop at the client's sqlhosts

The snoop has to be inserted into the connection path, and that is done at the client's sqlhosts. The IDS server is left untouched — it keeps its port, its bind address, and its onconfig. On the client, the application, its $INFORMIXSERVER, its connect strings, and its SQL all stay exactly as they are; the single change is the one sqlhosts entry the client uses to reach the server — repoint its host / port at the snoop's --listen address. The snoop then forwards to the real IDS via --upstream.

The snoop and IDS cannot share a port, so the snoop listens on a different one and the client's sqlhosts names the snoop instead of IDS. For example, with IDS on 192.168.203.4:9088, run the snoop on 9089 and change the client's sqlhosts port from 9088 to 9089 — IDS stays on 9088, untouched:

# client $INFORMIXSQLHOSTS — repoint the one entry
myids   onsoctcp   192.168.203.4   9089      # was 9088; 9089 is the snoop

# on the IDS host (IDS still on 9088):
oni_snoop --listen 0.0.0.0:9089 --upstream 127.0.0.1:9088

The snoop can equally run on a separate host — then the sqlhosts entry names that host instead, and --upstream names the real IDS. Either way the change lives in the client's sqlhosts, and the IDS instance keeps running.

The insertion can instead be made at the server end — relocate IDS to a different port so the snoop takes the original port and no client sqlhosts entry changes. That is a server-side configuration change, so it requires an IDS instance restart to take effect — especially when SSL is in use, since the secure listener is established at instance start. The client-side sqlhosts repoint above avoids the restart and leaves the running instance alone, which is why it is usually the lighter touch for an ad-hoc snoop.

TLS certificates (v4.0+)

TLS is configured entirely on the command line — still no config file the snoop owns. To terminate TLS towards the client the snoop needs a server certificate and key in PEM form; to verify the upstream IDS it needs the CA chain that signed the server certificate. Operators who already run TLS to IDS can point the snoop straight at their existing Informix conssl.cfg:

oni_snoop --listen 0.0.0.0:9089 --upstream 198.51.100.42:9088 \
    --tls-listen --tls-upstream --conssl-cfg $INFORMIXDIR/etc/conssl.cfg

The snoop reads SSL_KEYSTORE_FILE and SSL_KEYSTORE_STH from that file — the GSKit keystore and its password stash. The keystore's certificate and key become the snoop's listen-side identity; its CA certificates become the upstream trust store. The keystore password is recovered automatically from the .sth stash file (the classic GSKit XOR obfuscation).

Export the keystore to PKCS #12 first. OpenSSL cannot read a native GSKit CMS .kdb, so export it once and point SSL_KEYSTORE_FILE at the resulting .p12:

gsk8capicmd_64 -cert -export -db clikeydb.kdb -stashed \
    -label <label> -target clikeydb.p12 -target_type pkcs12

Stash files written by GSKit 8.0.50.88 and later use a stronger (v2) obfuscation the snoop cannot decode; re-stash with an older gsk8capicmd, or supply the certificate and key directly with --tls-listen-cert / --tls-listen-key. See Operations for the full TLS flag reference and the --tls-min-version floor for legacy servers.