Allow connections to update proxy not being respected!

[5xa50y...@guerrillamail.com]

Hi,

Strangely appvms that are marked and not "Allow connections to updates proxy" are still able to reach the tinyproxy, despite the iptables rules:

[root@sys-fw ~]# iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5 217 ACCEPT tcp -- vif+ * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8082
0 0 DROP udp -- vif+ * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
129 25433 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
3 264 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 208 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 172.16.0.0/16
0 0 ACCEPT all -- * * 172.16.0.0/16 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 ACCEPT all -- * * 192.168.0.0/16 0.0.0.0/0
0 0 DROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0
16 1136 DROP all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- vif0.0 * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- vif+ vif+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 10.137.2.9 10.137.1.1 udp dpt:53
0 0 ACCEPT udp -- * * 10.137.2.9 10.137.1.254 udp dpt:53
0 0 ACCEPT tcp -- * * 10.137.2.9 10.137.1.1 tcp dpt:53
0 0 ACCEPT tcp -- * * 10.137.2.9 10.137.1.254 tcp dpt:53
0 0 ACCEPT icmp -- * * 10.137.2.9 0.0.0.0/0
0 0 DROP tcp -- * * 10.137.2.9 10.137.255.254 tcp dpt:8082
0 0 ACCEPT all -- * * 10.137.2.9 0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
111 13152 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3 264 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
25 1493 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
1 42 ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp dpt:1197
26 1646 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "iptables_OUTPUT_denied: "

[user@untrusted ~]$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:16:3e:5e:6c:07 brd ff:ff:ff:ff:ff:ff
inet 10.137.2.9/32 brd 10.255.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe5e:6c07/64 scope link
valid_lft forever preferred_lft forever

So the untrusted appvm (10.137.2.9) is able to reach the tiny proxy (10.137.255.254) on port 8082, despite the drop rule on the FORWARD chain on the sys-fw :

" 0 0 DROP tcp -- * * 10.137.2.9 10.137.255.254 tcp dpt:8082"

[user@untrusted ~]$ telnet 10.137.255.254 8082
Trying 10.137.255.254...
Connected to 10.137.255.254.
Escape character is '^]'.

I confess I'm a bit baffle by this, the only thing I'm using on the sys-fw but that doesn't explain why the iptables rule is being ignored.

Does anyone knows why is this happening?

Thank you

----
Sent using Guerrillamail.com
Block or report abuse: https://www.guerrillamail.com//abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D

[Unman]

Look at the first line of the INPUT chain.
Then look at the nat rules.

If you are running the updates-proxy on sys-firewall, the redirect
rule in PR-QUBES-SERVICES is pushing the traffic destined for
10.137.255.254 to localhost 8082.
You have an explicit rule in INPUT allowing this traffic.
Note that you are not connecting to 10.137.255.254 but to the
sys-firewall IP.

The traffic never touches the FORWARD chain because it is redirected
first (in the nat tables) and then hits the INPUT chain. That's why you
can connect despite the FORWARD rule.

Heop that's clear

unman

[5xb562...@guerrillamail.com]

Oh, well spotted! Thx :)

So what is the option "Allow connections to update proxy" doing if the INPUT chain allows all traffic destined to 10.137.255.254 ?
Isn't this a flaw? Is there a way to avoid this?

[Unman]

On Mon, Jan 09, 2017 at 03:31:10PM +0000, 5xb562+7dpfa via qubes-users wrote:
> Oh, well spotted! Thx :)
>
> So what is the option "Allow connections to update proxy" doing if the INPUT chain allows all traffic destined to 10.137.255.254 ?
> Isn't this a flaw? Is there a way to avoid this?
>

Well, it's there to cover the case where the firewall is between your
qube and the updates proxy. In this case you are running the proxy
service on the firewall, and you have the qube configured to use the
updates proxy, so it is performing as expected.

The standard proxy is only there to provide some level of filtering:
less now than it used to.
If you don't want to use the updates proxy, either stop it running on the
firewall, or remove the Proxy setting on the qube/template. If you dont
want to do either you will have to introduce a custom rule in the chain
to make sure that there isnt any translation for your source IP.

[5xc9wd...@guerrillamail.com]

I'm a bit lost.
I have indeed some AppVMs to use the updates proxy(which is installed in the sys-fw), but not for all of them (only for those that are allowed).
So I don't know how this is performed as expected and why should I need to create a specific rule to workaround this? Shouldn't these be created when I marked on the qubes-manager which appvms are allowed to use the updates-proxy?

[Unman]

On Mon, Jan 09, 2017 at 04:48:32PM +0000, 5xc9wd+2ok6e via qubes-users wrote:
> I'm a bit lost.
> I have indeed some AppVMs to use the updates proxy(which is installed in the sys-fw), but not for all of them (only for those that are allowed).
> So I don't know how this is performed as expected and why should I need to create a specific rule to workaround this? Shouldn't these be created when I marked on the qubes-manager which appvms are allowed to use the updates-proxy?
>
>
>

The firewall rule created governs connections THROUGH the firewall -
that's why it is in the FORWARD chain.
You are running the proxy ON the firewall - did you set this up or was
it done for you? The automatically created rules don't govern access in
this case.
If you want this set-up and you want to control access then you will
have to provide custom rules.

[5xe89r+1y7...@guerrillamail.com]

Got it now! :D

I set this up by myself because I want to force all the traffic to go through the vpn (that is installed on the sys-fw). I've created a custom iptables rule white-listing all traffic originated from the templateVMs on dport 8082 and now it works as expected!
Many thanks for the valuable help Unman!

Btw, strangely when the vpn is first set via the networkmanager that INPUT rule that white-lists everything to the dport 8082 is created. However when after that another AppVM is started the rule is trashed.
Any idea why this is happening?

Many thanks!

[Unman]

On Mon, Jan 09, 2017 at 07:09:41PM +0000, 5xe89r+1y7rhqhfisytc via qubes-users wrote:
> Got it now! :D
>
> I set this up by myself because I want to force all the traffic to go through the vpn (that is installed on the sys-fw). I've created a custom iptables rule white-listing all traffic originated from the templateVMs on dport 8082 and now it works as expected!
> Many thanks for the valuable help Unman!
>
> Btw, strangely when the vpn is first set via the networkmanager that INPUT rule that white-lists everything to the dport 8082 is created. However when after that another AppVM is started the rule is trashed.
> Any idea why this is happening?
>
> Many thanks!
>

You've hit the effect of the qubes-firewall service. This updates
iptables following the addition of a downstream qube.
To work around this you need tom out your custom rules in to
/rw/config/qubes-firewall-user-script, and make it executable.

This is in the docs at www.qubes-os.org/doc/firewall

If you have a consistent setup then you could save the rules as you want
them, load them from rc.local and /rw/config/qubes-firewall-user-script
and disable the qubes-firewall service.