On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki < [email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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 < > > [email protected]> wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > On Mon, Jul 25, 2016 at 09:37:10AM -0400, Steve Coleman wrote: > > > > 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 < > [email protected] > > > >: > > > > > > > > > > > > > > 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: > > > > > > > > > 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. > > > > > > 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). > > > > > > > > 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? > > Currently no. > > > 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? > 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 > > iQEcBAEBCAAGBQJXlj1VAAoJENuP0xzK19cstjMH/0gXfr2o8GfIZEcdogZd0KbR > or+K3CNtjalGTkouEfcpOPS4tCXxIreTeS2la9skTnHzlSDu47iL1SFuUNt8RXqb > 900oVx4/iJpm2iOy5lqps24Br/ZUsiLlX6XNSpQoCF9bima3wI5u/H1HtV98Gv6G > /ll6wu6axRQfasrhX1KMyq/nsQxlpVyc/rW2sDd5uSlobQdg0xgflxL2G+ndPS69 > Sd3YWwzynKQVNt57oi+Kajizv6M+5fevpWZ/Zi4Tngnm8ZZNmEEuhFvhy7Gh07uJ > mxsql7qJ11BQkYHMtt0ql54RvCuA6EQeSHO/T4gUg1uaQZvPuf1LLdPwRJD5eGs= > =RXdc > -----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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPzH-qB20AMKpcTTy9vP%2ByC_0ZaQF-CJYFfj22_jG%3Dssn3h%2BeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
