On 07/26/2016 06:25 PM, Franz wrote:
On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman
<[email protected] <mailto:[email protected]>> 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.
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
<http://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
<http://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
<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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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 <
> [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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 <
> > > [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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.
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?
- --
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
iQEcBAEBCAAGBQJXllGTAAoJENuP0xzK19cswBgH/A0OxAIaR7hzEfET8uAcNeiC
IjTNevVwL/z1ymB4HLwdQmOi3AQ5q8db/AoMd37AC06yzxEJkEQzt5HsMbnEK4UI
SFlKbKr5t7/eyK9R7B6dQH2dBL69ODZf8wQWl5T3oEJj3cZOCLOkAQZcjNHgPefU
AX2cKoi3q7TLxy810f08o+KicA2VclBA5Q66tf6GSoFG44VWfBtxZgkHTZ/s9aWW
cUvNfHIZtSZNiIOEJKLHP3y7tLAFZXOvdtIqIo2/jxWIJSc+47ypPxpOSiAdiA79
erUry7spy9ta5GNlblBf5fSGaQaYRBeEGl91+b++pX/zTg1/sMbv3hoCFpVHYnI=
=XmDi
-----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]
<mailto:qubes-users%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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.
--
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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>.
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 [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/db98a901-36cf-6fce-fc30-74b8afa95dce%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
