[HN Gopher] Kali Linux 2023.1 introduces 'Purple' distro for def...
___________________________________________________________________
Kali Linux 2023.1 introduces 'Purple' distro for defensive security
Author : favourable
Score : 177 points
Date : 2023-03-14 19:00 UTC (4 hours ago)
(HTM) web link (gitlab.com)
(TXT) w3m dump (gitlab.com)
| veganjay wrote:
| 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.
| mr_toad wrote:
| If you have local logs and you're not in an enterprise
| environment it makes sense to analyse the logs locally.
| milkshakes wrote:
| These tools (-elasticsearch) run on a server that's usually
| connected to a network tap that collects traffic from endpoints
| and servers alike.
|
| Running them locally, a tap, and a server are unnecessary.
| badrabbit wrote:
| 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.
| bee_rider wrote:
| How do BSD and Linux compare on the defensive in 2023? Has the
| larger community finally spent enough eyeballs to catch up with
| the better foundation?
| jms703 wrote:
| Out of the box distro security means very little when compared
| to a properly configured system.
| teawrecks wrote:
| 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.
| hsbauauvhabzb wrote:
| Almost all modern Linux distros are pretty reasonable
| Security out of the box, it's the user-specified
| configuration that causes the issues.
| bombcar wrote:
| Part of the problem is when distros "become secure in the
| default install" by having nothing installed and nothing
| running.
| 0cf8612b2e1e wrote:
| If the server does nothing but run Docker containers,
| maybe that's not so bad.
| NexRebular wrote:
| But what if one doesn't trust the security of docker?
| 0cf8612b2e1e wrote:
| At least switch to podman, which has a better isolation
| story.
| hsbauauvhabzb wrote:
| Then you have bigger issues to worry about.
| hsbauauvhabzb wrote:
| Last time I could checked you could install stuff during
| the initial deployment.
|
| Not sure what your point is though, a default install of
| Linux is far better than a default install of windows.
| wkat4242 wrote:
| 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.
| thewataccount wrote:
| 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?
| JohnFen wrote:
| > has the drawback of older tech like X11.
|
| Not everyone considers that a drawback.
| inductive_magic wrote:
| Disclaimer: I'm not an infosec guy, just peripherally following
| some blogs. After reading this:
| https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
| my position is that freeBSD can't be competitive.
| dijit wrote:
| There is also the evergreen document titled: "FreeBSD: A
| lesson in poor defaults"
|
| https://vez.mrsk.me/freebsd-defaults.html
|
| (Discussion on HN from 6 months ago:
| https://news.ycombinator.com/item?id=32506675)
| yjftsjthsd-h wrote:
| 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.
| criddell wrote:
| Does this distro have modern application sandboxing? For example,
| can I say which applications have access to my photos, email,
| location, microphone, etc...?
| bombcar wrote:
| You might be interested in Qubes instead - https://www.qubes-
| os.org as this is more of a toolkit for security testing.
| shp0ngle wrote:
| Qubes is not Linux really. I mean it technically is Fedora
| apparently but the main thing really is Xen and hypervisor.
|
| 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.
| sylens wrote:
| Kali is not really meant as a general purpose desktop OS.
| Everything runs as root, IIRC (been years since I was
| pentesting).
| Shared404 wrote:
| Until relatively recently it did.
|
| Now there's a default kali user and you escalate via sudo, at
| least on the live systems.
| AbraKdabra wrote:
| 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.
| antmldr wrote:
| 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.
| nostoc wrote:
| Kali was running everything as root up to a few years ago, I'd
| be very surprised if this had application sandboxing.
| wkat4242 wrote:
| 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.
| lucideer wrote:
| 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.
| JohnFen wrote:
| 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.
| Arch-TK wrote:
| 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.
| ChuckNorris89 wrote:
| _> 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.
| wkat4242 wrote:
| I don't but when it comes to pentests we only do them
| internally and not very often either.
|
| 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.
| ChuckNorris89 wrote:
| _> I like keeping custom scripts and installed apps/python
| scripts because we'll usually need them again next time._
|
| You can make custom Kali images with your own tools. Or you
| can just put those tools on git and pull them every time.
| wkat4242 wrote:
| I know and if you're a full time red team pentester that
| would make total sense :)
|
| Our team is a little bit of everything which makes it
| harder to justify that overhead.
| hitpointdrew wrote:
| If you are looking for a "pen testing distro" to use a daily
| driver check out Parrot Linux. https://parrotlinux.org/
| lucideer wrote:
| 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.
| 0x1f606 wrote:
| > but as VMs
|
| 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.
| stirfish wrote:
| >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?
| criddell wrote:
| Thanks for explaining. I misunderstood what Kali was for.
| unethical_ban wrote:
| 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?
| candiddevmike wrote:
| What is your definition of hyperconverged? How many physical
| servers are you talking about?
|
| You can get really, really far with just libvirt.
| yjftsjthsd-h wrote:
| 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.
| ahepp wrote:
| Something I don't understand:
|
| 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?
| yabones wrote:
| Yeah, it's a word that just describes using Ceph or DRBD
| with Libvirt on top and connecting the machines together
| with good old fashioned VLAN trunks.
| wkat4242 wrote:
| 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.
| unethical_ban wrote:
| "hyperconverged" is easier to pronounce than
| "data+network+storage running on the same software stack
| on commodity hardware"
| ganoushoreilly wrote:
| there are many people doing this, check out /r/homelab on
| reddit (assuming it ever comes back up).
|
| Lots of people running proxmox, esxi, freenas, trunas, unraid,
| and others.
| 0x1f606 wrote:
| > (assuming it ever comes back up)
|
| Don't you bring that negativity into the universe; I need my
| fix, man.
| ncrmro wrote:
| 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
| NexRebular wrote:
| Why not SmartOS with bhyve VMs running inside secure zones?
|
| 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.
| cjbprime wrote:
| This looks good! What do people use for fast indexed search of
| pcaps? (Contents, not metadata.)
| aviditas wrote:
| 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.
| PenguinCoder wrote:
| Whats the difference compared to something like SIFT workstation?
|
| Seems like this is geared more towards training images and
| enterprise level aggregation vs being a DIFR type workstation
| with analyst tools.
___________________________________________________________________
(page generated 2023-03-14 23:00 UTC)