rustybird / corridor Goto Github PK

View Code? Open in Web Editor NEW

68.0 68.0 6.0 189 KB

Tor traffic whitelisting gateway

License: ISC License

Makefile 18.80% Shell 81.20%

firewall tor

corridor's People

Contributors

Stargazers

Watchers

Forkers

adrelanos hobbit19 merge setiakkr

corridor's Issues

systemd broken dependencies, ordering cycle, Unknown lvalue 'Require' in section 'Unit'

broken dependencies

Unknown lvalue 'Require' in section 'Unit'

Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-misc-post.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'
Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-network.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'
Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-netwatcher.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'

dependency cycle

(not a Debian issue)

Jul 29 16:22:22 localhost systemd[1]: Found ordering cycle on basic.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on sysinit.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on networking.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on network-pre.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on corridor-init-forwarding.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on qubes-iptables.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on basic.target/start
Jul 29 16:22:22 localhost systemd[1]: Breaking ordering cycle by deleting job networking.service/start
Jul 29 16:22:22 localhost systemd[1]: Job networking.service/start deleted to break ordering cycle starting with basic.target/start

Qubes support

Is Qubes (Qubes ProxyVMs) officially supported? Tested by you?

If you/no, let's please add this to corridor's readme.

There are some things in Qubes that may interfere with firewall rules:

qubes-iptables
qubes-firewall
/usr/lib/qubes/qubes-setup-dnat-to-ns (reference)

Jul 31 21:20:27 sys-corridor corridor-data[731]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
Jul 31 21:20:27 sys-corridor corridor-data[731]: 2016/07/31 21:20:27 socat[815] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory

I don't know how severe that issue is.

Perhaps in corridor-data.service should use After=tor.service?

I am not sure [email protected] is also required.

Generally, could you look into sudo journalctl -b please to see if the boot order looks right?

corridor systemd services hang during corridor upgrades

These are issues that have happened. These could happen if Tor's control protocol is not reachable / not properly set up or if Tor is not running (yet).

25 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file

25 debian corridor-data[1917]: :25 socat[1923] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory

52 debian corridor-data[1917]: 515 Authentication failed: Wrong length on authentication cookie.

53 debian corridor-data[1917]: :53 socat[3031] E write(1, 0x2551aa0, 7963): Broken pipe

As a follow up issue, it looks like corridor systemd services hang during corridor upgrades / therefore break the package management.

debian packaging

