Attack Early Warning, Detection, Delay and Denial System (IDS) for the Eye of Sauron & Co

After suffering The Eye of Sauron’s laser-fiberic gaze including harassment by it’s fat sloppy hopelessly telegraphing Orcs and Nazgul with overly large comedic fake iphone earbuds obviously not connected to a duplex GSM device, I believe it’s time to develop an attack early warning detection, delay and denial system within qubes through the use of IDS, Honeytraps, firewall and good old fashioned evidence collection and response. As icing on the cake, it would be great to have meta-data and fingerprint awareness through the SIEM, but IDS first.

I believe it will take quite a bit of research and study, but it’s worth it to me to achieve building this system. I’m sure the research on the matter would benefit all.

Please tell me if you have experience with this type of setup I’m pondering. I have some experience with snort, but looks like I could benefit from host intrusion detection system as well, such as OSSEC.

I’m choosing OSSEC and Snort because they seem to be both compatible with stock qubes os install and stock templates. Whereas I know many love suricata and pfsense but that’s openbsd, which would be another OS for me to manage, which I cannot afford to adopt and manage and secure time wise.

After reading the below sourced blogpost which says; “HIDSs monitor the traffic and suspicious activity on the specific computer infrastructure they’re installed on. NIDSs, on the other hand, monitor network-based traffic and activity. Both systems work by surveying log and event messages the system generates, but NIDSs also examine packet data as information moves across a network. Another way the two forms of intrusion detection system differ is: NIDSs work more in real time, tracking live data for signs of tampering, while HIDSs check logged files for evidence of malicious activity. A solid security regimen will include both a HIDS and a NIDS, as they work together in a way meant to be complementary.”

Source: 8 Best HIDS Tools - Host-Based Intrusion Detection System - DNSstuff

It’s my understanding, please help me correct myself if I’m mistaken, snort will help me log and automate the network stuff and OSSEC will help me automate log parsing and alert me of threatening changes to my qubes system.

I’m choosing to learn more about OSSEC because I’ve read it does have compatibility and some documentation for xen server. I’ve also read that it’s basically compatible with anything through “agent installation”.

And for GUI or SIEM purposes I may later want to do SecurityOnion on top of all this for at a glance situational awareness. Does that sound right?

If you have experience with OSSEC could you kindly share what I should start looking into monitoring, which logs in qubes? And how would I do so in a way that keeps me from installing anything on dom 0? I’m guessing it would be best to mirror or send logs chosen for monitoring to it’s own appvm. A secure method of transfer which I’m not quite sure what is the best method to mirror logs while not exposing them?

My proposed attack early warning, delay, denial system would look like the following.

Following some ideas here Can Qubes protect user from backdoor, that resides in BIOS firmware and device driver? - #6 by Plexus

and here: Intrustion Detectors in dom0: bad idea? - #11 by tripleh

and here:

The system in qubes I vision would look as follows:

  1. Dom 0 → 1. XenServer Honeypot (Fake Dom 0) → 2. AppVms → 3.xx Many ASPs* <–> 4. OSSEC → 5.xx Many OpenVPN AppVMs (First Line of Defence) → 6. OpenWRT_Snort_KillSwitches-AppVM* (second line) → 7. External Coreboot_WRT_OVPN_Snort_OSSEC-PocketPC (third line) → 8. SecurityOnion_Read-Only_SIEM-LinuxPhone (later, nice to have, not critical.)

Xen Server Honeypot made to look like a QubesOS Dom 0 fingerprint with some seemingly interesting goodies that look like they come from a main storage device that stores appvm storage. Honeypot includes honeywall monitored by OSSEC to give alerts of adversary’s movements and collections to hopefully garner motives. Not sure if possible, but would be great to achieve automated counter-stealth-probing for fingerprinting and evidence collection for appropriate responses.

*ASPs = App Specific Firewalls: only allowing connections specific to the app requirements. For example a Matrix chat can only connect to servers and nothing else–DENIED ALL.

OSSEC monitoring agents hopefully if possible on all ASPs, Honeypot, Honeywall, WRT and external coreboot wrt-router with alert capabilities.

Many Inner OpenVPNs (proxyvm) for purpose based context specific compartmentalization.

*OpenWRT_Snort_KillSwitches-AppVM: I like the simplicity of OpenWRT, if possible as a second line of defence, would like this to reinforce the upstream openvpn proxy vm’s kill-switch capability, should this upstream device get exploited or just fail, as vpns and these so-called ‘killswitches’ always seem finnicy or leak some other fingerprintable meta-crap.

External coreboot pocket sized mini-computer running it’s own openwrt, snort, openvpn and OSSEC monitoring the entire qubes stack I just proposed for any changes. Since this is external, and I’m new to OSSEC, not sure how it would monitor securely without making log data a new security risk.

And finally an SecurityOnion_SIEM-LinuxPhone one day should I mass-deploy qubes for example in an office for all employees, it would be great to have awareness of that collection of assets in real-time. I mentioned earlier fingerprint awareness. This would be great to have real-time-statistics of ‘uniqueness’ and other meta-data leaks. Should I ever achieve an office with this setup in mass, I hereby dedicate all profits of that operation to QubesOS.

Please pick this apart. Destroy where you must. Prune where just. But please advise what I need to study, dive into, which courses, practice, who I need to talk to, which rocks I should look under etc. No matter the amount of time it takes. I’ve got the time and motivation to make this happen.

