Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Security notice: PHP 7.4 is *dead* - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Security notice: PHP 7.4 is *dead*

2»

Comments

  • lewellynlewellyn Member
    edited November 2022

    @Hxxx said:
    @lewellyn following your signature, since your post is excellent, should I compliment Elliotj?

    Haha possibly but I think he's at least as lurky as I am these days. -.- Now that deals season is over, I'm likely to hibernate again soon.

    Also thanks for the compliment :3

    Thanked by 1Hxxx
  • @cheapdave said:
    Cloudlinux's Extended Support for Centos 6.x seems pretty good, but Docker is supposed to be meant for such things, right?

    If you add the security layer (firewall / WAF / mod_security) to the outer OS (host inside which docker runs) and run PHP 5.x/7.x on Centos 6.x / etc inside docker, it should mitigate against the attacks that make upgrades "mandatory", IMO.

    Any flaws in this idea?

    How exactly do you plan for Docker to protect the stuff running inside from arbitrary data access vulns? I've been thinking on this and I cannot see any way that Docker is relevant to the general classes of CVE that tend to affect downlevel PHP versions: denial of service and arbitrary data access.

    People aren't trying to sell info on the dark web of what your OS is doing: they want the data your site has. Docker can't protect an application from itself. It is barely suitable for protecting applications from each other. (You'd want a rootless, daemonless containerization solution such as Podman or OpenShift if you were trying to more properly isolate containers from "accidentally" seeing each other's private bits.)

    And using a WAF or mod_security or something means you'd have to stay ahead of what the baddies are doing to exploit the CVEs. There's little way for you to know as an individual. And if you're paying for cloud-based definitions, you might want to consider tossing a coin to your witcher... er your sysadmin... and having them keep your tech stack up to date.

    In all honesty, "I hate going through the upgrade process" is a thought process I tend to recommend a rolling distro release to. It forces you to upgrade things regularly, but at the same time, each update is bite-sized. And the result is that you have a good baseline security posture.

  • Firstly, thanks for the comprehensive reply.

    @lewellyn said: How exactly do you plan for Docker to protect the stuff running inside from arbitrary data access vulns? I've been thinking on this and I cannot see any way that Docker is relevant to the general classes of CVE that tend to affect downlevel PHP versions: denial of service and arbitrary data access.

    People aren't trying to sell info on the dark web of what your OS is doing: they want the data your site has. Docker can't protect an application from itself. It is barely suitable for protecting applications from each other. (You'd want a rootless, daemonless containerization solution such as Podman or OpenShift if you were trying to more properly isolate containers from "accidentally" seeing each other's private bits.)

    I'm quite ignorant about docker. Hence my generic question. I will look into docker and podman (seems better). K8s and Openshift are currently "above my pay grade" i.e. They are too big and my setup cannot afford to buy the hardware needed to run those.

    I saw your other reply about Wordpress and I agree that no amount of containerisation / sandbox / etc protects from abuse of the application itself, for example, SQL, CLI or XSS injection. But I hadn't quite paid attention to the bugs like the one you mentioned (CVE-2019-9641). I'm not a Pen Tester, so I'll need to spend time on this just to see the impact and understand the problem first hand. It's an awareness problem for me at the moment.

    And using a WAF or mod_security or something means you'd have to stay ahead of what the baddies are doing to exploit the CVEs. There's little way for you to know as an individual. And if you're paying for cloud-based definitions, you might want to consider tossing a coin to your witcher... er your sysadmin... and having them keep your tech stack up to date.

    I agree, getting and running the latest ruleset and tweaking it, is a major pain. I'm the system admin so it's not about the cost, the problem is forcing the developers and boss to give time for upgrades. We're often a few months behind the latest version although the OWASP top 10 are always patched quickly. I was essentially hoping that Docker might help protect against attacks on the platform (Apache, Linux), but that's clearly not the case.

    In all honesty, "I hate going through the upgrade process" is a thought process I tend to recommend a rolling distro release to. It forces you to upgrade things regularly, but at the same time, each update is bite-sized. And the result is that you have a good baseline security posture.

    This is and interesting and very useful suggestion. I'll have to think long and hard about this. This is a great strategy because once the "hardships" of the first move to rolling release are accepted as normal by the team, upgrading things constantly will become a habit. Rolling release in production looks quite scary at first sight, but I think we can make it "delayed rolling release" using some settings, so that production doesn't break.

    Thank you for both replies. Good thing I posted on this thread. :)

    Thanked by 1lewellyn
  • jokes on them, I'm still using PHP5

Sign In or Register to comment.