Pandora: Secure your Cloudron
-
hmm. just from an observing position I am not 100% sure if all these changes are a good idea in the context of Cloudron.
If there are sensible hardening steps, they should probably be baked into the base setup of Cloudron already.
https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L43
this installs etckeeper, but as far as I can see does not configure it (at least the last time I played with it, it still required anetckeeper initof some sorts to actually record changes). Seeing the amount of configuration changes it may be a good idea to take a snapshot of the current configuration before modifying anything.https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L22
why install non security related stuff like byobu?
this also installs packages which probably already exist on a system (likeca-certificates) and also some stuff that may be better left to cloudron, likeunattended-upgrades. In the past the statement for this was that Cloudron will take care of package updates, this is to make sure that an updated package does not break compatibility.https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L155
Moving the ssh port is security by obscurity.https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L232
pulling in unversioned changes can result in unpredicable behaviour -
Hi @fbartels thanks for your precious feedback
Obviously the original script wasn't dedicated to Cloudron and this version still need some works, this is why I post it in App Whislist and not pretending it is ready.
However
-
etckeeper init is done during the installation, if I remember well, this is/was not the case on older Debian (7/8).
-
byobu is arbitrary but also by default on Ubuntu, I guess is a personal choice such as Cloudron seams to prefer Mosh when it comes time to interact with a remote terminal
-
SSH on port 202: I just go with the Cloudron flow but also any SSH configuration agreed changing the port help again scriptkiddy
https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L232
pulling in unversioned changes can result in unpredicable behaviourYes this one need more control
At the end you are welcome to help us and propose change
-
-
@JOduMonT said in Pandora: Secure your Cloudron:
etckeeper init is done during the installation, if I remember well, this is/was not the case on older Debian (7/8).
yes, that could indeed match up with the last time I seriously looked at it.
@JOduMonT said in Pandora: Secure your Cloudron:
byobu is arbitrary but also by default on Ubuntu, I guess is a personal choice such as Cloudron seams to prefer Mosh when it comes time to interact with a remote terminal
I am not sure of the linked chapter really establishes that mosh is preferred. It was probably simply a questions from someone and easy to add to the documentation. But mosh is also something quite different to byobu/tmux.
@JOduMonT said in Pandora: Secure your Cloudron:
At the end you are welcome to help us and propose change
Thats why I am giving feedback here
-
@fbartels Security by obscurity is a valid use case. Do you want it to be your only source of security? No, but it contributes to a "defense in depth" strategy used successfully by the DoD.
Also blocking automated scripts by obscuring common ports and the like massively reduces your attack surface from automated bots.Agree that all non security items should NOT be in a project like this.
Such a wonder piece of work! The more eyes we have on this the better? How do I get involved?
-
@murgero Given that just the Navy alone is a massive enterprise, the biggest active directory domain in the world all on its own, it is a massive target. It is an amazing feat of good security at scale.
Is everything down right? Absolutely not. Have they been breached? More times than I can say. Is the security principle sound? That should be obvious to a security practitioner, in fact, the "new hotness" ZeroTrust framework is built on exactly that idea.All of us have holes in our knowledge, working together we can combine our powers like Vol-tron and kick ass.
-
@will said in Pandora: Secure your Cloudron:
Agree that all non security items should NOT be in a project like this.
my hope is to raise awareness, and as I already did
@girishOh, this is a fantastic tool, never heard of it previously. I gave it a quick run and got https://paste.cloudron.io/nihezomima.coffeescript (63% as @JOduMonT already pointed out).
the spect of this repo will end through few line in the box code such as removing lxd and lxc since not every provider image have this by default anyway (example upcloud ubuntu default image), waste ressource and could potentially end as a conflit with docker.
@will said in Pandora: Secure your Cloudron:
Have they been breached
A breach is normal, this become problematic when the breach can't be counter by a front-end firewall and/or a WAF.
Cloudron already manage apparmor (which is outstanding most of actual project) but if Cloudron want to go further we should might want to think about naxsi or implementing ModSecurity 3.0.
-
@girish and @nebulon I saw the notice when we login through SSH.
I understand it is not specially related to pandora but before going further with this I would like to understand how much you are open to open your box to contributors ?
I means obviously not every modification and addons made by this project (Pandora) worth it but I believe few line should be considered. How would you like to work on it so it's win win, I means I don't mess your box and I don't loose my time
-
@JOduMonT said in Pandora: Secure your Cloudron:
I understand it is not specially related to pandora but before going further with this I would like to understand how much you are open to open your box to contributors ?
I've contributed to
boxbefore. As with many open source projects, narrowly scoped changes can be submitted and discussed on a review but if a large change is going to be submitted, it's probably best to discuss somewhere (forum, chat, RFC issue) before you invest a bunch of time. -
Agreed on that last point - might be easier to try and extract individual controls and propose those in merge requests separately so they can each be discussed in depth, otherwise, this seems like a nice place to have it out on some of the details
IMO, it would be useful to aim at particular concrete standards as initial hardening steps, as needed - CIS is a solid starting point, NIST may have something useful, and so on - adding each of those as a credential to the solution as it approaches something more "PCI/DSS ready" (though that claim needs a whole bunch of other analysis that's harder). A lot of it comes down to the applications installed and how they're configured for the more advanced PCI/HIPAA/etc. sort of standards. That's my main reason for advocating for more specific and concrete standards for the components involved as a stepping stone.
Edit: Just to be clear, I love that the community is taking steps to ask and help contribute answers to these questions, and this is all intended to help advance that cause, not to impede it at all. Thanks for getting this thread going!
-
it is true than PCI/DSS depend on a lot of parameters.
as @jimcavoli said in Pandora: Secure your Cloudron:CIS is a solid starting point, NIST
following a step by step such as CIS instead of PCI/DSS v3.2.1 will be easier and already a great step forward.
thank to @jimcavoli and @iamthefij for your guidance and I hope to see you to the other side -
I recommend the DoD STIGS as an awesome starting point, with a lot of stuff to back it up
https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=operating-systems%2Cunix-linuxThe stig is old, for ubuntu 16, but is a great place to steal from.
Break out each control against a stig number, and that way you can control what you implement or not.STIG viewer:
https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=stig-viewingWhats cool is each check has the way to fix the check, so you can save a TON of work by taking their fixes and using whats useful.
Another big thing is both the military, and the vendors themselves are involved in making STIGs, so you get a ton of eyes and expert advice involved in it.(Note: I helped to create the Vendor STIG recommendation for several Symantec security products)
-
@will said in Pandora: Secure your Cloudron:
I recommend the DoD STIGS as an awesome starting point, with a lot of stuff to back it up
https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=operating-systems%2Cunix-linuxThe stig is old, for ubuntu 16, but is a great place to steal from.
Break out each control against a stig number, and that way you can control what you implement or not.STIG viewer:
https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=stig-viewingWhats cool is each check has the way to fix the check, so you can save a TON of work by taking their fixes and using whats useful.
Another big thing is both the military, and the vendors themselves are involved in making STIGs, so you get a ton of eyes and expert advice involved in it.(Note: I helped to create the Vendor STIG recommendation for several Symantec security products)
men, this is like going backward since pandora is based on
konstruktoid/hardening which is based on:
- Canonical Ubuntu 16.04 LTS STIG - Ver 1, Rel 2
- CIS Distribution Independent Linux Benchmark
- CIS Ubuntu Linux Benchmark
- EUD Security Guidance: Ubuntu 18.04 LTS Red Hat Enterprise Linux 7 - Ver 2, Rel 3 STIG
- https://wiki.ubuntu.com/Security/Features
- https://help.ubuntu.com/community/StricterDefaults
-
@JOduMonT Why don't we pick one standard
Say, EUD Security Guidance: Ubuntu 18.04 (since that is what Cloudron currently uses I believe) Once we are happy with the workflow, layout, commenting, etc... We can take on other standards, or subset of standards.Like they say in the Navy, crawl, walk, run.
- Will
