Re: [qubes-users] How to log all the websites accessed by a VM
320 views
Skip to first unread message
Andrew David Wong
Jul 22, 2016, 6:41:09 PM7/22/16
to gal...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-07-21 06:59, gal...@gmail.com wrote:
> I'm created a VM that I want to use for online banking. I want to set the
> firewall rules so that it can only access the bank's website but it is
> proving to be tricky. The issue is that I go to www.bank.com and I added
> this to the VM firewall. When I try to log in, it goes to online.bank.com
> and then to secure.bank.com. I've added all of these to the firewall but
> it is still getting stuck somewhere.
>
> I can log in fine from a disposable VM. Is there a way to log all the web
> addresses that the disposable VM accessed during my banking session so
> that I can add them all the the banking VM's firewall?
>
> Alternatively, can I add *.bank.com?
>
Your best bet is to whitelist the entire CIDR block of bank's domain (and hope
the site doesn't rely too much on CDNs). You can typically find the CIDR block
in the domain's WHOIS information:
$ host bank.com
bank.com has address 000.000.000.000
$ whois 000.000.000.000
[...]
CIDR: 000.000.0.0/0
[...]
Then you'd allow all HTTPS connections to 000.000.0.0/0 in that VM's firewall
settings. You may have to repeat for subdomains, as well as any other domains
the site relies upon.
If things still aren't loading properly, use the developer console in your
browser (e.g., press F12) to see the domains of any network resources that
aren't being loaded properly, then follow the same procedure to whitelist
those, as well.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXkqD9AAoJENtN07w5UDAwP2oP/Rb3kDrAeFL557eF5OUVdswI
89p6pJpCQd3iPYMyUwyPwcneTEfQgZ2/nWPwPJtbzYvpVcH2iZIscXucaDvnWKQh
AIontnTA3VWhKqTOJy5ntWA7Sd28dz69kzxlBthAUewNq1awUjq1M1zQogfl3heR
XQ4eBqHv0W0gNFZNhdPuGBBx3q7mAQe643dnsgCxYo9flBf0YdBZ1ICaRDFaX+8A
crAUxd3BGGcNP23kOFhg0j6ncGOXfja+ONJAAdApZ+5Sz1itAZLlCZd/1VikvCSh
f2Wv5PJqCaibnAzn76T4i8c+UR6VA9eIGbeI5FP2KTuEwE3kDrIsRGqK3OQe40fC
zdD9yeRhGgi6Ph8DUxl+svWYEUQ/PcfQcNbJBDZxtg4D3aIgfXjbjDgocDhNUIPJ
HPPVAwnVhlJZFKH3ME0twwZLcgJQZymK0Cq8ah475KCjZ+cw0mlm8wyeARPxxqWL
RIbzZO1TmZTsD+XrT5g38ITUEJFJrFMxMwipwjJUqupb+2CmnjehABBpXa5gok6C
OCMJ2Z88+gfiYRjybuMqx09XzGdg+6nAW09EIXCaNHKt9iCCWxAL3YseWUnGWtu2
FBg8WWEXmJN/ovTiVuQfU82kvEHO97dVKHZ0zcpL1ARnlig5PQcah3mBbUjYHAS6
Hxii1+oUpnAxFMIZWZ2d
=zEZR
-----END PGP SIGNATURE-----
Hash: SHA512
On 2016-07-21 06:59, gal...@gmail.com wrote:
> I'm created a VM that I want to use for online banking. I want to set the
> firewall rules so that it can only access the bank's website but it is
> proving to be tricky. The issue is that I go to www.bank.com and I added
> this to the VM firewall. When I try to log in, it goes to online.bank.com
> and then to secure.bank.com. I've added all of these to the firewall but
> it is still getting stuck somewhere.
>
> I can log in fine from a disposable VM. Is there a way to log all the web
> addresses that the disposable VM accessed during my banking session so
> that I can add them all the the banking VM's firewall?
>
> Alternatively, can I add *.bank.com?
>
Your best bet is to whitelist the entire CIDR block of bank's domain (and hope
the site doesn't rely too much on CDNs). You can typically find the CIDR block
in the domain's WHOIS information:
$ host bank.com
bank.com has address 000.000.000.000
$ whois 000.000.000.000
[...]
CIDR: 000.000.0.0/0
[...]
Then you'd allow all HTTPS connections to 000.000.0.0/0 in that VM's firewall
settings. You may have to repeat for subdomains, as well as any other domains
the site relies upon.
If things still aren't loading properly, use the developer console in your
browser (e.g., press F12) to see the domains of any network resources that
aren't being loaded properly, then follow the same procedure to whitelist
those, as well.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXkqD9AAoJENtN07w5UDAwP2oP/Rb3kDrAeFL557eF5OUVdswI
89p6pJpCQd3iPYMyUwyPwcneTEfQgZ2/nWPwPJtbzYvpVcH2iZIscXucaDvnWKQh
AIontnTA3VWhKqTOJy5ntWA7Sd28dz69kzxlBthAUewNq1awUjq1M1zQogfl3heR
XQ4eBqHv0W0gNFZNhdPuGBBx3q7mAQe643dnsgCxYo9flBf0YdBZ1ICaRDFaX+8A
crAUxd3BGGcNP23kOFhg0j6ncGOXfja+ONJAAdApZ+5Sz1itAZLlCZd/1VikvCSh
f2Wv5PJqCaibnAzn76T4i8c+UR6VA9eIGbeI5FP2KTuEwE3kDrIsRGqK3OQe40fC
zdD9yeRhGgi6Ph8DUxl+svWYEUQ/PcfQcNbJBDZxtg4D3aIgfXjbjDgocDhNUIPJ
HPPVAwnVhlJZFKH3ME0twwZLcgJQZymK0Cq8ah475KCjZ+cw0mlm8wyeARPxxqWL
RIbzZO1TmZTsD+XrT5g38ITUEJFJrFMxMwipwjJUqupb+2CmnjehABBpXa5gok6C
OCMJ2Z88+gfiYRjybuMqx09XzGdg+6nAW09EIXCaNHKt9iCCWxAL3YseWUnGWtu2
FBg8WWEXmJN/ovTiVuQfU82kvEHO97dVKHZ0zcpL1ARnlig5PQcah3mBbUjYHAS6
Hxii1+oUpnAxFMIZWZ2d
=zEZR
-----END PGP SIGNATURE-----
Achim Patzner
Jul 24, 2016, 1:56:48 PM7/24/16
to qubes-users
> Am 23.07.2016 um 00:41 schrieb Andrew David Wong <a...@qubes-os.org>:
>
> Your best bet is to whitelist the entire CIDR block of bank's domain (and hope
> the site doesn't rely too much on CDNs). You can typically find the CIDR block
> in the domain's WHOIS information:
Sorry, but this answer might cause more problems than it solves.
Achim
Andrew David Wong
Jul 24, 2016, 7:22:38 PM7/24/16
to Achim Patzner, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-07-24 10:56, Achim Patzner wrote:
>
>> Am 23.07.2016 um 00:41 schrieb Andrew David Wong <a...@qubes-os.org>:
>>
>> Your best bet is to whitelist the entire CIDR block of bank's domain
>> (and hope the site doesn't rely too much on CDNs). You can typically find
>> the CIDR block in the domain's WHOIS information:
>
> … and then you’ll find out that $BANK is using an external service for its
> financial transactions and their website is only providing you with a
> locally running front end to that gateway. Which will probably not use any
> machine in their own registered block. Or the web servers are hosted by a
> third party who is not hosting the transaction gateway.
>
>
>> Am 23.07.2016 um 00:41 schrieb Andrew David Wong <a...@qubes-os.org>:
>>
>> Your best bet is to whitelist the entire CIDR block of bank's domain
>> (and hope the site doesn't rely too much on CDNs). You can typically find
>> the CIDR block in the domain's WHOIS information:
>
> … and then you’ll find out that $BANK is using an external service for its
> financial transactions and their website is only providing you with a
> locally running front end to that gateway. Which will probably not use any
> machine in their own registered block. Or the web servers are hosted by a
> third party who is not hosting the transaction gateway.
>
Well, that's why I said:
>> If things still aren't loading properly, use the developer console in
>> your browser (e.g., press F12) to see the domains of any network
>> resources that aren't being loaded properly, then follow the same
>> procedure to whitelist those, as well.
>> If things still aren't loading properly, use the developer console in
>> your browser (e.g., press F12) to see the domains of any network
>> resources that aren't being loaded properly, then follow the same
>> procedure to whitelist those, as well.
> Sorry, but this answer might cause more problems than it solves.
>
Have you actually tried it? It's been working for me for years.
>
But if anyone has a better solution, I'm all ears.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
90ss/+YPO8UvkWCJYheQQ5U85nEF78eNhNq0VGBb5P383JIJTLpBXG9Y5WzjZLS/
/9pEx7FUCIC1hcIITTExu2zAzQJjzeEwPUnf6CTEfvjzKkN8eXmITValwbfshzoY
B2pNqME8n6HZ0ndgdXKYzxe6kZ3tZqkR+oFF0+wuDwjyn/KNgyCqCzQ25csqdAWw
z6rUsbVF6vBep3ViNL/iMu3KKipkQ5Czklg7C16y+2QTzR0ASPALEgT1ZiNvQMNM
S3kniRJ+u0gLvt9ZKsQSm/p5ngXC7MCAn2apo8ky++yFh+ekyF8odGZslw7Ymb0c
lXWULRaRYcIJ3s2A1ffN9oB1Jg55bcYhTLKflaHhBaLqKxYEbNxyWL+21fOL7MeD
d9WiIoHmKmOEsXjs4KpkYD+vNdcZskNetyK/6o/iph6RasRiMLpQu0mEtM3LiYf+
9nOyiRPAFHzc8DKCciDA4HHO800v4XNhrtgUJ3HAgcD+JA1WaBdxVO1Zsy9a8W7j
1d8COT2dtMPvUwkGmWBiZReNqJyHzNsdcwnAdd6isqJWKFA7GJ/wltI/ukgjxDyh
AEeJbV/VMxTUY6ALT0iHf2NwOAv3tBlgjTpErswx4mVMnbbElhQ8At373XuIkBoT
oDNgrOexOJmSvbERU3ok
=q9re
-----END PGP SIGNATURE-----
Steve Coleman
Jul 25, 2016, 9:33:50 AM7/25/16
to qubes-users
On 07/24/2016 07:22 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-07-24 10:56, Achim Patzner wrote:
>>
>>> Am 23.07.2016 um 00:41 schrieb Andrew David Wong <a...@qubes-os.org>:
>>>
>>> Your best bet is to whitelist the entire CIDR block of bank's domain
>>> (and hope the site doesn't rely too much on CDNs). You can typically find
>>> the CIDR block in the domain's WHOIS information:
>>
>> … and then you’ll find out that $BANK is using an external service for its
>> financial transactions and their website is only providing you with a
>> locally running front end to that gateway. Which will probably not use any
>> machine in their own registered block. Or the web servers are hosted by a
>> third party who is not hosting the transaction gateway.
>>
>
> Well, that's why I said:
>
>>> If things still aren't loading properly, use the developer console in
>>> your browser (e.g., press F12) to see the domains of any network
>>> resources that aren't being loaded properly, then follow the same
>>> procedure to whitelist those, as well.
>
>
>> Sorry, but this answer might cause more problems than it solves.
>>
>
> Have you actually tried it? It's been working for me for years.
>
> But if anyone has a better solution, I'm all ears.
>
A quick and dirty solution: In each restricted VM I open a terminal and do:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-07-24 10:56, Achim Patzner wrote:
>>
>>> Am 23.07.2016 um 00:41 schrieb Andrew David Wong <a...@qubes-os.org>:
>>>
>>> Your best bet is to whitelist the entire CIDR block of bank's domain
>>> (and hope the site doesn't rely too much on CDNs). You can typically find
>>> the CIDR block in the domain's WHOIS information:
>>
>> … and then you’ll find out that $BANK is using an external service for its
>> financial transactions and their website is only providing you with a
>> locally running front end to that gateway. Which will probably not use any
>> machine in their own registered block. Or the web servers are hosted by a
>> third party who is not hosting the transaction gateway.
>>
>
> Well, that's why I said:
>
>>> If things still aren't loading properly, use the developer console in
>>> your browser (e.g., press F12) to see the domains of any network
>>> resources that aren't being loaded properly, then follow the same
>>> procedure to whitelist those, as well.
>
>
>> Sorry, but this answer might cause more problems than it solves.
>>
>
> Have you actually tried it? It's been working for me for years.
>
> But if anyone has a better solution, I'm all ears.
>
> sudo tcpdump | grep unreachable | awk '{print $8}'
When the firewall rejects a connection, sending back an ICMP message,
the hostname will be listed in that window. My .bashrc for each
restricted VM contains a simple alias:
prohibitedHosts() {
sudo tcpdump | grep unreachable | awk '{print $8}'
}
alias blocked=prohibitedHosts
So I can just type the word "blocked" at the command line, perform the
failing operation, and then use the hostnames to tweak the firewall
rules for that VM. I'm sure you could do filtering with tcpdump rather
than using grep, but the stream buffering doesn't delay the output too
much. Its been working fine for me.
Marek Marczykowski-Górecki
Jul 25, 2016, 10:11:10 AM7/25/16
to Steve Coleman, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Take a look at this message:
https://groups.google.com/d/msgid/qubes-users/20160425084647.GQ1053%40mail-itl
It uses very similar approach, but instead of using reverse DNS lookup
(by tcpdump), it caches DNS responses to guess what name application
asked for (which may not match reverse DNS - especially for some CDNs).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXlh32AAoJENuP0xzK19csjSYH/RnXVk+obgoweKpn/oBMQnJi
OzCHSL3IOU4+CKxh4Y1soO51e5ye11Zq43IfrzQizRi7GAeGpUc2988mZgqNZB4V
3SNRg9R0SN2gQc1JSlnwKMNjG2khW4HPl6wy3beAO/tylu9OmyaixQQms4wB0cSN
LxeRCLSeI9tNBgHF97IiLTr6p7fvwLJEFvm51+Ngt4Wtd2Khtaw9fbhInqy88Pfc
TjnEWElBS1QdRyQaCRskvSP9XbyyaBcQiqqV5l7ao6RV0DfwKpcV2Xa/kNCRI0Rd
+VchKtNGjMkz2jOFQ0bjbIa6O+cynO4I/YHi5h+0HJq6Oauu1gu/LBQH1q/nc00=
=pORh
-----END PGP SIGNATURE-----
Hash: SHA256
https://groups.google.com/d/msgid/qubes-users/20160425084647.GQ1053%40mail-itl
It uses very similar approach, but instead of using reverse DNS lookup
(by tcpdump), it caches DNS responses to guess what name application
asked for (which may not match reverse DNS - especially for some CDNs).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXlh32AAoJENuP0xzK19csjSYH/RnXVk+obgoweKpn/oBMQnJi
OzCHSL3IOU4+CKxh4Y1soO51e5ye11Zq43IfrzQizRi7GAeGpUc2988mZgqNZB4V
3SNRg9R0SN2gQc1JSlnwKMNjG2khW4HPl6wy3beAO/tylu9OmyaixQQms4wB0cSN
LxeRCLSeI9tNBgHF97IiLTr6p7fvwLJEFvm51+Ngt4Wtd2Khtaw9fbhInqy88Pfc
TjnEWElBS1QdRyQaCRskvSP9XbyyaBcQiqqV5l7ao6RV0DfwKpcV2Xa/kNCRI0Rd
+VchKtNGjMkz2jOFQ0bjbIa6O+cynO4I/YHi5h+0HJq6Oauu1gu/LBQH1q/nc00=
=pORh
-----END PGP SIGNATURE-----
Franz
Jul 25, 2016, 11:06:59 AM7/25/16
to Marek Marczykowski-Górecki, Steve Coleman, qubes-users
All this seems very interesting, but if someone has various banks/brokers/bitcoins accounts etc it seems very time consuming and requiring much attention both for setting it up and for maintaining it because institutions change name, settings etc.
Is there a plan to automate it somehow?
Anyway regarding Marek script I tried it in a dispVM, it writes:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
but then if on the same dispVM I use firefox to go to a gmail account or another account, nothing appears on the terminal.
I even looked if anything changed on dispVM firewall rules, but found nothing different.
So how is this script working?
Best
Fran
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXlh32AAoJENuP0xzK19csjSYH/RnXVk+obgoweKpn/oBMQnJi
OzCHSL3IOU4+CKxh4Y1soO51e5ye11Zq43IfrzQizRi7GAeGpUc2988mZgqNZB4V
3SNRg9R0SN2gQc1JSlnwKMNjG2khW4HPl6wy3beAO/tylu9OmyaixQQms4wB0cSN
LxeRCLSeI9tNBgHF97IiLTr6p7fvwLJEFvm51+Ngt4Wtd2Khtaw9fbhInqy88Pfc
TjnEWElBS1QdRyQaCRskvSP9XbyyaBcQiqqV5l7ao6RV0DfwKpcV2Xa/kNCRI0Rd
+VchKtNGjMkz2jOFQ0bjbIa6O+cynO4I/YHi5h+0HJq6Oauu1gu/LBQH1q/nc00=
=pORh
-----END PGP SIGNATURE-----
--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160725141102.GG32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
Marek Marczykowski-Górecki
Jul 25, 2016, 12:25:00 PM7/25/16
to Franz, Steve Coleman, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
> Anyway regarding Marek script I tried it in a dispVM, it writes:
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
>
> but then if on the same dispVM I use firefox to go to a gmail account or
> another account, nothing appears on the terminal.
>
> I even looked if anything changed on dispVM firewall rules, but found
> nothing different.
>
> So how is this script working?
blocked destinations in format of qvm-firewall commands ready to load
into Qubes firewall.
I've tested it only in Fedore VM.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
or+K3CNtjalGTkouEfcpOPS4tCXxIreTeS2la9skTnHzlSDu47iL1SFuUNt8RXqb
900oVx4/iJpm2iOy5lqps24Br/ZUsiLlX6XNSpQoCF9bima3wI5u/H1HtV98Gv6G
/ll6wu6axRQfasrhX1KMyq/nsQxlpVyc/rW2sDd5uSlobQdg0xgflxL2G+ndPS69
Sd3YWwzynKQVNt57oi+Kajizv6M+5fevpWZ/Zi4Tngnm8ZZNmEEuhFvhy7Gh07uJ
mxsql7qJ11BQkYHMtt0ql54RvCuA6EQeSHO/T4gUg1uaQZvPuf1LLdPwRJD5eGs=
=RXdc
-----END PGP SIGNATURE-----
Franz
Jul 25, 2016, 1:46:58 PM7/25/16
to Marek Marczykowski-Górecki, Steve Coleman, qubes-users
,
"blocked destinations"? This makes me think that I should block destinations somehow before running the script. Is that so?
Marek Marczykowski-Górecki
Jul 25, 2016, 1:51:23 PM7/25/16
to Franz, Steve Coleman, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> wrote:
> > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > marm...@invisiblethingslab.com> wrote:
> > > > On Mon, Jul 25, 2016 at 09:37:10AM -0400, Steve Coleman wrote:
> > > Anyway regarding Marek script I tried it in a dispVM, it writes:
> > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> > > 262144 bytes
> > >
> > > but then if on the same dispVM I use firefox to go to a gmail account or
> > > another account, nothing appears on the terminal.
> > >
> > > I even looked if anything changed on dispVM firewall rules, but found
> > > nothing different.
> > >
> > > So how is this script working?
> >
> > I've just tried and it is still working. It should output list of
> > blocked destinations in format of qvm-firewall commands ready to load
> > into Qubes firewall.
> >
> ,
> "blocked destinations"? This makes me think that I should block
> destinations somehow before running the script. Is that so?
Yes, change VM firewall to deny by default.
> On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> wrote:
> > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > marm...@invisiblethingslab.com> wrote:
> > > > On Mon, Jul 25, 2016 at 09:37:10AM -0400, Steve Coleman wrote:
> > > Anyway regarding Marek script I tried it in a dispVM, it writes:
> > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> > > 262144 bytes
> > >
> > > but then if on the same dispVM I use firefox to go to a gmail account or
> > > another account, nothing appears on the terminal.
> > >
> > > I even looked if anything changed on dispVM firewall rules, but found
> > > nothing different.
> > >
> > > So how is this script working?
> >
> > I've just tried and it is still working. It should output list of
> > blocked destinations in format of qvm-firewall commands ready to load
> > into Qubes firewall.
> >
> ,
> "blocked destinations"? This makes me think that I should block
> destinations somehow before running the script. Is that so?
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
IjTNevVwL/z1ymB4HLwdQmOi3AQ5q8db/AoMd37AC06yzxEJkEQzt5HsMbnEK4UI
SFlKbKr5t7/eyK9R7B6dQH2dBL69ODZf8wQWl5T3oEJj3cZOCLOkAQZcjNHgPefU
AX2cKoi3q7TLxy810f08o+KicA2VclBA5Q66tf6GSoFG44VWfBtxZgkHTZ/s9aWW
cUvNfHIZtSZNiIOEJKLHP3y7tLAFZXOvdtIqIo2/jxWIJSc+47ypPxpOSiAdiA79
erUry7spy9ta5GNlblBf5fSGaQaYRBeEGl91+b++pX/zTg1/sMbv3hoCFpVHYnI=
=XmDi
-----END PGP SIGNATURE-----
Franz
Jul 25, 2016, 2:14:04 PM7/25/16
to Marek Marczykowski-Górecki, Steve Coleman, qubes-users
ok now it works, it outputted a list of addresses. But I have to paste this list on firewall rules of that VM and this is on Qubes Manager that is on Dom0, so normal copy paste between VMs does not work.
I can only imagine of writing the addresses on a text file, then copying the file to Dom0, using
qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0Otherwise I'll have to digit manually the addresses to Qubes Manager.
Which is the suggested way to do that?
Marek Marczykowski-Górecki
Jul 25, 2016, 2:20:36 PM7/25/16
to Franz, Steve Coleman, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
qvm-run --pass-io <src-vm> 'cat output-of-that-command'
Then copy&paste selected lines into shell (those are ready commands to
add firewall entries).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
q+idjhGTUpMUZ2iXDvxnKABt2B4gkoGcjXtRbo7kO1j/iJvd2huMXxl/27iL5X3g
6U2ZVoE7GD4YPecNfAQj/QKCmU4oyydoFqHu2QZMM9sRawwjjksnETCLm9U1FSxW
jfbHn3srorRRxHBSQQnseYKyIk6HLVYNdh9YW1gBNbatbVgff9fWTPWni5BI2bfo
01mPlbVX+whfL+5WpBtEPuulTxfp27yfou2FtqI73SSTbpnM/J025cGA8YcQ40Xy
5Dcuax/p1s75YzAe63yfwngb+/h3WGRNm33LFtHKQdtLIPjKD9p1P7giCXbqyJk=
=W3m8
-----END PGP SIGNATURE-----
Franz
Jul 25, 2016, 3:31:33 PM7/25/16
to Marek Marczykowski-Górecki, Steve Coleman, qubes-users
After much trying I am unable to figure out how to get this command working. If anybody may give an example I would appreciate.
Best
Fran
R.B.
Jul 25, 2016, 4:40:48 PM7/25/16
to Franz, Marek Marczykowski-Górecki, Steve Coleman, qubes-users
On 07/25/2016 09:31 PM, Franz wrote:
>
>
> On Mon, Jul 25, 2016 at 3:20 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
>
>
> On Mon, Jul 25, 2016 at 3:20 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 03:14:02PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 03:14:02PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>> wrote:
> > > > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > > > > marm...@invisiblethingslab.com
> > > > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > > > > marm...@invisiblethingslab.com
The way I use it:
- Make sure Marek's perl script is in the vm you want to monitor.
Preferably in /home/user.
- Make sure the firewall is set to "Deny network access except..." by
default.
- Open a terminal in Dom0.
- Enter the command:
qvm-run --pass-io YourVM 'sudo tcpdump -vni eth0 port 53 or icmp |
perl ./firewall-learn.pl'
- Run your program you want to monitor.
- Select the rules you think you need the program to run properly and
copy/paste them to another terminal in Dom0.
Few things I'm unsure about,
- a Check at ICMP?
- a Check at DNS?
- is using this perl script via qvm-run considered safe?
Have fun and thanks Marek for your script! Just what I needed!
Greetings,
RB
R.B.
Jul 25, 2016, 5:05:56 PM7/25/16
to Franz, Marek Marczykowski-Górecki, Steve Coleman, qubes-users
DNS has to be checked if you want to filter on name instead of ip-adresses.
I noticed there can be some dalay between the action in the browser and
the result in the terminal.
Greetings,
RB
Chris Laprise
Jul 25, 2016, 5:25:13 PM7/25/16
to Marek Marczykowski-Górecki, Franz, Steve Coleman, qubes-users
On 07/25/2016 02:20 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 03:14:02PM -0300, Franz wrote:
>>
>> ok now it works, it outputted a list of addresses. But I have to paste this
>> list on firewall rules of that VM and this is on Qubes Manager that is on
>> Dom0, so normal copy paste between VMs does not work.
>>
>> I can only imagine of writing the addresses on a text file, then copying
>> the file to Dom0, using
>>
>> qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' >
>> /path/to/file_name_in_dom0
>>
>> opening the file in Dom0 (which seems half prohibited) and finally copying
>> the adresses to Qubes Manager.
>>
>> Otherwise I'll have to digit manually the addresses to Qubes Manager.
>>
>> Which is the suggested way to do that?
> Personally I do some thing like:
> qvm-run --pass-io <src-vm> 'cat output-of-that-command'
>
> Then copy&paste selected lines into shell (those are ready commands to
> add firewall entries).
>
> - --
A less tedious method to get a somewhat similar effect is to install
>>
>> ok now it works, it outputted a list of addresses. But I have to paste this
>> list on firewall rules of that VM and this is on Qubes Manager that is on
>> Dom0, so normal copy paste between VMs does not work.
>>
>> I can only imagine of writing the addresses on a text file, then copying
>> the file to Dom0, using
>>
>> qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' >
>> /path/to/file_name_in_dom0
>>
>> opening the file in Dom0 (which seems half prohibited) and finally copying
>> the adresses to Qubes Manager.
>>
>> Otherwise I'll have to digit manually the addresses to Qubes Manager.
>>
>> Which is the suggested way to do that?
> Personally I do some thing like:
> qvm-run --pass-io <src-vm> 'cat output-of-that-command'
>
> Then copy&paste selected lines into shell (those are ready commands to
> add firewall entries).
>
> - --
'HTTPS Everywhere' extension in Firefox and turn on the "block all
unencrypted" feature. Then create some bookmarks for the (HTTPS) sites
you wish to use.
You can control it further by adding the 'Request Policy' extension and
use it to whitelist the 3rd party sites as you encounter them (the
extension will remember your choices).
Chris
Franz
Jul 25, 2016, 6:58:51 PM7/25/16
to R.B., Marek Marczykowski-Górecki, Steve Coleman, qubes-users
Thanks for the example, this goes a little more, in dom0 I reach the step:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
but then instead of
qvm-firewall -a debian-8-multimedia-dvm 104.20.30.3 tcp 443 that I get on dispVM terminal
qvm-firewall -a debian-8-multimedia-dvm 104.20.30.3 tcp 443 that I get on dispVM terminal
I get nothing more appearing on Dom0 terminal.
On the other hand if I try to use Marek suggestion adding "cat" with something like
I get: cat: invalid option -- 'i'
I even tried to invent parenthesis :-)
qvm-run --pass-io disp16 'cat {sudo tcpdump -vni eth0 port 53 or icmp | perl ./firewall-learn.pl}'
qvm-run --pass-io disp16 'cat {sudo tcpdump -vni eth0 port 53 or icmp | perl ./firewall-learn.pl}'
getting more errors.
Fact is I cannot invent nothing. One should understand what is doing and I am not.
Best
Fran
Steve Coleman
Jul 26, 2016, 10:34:50 AM7/26/16
to qubes-users
Another hack to avoid having to manually type in the addresses is done
with the attached script. Its like Mareks solution, but does the parsing
on the dom0 side and the syntax is a little easier. It does the remote
tcpdump command in the vm and the results are returned through the
pass-io mechanism. With the -A option the script then generates the
qvm-firewall add commands to its stdout.
Then, if you want to add that address to the firewall you simply copy
and paste the lines you want from that dom0 command terminal window into
another dom0 command window, and the address is added to the firewall
without any manual typing. If you want, you can add a netmask (e.g.
address/24) to an IP in the target window before pressing enter.
[user@dom0 ~]$ qvm-fwdenied -A <MyVmName>
qvm-firewall <MyVmName> -add
ec2-54-200-125-198.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add 104.244.43.140 any
qvm-firewall <MyVmName> -add 104.244.43.44 any
qvm-firewall <MyVmName> -add
ec2-54-148-80-75.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add
ec2-52-88-118-150.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add
ec2-52-25-189-162.us-west-2.compute.amazonaws.com any
...
Note that these appear in batches on the console because tcpdump is in a
mode where it exits after some number of captured packets have been
filtered, with the default set to 200 packets. By default it will
repeatedly restart tcpdump for another batch. The -C ### option allows
that default number of packets to be changed.
It would be far better if the script was made to be multi-threaded so
the output of tcpdump could be read while another thread outputs the
commands and asks the user if each entry should be added or not. I just
have not had time to look into that yet. its obviously a work in progress.
Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to look
at what happened in your last session.
On 07/25/2016 02:14 PM, Franz wrote:
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
with the attached script. Its like Mareks solution, but does the parsing
on the dom0 side and the syntax is a little easier. It does the remote
tcpdump command in the vm and the results are returned through the
pass-io mechanism. With the -A option the script then generates the
qvm-firewall add commands to its stdout.
Then, if you want to add that address to the firewall you simply copy
and paste the lines you want from that dom0 command terminal window into
another dom0 command window, and the address is added to the firewall
without any manual typing. If you want, you can add a netmask (e.g.
address/24) to an IP in the target window before pressing enter.
[user@dom0 ~]$ qvm-fwdenied -A <MyVmName>
qvm-firewall <MyVmName> -add
ec2-54-200-125-198.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add 104.244.43.140 any
qvm-firewall <MyVmName> -add 104.244.43.44 any
qvm-firewall <MyVmName> -add
ec2-54-148-80-75.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add
ec2-52-88-118-150.us-west-2.compute.amazonaws.com any
qvm-firewall <MyVmName> -add
ec2-52-25-189-162.us-west-2.compute.amazonaws.com any
...
Note that these appear in batches on the console because tcpdump is in a
mode where it exits after some number of captured packets have been
filtered, with the default set to 200 packets. By default it will
repeatedly restart tcpdump for another batch. The -C ### option allows
that default number of packets to be changed.
It would be far better if the script was made to be multi-threaded so
the output of tcpdump could be read while another thread outputs the
commands and asks the user if each entry should be added or not. I just
have not had time to look into that yet. its obviously a work in progress.
Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to look
at what happened in your last session.
On 07/25/2016 02:14 PM, Franz wrote:
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>> wrote:
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
R.B.
Jul 26, 2016, 11:52:15 AM7/26/16
to Franz, Marek Marczykowski-Górecki, Steve Coleman, qubes-users
> <mailto:rebo...@reboli.nl>> wrote:
>
shortened a bit...
>
> Hi Franz,
>
> The way I use it:
>
> - Make sure Marek's perl script is in the vm you want to monitor.
> Preferably in /home/user.
> - Make sure the firewall is set to "Deny network access except..."
> by default.
> - Open a terminal in Dom0.
> - Enter the command:
> qvm-run --pass-io YourVM 'sudo tcpdump -vni eth0 port 53 or icmp |
> perl ./firewall-learn.pl <http://firewall-learn.pl>'
Hi Franz,
I tried it your way and it won't give immediate results. Looks like some
bucket of 262144 bytes has to be filled with enough packets before
tcpdump passes the data. After some effort requesting for a site
repeatedly, the buffer gets dumped.... finally ;-)
Could not find a quick way to remedy this though.
Greetings,
RB
>
shortened a bit...
>
> Hi Franz,
>
> The way I use it:
>
> - Make sure Marek's perl script is in the vm you want to monitor.
> Preferably in /home/user.
> - Make sure the firewall is set to "Deny network access except..."
> by default.
> - Open a terminal in Dom0.
> - Enter the command:
> qvm-run --pass-io YourVM 'sudo tcpdump -vni eth0 port 53 or icmp |
>
>
> Thanks for the example, this goes a little more, in dom0 I reach the step:
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
>
> but then instead of
> qvm-firewall -a debian-8-multimedia-dvm 104.20.30.3 tcp 443 that I get
> on dispVM terminal
>
> I get nothing more appearing on Dom0 terminal.
>
> On the other hand if I try to use Marek suggestion adding "cat" with
> something like
> qvm-run --pass-io disp16 'cat sudo tcpdump -vni eth0 port 53 or icmp |
> perl ./firewall-learn.pl <http://firewall-learn.pl>'
>
> Thanks for the example, this goes a little more, in dom0 I reach the step:
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
>
> but then instead of
> qvm-firewall -a debian-8-multimedia-dvm 104.20.30.3 tcp 443 that I get
> on dispVM terminal
>
> I get nothing more appearing on Dom0 terminal.
>
> On the other hand if I try to use Marek suggestion adding "cat" with
> something like
> qvm-run --pass-io disp16 'cat sudo tcpdump -vni eth0 port 53 or icmp |
Hi Franz,
I tried it your way and it won't give immediate results. Looks like some
bucket of 262144 bytes has to be filled with enough packets before
tcpdump passes the data. After some effort requesting for a site
repeatedly, the buffer gets dumped.... finally ;-)
Could not find a quick way to remedy this though.
Greetings,
RB
Franz
Jul 26, 2016, 6:25:16 PM7/26/16
to Steve Coleman, qubes-users
On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman <Steve....@jhuapl.edu> wrote:
Another hack to avoid having to manually type in the addresses is done with the attached script. Its like Mareks solution, but does the parsing on the dom0 side
I understand this means this script should be executed directly in dom0, but isn't this a security problem?
--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d154763d-ce5f-e02c-dee6-481ec0d4b02c%40jhuapl.edu.
R.B.
Jul 27, 2016, 4:35:47 PM7/27/16
to Franz, Steve Coleman, qubes-users
On 07/27/2016 12:25 AM, Franz wrote:
>
>
> On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
> <Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
>
> Another hack to avoid having to manually type in the addresses is
> done with the attached script. Its like Mareks solution, but does
> the parsing on the dom0 side
>
>
> I understand this means this script should be executed directly in dom0,
> but isn't this a security problem?
Let's see... In this use case we have a "new" vm we want to give a
>
>
> On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
> <Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
>
> Another hack to avoid having to manually type in the addresses is
> done with the attached script. Its like Mareks solution, but does
> the parsing on the dom0 side
>
>
> I understand this means this script should be executed directly in dom0,
> but isn't this a security problem?
filter. So, you fire up the vm and start the script from Dom0.
Then you start your browser and visit the site you want it to work with.
At first it will be dns requests originating from the browser and
answers from you dns server.
The risks here are malformed packets that could trip either tcpdump or
python (in this case). To me, it is very unlikely this could result in
an advanced persistent threat (APT) in Dom0.
Nevertheless, running full streams back-and-forth through any program
like tcpdump with a --pass-io to Dom0 can be considered a possible hazard.
In short: As a way to test what you need to communicate with your bank,
while only dns or icmp packets are considered - like in the tcpdump
example of Marek, it should be OK.
Use it with care.
Greetings,
RB
>
>
> and the syntax is a little easier. It does the remote tcpdump
> command in the vm and the results are returned through the pass-io
> mechanism. With the -A option the script then generates the
> qvm-firewall add commands to its stdout.
>
> Then, if you want to add that address to the firewall you simply
> copy and paste the lines you want from that dom0 command terminal
> window into another dom0 command window, and the address is added to
> the firewall without any manual typing. If you want, you can add a
> netmask (e.g. address/24) to an IP in the target window before
> pressing enter.
>
> [user@dom0 ~]$ qvm-fwdenied -A <MyVmName>
> qvm-firewall <MyVmName> -add
> ec2-54-200-125-198.us-west-2.compute.amazonaws.com
> qvm-firewall <MyVmName> -add 104.244.43.140 any
> qvm-firewall <MyVmName> -add 104.244.43.44 any
> qvm-firewall <MyVmName> -add
> ec2-54-148-80-75.us-west-2.compute.amazonaws.com
> <http://ec2-54-148-80-75.us-west-2.compute.amazonaws.com> any
> qvm-firewall <MyVmName> -add 104.244.43.44 any
> qvm-firewall <MyVmName> -add
> ec2-54-148-80-75.us-west-2.compute.amazonaws.com
> qvm-firewall <MyVmName> -add
> ec2-52-88-118-150.us-west-2.compute.amazonaws.com
> <http://ec2-52-88-118-150.us-west-2.compute.amazonaws.com> any
> qvm-firewall <MyVmName> -add
> ec2-52-25-189-162.us-west-2.compute.amazonaws.com
> <http://ec2-52-25-189-162.us-west-2.compute.amazonaws.com> any
> ...
>
> Note that these appear in batches on the console because tcpdump is
> in a mode where it exits after some number of captured packets have
> been filtered, with the default set to 200 packets. By default it
> will repeatedly restart tcpdump for another batch. The -C ### option
> allows that default number of packets to be changed.
>
> It would be far better if the script was made to be multi-threaded
> so the output of tcpdump could be read while another thread outputs
> the commands and asks the user if each entry should be added or not.
> I just have not had time to look into that yet. its obviously a work
> in progress.
>
> Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to
> look at what happened in your last session.
>
>
> On 07/25/2016 02:14 PM, Franz wrote:
>
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
>
> Note that these appear in batches on the console because tcpdump is
> in a mode where it exits after some number of captured packets have
> been filtered, with the default set to 200 packets. By default it
> will repeatedly restart tcpdump for another batch. The -C ### option
> allows that default number of packets to be changed.
>
> It would be far better if the script was made to be multi-threaded
> so the output of tcpdump could be read while another thread outputs
> the commands and asks the user if each entry should be added or not.
> I just have not had time to look into that yet. its obviously a work
> in progress.
>
> Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to
> look at what happened in your last session.
>
>
> On 07/25/2016 02:14 PM, Franz wrote:
>
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com>>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com>>> wrote:
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek
> Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek
> Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/d154763d-ce5f-e02c-dee6-481ec0d4b02c%40jhuapl.edu.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> https://groups.google.com/d/msgid/qubes-users/d154763d-ce5f-e02c-dee6-481ec0d4b02c%40jhuapl.edu.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> 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...@googlegroups.com
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAPzH-qAOek%2BGoWcy%3DtrgDTM9kiu10iUDg1%3D0r6c4xJ1iu%3DFFAg%40mail.gmail.com
> <https://groups.google.com/d/msgid/qubes-users/CAPzH-qAOek%2BGoWcy%3DtrgDTM9kiu10iUDg1%3D0r6c4xJ1iu%3DFFAg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Franz
Jul 28, 2016, 3:38:25 PM7/28/16
to R.B., Steve Coleman, qubes-users
On Wed, Jul 27, 2016 at 5:35 PM, R.B. <rebo...@reboli.nl> wrote:
On 07/27/2016 12:25 AM, Franz wrote:
On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
<Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
Another hack to avoid having to manually type in the addresses is
done with the attached script. Its like Mareks solution, but does
the parsing on the dom0 side
I understand this means this script should be executed directly in dom0,
but isn't this a security problem?
Let's see... In this use case we have a "new" vm we want to give a filter. So, you fire up the vm and start the script from Dom0.
Then you start your browser and visit the site you want it to work with. At first it will be dns requests originating from the browser and answers from you dns server.
The risks here are malformed packets that could trip either tcpdump or python (in this case). To me, it is very unlikely this could result in an advanced persistent threat (APT) in Dom0.
Nevertheless, running full streams back-and-forth through any program like tcpdump with a --pass-io to Dom0 can be considered a possible hazard.
In short: As a way to test what you need to communicate with your bank, while only dns or icmp packets are considered - like in the tcpdump example of Marek, it should be OK.
Use it with care.
I tried to do that, but on the way I was too frightened to do something wrong, so stopped. But found an easier way:
Run Marek script
https://gist.github.com/marmarek/1d0a296930b7784327aaf9a801ec5585
into the applVM that tries to connect to the net, but cannot because the firewall is manually set to "Deny network access except...". Then copy the result into a file in the same applVM.
https://gist.github.com/marmarek/1d0a296930b7784327aaf9a801ec5585
into the applVM that tries to connect to the net, but cannot because the firewall is manually set to "Deny network access except...". Then copy the result into a file in the same applVM.
then from Dom0 terminal wrote:
qvm-run --pass-io appl-VM-name 'cat path to just-created-file'
This makes all the firewall setting to appear directly on Dom0 terminal. It is enough to copy all of them and past them on the same terminal and it is done.
This seems safer for one like me that does not know what he is doing.
The most surprising thing is that it works, the applVM can really connect through the selected addresses.
Best
Best
Fran
Desobediente
Jul 28, 2016, 4:01:58 PM7/28/16
to qubes-users
I'd like to add that I also use CIDR notation for the firewall rules, in addition to the name rules, and it works in most cases.
Sometimes some services change their addresses, but the time consumed to add new entries is not relevant.
I use the 'dig' tool to find out in which block they are. Some of them use a whole /24 block. But most of time that's too many addresses, and would lead to unblock totally unrelated stuff:
$ dig service.example.com
Steve Coleman
Jul 28, 2016, 6:56:43 PM7/28/16
to qubes-users
On 07/26/2016 06:25 PM, Franz wrote:
>
>
> On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
> <Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
>
> Another hack to avoid having to manually type in the addresses is
> done with the attached script. Its like Mareks solution, but does
> the parsing on the dom0 side
> I understand this means this script should be executed directly in dom0,
> but isn't this a security problem?
Yes, there is one risk I know. If the VM that had been firewalled off
>
>
> On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
> <Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
>
> Another hack to avoid having to manually type in the addresses is
> done with the attached script. Its like Mareks solution, but does
> the parsing on the dom0 side
> I understand this means this script should be executed directly in dom0,
> but isn't this a security problem?
from the Internet has already been 0wned, then the hacker could replace
the tcpdump utility with something that passes a ";" back withing the ip
address field and has a shell command after that. DNS could be hacked,
or a man in the middle could do it too. Then that ";" in the field might
then get parsed by the python script and passed to the command line
where the qvm-firewall command is invoked with the bogus IP/hostname,
thus executing something nefarious in the dom0 shell. All that would be
needed to correct this flaw is a little sanitation of the IP/host
parameter, proper detection of that hack-attack, and that problem is
solved, except that your VM was rooted.
That being said the script is only a work in progress shared for input,
and if your VM is already 0wned then you already do have a real problem.
Firewalling the VM off obviously is too little too late. Detection then
becomes key to resiliency and recovery. The one problem I have with this
architecture in general is that detection of an attack is not an
inherent feature of the overall design. Ideally I would want something
like an selinux targeted policy in each VM, generating avc messages,
that would then be forwarded by the kernel in realtime and then somehow
feeding a central intrusion monitor which could then notify the owner
when important system resources are being tampered with. Before that
tampering leads to a full scale system circumvention. Perhaps just
monitoring a checksum on the copy-on-write system image? or just detect
a page write back to the cow? Whatever it is it needs to be realtime and
not easily interceptable by the adversary considering they already have
root in at least one VM.
As in the above example, if you knew that your tcpdump executable had
just been replaced, before you locked down your firewall on that VM,
then you would have a much better chance at getting your system back
under your own control before they can start attacking the hypervisor.
Without knowing if your system is hacked or not can you really feel
safe? I don't feel unsafe, but I do feel blind. Don't get me wrong,
qubes is a *beautiful* design, I love it and use it daily and tell
*everyone* about it, its just that prevention of a hack only takes you
so far. Application level protocol attacks that bypass network
restrictions are way too easy, and too numerous, so system level
detection can be equally important. This is because there are people out
there that do this for a living. You really don't want to be their
target, but if for some reason you are, you _really_ need to detect that
they have arrived. Its nice when you can tell if someone is jiggling
your doorknob or not. Detection doesn't always work, but neither does
system software. It absolutely needs to be a multilayered solution to be
resilient.
best regards.
> and the syntax is a little easier. It does the remote tcpdump
> command in the vm and the results are returned through the pass-io
> mechanism. With the -A option the script then generates the
> qvm-firewall add commands to its stdout.
>
> Then, if you want to add that address to the firewall you simply
> copy and paste the lines you want from that dom0 command terminal
> window into another dom0 command window, and the address is added to
> the firewall without any manual typing. If you want, you can add a
> netmask (e.g. address/24) to an IP in the target window before
> pressing enter.
>
> [user@dom0 ~]$ qvm-fwdenied -A <MyVmName>
> qvm-firewall <MyVmName> -add
> ec2-54-200-125-198.us-west-2.compute.amazonaws.com
> qvm-firewall <MyVmName> -add 104.244.43.140 any
> qvm-firewall <MyVmName> -add 104.244.43.44 any
> qvm-firewall <MyVmName> -add
> ec2-54-148-80-75.us-west-2.compute.amazonaws.com
> <http://ec2-54-148-80-75.us-west-2.compute.amazonaws.com> any
> qvm-firewall <MyVmName> -add 104.244.43.44 any
> qvm-firewall <MyVmName> -add
> ec2-54-148-80-75.us-west-2.compute.amazonaws.com
> qvm-firewall <MyVmName> -add
> ec2-52-88-118-150.us-west-2.compute.amazonaws.com
> <http://ec2-52-88-118-150.us-west-2.compute.amazonaws.com> any
> qvm-firewall <MyVmName> -add
> ec2-52-25-189-162.us-west-2.compute.amazonaws.com
> <http://ec2-52-25-189-162.us-west-2.compute.amazonaws.com> any
> ...
>
> Note that these appear in batches on the console because tcpdump is
> in a mode where it exits after some number of captured packets have
> been filtered, with the default set to 200 packets. By default it
> will repeatedly restart tcpdump for another batch. The -C ### option
> allows that default number of packets to be changed.
>
> It would be far better if the script was made to be multi-threaded
> so the output of tcpdump could be read while another thread outputs
> the commands and asks the user if each entry should be added or not.
> I just have not had time to look into that yet. its obviously a work
> in progress.
>
> Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to
> look at what happened in your last session.
>
>
> On 07/25/2016 02:14 PM, Franz wrote:
>
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
>
> Note that these appear in batches on the console because tcpdump is
> in a mode where it exits after some number of captured packets have
> been filtered, with the default set to 200 packets. By default it
> will repeatedly restart tcpdump for another batch. The -C ### option
> allows that default number of packets to be changed.
>
> It would be far better if the script was made to be multi-threaded
> so the output of tcpdump could be read while another thread outputs
> the commands and asks the user if each entry should be added or not.
> I just have not had time to look into that yet. its obviously a work
> in progress.
>
> Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to
> look at what happened in your last session.
>
>
> On 07/25/2016 02:14 PM, Franz wrote:
>
>
>
> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com>>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com>>> wrote:
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek
> Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> <mailto:marm...@invisiblethingslab.com
> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek
> Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com
> <mailto:marm...@invisiblethingslab.com>
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/d154763d-ce5f-e02c-dee6-481ec0d4b02c%40jhuapl.edu.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> https://groups.google.com/d/msgid/qubes-users/d154763d-ce5f-e02c-dee6-481ec0d4b02c%40jhuapl.edu.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> 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...@googlegroups.com
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAPzH-qAOek%2BGoWcy%3DtrgDTM9kiu10iUDg1%3D0r6c4xJ1iu%3DFFAg%40mail.gmail.com
> <https://groups.google.com/d/msgid/qubes-users/CAPzH-qAOek%2BGoWcy%3DtrgDTM9kiu10iUDg1%3D0r6c4xJ1iu%3DFFAg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Franz
Jul 28, 2016, 8:45:08 PM7/28/16
to Steve Coleman, qubes-users
On Thu, Jul 28, 2016 at 8:00 PM, Steve Coleman <Steve....@jhuapl.edu> wrote:
On 07/26/2016 06:25 PM, Franz wrote:
On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
<Steve....@jhuapl.edu <mailto:Steve....@jhuapl.edu>> wrote:
Another hack to avoid having to manually type in the addresses is
done with the attached script. Its like Mareks solution, but does
the parsing on the dom0 side
I understand this means this script should be executed directly in dom0,
but isn't this a security problem?
Yes, there is one risk I know. If the VM that had been firewalled off from the Internet has already been 0wned, then the hacker could replace the tcpdump utility with something that passes a ";" back withing the ip address field and has a shell command after that. DNS could be hacked, or a man in the middle could do it too. Then that ";" in the field might then get parsed by the python script and passed to the command line where the qvm-firewall command is invoked with the bogus IP/hostname, thus executing something nefarious in the dom0 shell. All that would be needed to correct this flaw is a little sanitation of the IP/host parameter, proper detection of that hack-attack, and that problem is solved, except that your VM was rooted.
That being said the script is only a work in progress shared for input, and if your VM is already 0wned then you already do have a real problem. Firewalling the VM off obviously is too little too late. Detection then becomes key to resiliency and recovery. The one problem I have with this architecture in general is that detection of an attack is not an inherent feature of the overall design. Ideally I would want something like an selinux targeted policy in each VM, generating avc messages, that would then be forwarded by the kernel in realtime and then somehow feeding a central intrusion monitor which could then notify the owner when important system resources are being tampered with. Before that tampering leads to a full scale system circumvention. Perhaps just monitoring a checksum on the copy-on-write system image? or just detect a page write back to the cow? Whatever it is it needs to be realtime and not easily interceptable by the adversary considering they already have root in at least one VM.
As in the above example, if you knew that your tcpdump executable had just been replaced, before you locked down your firewall on that VM, then you would have a much better chance at getting your system back under your own control before they can start attacking the hypervisor. Without knowing if your system is hacked or not can you really feel safe? I don't feel unsafe, but I do feel blind. Don't get me wrong, qubes is a *beautiful* design, I love it and use it daily and tell *everyone* about it, its just that prevention of a hack only takes you so far. Application level protocol attacks that bypass network restrictions are way too easy, and too numerous, so system level detection can be equally important. This is because there are people out there that do this for a living. You really don't want to be their target, but if for some reason you are, you _really_ need to detect that they have arrived. Its nice when you can tell if someone is jiggling your doorknob or not. Detection doesn't always work, but neither does system software. It absolutely needs to be a multilayered solution to be resilient.
Joanna wrote in the past something like that it is impossible to identify an attack and for this reason we should focus so much on prevention. I have personally no idea, but this goes beyond the purpose of this thread. Perhaps you should start a new thread to properly support your ideas.
Best
Fran
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/db98a901-36cf-6fce-fc30-74b8afa95dce%40jhuapl.edu.
Andrew David Wong
Jul 29, 2016, 1:18:51 PM7/29/16
to qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-07-24 16:22, Andrew David Wong wrote:
> But if anyone has a better solution, I'm all ears.
>
I appreciate all the alternative suggestions. It's always nice to have
> But if anyone has a better solution, I'm all ears.
>
multiple options for achieving the same effect, but I'm struggling to see why
I should switch from my current method (which seems to work fine for me) to
one of the other proposed methods (which seem more complicated to me). It's
quite possible I'm missing something. So, which of these many methods is
better (more secure, more reliable, etc.), and why?
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
ctqIeowBENekv/jubdgOzZcLL1alUoRky1r1xUXF4bZk9V3DePS/W0NKrEQzc/Ip
IFRfQUy1+eoDxrJkYkz++es1SiIy/jWR9MkqkUcDbxWQDHQKX5LQk/6aiQG7fHvT
8eER5KYDOxAbuVl6sWQrgf6SG5feOGmKP1jznwfzrT3KhCFlJB79kikh2S0SoaIZ
jAgwOpJf6x/hpcjISSKLAQ/hDJyBw8qj6A9siwEoIILx+j9bFT0bK1kqz3b8npYP
OaaOzuWHbVFgPsCJkai6j/wKXIeGEM4caFrGpCssLJFDLadABkKFpcpKv561Xt5m
G7p5BD6RFXiPi9rgnuqBI9qLSS4MJfn+ES4l2GJdB1hCnd+o9N0XugZouc1fEEXk
Qx3qOd0VsBpgUDCHfl+juAYh6yNUCrF8RubvcltGZVy8oW0aE/0utXlbnkkle8SA
hdziRvpdBlr20kVyhZbZiUlgyaEkBBsbXPfsfQNnIOzwt8nuNEUmcFQQeHuwO2TF
lYMPgyJhAfVhJjuUYjDZMwYEVBTtnCVEtH47c4rdRCvCzOCMQoixg1NWxQPx9ntc
yDtV2Jh7wPlvKWtRh6DsNFBGrvUI/LXjRwlgLwlGrct5BJt33/We9Sdr1iZVrRZS
CrC0SrbQbbBQJ55KKxoT
=dOfF
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages