Pandora: Secure your Cloudron



  • @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?



  • @will said in Pandora: Secure your Cloudron:

    used successfully by the DoD

    Given the DoD just recently in 2018 AND 2019 had a data breach, they are not a good example of "Successful Security".



  • @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.

    Or... Captain Planet? Which ring are you?!



  • @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
    @girish

    Oh, 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 box before. 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-linux

    The 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-viewing

    Whats 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)


Log in to reply