Update homepage in README: Add binary URL
Generalize debian build file
Sign tagged packages
seqknock - Use TCP sequence numbers to provide an in-band, hard-to-detect method of stream authentication, much like port knocking.
Inspired by SilentKnock[1], seqknock will install firewall rules for configured ports that only allow TCP packets with a given sequence number through the local firewall. Whenever a valid sequence number is observed, it's invalidated for further authentication, and the observed stream is allowed through using connection tracking.
Unlike SilentKnock, the algorithm is time-based much like a standard TOTP, including the default period of 30s. This design decision was taken to simplify the implementation into the firewall, as it only has a limited need to react to incoming packets, unlike the SilentKnock algorithm. It does have a few drawbacks, discussed below.
The upsides compare to port knocking are that no additional ports needs to be opened in addition to the service port, and that it relies fully on the local firewall, which ought to be a hardened piece of software. Finally, the packets are to a large degree indistinguishable from "normal" traffic.
The reference implementation of the MAC-based sequence number generator is available in the seqknock-common directory of the source tree.
For a server implementation, see seqknock-nftables. For a client implementation, see seqknock-proxycmd.
Limited connection rate. With the default setting of 30s periods, users need to
wait for a new sequence number to be rotated in before being able to reconnect.
This can be alleviated by lowering the period, or allowing for overlapping
periods by setting the tolerance to a multiple of the period (combined with the
--fudge-time argument to seqknock-proxycmd. For specific clients, such as
OpenSSH, Control Sockets can be used. Before enabling them, make sure to read
up on any security considerations beforehand. Finally, contention between
multiple users connecting simultaneously can be solved by employing per-user
PSKs.
Only Linux supported for client/server. This implementation relies heavily on
Linux-only features, such as nftables on the server side, and the TCP_REPAIR
option for sockets on the client side. Server support may be extended to other
platforms by adding an abstraction for other firewall technologies, but
client support will be trickier to implement.
Need for root on the client side. Sadly, there is no other option to using
TCP_REPAIR than run with the CAP_NET_ADMIN capability. Options include
having a service handing out pre-"repaired" sockets over Unix Domain Sockets,
which would solve a few issues, but is clunkier.
The role of port knocking (and by relation sequence knocking) in a security context is contended. However, if applied using the correct scope, it can be useful. As an example, it provides a a low-entry (compared to e.g. IPsec) way of hiding services from port scanning utilities and services. Do however note that it should not be relied upon as a method of authentication or for secrecy, but rather to provide a layer of obscurity on top of an already secured protocol, such as SSH or TLS.
Replayed sequences could reveal the method to an observer. Related to the first point above, if reconnecting twice in the same period using the same key, the client send two packets containing the same TCP sequence but with separate source ports. This will ultimately lead an observer into suspecting that the sequence number is the reason whether or not connections succeed. This is mostly true for the current stateless proxycmd implementation, as it could be alleviated by replacing it with something stateful, e.g. a daemon, that would "retire" each sequence number after use.
Jonas Eriksson
Source: https://sr.ht/~upto/seqknock/ Binaries: https://artifacts.upto.se/seqknock/
[1] https://www-users.cse.umn.edu/~hoppernj/silentknock_esorics.pdf