Something to add: use proxychains to ensure that the requests of all apps go through the proxy. A lot of applications don't have good proxy support, or have nothing at all. If you configure proxychains with the SOCKS proxy provided by this script, then you can do "proxychains my-command-that-doesnt-use-proxy" and it will automatically patch the libc calls to use the proxy properly.
I don't really get what the definition of "network" is here, clearly the box has network access since it is SSH'able. Could you give an example of a situation when this is used?
This would be a common setup. They allow SSH ingress so that the server can be managed or provisioned with something like Ansible. However, they block all other unused ingress ports, as well as any egress that does not contribute to the function of the server. Also common would be a bastion or VPN to get to the network where SSH is accessible. A mistake is to have SSH accessible to the entire corporate network, which is all too common.
Suppose you configured your webserver to run with limited privileges so as if someone hacks it it has limited access. Suppose it still has access to DB and stuff. Well, filtering outgoing connections makes harder to exfiltrate the data OR hop to another hosts. And then you can monitor failed outgoing requests to be able to act/investigate when that happens.
Yeah there are a bunch of tools like this - I'm using Aviatrix at the moment for a bunch of hosts:
* Incoming access is allowed to "stuff" when connected to the OpenVPN host.
* Outgoing access to services is very heavily restricted.
* Outgoing HTTP/HTTPS requires the site to be on an allow-list. By default all outgoing HTTP/HTTPS traffic is denied.
(We might add yum-repositories to the allowlist, or permit access to the various "Windows Updates" services, for example. But all other downloads from remote sites would be denied.)
Couldn't an attacker exfiltrate over ssh or over an incoming HTTP connection instead of an outgoing? Or is this a defense-in-depth thing, not meant as a "hard stop"?
I see this as a defense in depth. It can buy you time until attacker figures out how to exfiltrate and you maybe notice via monitoring that something fishy is happening. It also prevents you participating in a DoS or other attacks.
You could have a bridge (e.g. with an IDS or a packet filter) with a management interface on a separate VLAN, or which requires management via a physical cable of some sort. But the bridge could also intercept traffic to port 22 and redirect it to itself. Personally, I resort to Wireguard instead being the only reachable port.
The name, Airgapt - "airgapped" apt, is also a little "weird". When I work on air gapped devices it normally involved bringing DVDs and physically going to a datacenter.
Naming things is hard. I love the project though, not because I need it, but it proves one of my point: "If you didn't want me to be able to do X, then you shouldn't have allowed SSH access".
Not OP, but some air-gapped servers can be connected to from a private "trusted" network, but are otherwise unable to connect to the internet or elsewhere. Perhaps that's what OP means?
I wish companies would hurry up and move away from "trusted" networks and move onto zero trust.
Bingo. Air-gapped machines, by definition, have no connection to each other. Not so much as an audio cable between them. Everything that goes back and forth is manually transferred, either by eyes-on-one-screen-hands-on-the-other-keyboard, or by sneakernet typically of media which may be inspected at yet a third station en route.
This is a proxy or a bastion host, no more, no less. Calling it an airgap, even in "scare quotes", is clownishly terrible and serves no purpose beyond polluting the language.
Ha. I totally get what you mean, but I wish. I've seen plenty of air-gapped servers, and I'm not even that old. And everytime I've challenged the set up for it to be truly air-gapped, I've been fought for it.
Only way to block this is that “airgapt” thingie is hopefully this sshd_config setting:
# DisableForwarding disables all forwarding features,
# including X11, ssh-agent(1), TCP and StreamLocal.
# This option overrides all other forwarding-related
# options and may simplify restricted configurations.
#
# CLI option: -o
# options.disable_forwarding/do_authenticated()
DisableForwarding no
Bastion SSH? This new-finagle “airgapt” makes GatewayPorts sshd_option setting of OpenSSL kinda useless?
My code review notes says:
# GatewayPorts specifies whether remote hosts are
# allowed to connect to ports forwarded for the
# client. By default, sshd(8) binds remote port
# forwardings to the loopback address. This prevents
# other remote hosts from connecting to forwarded
# ports. GatewayPorts can be used to specify that sshd
# should allow remote port forwardings to bind to
# non-loopback addresses, thus allowing other hosts to
# connect. The argument may be no to force remote port
# forwardings to be available to the local host only,
# yes to force remote port forwardings to bind to the
# wildcard address, or clientspecified to allow the
# client to select the address to which the forwarding
# is bound.
#
# CLI option: -o
# options.fwd_opts.gateway_ports/channel_fwd_bind_addr()/channel_setup_fwd_listener_tcpip()/channel_setup_remote_fwd_listener()
# options.fwd_opts.gateway_ports/channel_fwd_bind_addr()/channel_setup_fwd_listener_tcpip()/channel_setup_local_fwd_listener()
# GatewayPorts defaults to 'no'.
