Remote tunnels

[kpcyrd]

Considering all the network discovery tools we have it might make sense to add additional features to support usecases with multiple sensors that log to a central sn0int instance.

A naive solution is fairly trivial:

ncat -vlkp 1234 | sn0int run --stdin -v passive-arp -o network=example

There are some obvious disadvantages though:

• An attacker can read the data
• An attacker can replay or otherwise manipulate the data we receive

Setting up openssl is annoying, instead we should use either zmq or build something similar:

sn0int tunnel keygen                        # generate a keypair in
                                            # ~/.local/share/sn0int
sn0int tunnel connect <addr> <pubkeys ...>  # connect to addr and expect one
                                            # of these pubkeys, usually
                                            # only one
sn0int tunnel listen <addr> <pubkeys ...>   # bind to addr and wait for
                                            # connections, only accept
                                            # clients with the right pubkey

This would allow us to rewrite our previous approach to:

sn0int tunnel listen 0.0.0.0:1234 "$KEY" | \
    sn0int run --stdin -v passive-arp -o network=example

Note that listen could be replaced with connect, the connection direction doesn't indicate in which direction the data flows. In fact, the connection would be bi-directional but only one side would actually expect data.

On the sending side we would want to be able to define a buffer (possibly with disk persistence). This means that sn0int tunnel is still reading data from stdin into a ring buffer of configurable size even if the network is down, then replay everything after the network is up again. The script might want to know if messages have been skipped/dropped.

To avoid the need for pipes we could eventually add this as an option for sn0int run so it's able to connect/bind on its own. Especially in listen mode we could allow one script child per connection to avoid interference if both clients write at the same time.