It's easy. Shut down your Mirage OS Firewall VMs, copy over the new kernel files to the relevant directory in /var/lib/qubes/vm-kernels in dom0, and then restart the Mirage firewalls.
However, I don't know if it's more secure than using a Debian or Fedora based sys-firewall; it *might* help guard against a 0 day cascade though.
That said, because the Mirage firewall doesn't seem to work with a dispVM (at least for me, even running the latest code off of github), I still have sys-firewall running in the background anyways. So what I do is run my mirage-firewall behind sys-firewall (which in turn is behind sys-net). I don't know if that's best practice or even has any effect in guarding against a 0-day cascade, but things still work normally for the machines where I don't do any custom vm iptables filter rules and the ram hit isn't too much (I use 32MB).
Note that if you're trying to compile the latest mirage firewall code from github (which isn't reflected on the Release pages yet; there have been some minor changes since the last one), it might be a bit tricky since if you follow the default github instructions, the compilation will eventually fail as mirage-nat tries to pull in older versions of its package dependencies by default.
What I had to do was follow the github instructions until it failed, run 'opam
upgrade' to update what mirage-nat pulled in, then manually install the latest version of the tcpip package by running 'opam install tcpip' and then finally run 'opam install mirage-nat.' After that, following the rest of the github instructions should be fine. That'll work with both the 4.02.3 OCAML compiler, and the 4.03.0+flambda compiler. Compiling mirage-firewall won't work yet with the 4.04 series compilers because the version of mirage-xen in the repository only works with up to version 4.03. The code on mirage-xen's github page has been updated to work with 4.04 a while back, but a release roll up hasn't been pushed out to the repositories yet; not sure when that'll happen.
Is anyone using the mirage firewall in connection with a proxyVM? How do you configure it properly? Does it handle qubes-firewall-users-scripts?
It seems to work for me. To make things more predictable, I've added a script to build it with Docker:
sudo yum install docker
sudo systemctl start docker
git clone https://github.com/talex5/qubes-mirage-firewall.git
cd qubes-mirage-firewall
sudo ./build-with-docker.sh
The Dockerfile uses a fixed version of opam-repository, so it shouldn't break even if something gets updated. It also prints out the sha256sum of the binary it built and the expected hash (hard-coded in the file), e.g.
$ sudo ./build-with-docker.sh
[...]
SHA2 of build: f0c1a06fc4b02b494c81972dc89419af6cffa73b75839c0e8ee3798d77bf69b3 mir-qubes-firewall.xen
SHA2 last known: f0c1a06fc4b02b494c81972dc89419af6cffa73b75839c0e8ee3798d77bf69b3
I'd be interested to know if other people get the same hash (of course, the hash will change if you e.g. modify the rules.ml file to change the policy).
Do the logs show an out-of-memory error when that happens? I haven't seen one for a long time now, but maybe torrents stress it more than usual.
If so, it could be https://github.com/yomimono/mirage-nat/issues/17 - there's a Mirage hackathon next month and I'm hoping to get some time to work on this there.
Yes. "Fatal error: out or memory. Mirage exiting with status 2"
That said, 2 minutes earlier the log notes that memory use was still only at 16.7/38.2 MB. (Most of the log -- 90-95% -- consists of 'Failed to parse frame' messages, btw.)
By the way, what version of the firewall are you using?
If it's not qubes-mirage-firewall v0.2 then try upgrading first - there were lots of OOM problems in v0.1.
> That said, 2 minutes earlier the log notes that memory use was still only at 16.7/38.2 MB.
The annoying thing about hashtables is the way they suddenly double in size. Since you're allocating 60 MB to the firewall (I only use 20 MB for mine), you could try adjusting the thresholds at these two lines:
https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L41
https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L47
Change the 0.9 (allow 90% of memory to be used) to 0.4 in both places. If the NAT table is the cause, that should make the problem go away.
> (Most of the log -- 90-95% -- consists of 'Failed to parse frame' messages, btw.)
"Failed to parse frame" probably means it saw an ICMP (not TCP or UDP) packet and therefore didn't handle it. Another thing I'm hoping to fix soon... https://github.com/yomimono/mirage-nat/issues/15
I built it using docker about 2 days ago. Will do the other things you mentioned, report back when I know more :)
Thanks! If that is the cause of the memory problem, it should be easy to fix anyway.
That fixed it - thanks!
It looks stable now (uptime 3-4 days since last reboot, whereas before it only lasted ~8h max).
Thanks for the report! I've now made some updates to the firewall:
- It now uses an LRU-cache to drop old entries, rather than growing until it runs out of memory.
- ICMP queries (e.g. ping) and errors (e.g. Host unreachable) now work (they were dropped before).
- I've ported it to the new Mirage 3 release.
There are quite a lot of changes, so I'd be happy to get reports about whether it works or not (I've just started running the new version on my laptop).
Thanks for testing!
I've made a new release of that version now (identical binary):
https://github.com/talex5/qubes-mirage-firewall/releases/tag/v0.3
I've never tried it. Do the mirage-firewall logs show anything interesting when you try to boot Windows?
Oh, that's more useful than I was expecting! Looks like the Windows boot process starts by running MiniOS! It's hanging at
close network: backend at /local/domain/4/backend/vif/79/0
I guess it asked the firewall to close the network, and never got a reply (because the firewall doesn't have any code to do that).
OK, I finally got some time to look into this. I think this patch should fix it (works for Linux HVM anyway):
https://github.com/mirage/mirage-net-xen/pull/67
I also made a patch that seems to let the firewall work with disposable VMs:
https://github.com/mirage/mirage-net-xen/pull/68
Both are based on guesswork though - is the Xen netback protocol documented somewhere?
Thanks. Is there anything about the setup protocol, though? This file seems less well commented:
BTW, I've updated the Dockerfile to build with the patches applied now, if anyone wants to test it:
https://github.com/talex5/qubes-mirage-firewall/
I've had one report from a Qubes 4.0rc1 user that it now works for them (for HVM Linux).