From 22439b4c7cf9bba7777855e527bceaa5b66d7696 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Thu, 15 Sep 2016 01:20:38 +0200 Subject: [PATCH] Clarification/update for vm-interface - firewall --- debugging/vm-interface.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/debugging/vm-interface.md b/debugging/vm-interface.md index f44132f2..f9bde9cb 100644 --- a/debugging/vm-interface.md +++ b/debugging/vm-interface.md @@ -66,17 +66,18 @@ communicating problem - like a popup. QubesDB is also used to configure firewall in ProxyVMs. Each rule is stored as a separate entry, grouped on target VM: -- `/qubes-firewall/TARGET_IP` - base tree under which rules are placed. All -there rules there should be applied to filter traffic coming from `TARGET_IP`. +- `/qubes-firewall/SOURCE_IP` - base tree under which rules are placed. All +rules there should be applied to filter traffic coming from `SOURCE_IP`. This +can be either IPv4 or IPv6 address. Dom0 will do an empty write to this top level entry after finishing rules update, so VM can setup a watch here to trigger rules reload. -- `/qubes-firewall/TARGET_IP/policy` - default action if no rule matches: -`DROP` or `ACCEPT`. -- `/qubes-firewall/TARGET_IP/NNNN` - rule number `NNNN` - decimal number, +- `/qubes-firewall/SOURCE_IP/policy` - default action if no rule matches: +`drop` or `accept`. +- `/qubes-firewall/SOURCE_IP/NNNN` - rule number `NNNN` - decimal number, padded with zeros. Se below for rule format. All the rules should be applied in order of rules implied by those numbers. Note that QubesDB itself does not impose any ordering (you need to sort the rules after - retrieving them). + retrieving them). The first rule has number `0000`. Each rule is a single QubesDB entry, consisting of pairs `key=value` separated by space. Order of those pairs in a single rule is undefined. QubesDB enforces @@ -88,22 +89,27 @@ Possible options for a single rule: - `dst6`, value: destination IPv6 address with a mask; for example: `2000::/3` - `dstname`, value: DNS hostname of destination host - `proto`, values: `tcp`, `udp`, `icmp` + - `specialtarget`, value: One of predefined target, currently defined values: + - `dns` - such option should match DNS traffic to default DNS server (but + not any DNS server), on both TCP and UDP - `dstports`, value: destination ports range separated with `-`, valid only together with `proto=tcp` or `proto=udp`; for example `1-1024`, `80-80` - - `icmp-type`, value: numeric (decimal) icmp message type, for example `8` for + - `icmptype`, value: numeric (decimal) icmp message type, for example `8` for echo request, valid only together with `proto=icmp` Rule matches only when all predicates matches. Only one of `dst4`, `dst6`, -`dstname` can be used in a single rule. +`dstname`, `specialtarget` can be used in a single rule. If tool applying firewall encounter any parse error (unknown option, invalid -value etc), it should drop all the traffic coming from that `TARGET_IP`, +value etc), it should drop all the traffic coming from that `SOURCE_IP`, regardless of properly parsed rules. Example valid rules: - `action=accept dst4=8.8.8.8 proto=udp dstports=53-53` - `action=drop dst6=2a00:1450:4000::/37 proto=tcp` +- `specialtarget=dns action=accept` +- `specialtarget=dns action=drop proto=tcp` - drop DNS queries sent using TCP - `action=drop` ### Keys set by VM for passing info to dom0 ###