On Thursday, April 11, 2019 at 8:02:33 PM UTC+8, Thomas Leonard wrote: > On Thursday, April 11, 2019 at 4:16:17 AM UTC+1, Sphere wrote: > > @unman Thanks for the clarification. I suppose I misunderstood it wrong > > since I thought you have to set it directly using some sort of text editor > > and be done with it. So I'll have to recompile it I see, welp guess I have > > no choice but go through with that haha > > > > On Thursday, April 11, 2019 at 3:16:32 AM UTC+8, 799 wrote: > > > Hello, > > > > > > > > > > > > Thomas Leonard <tal...@gmail.com> schrieb am Mi., 10. Apr. 2019, 20:42: > > > (...) > > > > > > To change the rules, you edit rules.ml, rebuild and redeploy (this should > > > only take a couple of seconds after the first build). > > > > > > > > > (...) > > > > > > > > > > > > Can you or someone from the mirage fw for Qubes team give some examples > > > how to write rules for mirage? > > > > > > > > > Examples: > > > > > > > > > 1) <AppVM1> can access <AppVM2> via ssh > > > 2) <AppVM3> can reach <InternetHost1> using <Port1> via TCP > > > 3) Block access from <AppVM4> to <InternetHost2> > > > > > > I think some example rules will make it easier to understand how to write > > > rules. > > I've added some examples at > https://github.com/mirage/qubes-mirage-firewall/pull/54 (see the changes to > rules.ml). > > Actually, matching on individual machines was a bit ugly, so I also made some > changes to let you name all the machines you want to refer at the start of > the rules file. You'll need those changes too for the new examples to work. > > > > Regarding rebuilding and redployment: > > > Maybe we can write a small script that will do the following: > > > > > > > > > - launch mirage build VM > > > - apply changes to rules.ml > > > - rebuild > > > - copy new kernel files back to dom0 > > > - shutdown mirage build VM > > > - restart mirage firewall proxyVM > > See: > https://github.com/mirage/qubes-mirage-firewall/#easy-deployment-for-developers > > e.g. I build and deploy the firewall from my dev VM with: > > [dev]$ make && test-mirage qubes_firewall.xen mirage-firewall > > It does what you describe, and also tails the log file so you can see it from > the build VM. The process is triggered from the build VM rather than from > dom0 because working in dom0 is risky. There is a policy so that only the > builder VM can push the kernel, and only the mirage-firewall kernel can be > updated. > > Note that the instructions for test-mirage show how to set up a "mirage-test" > unikernel. You'll need to use "mirage-firewall" as the name instead. > > > I second this idea. I'm having a hard time myself trying to absorb the very > > raw instructions of making rules in the rules.ml > > > > While the added convenience expands the surface of attack by a bit, I think > > this can be very useful in environments where you have to frequently > > interact with firewall rules. > > > > Also got questions about makings rules in rules.ml > > > > let from_client = function > > | { dst = (`External _ | `NetVM) } -> `NAT > > | { dst = `Client_gateway; proto = `UDP { dport = 53 } } -> `NAT_to > > (`NetVM, 53) > > | { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet > > addressed to firewall itself" > > | { dst = `Client _ } -> `Drop "prevent communication between client VMs" > > > > Does `NAT_to (`NetVM, 53) mean that NAT will be applied to the outgoing > > packet then NetVM itself will process the DNS Query within its own VM > > context? If this is right, then configuring a wrong DNS server within NetVM > > would essentially mean DNS resolutions will fail right? > > Yes. Client AppVMs are by default configured to use the firewall as their DNS > (check your /etc/resolv.conf). The firewall then just forwards these requests > to sys-net. > > > Or is this because the rule { dst = `Client_gateway; proto = `UDP { dport = > > 53 } } -> `NAT_to (`NetVM, 53) is intended for internal DNS resolutions? > > (From my own understanding, that seems to be the case but I'd like to be > > corrected if this rule really is for internet DNS resolutions) > > > > Moving forward, if I have no lapses in understanding the guidelines in > > making rules, then this must be the ruleset for allowing only outgoing > > traffic towards port 25, 110, and 143: > > > > let from_client = function > > | { dst = (`External _ | `NetVM); proto = `TCP { dport = 25, 110, 143 } } > > -> `NAT > > Nearly: dport = (25 | 110 | 143) > > > | { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet > > addressed to firewall itself" > > | { dst = `Client _ } -> `Drop "prevent communication between client VMs" > > > > I also want to know why there is an underscore in front of `External and > > `Client > > That space contains information about which client or external machine it is. > "_" matches anything.
Thank you very much for the sweet details! Sorry if I only got to reply now as I was on vacation -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2b404126-7827-4323-9c95-1b148606d650%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