Since @rustybird does not wish to merge distribution specific stuff of distributions he does not use (#2 (comment)), I am only opening this as an issue, not as a pull request.

Work in progress:

EDIT:

There is one issue that Debian will complain about.

W: corridor: executable-not-elf-or-script usr/sbin/corridor-load-config

That script if not executable does not belong there.

Can we move it to a more appropriate location?
Alternatively, can we make it executable and useful instead? When manually executed it could work as a config file sanity tester, i.e. just sourcing the config files in verbose -x mode and then exit with an "success" if that did not result in an error.

Would you like to ship a man folder with manuals in ruby-ronn format in rustybird/corridor master?

I guess I could contribute the original, basic man pages.

(The Debian packaging that I am using would convert them during package build to proper man pages compatible with gnu man. Much better than learning and writing the roff format.)

That would help Debian lintian (package checker) no longer complain about missing man pages. The man pages shipped at upstream rustybird/corridor seems more useful than in downstream adrelanos/corridor.

Qubes: also process /rw/corridor.d configuration folder

https://github.com/rustybird/corridor/blob/master/sbin/corridor-load-config

Please also source configuration files in /rw/corridor.d folder. It should have a higher priority than /etc/corridor.d. I.e. source /rw/corridor.d frist followed by /rw/corridor.d.

clarify alpha / beta / stable

Interesting to know for Debian packaging (#10)...

Is corridor considered alpha, beta or stable?

Perhaps this could be clarified in the readme.

corridor-init-forwarding not idempotent

corridor-init-forwarding is currently not idempotent. Re-running corridor-init-forwarding will fail. This is problematic, because then the systemd service cannot be successfully restarted.

user@corridor:~$ sudo service corridor-init-forwarding status
● corridor-init-forwarding.service - corridor's forwarding
   Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled)
   Active: failed (Result: exit-code) since Tue 2016-07-05 19:49:35 CEST; 8min ago
  Process: 11067 ExecStart=/usr/sbin/corridor-init-forwarding (code=exited, status=1/FAILURE)
 Main PID: 11067 (code=exited, status=1/FAILURE)

Jul 05 19:49:35 corridor corridor-init-forwarding[11067]: iptables: Chain already exists.
Jul 05 19:49:35 corridor systemd[1]: corridor-init-forwarding.service: main process exited, code=exited, status=1/FAILURE
Jul 05 19:49:35 corridor systemd[1]: Failed to start corridor's forwarding.
Jul 05 19:49:35 corridor systemd[1]: Unit corridor-init-forwarding.service entered failed state.

user@corridor:~$ sudo sh -x -e /usr/sbin/corridor-init-forwarding
+ corridor-load-ipset-relays --init
+ corridor-load-ipset-logged --init
+ iptables -w -N CORRIDOR
iptables: Chain already exists

Could you make corridor-init-forwarding idempotent please? (That would help with Debian packaging. #10)

corridor-init-forwarding.service use Before=shutdown.target Conflicts=shutdown.target

When using DefaultDependencies=No, also

Before=shutdown.target
Conflicts=shutdown.target

should be used. (I learned that from you, @rustybird, I think.)

https://github.com/rustybird/corridor/blob/master/systemd/corridor-init-forwarding.service.in

Qubes mkdir -p "$RELAYS_STATE" missing

https://github.com/rustybird/corridor/blob/master/qubes/corridor.d/31-state-qubes.conf
Makefile_orig: install -d $(DESTDIR)$(SBIN) $(DESTDIR)$(MAN)/man8 $(DESTDIR)/etc/corridor.d $(DESTDIR)/var/lib/corridor
https://github.com/rustybird/corridor/blob/master/sbin/corridor-data

Unless I am missing something, for Qubes there is some. mkdir -p "$RELAYS_STATE" required. For /var/lib/corridor non-Qubes case you handle it in the makefile but for the Qubes case this is currently not handled. I guess folder existence should be checked/created in corridor-data.

systemd WantedBy=multi-user.target correct - resulting in applications using networking before corridor firewall rules are load?

systemd unit files using:

WantedBy=multi-user.target

Is this correct? Might this result in firewall rules not being load early enough before any other applications that might use networking?

Better...

WantedBy=sysinit.target

For comparison of other early boot systemd unit files. Perhaps we could compare with something else firewall related.

grep -r WantedBy /lib/systemd/system | grep sysinit

please avoid symlinks / breaks Debian packaging

5c0cf80 broke Debian packaging. (#10)

 dpkg-source -b corridor
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building corridor using existing ./corridor_20160710131757.orig.tar.gz
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-logged.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-forwarding.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-snat.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-data.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b corridor gave error exit status 2
debuild: fatal error at line 1376:
dpkg-buildpackage -r/home/user/Whonix/packages/corridor/debian/gain-root-command -D -us -uc -sa failed

Symlinks are somewhat non-ideal.

Can this be better expressed using text configuration files without any symlinks?

missing make all target

make all is a default target. [1]

For standard compliance, can we add a make all target please?

(Background: This would make some thing in genmkfile easier. [Adding compilation feature.] However, if this is not a standard thing, then I'll find another solution.)

[1] https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html

avoid DirPort 127.0.0.1:9030

From the corridor readme... Quote:

You may want to add the line

DirPort 127.0.0.1:9030

to /etc/tor/torrc to always keep the relay list up to date, even when there's no local activity and tor would otherwise suspend itself.

This is quite bad since this:

complicates instructions
setup cannot be as automatic as installing a package, still requires manual /etc/tor/torrc edits. (And editing such files by using scripts is problematic for many reasons and usually forbidden by distribution policies.)
This issue has probably not been reported upstream?
Could have unwanted effects, see below.

From https://www.torproject.org/docs/tor-manual.html.en:

DirPort [address:]PORT|auto [flags]

If this option is nonzero, advertise the directory service on this port. Set it to "auto" to have Tor pick a port for you. This option can occur more than once, but only one advertised DirPort is supported: all but one DirPort must have the NoAdvertise flag set. (Default: 0)

The same flags are supported here as are supported by ORPort.

advertise the directory sounds scary. Even if only listening on localhost as corridor instructions recommend, I would not be surprised if it still is advertised to the directories, due to some bug. It looks like a very uncommon way to use Tor so I would not be surprised if this is entirely untested.

Perhaps as short term fix, the NoAdvertise flag should be set.

As long term fix, could you report a bug against Tor please? I would do it myself, but I do not really understand the issue you are trying to work around here. Or raise this issue on the tor-talk mailing list? Perhaps there is a better workaround. (Yes, asking on tor-talk can work, I recently got my questions quickly and exhaustingly answered by Roger.)

add IPv6 support / port to nftables or Berkeley Packet Filter (BPF)

IPv6 is coming.

https://trac.torproject.org/projects/tor/ticket/21269

Having corridor support IPv6 would be of tremendous help leak testing Whonix if/when it gets added IPv6 supports / ported to nftables.

https://phabricator.whonix.org/T509

corridor config in /usr/local [/rw] ignored

corridor-load-config is used by:

corridor-data
corridor-init-logged
corridor-init-snat

These should start after qubes-mount-dirs.service because corridor-load-configwill source /usr/local/etc/corridor.d.

sudo journalctl -b reveals, that is currently not the case. Startup of corridor-ini-forwarding and mount-dirs.sh happens simultaneously.

So, all of:

corridor-data.service
corridor-init-logged.service
corridor-init-snat.service

probably should use After=qubes-sysinit.service or more generically, After=sysinit.target. Or perhaps After=local-fs.target.

Related:
QubesOS/qubes-issues#2194

Option to use corridor as host firewall rather than gateway?

There are good reasons for anonymity not to emit any non-Tor traffic while browsing with Tor. Example, correlation of torified and non-torified TLS HELLO gmt_unix_time:
https://trac.torproject.org/projects/tor/ticket/8751

One could use Tails or Whonix in a VM. And corridor firewall could run on the host to forbid any non-Tor traffic.

Could you add such a feature please?

Or would you accept a patch implementing this feature? Would require some if/else magic.

corridor causes Tor assertion failure on Qubes-Fedora-26-minimal standalone proxyVM

installed per README#Qubes (+ iptables package) in a fedora-26-minimal standalone proxyVM.

tor.service is error-free when systemctl disable corridor.target

journalctl:

Dec 06 02:27:07 corridor Tor[851]: Bootstrapped 100%: Done
Dec 06 02:27:08 corridor corridor-data[388]: corridor_relays updated.
Dec 06 02:28:10 corridor Tor[851]: tor_assertion_failed_(): Bug: src/or/cpuworker.c:499: cpuworker_queue_work: Assertion threadpool failed; aborting. (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug: Assertion threadpool failed in cpuworker_queue_work at src/or/cpuworker.c:499. Stack trace: (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(log_backtrace+0x43) [0x559082b81c13] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(tor_assertion_failed_+0x91) [0x559082b9aa51] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(cpuworker_queue_work+0x6f) [0x559082b3d8ef] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(consdiffmgr_add_consensus+0x2fb) [0x559082b2f96b] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(networkstatus_set_current_consensus+0x7ec) [0x559082a70a8c] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(connection_dir_reached_eof+0x1354) [0x559082b465b4] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(+0x1083d9) [0x559082b1f3d9] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(+0x4d7ee) [0x559082a647ee] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /lib64/libevent-2.0.so.5(event_base_loop+0x7a9) [0x777311fb53f9] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(do_main_loop+0x29d) [0x559082a6578d] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(tor_main+0xe25) [0x559082a685a5] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(main+0x19) [0x559082a61009] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor kernel: audit: type=1701 audit(1512527290.060:105): auid=4294967295 uid=993 gid=989 ses=4294967295 pid=851 comm="tor" exe="/usr/bin/tor" sig=6
Dec 06 02:28:10 corridor audit[851]: ANOM_ABEND auid=4294967295 uid=993 gid=989 ses=4294967295 pid=851 comm="tor" exe="/usr/bin/tor" sig=6
Dec 06 02:28:10 corridor Tor[851]: Bug:     /lib64/libc.so.6(__libc_start_main+0xea) [0x777310e9488a] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor Tor[851]: Bug:     /usr/bin/tor(_start+0x2a) [0x559082a6105a] (on Tor 0.3.1.8 ad5027f7dc790624)
Dec 06 02:28:10 corridor kernel: audit: type=1131 audit(1512527290.064:106): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Dec 06 02:28:10 corridor audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Dec 06 02:28:10 corridor systemd[1]: tor.service: Main process exited, code=killed, status=6/ABRT
Dec 06 02:28:10 corridor systemd[1]: tor.service: Unit entered failed state.
Dec 06 02:28:10 corridor systemd[1]: tor.service: Failed with result 'signal'.
Dec 06 02:28:11 corridor corridor-data[388]: 2017/12/06 02:28:11 socat[885] E connect(5, AF=1 "/var/run/tor/control", 22): Connection refused
Dec 06 02:28:11 corridor kernel: audit: type=1130 audit(1512527291.094:107): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 06 02:28:11 corridor kernel: audit: type=1131 audit(1512527291.094:108): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

repeats every 10 seconds.

create a signed git tag, create a release

Whonix corridor instructions WIP:
https://www.whonix.org/wiki/Corridor

It would help if there was a release, a signed git tag that users could be pointed at.

license clarification

I suggest public domain
CC0 1.0 Universal
https://creativecommons.org/publicdomain/zero/1.0/

If you wish, I'll send a pull request.

clarify compatibility with ufw

We are wondering, is corridor (as a host firewall #3) compatible with ufw? Has this been tested? Is that discouraged?

Please clarify. Then documentation will perhaps recommend to uninstall ufw first. (And I'd add a Conflicts: for Debian packaging. (#10))

default to /var/run/tor/control and /var/run/tor/control.authcookie

How does corridor-data open a Tor control connection?

If $TOR_CONTROL_SOCKET is nonempty (e.g. /var/run/tor/control), use it. Otherwise, connect to $TOR_CONTROL_HOST (defaults to localhost) on port $TOR_CONTROL_PORT (defaults to 9051).

If $TOR_CONTROL_COOKIE_AUTH_FILE is nonempty (e.g. /var/run/tor/control.authcookie), use it. Otherwise, pass $TOR_CONTROL_PASSWD (defaults to an empty password).

Defaulting to localhost:9051 with an empty Tor control password is not great. I doubt any distribution / user has such settings set.

I guess defaulting to /var/run/tor/control and /var/run/tor/control.authcookie has a higher chance of working for a bigger amount of people out of the box. By now, all distributions should have updated to providing Tor control cookies authentication by default?

Implementing this ticket would ease Debian packaging. (#10) Otherwise the Debian packaging would have to add a patch to add a "debian specific" configuration file /etc/corridor.conf/50-debian.conf.

TOR_CONTROL_SOCKET=/var/run/tor/control
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie

Qubes: systemd corridor-data.service should wait for /rw

corridor-data.service should probably run after qubes-mount-dirs.service or even after qubes-sysinit.service? Otherwise /rw may not be available at that time.

testing on Debian host

Hi. I tested corridor on a Debian host running Whonix KVM guests.

Results:

It blocks any new Whonix connections after the corridor service successfully starts while Tor connections on the host still work.
LAN connections are permitted. Is this intentional? Its safer for this to be restricted unless a user wants otherwise. Imagine subscribing to a wireless carrier or ISP which assigns local addresses. Leaking anything to this non-trusted network is dangerous.

Two solutions come to mind: adding a LAN permission option to corridor for manual use. Out of scope of this ticket but an interesting topic that should be discussed: add a barebones captive portal responder on the host under its own user account that is exempted by corridor. This keeps leaks absolutely minimal and reduces attack surface when having to deal with captive portals.

/cc @adrelanos

please merge qubes subfolder

Could you please move /qubes/systemd/corridor-data.service.d/qubes.conf directly into /qubes/systemd/corridor-data.service.d/qubes.conf? [Analogous for other similar files in /qubes/systemd/ folder.)

Alternatively /systemd/corridor-data.service.d/qubes.conf would also be very nice.

Would simplify the whole corridor package. (Less files, folders.)
Would simplify the systemd service.
Does no damage at any non-Qubes users having these settings.
- Statements like After=qubes-iptables.service are simply ignored for non-Qubes users.
Would simplify the makefile and packaging (#10).

Also /qubes/corridor.d could be avoided and merged into the corridor.d if using the "if Qubes is detected" way.

# Setting this by default in Qubes only.
if command -v qubesdb-read >/dev/null 2>&1 ; then
   # Qubes specific config snippett
fi

/etc/torrc.d/ vs bridges grep?

BRIDGES=`grep -Ei '^[[:space:]]*Bridge[[:space:]]' /usr/local/etc/torrc.d/*`

Doesn't work anymore.

Know any line that works with /etc/torrc.d/?

does not fail systemd unit file if folder inaccessible

user@debian:~$ sudo journalctl | grep -i corridor
Dec 11 08:33:03 debian sudo[3338]:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/apt install corridor
Dec 11 08:35:15 debian systemd[1]: Started corridor's relay list.
Dec 11 08:35:15 debian systemd[1]: Starting corridor's forwarding...
Dec 11 08:35:15 debian systemd[1]: Starting corridor's logging...
Dec 11 08:35:15 debian systemd[1]: Starting corridor's source NAT...
Dec 11 08:35:15 debian corridor-data[3861]: Processing router list...
Dec 11 08:35:16 debian corridor-data[3861]: tee: /rw/corridor_relays.tmp: No such file or directory
Dec 11 08:35:16 debian systemd[1]: Started corridor's source NAT.
Dec 11 08:35:16 debian corridor-data[3861]: corridor_relays updated.
Dec 11 08:35:16 debian corridor-data[3861]: mv: cannot stat '/rw/corridor_relays.tmp': No such file or directory
Dec 11 08:35:17 debian corridor-init-forwarding[3865]: net.ipv4.ip_forward = 1
Dec 11 08:35:17 debian corridor-init-forwarding[3865]: net.ipv6.conf.all.forwarding = 0
Dec 11 08:35:17 debian systemd[1]: Started corridor's forwarding.
Dec 11 08:35:17 debian corridor-init-logged[3871]: corridor_logged updated.
Dec 11 08:35:17 debian systemd[1]: Started corridor's logging.
Dec 11 08:35:17 debian systemd[1]: Reached target corridor, a Tor traffic whitelisting gateway.

This error is ignored.

Dec 11 08:35:16 debian corridor-data[3861]: tee: /rw/corridor_relays.tmp: No such file or directory

Could you make that error out instead please?

consider iptables policy drop

I think it would be much more secure and leak-proof, if corridor was using at the beginning of the firewall rules.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

And then white-list all allowed traffic from there.

firewall lockdown failure mode

In case some corridor systemd service or corridor binary fails (perhaps due to some configuration mistake or hypothetical corridor bug), please iptables lock all networking.

Or maybe better, have a corridor service that locks the network first and have corridor on success unlock it.

port to netfilter-persistent

https://packages.debian.org/jessie/netfilter-persistent is a reliable way to load firewall rules.

It is better than inventing custom firewall loading mechanisms.