3

I've started recently to use Qubes OS and I want to set up a virtual IDS and IPS in separate VMs, but I can't figure out how the communications between different VMs works here.

Each VM should be isolated and all the connections handled by a separate FirewallWM (sys-firewall), which is connected to the NetWM (sys-net), which, in the basic configuration, is the only one which has Network Device attached (Ethernet and WiFi cards).

I've read the iptables in all VMs and I found the VM Manager set up automatically a DNAT Redirection to let the DNS packets (port 53) exit though sys-net, but I can't understand how all the packets can go through each layer and return back to the different original sources AppVM connected through sys-firewall.

For what concerns the IDS and IPS, I can easily handle and filter packet based on the content, but I can't think how to filter. For example, Source IP based on a blacklist, since I can't see the real origin and since each VM is a separate system which can be based on differents Template (Fedora, Debian, Whonix, ...). I think the Packet Options can be altered.

So, the iptables and the auditings like Psad can only be placed in the VM that is directly connected to the Router?

Some basic info

  • Qubes OS is a system based on Isolation through Hardware Virtualization Technology that let you run different Domains (Personal, Work, Untrusted, ... ) based on different Systems (Templates) on VMs and each instance is complete separate from others, so that if one get compromised, the system remains clean and fully usable
  • You can choose what devices attach to a VM and detach from it, so in the standard and savvy configuration you have a sys-net machine which is the only one that can connect to Internet (Ethernet/WiFi attached) and a sys-firewall machine which handles all the connections and pass through sys-net, so you have 2 levels (you can add more) of isolation for the other domains (ex. PublicWiFi -> sys-firewall -> sys-net, Trusted -> sys-firewall -> sys-net )


I'll post the sys-firewall and sys-net ifconfig and iptables-save outputs, to give you all the details.

VMs Details:

             me | updbl |  type |         netvm |          ip |    ip back | gateway/DNS |
----------------+-------+-------+---------------+-------------+------------+-------------+
         {dom0} |   Yes | Admin |           n/a |  10.137.0.2 | 10.137.0.1 |         n/a |
      {sys-net} |       |   Net |           n/a |        None | 10.137.1.1 |         n/a |
 {sys-firewall} |       | Proxy |       sys-net |  10.137.1.8 | 10.137.2.1 |  10.137.1.1 |
   {sys-whonix} |       | Proxy |  sys-firewall | 10.137.2.10 | 10.137.3.1 |  10.137.2.1 |
      {sys-usb} |       |   Net |           n/a |        None | 10.137.4.1 |         n/a |
    [fedora-23] |   Yes |   Tpl | *sys-firewall |  10.137.2.3 |        n/a |  10.137.2.1 |
      untrusted |       |       | *sys-firewall |  10.137.2.9 |        n/a |  10.137.2.1 |
     [debian-8] |   Yes |   Tpl |  sys-firewall |  10.137.2.4 |        n/a |  10.137.2.1 |
       personal |       |       |             - |        None |        n/a |         n/a |
    [whonix-gw] |   Yes |   Tpl |    sys-whonix |  10.137.3.5 |        n/a |  10.137.3.1 |
    [whonix-ws] |   Yes |   Tpl |    sys-whonix |  10.137.3.6 |        n/a |  10.137.3.1 |
    anon-whonix |       |       |    sys-whonix | 10.137.3.11 |        n/a |  10.137.3.1 |

sys-firewall iptables:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

:PR-QBS - [0:0]
:PR-QBS-SERVICES - [0:0]

-A PREROUTING -j PR-QBS
-A PREROUTING -j PR-QBS-SERVICES

-A POSTROUTING -o vif+ -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -j MASQUERADE

-A PR-QBS -d 10.137.2.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.137.1.1
-A PR-QBS -d 10.137.2.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.137.1.1

-A PR-QBS -d 10.137.2.254/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.137.1.254
-A PR-QBS -d 10.137.2.254/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.137.1.254

sys-firewall ifconfig:

eth0      Link encap:Ethernet  HWaddr 00:16:3e:5e:6c:06  
          inet addr:10.137.1.8  Bcast:10.255.255.255  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:N errors:0 dropped:0 overruns:0 frame:0
          TX packets:N errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:N errors:0 dropped:0 overruns:0 frame:0
          TX packets:N errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 

sys-net iptables:

COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

:PR-QBS - [0:0]
:PR-QBS-SERVICES - [0:0]

-A PREROUTING -j PR-QBS
-A PREROUTING -j PR-QBS-SERVICES

-A POSTROUTING -o vif+ -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -j MASQUERADE

-A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.1
-A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.1

-A PR-QBS-SERVICES -d 10.137.255.254/32 -i vif+ -p tcp -m tcp --dport 8082 -j REDIRECT

sys-net ifconfig:

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets N bytes N
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets N bytes N
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vif62.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.137.1.1  netmask 255.255.255.255  broadcast 0.0.0.0
        ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
        RX packets N bytes N
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets N bytes N
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp0s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 30:3a:64:3a:a2:2d  txqueuelen 1000  (Ethernet)
        RX packets N bytes N
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets N bytes N
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

closed as off-topic by schroeder Jul 14 '17 at 22:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – schroeder
If this question can be reworded to fit the rules in the help center, please edit the question.

  • This is off-topic here, I think. It looks like a networking question or a Qubes-specific config question. – schroeder Feb 5 '17 at 20:41
  • @schroeder There's an important consideration about IDS and IPS configuration, wich is related to security... – JumpAlways Feb 6 '17 at 1:33
  • You want to use the answer to apply to IDS/IPS, but the question itself is more a pure networking question as it pertains to how Qubes implements it internally. I'm completely unsure where I might move this question, though. It really is very Qubes-specific. – schroeder Feb 6 '17 at 7:26
  • 1
    I see that you've asked a number of questions about Qubes on another SE site. I understand why you'v'e asked this here and not there, but I have low confidence that you are going to find an answer on SE. – schroeder Feb 6 '17 at 7:30
1

Its best to think of a Qubes proxyVM (such as sys-firewall) like a regular Linux router that has a slightly odd DNS configuration. As a router, this means most of the action happens in the FORWARD chain and that is where you want filtering rules to go.

There are two ways to add filtering rules:

  1. In the Settings/Firewall tab for each downstream VM connected to the proxyVM. This allows you to customize easily for each appVM.

  2. As iptables commands in the proxyVM's /rw/config/qubes-firewall-user-script designed for this purpose.

Option 1 is a straightforward, if limited, option. You just have to remember that the settings are applied inside the upstream proxyVM, not the VM attached to the settings. (This makes sense because the downstream VM is the one affected by the settings. You can also experiment with adding rules here and looking at the resulting iptables rules in the proxyVM.)

Option 2 requires editing and enabling the script, and being mindful of:

A) the kind of FORWARD rules qubes-firewall adds (as you've already seen), and these can change when Settings/Firewall tab options are changed

B) the fact that FORWARD is purged and re-built when certain events occur

C) that the qubes-firewall-user-script is the last step in that re-building process; it is the vehicle for persisting your rules despite the re-building process

Not the answer you're looking for? Browse other questions tagged or ask your own question.