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. -- 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/37a88678-4afc-4ea8-aa8c-b7fc6515c538%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
