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:
https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html
The system in qubes I vision would look as follows:
- 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 matrix.org 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.
