Can you elaborate, please?

snickerdoodle12 a day ago | parent | next [-]

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

▲

kstrauser a day ago | parent | next [-]

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

▲

lucb1e a day ago | parent [-]

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)

▲

kstrauser a day ago | parent [-]

Consensus from friends after I posted that is that attackers monitor the Let's Encrypt transparency logs and pounce on new entries the moment they're created. Here I was using Caddy, which by default uses LE to create a cert on any hosts you define.

I can definitely reproduce this. It shocked me so much that I tried a few times:

1. Create a new random hostname in DNS.

2. `tail -f` the webserver logs.

3. Define an entry for that hostname and reload the server (or do whatever your webserver requires to generate a Let's Encrypt certificate).

4. Start your stopwatch.

▲

lucb1e a day ago | parent [-]

Thanks! CT logs do explain it. So it's not actually the DNS entry or vhost, but the sharing of the new domain in a well-known place. That's making a lot more sense to me! I can see how that happens unwittingly though

We also use CT logs at work to discover subdomains that customers forgot about and may host vulnerable software at (if such broad checks are in the scope that the customer contracted us to check)

▲

kstrauser a day ago | parent [-]

Yep, that’s right. And I guarantee, like would bet my retirement savings on it, that someone today has counted on security through obscurity and not realized their new website was compromised a few seconds after they launched it for the first time ever. “I just registered example.com. No one’s ever even heard of it! I’ll just have to clean it up before announcing it”, not realizing they announced it when they turned the server on.

3 seconds.

▲

snickerdoodle12 21 hours ago | parent [-]

I had a similar fun experience when I was generating UUID subdomains and was shocked to see traffic in the logs before ever sharing the URL. I've since switched to a wildcard certificate but regardless, you can't really trust the hostname to be secret because of SNI and all that.

	▲	kstrauser 7 hours ago \| parent [-]
		That would’ve been quite the surprise! I was initially shocked enough when @ and www were getting hammered. A fully random hostname would’ve dazzled me for a bit.

▲

LeifCarrotson a day ago | parent | prev | next [-]

> Huh, so anyone who can access my web server can access the installation script?

"Obviously", the server should not be accessible from the public Internet while you're still doing setup. I assume it should still behind a firewall and you're accessing it by VPN. Only after you're happy with all the configuration and have the security locked down tight would you publish it to the world. Right?

	▲	a day ago \| parent \| next [-]
		[deleted]
	▲	snickerdoodle12 a day ago \| parent \| prev [-]
		Obviously you should lock it down. I'm just going off these instructions and how they might be interpreted.

▲

reconnecting a day ago | parent | prev [-]

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 a day ago \| parent [-]
		> as it's the usual installation process of any PHP application Maybe a decade ago. Look into composer.

▲

kassner a day ago | parent | prev [-]

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 a day ago \| parent [-]
		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