Pandora: Secure your Cloudron
-
@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
