[qubes-users] DNS issues: servfail on selected subdomains, Qubes modifying DNS replies by stripping IPv6?

2021-05-11 Thread 'qtpie' via qubes-users
I have a very annoying issue with DNS recently. I'm using the standard 
DNS device and servers provided by my internetprovider which runs a full 
dual-stack IPv4/6. Other non-qubes devices have no issues. I think this 
might be a Qubes bug but I want to ask for help first to rule out an 
error on my side.


Selected domainnames (all subdomains, eg www.qubes.org, so not 
qubes.org) get a SERVFAIL when trying to resolve them within 
applications, and on the commandline with 'host' and 'nslookup'. 
Strangely enough, 'dig' has no issues, (querying the same default 
resolver ip of course). At times, the domainname will resolve inside 
sys-net and certain app-vm's, and not in another app-vm. At other times, 
it resolves nowhere. When quering resolvers directly (like my isp's 
resolvers or 1.1.1.1) the issue does not occur.


What can be happening here? One of the only consistent hints I found is 
that Qubes does not seem to pass the full nslookup response from sys-net 
to the appvm (compare nslookup examples below). My router gives a 
servfail when quering it via ipv4, nslookup then tries it's ipv6 
address, where it does get a reply, but this reply is not passed to the 
appvm. The servfail might be an ipv6 issue or an issue with my router, 
but I think still Qubes should pass the full response, right?



some affected domainnames:
www.duckduckgo.com
www.startpage.com
textsecure-service.whispersystems.org



user@chat-1:~$ host -v www.startpage.com
Trying "www.startpage.com"
Host www.startpage.com not found: 2(SERVFAIL)
Received 35 bytes from 10.139.1.2#53 in 2 ms

-

user@chat-1:~$ nslookup  www.startpage.com
;; Got SERVFAIL reply from 10.139.1.1, trying next server
Server:        10.139.1.2
Address:    10.139.1.2#53

** server can't find www.startpage.com: SERVFAIL



user@sys-net:~$ host -v www.startpage.com
Trying "www.startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22135
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.startpage.com.        IN    A

;; ANSWER SECTION:
www.startpage.com.    2393    IN    CNAME    startpage.com.
startpage.com.        10    IN    A    145.131.132.72

Received 65 bytes from 192.168.0.1#53 in 4 ms
Trying "startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8508
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;startpage.com.            IN    

;; AUTHORITY SECTION:
startpage.com.        2598    
IN    SOA    dns1.p01.nsone.net. 
hostmaster.nsone.net. 1619470914 3600 600 1209600 3600


Received 96 bytes from 192.168.0.1#53 in 3 ms
Trying "startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;startpage.com.            IN    MX

;; ANSWER SECTION:
startpage.com.        2598    
IN    MX    10 mx2.startmail.com.
startpage.com.        2598    
IN    MX    10 mx1.startmail.com.


Received 81 bytes from 192.168.0.1#53 in 1 ms




user@sys-net:~$ nslookup  www.startpage.com
;; Got SERVFAIL reply from 192.168.0.1, trying next server
Server:        fd00::(redacted):ee5e
Address:    fd00::(redacted):ee5e#53

Non-authoritative answer:
www.startpage.com    canonical name = startpage.com.
Name:    startpage.com
Address: 37.0.87.39



--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cf58fe9c-c3f8-be3c-42be-1e40fd64b135%40disroot.org.


Re: [qubes-users] detect tcp/ip connections of executables due to qubes firewall restrictions

2021-05-11 Thread Steve Coleman
On Mon, May 10, 2021, 2:57 PM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> lik...@gmx.de:
> > Hi!
> >
> > Due to the current implementation/design of qubes firewall, it's hard to
> use domain names for firewall rules, because of "static" DNS resolution:
> > https://github.com/QubesOS/qubes-issues/issues/5225
> >
> > To find out the "connection wishes/tries" of an executable, what's the
> recommendation to use them for firewall rules?
> >   1.  Let's assume all network access except DNS is restricted from
> a AppVM. How can I find out which domains/IPs which executable is trying to
> use/connect to?
> >   2. What are you're best practices to find out all IPs for a domain
> to white list them?
> >
> > Best, P
> >
> 1. netstat -pan, and/or tcpdump from somewhere networking isn't blocked.
> Might have to watch DNS requests to see what it's attempting to resolve.
> Don't know of a way to do it with networking disabled.
>

