@unman, I have seen in your notes that you run openbsd netvm, Do you still do the same?
If yes Why not to integrate it in default Qubes installation?
1 Like
I do still use this configuration.
There are two reasons not to integrate as default:
- hardware support
- user support - users (many new to Linux) seem to have enough trouble
coping with Fedora/Debian netvm without throwing BSD in to the mix.
Have you got a link to these notes? I’d be quite interested in how this
is configured.
Problem is I was not able to run openbsd as HVM at all yet. I haven’t figured out networking part in simple Openbsd hvm although I was able to run Windows as HVM.
So no option to progress on this guide.
Make a try and if possible create some guide for persons who are not very competent in tech stuff.
1 Like
I was thinking more along the lines of being much more easily targetable via your ISP IP address (since that’s usually directly linked to you) than via VPN/Tor, since attacking you through those channels requires a lot more observation and planning (e.g. figuring out where the traffic exits and sending things your way that you might or might not open or placing things on sites that you trust). I think the term for the ISP one is ‘directed drive-by attacks’.
This is where my lack of formal training in infosec begins to show–I know that vulnerabilities are exploited by malware via exploit(s), but have never thought of exploits as single items akin to malware in independence. Are they what scripts are to programs? Why would sophisticated actors use exploits instead of malware that includes them (aside from cost of development), especially if standalone exploits are more easily detectable, which puts the investment at risk?
This reminds me of ‘the most secure computer on the planet’ argument later in your post–a powerful exploit is worth a lot less if you can’t even use it on a bunch of muggles.
By community development I presume you mean being a constructive poster in forums? Since I think I’m already doing that, is there anything else I can help with?
This sounds like something that’d tide me over until a unikernel hopefully comes. Maybe this will spawn a thread on how to use openBSD as netVM. Thanks for bringing this up.
@unman are there any critical pitfalls to avoid when configuring an openBSD netVM? Like, what might a newbie to openBSD misconfigure that might lead to them being even more vulnerable than using Linux?
“Community development” usually refers to writing code and submitting patches/PRs to the Qubes codebase. However, there are a also a lot of other ways to help. 
This is where my lack of formal training in infosec begins to show–I know that vulnerabilities are exploited by malware via exploit(s), but have never thought of exploits as single items akin to malware in independence. Are they what scripts are to programs? Why would sophisticated actors use exploits instead of malware that includes them (aside from cost of development), especially if standalone exploits are more easily detectable, which puts the investment at risk?
That’s not a bad way to think about it, but there is some more depth.
Malware has to be delivered somehow. Complex malware which uses
spohisticated obfuscation and hiding techniques is usually a secondary
or tirtary payload. Something has to get onto the system in the first
place to download and execute it. This “something” is the exploit and
it’s shellcode. By virtue of the fact that it is first and the target
computer does not want to run it, the exploit often cannot contain any
sophisticated anti-detection techniques. Most of the time, it is an
otherwise legitimate packet or file, which happens to contain something
which will trigger the invalid program state.
While it is possible to do some obfuscation, you are limited by what the
machine on the other hand can interpret.
This reminds me of ‘the most secure computer on the planet’ argument later in your post–a powerful exploit is worth a lot less if you can’t even use it on a bunch of muggles.
This is exactly the case, but the other question to ask is why target
the “muggles”?By community development I presume you mean being a constructive poster in forums? Since I think I’m already doing that, is there anything else I can help with?
Andrew’s comment (and example) answer this, but I was meaning helping to
bring people together around the issue, motivating those with technical
skills to solve the problem.
1 Like
Ah so it’s the spearhead/point-man/vanguard who has to lower the castle drawbridge to let the actual raiding party in, so he has to stay lightweight. Thanks for taking the time to educate me on this.
By ‘muggle’ I’m referring to people who are not trained in infosec and not protected by those who are trained. There are plenty of these people with valuable information worth stealing (business executives, politicians, journalists, even software engineers).
Sounds good. So I’ll just keep doing what I’ve been doing. I might work on overhauling (or just editing) the documentation simply because I think good documentation and education provides the most bang for the buck (in my case, zero bucks) in terms of accessibility.
My solution WAS anonsurf in sys-net. It uses pandora to clean memory and other apps. You start it and stop ip.
I did not bother to switch to the new version:
You can even use the old Kali anonsurf on github!
I use sys-net in PV mode, which increases the attack surface even more. Not willingly, but because my components force me to.
Qubes is designed under the assumption that sys-net is already compromised, which is why it’s untrusted from the start. However, there are things you can do right now to improve security further:
- Make it a DisposableVM.
- Pause it or shut it down when performing sensitive operations in other VMs (to mitigate speculative execution zero day risk).
- As unman said, make sure nothing it doesn’t have access to any important plaintext, for example, by always using HTTPS when connecting to important websites.
7 Likes
I hope this is the right discussion to ask this:
-
Suppose that
sys-netis remotely compromised and the PCI network connection is attacked. Could this affect other components, such as the graphics cards, though the PCI? -
My understanding is that the compromise could be persistent even with a DisposableVM. Does this mean that the PCI firmware has been altered? Could this be automatically checked and fixed on boot (e.g. by rewriting the firmware)?
If an adversary compromised sys-net he could manipulate traffic on the fly, i.e. dns-queries. Any http traffic could be used to BeEF all AppVMs browsers.
I recommend at least to disable http-traffic in your AppVMs.
Another solution would be to encrypt all traffic, including DNS, going through sys-net (e.g. via VPN).
The easiest and most foolproof way to achieve this is by placing a firewall between your VPN VM and sys-net, and restricting traffic to VPN servers.
Note that this thread is nearly two years old, and some things have changed in the meantime. In particular, QSB-081 (perhaps in conjunction with other recent events) has prompted the devs to reconsider the way qubes like sys-net and sys-usb are handled.
Yes, I already use VPN. But I was asking about threats such as the XSA in your original post.
I guess it was not meant to be a response to my recent query. But just in case:
After doing some more reading it seems like my question about the remotely compromised PCI hardware could only affect the rest of the system through side-channel attacks, which I will have to read up on.
What about my question about persistence? Can compromised network PCI controller be repaired by reflashing its firmware?
I’d better buy a new one and preserve that for evidence.
1 Like
How well documented / realistic is this threat? So malicious firmware in the network controller creating a vector of persistence. How much could that undermine the sys-net compartmentalization framework, isn’t the network controller already treated as hostile? Seems likely in a TAO type setup.
Is setting the firewall rules in vpn-VM for the VPN ip’s not enough?
No one seen it in the wild yet. But it is realistic to certain degree.
1 Like