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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
When PHP-FPM goes down
Let's solve a hypothetical problem: supose you have web server and php-fpm.
For some reason fpm daemon goes belly up but web server stays alive. You have situation when visitors can download .php files as a text files. A nasty situation non-the-less.
What solutions would you apply to solve or go around this problem?
Comments
Isn't web server supposed to return 502/504 when PHP-FPM is dead, no? Have you tried it yourself and it returns plain text PHP?
Yes, it returns gateway error. But what if missconfigured?
Fix the webserver misconfiguration and solve the php-fpm issue as well. I hope Murphy doesn't hear me but if php-fpm is going down it leads me to believe something seriously needs resolving/fixing.
Eg. Install up a trusted panel and see how it's webserver and php-fpm is configured and imitate that config.
I don't know what kind of web server this is but at least for nginx i'm pretty sure that if php-fpm leads to scripts being downloadable there would be some kind of massive misconfiguration. To be honest i'm not even sure if it would be possible to configure it that way if one specifically tried to.
I'll also second @risharde . php-fpm just dying really shouldn't happen at all, so this should be thoroughly investigated because something is obviously seriously broken.
Guys, either I didn't clearly express topic idea or you don't understand topic at all...
Here is simpler variant: how detect that .php interpreter gone sideways and visitors started to download your website files?
Just out of the blue.
Are you by any chance Romanian and offer basement services? (/s)
Vistors don't download your scripts just because php-fpm died. At least not with any of the webservers i'm familiar with. Detection could likely bedone with a custom error page, i guess (disclaimer: i've never tried doing this).
Probably, Romanian but also running perfume business 😂😂😂
On serious note if server correctly setup no php code will be downloaded as plain text.
I mean, what kind of solutions are you talking about?
I guess for example with WordPress you could force-block certain files that aren't supposed to be accessed by anyone.
wp-config.phpthat shouldn't ever be accessed directly, so in NGINX you can do things like:Another method would be to simply not have PHP files in your webroot.
For example, solutions built on top of Symfony/Laravel/etc. have the webroot in (for example)
/var/www/public, which is where theindex.phpexists.All the PHP files that contain any important logic exists in
/var/www, but that's not accessible from the webserver, even if your PHP handler is misconfigured in some way.Even so, I don't see how your webserver would just "start" serving PHP files out of the blue. It's quite simple to test this by just temporarily stopping the php-fpm service and checking how your web server handles this.
Virtono.com anyone? Ffs people... Ihostart? Florin?
In the case of Apache, you would define a handler for PHP:
https://httpd.apache.org/docs/2.4/handler.html
This defines what happens when a file with a certain extension is requested. If this is set up for PHP, then it's impossible for Apache to serve up the file directly, since this action is not defined for that file type.
There is a big difference between uploading a broken configuration and not actually testing it versus "something happening suddenly". If you upload a broken config and go take a nap without thinking twice about it all safeguards you could add there likely aren't there/tested either.
And no monitoring for situations like this?
Yeah, like... if you simply do what I said and kill your php-fpm process and test what happens you'll figure out rather quickly whether or not this could happen to you.
It's not a solar flare bitflip happening overnight, it's a misconfiguration that happened when you set everything up.
Hell, this didn't even happen with Virtono. If you try to access one of any of those files (.php or not), you get a 404.
I would never consider setting up monitoring for a situation like this, because if the defined PHP handler isn't working, then nothing would be served anyway.
And if your config is so broken or non-standard that you can't figure out what it's doing, then monitoring won't help.
Well, you could setup a looped curl on another box that would constantly request some php file and send emails to everyone including your dog while setting off a text message every 30 seconds to your private cellphone. Well, either this or... you just actually test the configurations you upload.
Can I do this on the edge, computerless, serverless & brainless?
Asking for a friend
When PHP files can be downloaded, it's usually not because the interpreter is down. It's more likely that a default virtual host was left on without being set up to use the interpreter, and no one noticed. There's no real way to monitor for this, so you just have to be careful when setting things up.
Credentials should never live in a PHP file, and certainly not in a PHP file in your webroot.
If you follow this rule.... in the case you make a configuration error on your web server, nothing too serious should be exposed.
Does said friend have a dog?
This was going to be my second set if thoughts as well!
How about you monitor to see if raw php code is detected when accessing your website and figure out a way to autoshutdown webserver until you fix it including receiving emails at @totally_not_banned said.
Edit: a monitor script on the server could theoretically do this without remote monitoring.
True, the monitor doesn't really have to run remotely. If the webserver isn't up there's nothing to monitor anyways.
https://paste.sh/7uuC1tf2#7tQeS_M7hsQ6lR5FPjgsAF_H
Autoshutdown technology
I guess personally i'd probably still prefer the dog approach though.
Piss off @FlorinMarian.
He will then monitor your website for free and post security issues on other forums than LET.
Kind people will then contact you directly (after they downloaded everything).
Well, it might be a better idea to stop nginx/apache with the script instead of shutting down the server.
Based on your case, I assume you've already used and configured php-fpm and web server (e.g Nginx). Then on uncertain condition, php-fpm went down because of overload or misconfigured. When browser hit the URL, Nginx catch the request and try to match the URL against location block. when it's matched and it is a PHP file , Nginx forward it to PHP runtime (unix or tcp). Since it's not reacheable then Nginx return 503 (timeout)
This,
Solution is re-install. It's fucked in more ways than one.
Okay let's clear up some confusion. This is probably not possible. Almost certainly not possible unless you've intentionally done this.
Protecting against this kind of thing is like protecting against cosmic ray hits that somehow bypass ECC RAM.
There's absolutely no reason to even consider this
If I had to guess, the dude has 2 webservers and one takes over when another goes down, and the backup one lacks PHP or correct php configuration which makes it open php files as downloads. But even then it must be fucked in more ways than one, since by default this should be impossible since default configs usually have these things commented.
virtono.com root dir got exposed to the world for ~24 hours straight. Apparently it is possible and has potential to destroy reputation beyond repair.
In theory curl should give some kind of insight into situation.
Your supposed example is possible if the sysadmin follows multiple online guides and jumps between them copy pasting everything without knowing what he is doing.
It's impossible even for a novice to do this using the default commands for package installs.
Why are you even trying to block it, fix the crashing instead, and then figure out what happens after that.