Unrecognized calls to PHP and .env in the logs of Universal

Hi,

I was working on a Rest API and watched the logs when I found something I do not recognize. Perhaps it is OK, perhaps I have an … issue :slight_smile:

I changed the subdomain and domain name as I am not 100% it is wise to share while I doubt these calls in my logs.
So sub.domain.com is a fake site address.

UniversalAutomation.GroomService Groom date is: 1/21/2025 6:45:02 PM
UniversalAutomation.GroomService Finished groom job.
Microsoft.AspNetCore.Hosting.Diagnostics Request starting HTTP/1.1 GET http://sub.domain.com/xampp/phpinfo.php - null null
Microsoft.AspNetCore.Hosting.Diagnostics Request finished HTTP/1.1 GET https://sub.domain.com/xampp/phpinfo.php - 404 0 null 13.244ms
Microsoft.AspNetCore.Hosting.Diagnostics Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://sub.domain.com/xampp/phpinfo.php, Response status code: 404
Microsoft.AspNetCore.Hosting.Diagnostics Request starting HTTP/1.1 GET http://sub.domain.com/lara/info.php - null null
Microsoft.AspNetCore.Hosting.Diagnostics Request finished HTTP/1.1 GET https://sub.domain.com/lara/info.php - 404 0 null 22.7197ms
Microsoft.AspNetCore.Hosting.Diagnostics Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://sub.domain.com/lara/info.php, Response status code: 404
Microsoft.AspNetCore.Hosting.Diagnostics Request starting HTTP/1.1 GET http://sub.domain.com/app/.env - null null
Microsoft.AspNetCore.Hosting.Diagnostics Request finished HTTP/1.1 GET https://sub.domain.com/app/.env - 404 0 null 16.0761ms
Microsoft.AspNetCore.Hosting.Diagnostics Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://sub.domain.com/app/.env, Response status code: 404
Microsoft.AspNetCore.Hosting.Diagnostics Request starting HTTP/1.1 GET http://sub.domain.com/dev/.env - null null
Microsoft.AspNetCore.Hosting.Diagnostics Request finished HTTP/1.1 GET https://sub.domain.com/dev/.env - 404 0 null 20.7351ms
Microsoft.AspNetCore.Hosting.Diagnostics Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://sub.domain.com/dev/.env, Response status code: 404
UniversalAutomation.GroomService Starting groom job.
UniversalAutomation.GroomService Groom date is: 1/21/2025 6:46:02 PM
UniversalAutomation.GroomService Finished groom job.
Microsoft.AspNetCore.Hosting.Diagnostics Request starting HTTP/1.1 GET http://sub.domain.com/new/.env - null null
Microsoft.AspNetCore.Hosting.Diagnostics Request finished HTTP/1.1 GET https://sub.domain.com/new/.env - 404 0 null 20.1132ms
Microsoft.AspNetCore.Hosting.Diagnostics Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://sub.domain.com/new/.env, Response status code: 404

I do not have, for example, I dot have the PHP file lara/nfo.php nor do I know of any lara path, heck I do not know anyone called lara! :slight_smile:
Same goes for xampp/phpinfo.php, I do not recognize this at all.

By the way, when I try these URL’s in a browser I get only a blank page

Anyone have any idea if these are legit calls?

I have Nginx Proxy Manager in front of Universal so anything I expose is going through that first.

Product: PowerShell Universal
Version: 5.2.3

Is this publicly facing? Seems like some sort of crawler.

Hi Adam,

yes it is public facing. I have a couple of DNS records pointing to my IP address and in Nginx I route traffic to the concerning docker container .
For Universal I have 1 separate DNS record and the / route points to an App or API. I always liked having access to the Apps on my mobile (some calculators related to bread baking and stuff like that) but I’m starting to think if that is wise or not…
I probably should look into Authelia or something like that, if I continue to have public facing Apps and/or API’s

But aside from that, you do not recognize this traffic?

If this needs to be locked down, what would you recommendation be, if I may be so bold to ask :slight_smile:

For extrainfo the first two urls there are ones for some common web server software.
/xampp/phpinfo.php is an apache web server url
/lara/nfo.php is, I think, Laravel php

What this looks like (to me) is a bot testing urls on the open port to determine what is running on the DNS/IP Address. Its definitely not PSUniversal traffic.

The least risky scenario is this is someone using a UI that has made a typo, a more dangerous scenario is something like bots scanning for vulnerabilities to exploit. If your Nginx setup is allowing any IP address to proxy into the PSU server from the internet then this sort of scan is only a matter of time typically.

Im not an Nginx expert, but maybe someone else will have some info on how that can be used to restrict access to only your phone from the internet if its currently allowing any internet address to reach the server

Thanks for the detailed response!

If your Nginx setup is allowing any IP address to proxy into the PSU server from the internet then this sort of scan is only a matter of time typically.

My Nginx setup does not restrict access to the Universal instance, there is no filtering on IP address or something like that. It’s a simple sub.domain.com catch and all traffic is routed to Universal. Inside Universal the path (/appname1 or /appname2 etc.) decides which app (or Rest API) is executed.
I could add IP filtering as a short-stop for the current concerns but I think I need a little bit more robustness in the long run.

Luckily, that traffic gets routed to a docker container running Universal so if someone has access then only to whatever the Universal container has, not the host.

I’m not super worried as this setup is more for personal hobby projects that have little to no value, so there’s “safety through stagnation” at the very least I would say :slight_smile:

Anyway, I have been thinking about adding MFA/OTP on top of Nginx to make all hosts routed through it safe(r).

Again, thanks for the insights, it helps!

2 Likes