8 ms·

Odd installation steps.

by PokemonNoGo 1y ago

reconnecting 1y ago
Can you elaborate, please?
- kassner 1y ago
  composer install should be pretty much what one needs nowadays. Any installing scripts (although you really shouldn’t) can also be hooked into it.
  - lucb1e 1y ago
    This requires running the install scripts with your shell permissions rather than with the webserver's permissions, if I'm not mistaken. I could see why one might prefer the other way, even if shared hosting is less common nowadays and shells more often an option
- snickerdoodle12 1y ago
  The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software. > Download a zip file and extract it "where you want it installed on your web server" The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is. > Navigate to http://your-domain.example/install/index.php http://your-domain.example/install/index.php in a browser to launch the installation process. Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost? > After the successful installation, delete the install/ directory and its contents. Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
  - reconnecting 1y ago
    This is not something specific to tirreno, as it's the usual installation process of any PHP application. If there is an example of another approach, I will gladly take it into account.
    - snickerdoodle12 1y ago
      > as it's the usual installation process of any PHP application Maybe a decade ago. Look into composer.
  - kstrauser 1y ago
    I'll side with you here. This gives attackers a huge window of time in which to compromise your service and configure it the way they want it configured. In my recent experience, you have about 3 seconds to lock down and secure a new web service: https://honeypot.net/2024/05/16/i-am-not.html https://honeypot.net/2024/05/16/i-am-not.html
    - lucb1e 1y ago
      Wut? That can't have been a chance visit from a crawler unless maybe you linked it within those 3 seconds of creating the subdomain and the crawler visited the page it was linked from in that same second, or you/someone linked to it (in preparation) before it existed and bots were already constantly trying Where did you "create" this subdomain, do you mean the vhost in the webserver configuration or making an A record in the DNS configuration at e.g. your registrar? Because it seems to me that either: - Your computer's DNS queries are being logged and any unknown domains immediately get crawled, be it with malicious or white-hat intent, or - Whatever method you created that subdomain by is being logged (by whoever owns it, or by them e.g. having AXFR enabled accidentally for example) and immediately got crawled with whichever intent I can re-do the test on my side if you want to figure out what part of your process is leaky, assuming you can reproduce it in the first place (to within a few standard deviations of those three seconds at least; like if the next time is 40 seconds I'll call it 'same' but if it's 4 days then the 3 seconds were a lottery ticket -- not that I'd bet on those odds to deploy important software, but generally speaking about how aggressive-or-not the web is nowadays)
pests 1y ago
Id say it’s big standard for php apps and have been for awhile. Wordpress has a similar install flow. Docker images are provided tho.
- reconnecting 1y ago
  Yes, Matomo/Piwik, WordPress, and ProcessWire have more or less the same installation steps, but maybe we missed something along the way.
theamk 1y ago
Totally normal for PHP software, and that's a primary reason of why PHP apps have such a bad security reputation. Note: - The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want. - The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options. Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place. Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)
- reconnecting 1y ago
  Fair critique on traditional PHP deployment. However tirreno shouldn't be public-facing anyway. Production apps forward events via API on local network, security teams access dashboard over VPN. Perhaps we will add this recommendation to the documentation to avoid any confusion. Thanks for the clarification.
- PokemonNoGo 1y ago
  I kinda understood I was missing "something" when I commented but I haven't used any PHP for over a decade and honestly it looked very well you said the rest... Thanks for the clarification. Very unfamiliar with modern PHP.
  - lucb1e 1y ago
    What did you think you had missed? I'm not understanding > but I haven't used any PHP for over a decade This isn't modern PHP, this is the traditional installation method that I used also a decade ago. The only thing that could be older about it is to have a web-cron instead of a proper system cron line. Modern PHP dependency installation is to basically curl|bash something on the host system (composer iirc) rather than load in the code under the web server's user and running the install from there, as this repository suggests. Not that the parent comment is wrong about the risks that still exist in being able to dynamically pull third-party code this way and hosting secrets under the webroot
lucb1e 1y ago
Care to elaborate? They seem bog-standard to me

Odd installation steps.

reconnecting 1y ago

Can you elaborate, please?

kassner 1y ago
composer install should be pretty much what one needs nowadays. Any installing scripts (although you really shouldn’t) can also be hooked into it.
- lucb1e 1y ago
  This requires running the install scripts with your shell permissions rather than with the webserver's permissions, if I'm not mistaken. I could see why one might prefer the other way, even if shared hosting is less common nowadays and shells more often an option
snickerdoodle12 1y ago
The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software. > Download a zip file and extract it "where you want it installed on your web server" The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is. > Navigate to http://your-domain.example/install/index.php http://your-domain.example/install/index.php in a browser to launch the installation process. Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost? > After the successful installation, delete the install/ directory and its contents. Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
- reconnecting 1y ago
  This is not something specific to tirreno, as it's the usual installation process of any PHP application. If there is an example of another approach, I will gladly take it into account.
  - snickerdoodle12 1y ago
    > as it's the usual installation process of any PHP application Maybe a decade ago. Look into composer.
- kstrauser 1y ago
  I'll side with you here. This gives attackers a huge window of time in which to compromise your service and configure it the way they want it configured. In my recent experience, you have about 3 seconds to lock down and secure a new web service: https://honeypot.net/2024/05/16/i-am-not.html https://honeypot.net/2024/05/16/i-am-not.html
  - lucb1e 1y ago
    Wut? That can't have been a chance visit from a crawler unless maybe you linked it within those 3 seconds of creating the subdomain and the crawler visited the page it was linked from in that same second, or you/someone linked to it (in preparation) before it existed and bots were already constantly trying Where did you "create" this subdomain, do you mean the vhost in the webserver configuration or making an A record in the DNS configuration at e.g. your registrar? Because it seems to me that either: - Your computer's DNS queries are being logged and any unknown domains immediately get crawled, be it with malicious or white-hat intent, or - Whatever method you created that subdomain by is being logged (by whoever owns it, or by them e.g. having AXFR enabled accidentally for example) and immediately got crawled with whichever intent I can re-do the test on my side if you want to figure out what part of your process is leaky, assuming you can reproduce it in the first place (to within a few standard deviations of those three seconds at least; like if the next time is 40 seconds I'll call it 'same' but if it's 4 days then the 3 seconds were a lottery ticket -- not that I'd bet on those odds to deploy important software, but generally speaking about how aggressive-or-not the web is nowadays)

pests 1y ago

Id say it’s big standard for php apps and have been for awhile. Wordpress has a similar install flow. Docker images are provided tho.

reconnecting 1y ago
Yes, Matomo/Piwik, WordPress, and ProcessWire have more or less the same installation steps, but maybe we missed something along the way.

theamk 1y ago

Totally normal for PHP software, and that's a primary reason of why PHP apps have such a bad security reputation. Note: - The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want. - The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options. Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place. Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)

reconnecting 1y ago
Fair critique on traditional PHP deployment. However tirreno shouldn't be public-facing anyway. Production apps forward events via API on local network, security teams access dashboard over VPN. Perhaps we will add this recommendation to the documentation to avoid any confusion. Thanks for the clarification.
PokemonNoGo 1y ago
I kinda understood I was missing "something" when I commented but I haven't used any PHP for over a decade and honestly it looked very well you said the rest... Thanks for the clarification. Very unfamiliar with modern PHP.
- lucb1e 1y ago
  What did you think you had missed? I'm not understanding > but I haven't used any PHP for over a decade This isn't modern PHP, this is the traditional installation method that I used also a decade ago. The only thing that could be older about it is to have a web-cron instead of a proper system cron line. Modern PHP dependency installation is to basically curl|bash something on the host system (composer iirc) rather than load in the code under the web server's user and running the install from there, as this repository suggests. Not that the parent comment is wrong about the risks that still exist in being able to dynamically pull third-party code this way and hosting secrets under the webroot

lucb1e 1y ago

Care to elaborate? They seem bog-standard to me