Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-03-25 15:58:09 -04:00
Code Issues Packages Projects Releases Wiki Activity

Clarification/update for vm-interface - firewall

Browse Source
This commit is contained in:
Marek Marczykowski-Górecki 2016-09-15 01:20:38 +02:00
parent 6603a347fe
commit 22439b4c7c
No known key found for this signature in database
GPG Key ID: F32894BE9684938A
1 changed files with 15 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
debugging/vm-interface.md
View File

@ -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 ###