php_uname #652
Replies: 2 comments
-
This describes what php_uname does There is zero benefit from a security perspective to disable this. (Unless of course they are doing it to hide the fact that they are running old and outdated software on their servers) |
Beta Was this translation helpful? Give feedback.
-
@mostafaafrouzi The TL;DR here is that your host is dangerously ignorant of what security is; you should run to a different host. I will of course provide more details below. If your host's security is based on disabling php_uname(), I can see two problems. First and foremost, they believe that their own clients will hack their servers, i.e. they know that a. their server has zero security (not even a properly configured mod_security2), therefore sites on it get routinely hacked by known security vulnerabilities they do not try to protect against and b. they have no security monitoring in place to identify suspicious behaviour which would allow them to suspend potentially hacked sites. That's too YOLO for a paid service, if you ask me. The second reason is that their actions tell me they believe in security through obscurity, which is no real security. Even more so when we need to consider that php_uname() is by far not the best or only method available for fingerprinting the server software. We could access the environment directly through the $_SERVER superglobal. We could shell out to /usr/bin/uname. We could read information directly from /etc/lsb-release. We could access the /proc filesystem. And so on and so forth. No think about why they would even want to use such a pointless "sEcUrIty" measure to begin with. The only reason the kind of person who'd find this a good idea would do it is to hide they fact they are running out-of-date software with known vulnerabilities from hacked sites on their server. However, if an attacker was to plan an attack against the server (as opposed to against a site) they would not idiotically try to hack a site just to do basic reconnaissance. Instead, they would use other tools such as nmap and metasploit (there are a lot more far more specialised tools) to probe the server directly for and exploit known vulnerabilities. Therefore, blocking php_uname() is just plain stupid and tells me very clearly that the host does not actually understand security. For this reason alone, I would go to a different host. Big red flag, run away. As for Panopticon, php_uname() is used to determine the server's hostname when sending emails (it's part of the PHPmailer library), as well as displaying that hostname in the connection setup page and the error page. We are not just using |
Beta Was this translation helpful? Give feedback.
-
Hi,
Great work!
The hosting company has disabled php_uname for security reasons.
Is it possible to use panopticon without php_uname?
Please explain a little about the reason for needing php_uname in the project so that we can send it to convince the hosting providers.
Best,
Mostafa.
Beta Was this translation helpful? Give feedback.
All reactions