Kali Linux 2023.1 introduces 'Purple' distro for defensive security
gitlab.com
gitlab.com
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
I do like the idea of Kali Purple though - curious to check it out.
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.
Running them locally, a tap, and a server are unnecessary.
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.
You should check out FloCon put on by CMU. https://resources.sei.cmu.edu/news-events/events/flocon/inde...
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.
Seems like this is geared more towards training images and enterprise level aggregation vs being a DIFR type workstation with analyst tools.
Please open an issue at https://bugs.kali.org to keep discussing it. Thanks!
Sadly most EDR tools are just another ELK dashboard (wazuh included) and I think that has to change.
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.
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.
I like keeping custom scripts and installed apps/python scripts because we'll usually need them again next time.
Of course if you do constant engagements to external clients cross contamination is a big risk but we don't have this concern.
You can make custom Kali images with your own tools. Or you can just put those tools on git and pull them every time.
Our team is a little bit of everything which makes it harder to justify that overhead.
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.
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.
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?
Now there's a default kali user and you escalate via sudo, at least on the live systems.
You don’t really install apps on Qubes, you install entire operating systems as apps.
If normal linux is giving you too many hardware headaches, Qubes has some next level issues.
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.
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.
But yeah - the tools are available individually & this is how I typically use them.
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.
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.
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.
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?
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.
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.
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.
I'm talking about how electron apps prevent you from a wider range of window resizing
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.
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.
Not everyone considers that a drawback.
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.
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.
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.
https://vez.mrsk.me/freebsd-defaults.html
(Discussion on HN from 6 months ago: https://news.ycombinator.com/item?id=32506675)
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.
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.
[1] https://www.freebsd.org/security/advisories/
[2] https://www.openbsd.org/errata72.html
For upgrades, you use pkg_add -u for your installed packages and sysupgrade between releases for the base.
Not sure what your point is though, a default install of Linux is far better than a default install of windows.
or trueNAS Scale... any experience with that for hyperconverged labs?
You can get really, really far with just libvirt.
I hate it when marketing people through up hot air like this.
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?
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.
[1]: https://www.architecting.it/blog/what-is-a-forklift-upgrade/
* potentially compute and storage are colocated on the same chassis, providing maximum PCIe bandwidth and lower latency;
* reduced need to buy and mantain dedicated/offband storage networking solutions;
* You buy less half-filled, special purpose boxes.
Lots of people running proxmox, esxi, freenas, trunas, unraid, and others.
Don't you bring that negativity into the universe; I need my fix, man.
With this one could even go #vmless and use native SmartOS zones or lx zones for linux compatibility and more efficient use of system resources.