New bastion server for ssh/gateway subdomains

Maybe time for another Open Based Secure Distribution instance? https://youtu.be/watch?v=-tOJpFMKRu0

An opportunity to rebuild the fail2ban config, at least for that host, and on a new version:

is the idea that this would be within UCC infrastructure / the UWA network, or outside (eg. AWS EC2)?

Within, initially - an entry point FROM outside TO inside, to be a replacement ssh.ucc.asn.au

We haven't deliberately blocked all the other servers by and large, but a dedicated-to-purpose bastion would mean:

we could channel a lot of remote access through that point and look more suspiciously at other direct traffic
- even block a lot of it by default?
  - and wait for a successful auth and a fail2ban "allow" to enable access from a new remote network?

assigned to @zixty

assigned to @dylanh333 and unassigned @zixty

assigned to @zixty and unassigned @dylanh333

@zixty , @dylanh333 , @i2n2z expressed interest in building a service that uses MFA

@bird - we could use a hand!
Stretch goal:
- A successful MFA auth could also be used to self-service temporarily allowlist/un-fail2ban other services/servers? as in #51 (comment 396)

Running a genuine upstream OpenBSD server would have saved us from:

...of course, we may have been behind far enough to have been exposed to more likely bugs instead?

@mtearle : https://bsd-cloud-image.org/ with cloud init magic might be a good place to start....

The 2FA/MFA part is being tracked in #73 , though it may have different implementations on *BSD and Linux distros.

This bug is to track the building of a config-managed? bastion host, and yes, we would like enhanced logging and MFA.

Child items