Thank you all.

So is that “fake dom0 honeypot” going to be real Xen? If yes, I believe you cannot detect the axis of evil with this setup, because HVM machines are not going to run Xen (nested Xen on Xen, essentially).

If you want that kind of setup, why not use KVM or VMWare and install real Qubes on that, and then use some (experimental) probing features to detect the Axis on your real hypervisor.

Not sure how well the Qubes behaves on nested virtualization though.

I’m working on some of the same concerns. Here are a few thoughts I’ve developed so far:

  • A VPN connection is an straight through tunnel to the terminating client VM. It might make more sense to “wrap” the terminus with firewall rules or maybe also setup the client VPN in a proxy.
  • I think OPNsense includes Suricata and it might be worth figuring out how to create a BSD VM.
  • I think OPNsense is a NIDS and OSSEC is a HIDS.
  • Either way, I found that Suricata has repos for Debian and Ubuntu.
  • Any thoughts on a SIEM server? Can Suricata handle that?
  • How to install and configure a firewall that serves all the AppVMS?
1 Like

What you seek is alot of work, too much for one individual (me mere mortal mind thinks).

Try to order what you seek by priority, what is the biggest ROI.

I have delayed the vpn-chains project - a multi-protocol highly-customisable chaining tool with advanced features to make alot of work for GPAs.

Keep it simple, stupid. So recently I realised I can probably make vpn-chains pretty quickly by just piggybacking off-of another project which is already multi-protocol, and using the qubes communications protocol with VMs to interact with this project, creating a simple logical UI in the admin/vpn-chains master VM to manipulate all these VMs.

I too have suffered the eye of sauron’s laser-fiberic gaze. One minute he has an umbrella, the next he’s walking down the road with a pram. (They really should learn not to use wireless comms though). I understand how you’re feeling brother.


NIDS = network IDS
HIDS = host-based IDS

The issue with Qubes & HIDS is that it would need to run in every VM which is rather performance intensive. A much better approach would be to run the HIDS in the hypervisor with access to VM memory etc. and out of reach for everything inside the VM, but unfortunately such projects are not very mature yet. Sometimes it also opens up new attack vectors.

The general issue with NIDS nowadays is that almost no reasonable attacker sends traffic over the network without encryption. You might capture a few “bad IP” connections or “bad DNS” requests, but that’s roughly it. You can also run IP or DNS blacklists for that. Big companies go for TLS “inspection”/MitM attacks on their employees for that very reason nowadays, but that usually pulls in a lot of TLS vulnerabilities for all users of that network…
Also the quality of hits highly depends on the installed signatures and the most up-to date ones will only be available for $$.
There should be a few blog posts on the Internet about Qubes & snort inside a proxy VM.

A NIDS alternative might be to go with basic netflow tracking and simple rules (IP whitelists or blacklists, unexpectedly long sessions, sessions at unexpected times, …) in combination with a custom DNS server.

1 Like

I’m making some progress on this, will post more soon.

Great questions, I’m share more thoughts soon, have you made any progress?

I will look into this.

And yes, I’ve started focusing on higher ROI first, but the full breath of the proposal could serve as being aspirational, with many features being “nice to have” for the future but not critical now.

Thank you, this is helpful, I can better focus my research.

Considering your flexi-chain (which I don’t understand fully yet, but will read more), can this faciliate VPN obfuscation? This is definitely a fingerprinting method in areas where VPN use isn’t widespread, followed up by physical eyes-on at the location of VPN use.

On a side topic, considering Sauron and thier Orcs, when they aren’t using voice comms, it took us awhile to figure this out, how they’d be able to pop up again at new locations when large distances were covered with many route changes at speed, and we’d see they didn’t have eyes-on for every route change, no cctv or drones as well, and nobody talking into their mics, because they didn’t have any, how they’d be able able to restablish the target with seemingly no comms and long delays of their visuals on the target. However in a moment of luck we were able to observe one of them on their smartphones screens while they were issuing commands. They are using an internal custom version of android ATAK, dropping pins of last known location of the target. This certainly seems to be more productive and elusive than screaming into a mic over public airwaves and running around to close gaps due to the delay and confusion caused simplex comms. Beware. Not yet sure what to do with this CI. But it’s obvious another vector with it’s own set of limitations.

I can talk more about the topic, but do not wish to spam the forums.
I tried to DM you via this forum but it said you ‘are not accepting messages’.

IDK if its because you are a new user or you have manually turned it off. I am happy to discuss in more detail, (in DMs/away from posts to avoid spam), the status of flexi-chains. (Some on the forums also use slack if you use that).

(@GateOfRanre )

There is a special category here for such discussions: All Around Qubes.

1 Like

Slack, what’s that? Sounds like something that would need an MD5 of my genome to sign up. :slight_smile:

Speaking of which should this topic be moved?

i’m not sure what him referring but i think that (don’t use that)

1 Like

The first post here looks to me specific to Qubes, since it discusses the inter-vm networking paths. Perhaps another topic can be created for less relevant stuff.

1 Like

There is only one to be dom0 with XEN.
And there is also dom -3
which is your friendly MINIX-OS, which you
got for free with your recent intel CPU, which also contains an older generation (i486, i586?) intel cpu running a ring to rule them all