Managing Publicly hosted Linux Servers through Cockpit
-
What most people seems to miss is that the Solarwind attack was a supply chain attack.
That means that the tool itself was compromised.That means that any tool, regardless of how you use it, is at risk for this kind of attack. It certainly doesn't have to be anything that is centrally hosted/administered.
Even ssh itself is at risk, but it's more likely to occur in tools where you have lots of source code from many sources. For instance ansible or devops tooling.
-
Cockpit looks nice and all that, but the version I tried didn't seem to have as many features or as much control like webmin does.
-
@pete-s said in Managing Publicly hosted Linux Servers through Cockpit:
What most people seems to miss is that the Solarwind attack was a supply chain attack.
That means that the tool itself was compromised.That means that any tool, regardless of how you use it, is at risk for this kind of attack. It certainly doesn't have to be anything that is centrally hosted/administered.
Even ssh itself is at risk, but it's more likely to occur in tools where you have lots of source code from many sources. For instance ansible or devops tooling.
nobody was mentioning Solardwinds. They were referencing specific MSPs being breached and all of their clients being on the same networks.
The Solarwinds hack was from an injection during a pipeline where they modified the actual binary that was built. Ansible wouldn't be compromised that way since it's a Python package and you can just pull the Ansible source and run it. It doesn't need compiled.
Solarwinds is far from "devops tooling" and that feels like a weird thing to say since most devops tooling is open source and not built in private like Solarwinds.
-
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
-
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
-
We are working with Platform One and some others and they want to require it for everything. Hopefully that gets more traction.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
Well it mentions open source specifically, but also targets close source
-
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
Well it mentions open source specifically, but also targets close source
Ah I read the first part. It made it sound like it was only open source.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
Well it mentions open source specifically, but also targets close source
Ah I read the first part. It made it sound like it was only open source.
Not that anyone but the US Government will know what is actually included in any specific closed source software
-
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
Well it mentions open source specifically, but also targets close source
Ah I read the first part. It made it sound like it was only open source.
Not that anyone but the US Government will know what is actually included in any specific closed source software
If enterprises are smart they will require it too. And at that point it would hopefully just be publically available.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
@dustinb3403 said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
There's a big movement now around SBOM with tools like in-toto, SPIFFE/SPIRE, TUF, and a lot more. We are working with gov't clients and they are headed towards requiring SBOM information for each release.
It's been mandated that software now include a SBOM (see my recent post in IT news).
Yeah but that mandate is only for open source (for whatever dumb reason). I'm all for SBOMs for open source software, but it's ignoring the fact that the issue has historically come from closed source software. An SBOM is much less effective when you already have access to 99% of what's included in the product.
Well it mentions open source specifically, but also targets close source
Ah I read the first part. It made it sound like it was only open source.
Not that anyone but the US Government will know what is actually included in any specific closed source software
If enterprises are smart they will require it too. And at that point it would hopefully just be publically available.
While I would agree, the reality is that so many software companies are in business solely because their software is closed source.
The RHEL's of the world are far and few in-between
-
We use Cockpit very limitedly. It's only on internally and not machines are grouped together even at clients with multiple Cockpit installs. It's nice and all, but it's not as fast as SSH and there's no real need for a GUI like this so... why bother.
-
@scottalanmiller said in Managing Publicly hosted Linux Servers through Cockpit:
We use Cockpit very limitedly. It's only on internally and not machines are grouped together even at clients with multiple Cockpit installs. It's nice and all, but it's not as fast as SSH and there's no real need for a GUI like this so... why bother.
completely agree.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
The Solarwinds hack was from an injection during a pipeline where they modified the actual binary that was built. Ansible wouldn't be compromised that way since it's a Python package and you can just pull the Ansible source and run it. It doesn't need compiled.
Supply chain attack doesn't have to modify binaries. You could modify anything. In Ansible's case they say that the weak link is the community developed modules. That it's built on Python changes nothing.
-
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
Solarwinds is far from "devops tooling" and that feels like a weird thing to say since most devops tooling is open source and not built in private like Solarwinds.
I didn't say that. I said that the cybercriminals are going after management tools including devops tooling. Just because it's open source doesn't make it automatically safe.
-
@pete-s said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
The Solarwinds hack was from an injection during a pipeline where they modified the actual binary that was built. Ansible wouldn't be compromised that way since it's a Python package and you can just pull the Ansible source and run it. It doesn't need compiled.
Supply chain attack doesn't have to modify binaries. You could modify anything. In Ansible's case they say that the weak link is the community developed modules. That it's built on Python changes nothing.
No, them being community developed modules changes nothing. 1) All of Ansible is community maintained. 2) If you're referencing the modules that come with Ansible, they are in the main repo with Ansible. Only recently have they started shipping collections which are separately maintained and that wouldn't be a failing of Ansible itself.
-
@pete-s said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
Solarwinds is far from "devops tooling" and that feels like a weird thing to say since most devops tooling is open source and not built in private like Solarwinds.
I didn't say that. I said that the cybercriminals are going after management tools including devops tooling. Just because it's open source doesn't make it automatically safe.
Yeah no one said open source is automatically safe, but the reason the Solarwinds hack was successful was because it was closed. If the build logs were open like most open source tools, and the source was available, it could have easily been caught.
Relying on pre-built binaries is starting to fade. With languages like Go where you can pull the source and build locally in the same command, it's not needed any longer.
Also, in reality supply chain vulnerabilities are extremely difficult to pull off. Solarwinds wasn't because of an upstream dependency in the chain, it was the tool itself which was compromised in a build step. While SBOM information is really important, these attacks are rare and you're most likely to get attacked somewhere else.
-
@stuartjordan said in Managing Publicly hosted Linux Servers through Cockpit:
Cockpit looks nice and all that, but the version I tried didn't seem to have as many features or as much control like webmin does.
Tried Cockpit on Ubuntu? If so, you probably been using a old version because the only distro that I know that always has the latest version is Fedora.
-
@pete-s said in Managing Publicly hosted Linux Servers through Cockpit:
@stacksofplates said in Managing Publicly hosted Linux Servers through Cockpit:
Solarwinds is far from "devops tooling" and that feels like a weird thing to say since most devops tooling is open source and not built in private like Solarwinds.
I didn't say that. I said that the cybercriminals are going after management tools including devops tooling. Just because it's open source doesn't make it automatically safe.
No, but it means one of the biggest factors in encouraging safety has been taken. Closed source has fewer ways to be protected and is built around a culture that is very dangerous. Nothing makes people wearing seatbelts automatically better drivers, but good drivers are way more likely to lean towards wearing seatbelts because the ecosystem things that make you take the obvious smart step of wearing a seatbelt will make you more likely to take driving well seriously. Plus the seatbelt itself adds a huge layer of protection. The same with OS. Code visibility adds some safety, but the bigger deal is the correlation with good programming behaviour.