At one point in the past I was running  Boinc and Thunderbird in network
restricted AppVMs. The sys-firewall was set to the default deny mode so
that I could prevent connections to anywhere except the specific  servers I
gave it permissions to. I had a python script that ran tcpdump in a pipe
and read the output and then auto-generated the qubes firewall commands
needed to open the firewall, but I manually chose which addtesses to
actually allow.

When the firewall blocks a packet it sends a specific ICMP packet back to
the AppVM containing the address/port that was blocked. I simply filtered
for and read those packets from tcpdump and printed the appropriate 'add'
command to stout in a terminal so I could then copy/paste that command to
another terminal window to add the address/port once I investigated why the
requesting program might have needed that connection. It would be trivial
to add a gui with a click-to-add button.

This could likely be done on the internal interface in sys-firewall
(untested) or in the AppVM (where you could also check which process was
using that port number, e.g. netstat -pan) depending on the trust level in
your AppVM. One could put this in a batch learning mode to collect all
these commands during a test run and then add them to the sys-firewall
permanently once verified.

As for performance, you only need to monitor it periodically if the app
stops working, like when they shift to some other round-robbin server. You
could easilly run it as a cron job at night to see what connections had
been tried while you were not there. There is however limitations on the
number of rules you can add so you might need to change individual
addresses into network blocks once you start having those resource limiting
issues. Thunderbird for instance tried to check for plug-ins at lots of
different addresses.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDng%3DzSm9fDsLVbB5WjVGE7aDDJjsO8kihOzjWfFwgjQ68A%40mail.gmail.com.


Re: [qubes-users] How do I install trezor-bridge on a Qubes system without a sys-usb qube e

2021-05-11 Thread unman
On Mon, May 10, 2021 at 06:12:47PM +, 'awokd' via qubes-users wrote:
> 'Joanna Anders' via qubes-users:
> > 
> > I'm trying to make Trezor Model T work on my Qubes system installed on a
> > ssd *usb drive* according to this guide https://wiki.trezor.io/Qubes_OS .
> > So by default the *sys-usb qube is disabled*. If I try to enable it my
> > whole system turns unusable.
> > 
> > Should I edit the *sys-net* qube instead of nonexistent *sys-usb* ?
> > 
> If I'm not mistaken, running Qubes directly from a USB drive requires dom0
> to own at least the USB controller responsible for the drive. This would
> mean you would have to run the trezor service there as well, but as dom0's
> networking is disabled, wouldn't get you any further. Unfortunately, think
> you pretty much require a sys-usb. If you have more than one controller
> driving the external ports (fairly unusual on laptops, though) you may be
> able to assign a single unused controller to a sys-usb qube and use the
> Trezor device on those specific ports. Not an option if your drive is on one
> of the same ports. Other option could be to install Qubes on local disk
> instead of USB.
> 

Is it unusual to have more than one controller on a laptop? Venerable
old Thinkpads had 2 or 3, and you could easily keep one for dom0 and the
other(s) for sys-usb purposes.
But you're not mistaken - if you only have 1 controller, you cant
allocate that to a sys-usb while running from usb.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20210511144629.GA30353%40thirdeyesecurity.org.


Re: [qubes-users] Dom0 update error (Converting database from bdb to sqlite backend)

2021-05-11 Thread load...@gmail.com
On Monday, May 10, 2021 at 10:06:10 PM UTC+3 awokd wrote:

> load...@gmail.com: 
>
> In a sys-firewall terminal session, make a backup copy of the file it's 
> complaining about 
> (/var/lib/qubes/dom0-updates/etc/yum.repos.d/fedora.repo), then edit it. 
> Remove the value it's complaining about (failovermethod=priority). Save 
> and try again. 
>
 
Unfortunately the '*/var/lib/qubes/dom0-updates/*' completely empty in 
sys-firewall.
 

If it still fails, you might want to create a fresh sys-firewall, or 
> change your UpdateVM to point to a different AppVM. 
>

I tried with sys-net and also I tried with new netvm, but still have this 
error.
 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b235be97-d328-43f0-9d0c-ad2daae10a4bn%40googlegroups.com.