On Mon, Jan 09, 2017 at 02:18:52PM +0000, 5xa50y+5q6yw via qubes-users wrote:
> 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
> 
> 

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

-- 
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/20170109144756.GA6789%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to