[transpute]

SSH and other services can be further protected by Single Packet Authentication (SPA), https://github.com/mrash/fwknop

> SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) more difficult.

[jcynix]

Every now and then I use GnuPG encrypted emails (or a web form) to my servers to open the firewall for certain IP addresses. If the server can decrypt such a message it can safely act on it.

The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.

[g_p]

Presumably you sign the emails rather than encrypt them?

Otherwise anyone who knew the public key of the server (which shouldn't be presumed secret) could send an encrypted instruction, and it would be acted upon, and past encrypted instructions could be replayed.

[jcynix]

> Presumably you sign the emails rather than encrypt them?

That's correct, encrypted and signed. Replaying wouldn't be easy because the payload contains a timestamp. The main purpose was to limit the networks which can attempt to connect to ssh and still allow me to have a fallback if I'd happen to be outside of the "usual" network ranges.

[anotherhue]

Doesn’t wireguard solve the same issue? Crypto key packet authentication?

[nwellinghoff]

Same question. Can someone chime in on how deploying this would be different from putting ssh behind wiregaurd? On first glance it looks like if you were ultra paranoid you could put this in front of wiregaurd and not even have to open up a udp port? Would that be an advantage to add a layer to secure wiregaurd against 0day?

[jcynix]

> Doesn’t wireguard solve the same issue?

Presumably, but my solution is quite a bit older and just a poor man's hack from about 20 years ago ...

[hello_computer]

So instead of exposing thoroughly tested OpenSSH to the web, I’m exposing this thing, which can also run shell commands…

[exabrial]

Just had a random thought… what about port knocking, but the combination was TOTP’d? Port knocking is visible to third parties… but if the combination was a TOTP nonce, guessing the correct combination would be fairly difficult.

[hello_computer]

Didn’t have a beef with the general idea or the cryptography (assuming that some form of replay protection was already baked-in) so much as the idea that exposing a novel, less-tested, non-trivial service is a security win. If the implementation (TOTP or not) were dead-simple, I think SPA would be a win, but as soon as we get to dynamic cross-platform firewall-fiddling and custom commands, we are no longer in “dead-simple” territory.

[fn-mote]

There are many points made in the presentation, including that a significant number of ~~targets~~ hosts are not running OpenSSH. See the list and the claims that some classes of them are important.

The swipe at "running shell commands" isn't very credible, but the second attack surface is legitimate.

[hello_computer]

4th bullet from the bottom sounds credible to me:

> Supports the execution of shell commands on behalf of valid SPA packets.

Even if it were only a statically configured command (no idea if it is or isn't), as soon as that door is opened, it leads to a morass.

[ykonstant]

That is interesting! Is this widely used or are there downsides I am not seeing?

[transpute]

> is this widely used

Single Packet Authorization (SPA) is an architectural pattern of modern cloud security ("Software-Defined Perimeter"), with multiple OSS and proprietary implementations, https://cloudsecurityalliance.org/artifacts/software-defined...

  UDP-based SPA provides the following security benefits to the SPA-protected server:

  ● Blackens the server: The server will not respond to any attempted connections from any remote system until they have provided an authentic SPA that is valid for that SDP system. Specifically, the host will not respond to a TCP SYN, thereby avoiding the disclosure of any information to a potential attacker.

  ● Mitigates Denial of Service attacks on TLS: Internet-facing servers running the HTTPS protocol are highly susceptible to Denial-of-Service (DoS) attacks. SPA mitigates these attacks because it allows the server to reject unauthorized connection attempts before incurring the overhead of establishing a TCP or TLS connection and therefore allowing authorized connections during and in spite of DoS attacks.

  ● Attack detection: The first packet to an AH from any other host must be a SPA packet. If an AH receives any other packet, it should be viewed as an attack. Therefore, the SPA enables the SDP to determine an attack based on a single malicious packet.

[egberts1]

Dependencies of reliable Pinholing-by-SMTP are but not limited to:

- reliable SMTP hopping

- a working SMTP account

- pinholer is up and running and robust against DoS/DDoS.

- replayability of PGP (use TOTP in original message as well as wrapper of encrypted SMTP payload)