The heavy lifting of this is CISA's Malcom [1]. Unfortunately the blog posts only provides a non-linked bullet to it [2]. Seth Grover, the main driver behind Malcom, put a lot of effort over the years into creating a turnkey soc-in-a-box distro that works especially well for an network-first approach. Endpoint isn't neglected, but the focus on Zeek, Suricata, Arkime shows the primary visibility drivers. This is not surprising, because CISA also developed a bunch of custom ICS protocol dissectors that provide visibility (DNP3, Modbus, etc.). The list is impressive [3]. All of this is turnkey available by running Malcom. Especially for OT, where we have a lot more unmanaged black boxes and networks that you don't wanna actively scan (factories have been brought down this way), passively watching is a safe and powerful approach.
It's a bit unfortunate that Kali didn't give the props to Seth's project (not even an outbound link). Perhaps this was just an oversight, or a spotlight blog post is coming later, but I hope that the history of this gets properly acknowledged, because it's darn clear where this comes from.
I'm a little confused as to running the Suricata, Zeek and the Elasticsearch stack on Kali. I think of these tools run on a server, rather than a desktop. And it seems like SecurityOnion scratches this niche.
I do like the idea of Kali Purple though - curious to check it out.
Yeah, very unusual. Purpleteam is usually over some prod or prod-like environment.
I think they want you to put this in your purpleteam lab not as your actual defensive stack.
Might work for some folks but imo, the logging/detection/alerting part should alway be your actual prod stack but you can simulate attacks in a lab environment. What I have seen in the industry at large is a lot of purpleteam excercises are done in production, a red team excercise blended with a blue team investigation and response.
From what I can tell they call it a soc in a box. They have a wiki on how you are supposed to build it (on proxmox). Here is a link to their architecture diagram for it.
https://gitlab.com/kalilinux/kali-purple/documentation/-/raw...
It is intended mostly for training purposes. I think it looks pretty neat for a start. We'll see where the community takes it over the next couple of years.
IMO this is lowering the barrier of entry to newbies. I work in this space and often users coming out of boot camps that want to set up their own labs for learning have a steep learning curve. Such is the difficulty with entering cybersecurity without an IT background, for better or worse.
Why are they calling it purple if it's really blue?
Also, elastic is one of the worst siems you can choose for threat hunting and analysis. The language is incredibly limited, the parsing is confusing, there's no no built in aggregations that make sense, you can only search over one set set of data at a time (no joins). And it's even more limited through the search bar in the kibana GUI. Lastly, it uses techniques that estimate data results for the sake of speed. It does not guarantee full accuracy when returning data.
Arkime full packet capture? Full packet capture relevance has faded greatly since the early 2010s due to encryption. It's all about host based logging like EDR, sysmon and windows event logs, while shored up by specific cloud-based app logs, or pulling forensic artifacts with osquery (or similar). People aren’t writing or looking at suricata rules much anymore, unless you're lucky enough to have an environment being proactively man in the middled, which is rare.
This is a pretty interesting distro, but don't expect to be up to date with modern threat hunting, soc analysis, incident response or threat detection. It could be a nice intro in college, but you'll want to get modern data sets into real siems or DBs asap.
The final thing I have to say is that purple team is not a set of tools. These are all blue teamer tools. Purple team is when a red teamer works directly with a blue teamer to create an attack and watch how the blue team systems and people react when it's happening. It's a drill that captures misses.
Arkime full packet capture? Full packet capture relevance has faded greatly
since the early 2010s due to encryption. It's all about host based logging like
EDR, sysmon and windows event logs, while shored up by specific cloud-based app
logs, or pulling forensic artifacts with osquery (or similar). People aren’t
writing or looking at suricata rules much anymore, unless you're lucky enough
to have an environment being proactively man in the middled, which is rare.
I have to disagree here. Meta data on an actual session is useful for statistical inference and can be used for pattern matching at a larger scale on the network. IP addresses and file hashes are going to change frequently and be abandoned so sending out block lists to all your EDR software is more reactionary than proactive. Malware delivery/interaction observation through session data such as protocol, packet size, timing can all be used as features for detection. Additionally Suricata rules can be stacked using flowbits to provide correlation and actionable alerting on observed traffic outside of just the payload, url, etc. Lastly, having a data point outside of the end point device within the network is useful in the event of an incident, after all how can you trust logs and events being reported from a system that has been compromised. Arkime also can utilize the eve.json log file from Suricata to tag the same observed traffic allowing you to search by SID. Exporting data is probably one of the bigger features as that allows you to aggregate and analyze the data externally in something like Jupyter notebook.
> Why are they calling it purple if it's really blue?
Because they plan to offer a purple team training/certification. Kali Linux isn't a $color security distribution, it is a set of open source security tools that act as the student environment for their exam. That is why they continue to devote paid engineer hours to developing it.
Well, at least if you're gonna bash on Elastic provide some alternatives, we are running Elastic as a SIEM ingesting millions of records per day all for free (albeit we are in the process of aquiring a licence).
In the defensive security space there is also Kicksecure[0], which serves as the base for Whonix (a hardened linux distro that tries to provide strong privacy/anonymity via the Tor network). They have a wiki that goes over the desktop hardening features and tweaks that go into it.
Why would the ISO for this be unbootable on vmware vsphere? I've verified the checksum that all looks good. Attaching it to a VM and setting it as connected on start up etc and it still cannot find a bookable device. Frustrating because I really wanted to try thos out. I set VM hardware to Linux Other 5.x 64-bit too.
vSphere 7u3k (both esxi and vcenter). And it was the ISO installer for Purple. I tried downloading both via torrent & direct, uploaded to datastore, attached to a newly created VM and nothing. I'll try attaching it to an already working Linux box and see if it shows up there to rule out environment issues if possible. I'll open a ticket as well. Thanks!
Does this distro have modern application sandboxing? For example, can I say which applications have access to my photos, email, location, microphone, etc...?
I've used Kali Linux quite a lot but, as a Linux user, I wouldn't recommend it to anyone who knows Linux. It's mainly good for:
1. Students studying an OffSec course (the creators / maintainers of Kali) as the course material is designed with Kali in mind.
2. Mac/Windows-using security professionals running Kali in a VM (or light/casual Linux users doing the same - i.e. users without a deep Linux knowledge/comfort*)
For anyone more Linux-savvy* I would recommend simply installing the tools Kali bundles that you want to use. It can be helpful to have Kali as a VM if you want to trial/explore the curated software library, but for professional use people typically start to get to know the set of tools they're comfortable with / interested in.
* Aside: for anyone surprised security-professionals wouldn't be Linux-savvy, knowledge is specialised. Even if you are working in Linux-specific security (& not just using Linux cli tooling to access MS networks or decompile MS binaries), areas of security focus can still be quite compartmentalised.
Yeah there are tons of people working in infosec that don't know or use any linux. IMHO they're doing themselves a disservice (both professioally and personally) but it is the reality that you can have a solid infosec career and never have to know linux.
Can confirm, as a security consultant I just use debian(ish) with an archlinux container (or sometimes VM) with all the stuff I need. This is far more sane for me than dealing with the bizarreness of kali. All my coworkers who are windows users are happy with it though.
I'm really grateful for distros like Kali / Parrot / Pentoo as they act as a (much more selectively) curated list of tooling akin to those "awesome lists" on Github, as well as being a rallying point for the maintenance of those same tools.
But yeah - the tools are available individually & this is how I typically use them.
Yes, this. Kali (purple or otherwise) is meant as a special-purpose toolset. It is not meant to be used as a regular Linux installation, and I strongly recommend that people don't use it as that.
If you have photos and personal stuff in a Kali installation you're doing it wrong, Kali isn't supposed to be a day to day OS, some time ago your default credentials were root, so yeah, they changed it some versions ago but still, that gives you a look as how it should be used.
EDIT: If you want a daily driver OS but need some Kali tools without installing it as a second boot or VM you can use the Kali Bundles which are repositories ordered by type of tools.
Yeah, it's an unfortunate titling of the HN post. Defensive means something different in this context - it's meant for people working within the defensive roles of an organization's infosec department.
Kali are a little to blame here for that confusion as well - "We are making enterprise grade security accessible" - is open to misinterpretation of what they are presenting.
>can I say which applications have access to my photos, email, location, microphone
Kali distros are not meant to be run bare metal as your daily driver, but as VMs.
They usually have very lax security setting as to not interfere with all the networking and security related apps provided. This makes them quite insecure by design versus mainstream distro like Ubuntu/Fedora. So don't put any personal data on them.
We always spin them up as disposable VMs in their own VLAN, and nuke them after every encounter is over.
Agreed on all points but this one; Occasionally I'll run it bare-metal on an SBC like a Raspberry Pi as a dropbox or similar, though the SD-Card gets nuked shortly afterwards so I guess it's treated in a very similar "disposable" way as VMs are.
I know that's being pedantic about your wording, but I thought it worthwhile mentioning that there are use-cases for it running outside of a VM.
Probably of less broad appeal but another option to add to the mix for anyone who happens to be running Gentoo is the Pentoo overlay https://github.com/pentoo/pentoo-overlay
The Github repo is also a nice browseable categorised directory tree of security tooling, including nice readable plaintext ebuild files listing the src urls for building each.
>Kali distros are not meant to be run bare metal as your daily driver,
Oh.
I was looking for something that had some radio stuff preconfigured, saw Kali was basically a xfce debian, and have been using it as a daily driver for years. Should I not do that?
Speaking as one daily driving Qubes, the opposite is true. Whenever I have problems with Linux, Qubes allows to backup and restore it in a few clicks. It doesn't matter that Qubes is not really Linux. It runs Linux apps fine.
It'll be very difficult getting most pentesting apps to work in a sandbox anyway. It was difficult enough to move away from root and a ton of things will still need sudo.
But it's ok, this is not the kind of distro where this matters. It's not for general work and targeted at users that really know what they're doing.
You think they can't be competitive because there was some awful code that briefly made it into their development branch and was promptly caught before it could be released? I'd agree that there's room to improve the review process, but it's hard to be too critical of a process by citing a successful case of it working.
OP has probably never run FreeBSD and is likely commenting about an article they read a while back. I’ve run a sever for years and it’s been rock solid. Hardware support is not as good as other BSDs. Most people dont jump on the release candidates and incorporate them into their products, like PFSense did. One big exception is Netflix.
Not to mention the developer who did that seems like an absolute piece of work.
> The Macys' attempts to force their tenants out included sawing through floor support joists to make the building unfit for human habitation, sawing holes directly through the floors of tenants' apartments, and forging extremely threatening emails appearing to be from the tenants themselves. The couple fled to Italy to avoid prosecution but were eventually extradited back to the US—where they pled guilty to a reduced set of felonies and served four years and four months each.
That's not entirely right, I did run FreeBSD for a while and understand why people value it. My current understanding is simple: the smaller audience allows for flaws to be overlooked through internal dynamics like social proof.
Like I said, I'm not an infosec guy, all I can refer to is a somewhat informed gut feeling. A comparatively small audience which is convinced that it belongs to the "good" group is inherently vulnerable, the article just made some of those dynamics visible.
FreeBSD doesn't have OVAL data, and invented their own crappy XML format and disclose vulnerabilities via mailing lists (without any automateable parseable format, because it's emails). [1]
OpenBSD's erratas are maintained as patch files that people would have to merge in themselves. Literally [2]
So yeah, I'd argue to use Arch over BSD anytime. They patch vulnerabilities upstream first, don't diverge in their packages from upstream when it comes to backports, and patch critical vulnerabilities within less than 24 hours on average, if they are patchable. [3] and [4]
Also, don't use Debian or Ubuntu. Security-wise they are a nightmare due to soooooo many wrongly labelled issues, where they put in "too diverged from upstream" and dozens of other freetext-labels as a reason to not fix critical RCEs. Impossible to maintain security-wise.
Linux obviously gets a lot more attention but it's also more fast with new features and possible exploits.
BSD maintainers are fast fixing known exploits but has the drawback of older tech like X11. Wayland works on FreeBSD but still doesn't work with KDE on it.
TBH Wayland is rocky on linux too from my experience. It's really hit or miss with applications especially electron ones. I think electron natively supports wayland without adding a flag now? The issue is most applications don't use that version yet. Both me and my friend installed wayland on a fresh arch install and we both had issues with random "black boxes" on electron applications.
Games are also very hit or miss.
IDK it's just felt very half baked. And this was with Gnome which my understanding should have very decent wayland support?
Interesting, I've been running Wayland (Fedora) for years now and the only issues I've ever had were application compatibility (rather than bugs). Screen sharing is the big one.
Which GPU do you have? Wayland on nvidia is definitely more buggy than wayland on AMD and Intel, so if you run nvidia that could definitely be a factor.
Indeed we both have 4090's so that might explain the issue.
It sucks that nvidia is more buggy in general on linux because they're currently the only realistic* option for working with a bunch of ML stuff.
* Yes ROCM is gaining support, but it's still trailing behind CUDA unfortunately and you can't beat the 4090/3090 for ML in the consumer range right now.
Even screen sharing is mostly solved now. I do it daily without issue on Fedora with Wayland.
The only thing concession I need to make is running Slack in a browser tab instead of the app, because the app comes with an older version of Electron.
Yes most electron apps can be replaced by their browser counterparts without loss of any feature and wayland works great on the browsers. I don't even understand why electron exists to be honest, there is no added value.
The fact you make it run within a browser don't mean you can't run it in a separate window.
The only good point I can think of is having a separate icon for the app in an alt+tab situation. But in my case I use the activities view on Gnome and usually view and recognize the window content. Also epiphany browser allows me to create "apps" with their own icon. Sadly not all of them work due to user agent nazism.
You are speaking of millions but I have yet to encounter one.
And I would say missing one feature I am unlikely to use is a small price to pay for more control of my privacy, advertising, telemetry, hardware and OS access.
Sway worked pretty well in general for me, except Zoom didn’t play nice with it at all. Zoom is bad, but then, I wouldn’t be using it if I wasn’t paid to use it.
But we were talking about security and there's no denying that X11's architecture has inherent security risks. You can cover this in other ways but security wise I do consider it a drawback.
However in most other ways I do prefer X over Wayland too.
Yes, the need to take extra steps to lock things down is the biggest downside. I'd love to see a replacement for X that retains X's feature set but that is more secure by default (and more performant would be nice).
The thing that keeps me off the Wayland train is that they are not intending to support X's remote features, which I use quite heavily. I'm unaware of any other way to do simultaneous independent remote DE logins.
Same here, I totally agree with you there. SSHing into a remote box and having a GUI app popping up on my local screen without any fiddling is just amazing.
It's not very performant because it was designed for local networks and relies on too many round-trips. NX fixes that but it's too fiddly.
Also you really need to trust your remote box because it'll be able to see and control all your screens. It can do this even without popping up any user visible windows so be careful. For this reason I don't blanket enable it, I just use the -Y parameter only when I need it.
But yes I'd love to see something that continues on this path and brings it into the 21st century.
For distros marketed as desktop alternatives to windows or mac, it means a lot, because most of those users are going to install and run it without changing much at all. Especially if it comes preinstalled on a budget laptop.
PlayStation 4 OS is based on FreeBSD, so it certainly has been eyeballed quite extensively. There have been numerous jailbreaks in the past, but I can't tell how many of those were due to FreeBSD itself or just regular webkit exploits.
I like Arkime (used to be called Moloch). My only pet peeve is that the documentation for the search bar is not separated from the tool. Their site docs tell you to go to the tool instead of just having the information mirrored. But for large scale pcap analysis that still lets me look at individual packet data.. it's my first choice.
anyone here using a mac have an issue downloading the iso and making a vm with vmware? every time i try to do so, i open up the vm and it stays on a black screen with a message stating, ">>start pxe over ipv4."
any solutions to fix this?
This looks really interesting. If nothing else, it lumps a lot of cool tools together so that I can research them! Also makes me think of building a proxmox datacenter at home just to play around.
or trueNAS Scale... any experience with that for hyperconverged labs?
TruNAS is nice but Ubuntu with KVM is a better bet. You can install root on ZFS these days and can have automatic snapshot including vms as sparsely allocated zvols
Isn't hyperconverged just when you put compute/storage/network/whatever in the same box(es) and virtualize it all together? There's no inherent scale to that, it's just a structural thing.
Why is it important that storage/compute be in the same box? Isn't it desirable for there to be a "service boundary" between block storage, file storage, object storage, etc, and the consumers?
If that boundary is desirable, why would it matter where the storage resources are located? Wouldn't that be an implementation detail?
Hyperconverged is all about software defined storage and compute. You can create those service boundaries all on one cluster and pool like nodes together to create one big mesh of compute and storage. The precursor were things like EMC and NetApp storage clusters which typically had 2-4 "compute nodes" with a rack full of direct attached storage. This created a massive problem come upgrade time, and the term was called "forklift upgrade" [1] for a reason. With HCI you can add and replace single boxes as needed.
Also, latency is not an implementation detail for a lot of data-intensive workloads. We're talking differences of 1-10ms latency for Network Storage and 250-500µs for a local NVME SSD.
Yeah that happens too much. Just marketing. When MDM (mobile device management) expanded to also include Windows and Mac most vendors loved branding it as UEM (unified endpoint management) as if it's a totally new thing and theirs is so much better than the competitors. But it's the same stuff just applied more widely and even vendors still referring to MDM are supporting these platforms.
I hate it when marketing people through up hot air like this.
It's a bit unfortunate that Kali didn't give the props to Seth's project (not even an outbound link). Perhaps this was just an oversight, or a spotlight blog post is coming later, but I hope that the history of this gets properly acknowledged, because it's darn clear where this comes from.
[1]: https://github.com/cisagov/Malcolm
[2]: https://www.kali.org/blog/kali-linux-2023-1-release/
[3]: https://cisagov.github.io/Malcolm/docs/protocols.html