Security Link in ACP

[Davyc]

Is me or is the security link in the ACP menu missing?  This is link that gave you recommendations and made some fixes for you like making global.php non-writable.

Either I'm going nuts or it's not there in 4.3 Beta

[Mark]

You're not going nuts - those warnings have been updated (some were a bit out of date) and moved to the AdminCP dashboard so that you're more likely to actually see them.

[Davyc]

Aye, I noticed them in the dashboard.  It's a shame that some of them have been removed, making folders secure and making global.php non-writable and a few others that were helpful; it kind of made things a little smoother for those not really in the knowhow of changing things.  Any chance of them returning in an updated format?  It can be unnerving for a newbie to see all those dashboard warnings with no explanation as to what to do about them.

Thanks @Mark for telling me I'm not going nuts lol.

[The Old Man]

They were certainly useful time saving tools. The folder permissions tool was handy on a live server, but it also caused mayhem on local Win 10 XAMPP test install, until I found out what was causing my CSS to fail to load. 

Could you elaborate which results were outdated, please @Mark?

The one I always worry about is folder/file permissions being wrongly set or changed, the System Check button tells you if folders are writable but I never know if it warns you when some are when they in fact shouldn't be, especially if it's leftover folders from outdated versions that the upgrader didn't move their contents from or delete.

 

[Lindy]

We scrapped our recommendation for things like custom named admin directories, which now actually cause more trouble than they help and were introduced when a time when obfuscation was better than nothing. Now, there are much better solutions such as 2FA, web application firewalls and IP restrictions. 

Dangerous security concerns such as allowing exec() and system PHP commands are now in-line on the dashboard where they are more likely to be addressed. Things like file permissions should be addressed in the support tool. 

If you note anything that's missed in the support tool or are confused about anything being shown on the dashboard, please let us know specifics so we can address them. 

[Davyc]

@Lindy For me it's the dangerous commands.  I can't get any traction with my host as I'm on a shared package.  I can create an php.ini file with those commands disabled, but putting it in the root does nothing, putting it in the admin folder clears the error; however, I've noted that putting it in the admin folder is a kind of cheat and only clears the warning and does not make these commands safe.  The only solution, and one that is not practical, is to put that php.ini file into every folder and sub-folder.

One solution is to change packages where I have more control - but this pushes costs above what is comfortable and so is an option low down the ladder.  How dangerous are these commands if they are left alone?  Obviously you raise the issue to make us aware, but many like me are not really that savvy when it comes to server level functions.  

I attempted to add some code to the .htaccess file that was supposed to make the php.ini file recursive, but that just caused server errors (after many attempts of trying it different ways).

I've had to remove my forum and put it in stasis until I can find a solution as I don't feel comfortable with these warnings, so any ideas or information or help would be appreciated.

 

[Lindy]

Davyc, I'd recommend finding a new host (might I suggest www.invisioncommunity.com/buy ? ) Having those commands enabled, especially in a shared hosting environment is simply reckless. PHP has functionality called open_basedir that prevents a PHP script from "breaking out" of your account. In other words, let's say another customer on your server is running a PHP script full of security holes and an attacker exploits it. With in-built PHP security precautions (open_basedir) - an attacker should not be able to break out of that account housing the vulnerable script, meaning, they cannot use that script to get to other accounts on the server (including yours.) 

The issue is, the commands we recommend be disabled are system level commands. These completely bypass open_basedir. Using exec, system, passthru and the other listed commands in that scenario, an attacker simply needs to find one vulnerable account on the entire server and upload a "shell" script... because those commands are enabled, they can very easily browse other accounts on the server, read your conf_global to get your database details, then dump, alter or even drop your database. 

Disabling those commands isn't just protection from outside attackers directly on your site, it's also to protect your account from other accounts. Again, if your host won't disable them (server-wide), get another host, even if it's not us. It's akin to renting an apartment, finding all of your neighbors' keys fit your apartment and your landlord won't do anything about it. 

[Davyc]

WoW!  Now that's the kind of information that makes sense and I will most certainly be changing hosts unless they play ball and get their heads around this; I'll give them a chance and if they don't want to listen I'm off. Thank you so much for that detailed explanation - I may know my way around html, css and some javascript, but server-side stuff is not in my remit.  I would love to come to CiC, but I mentioned (somewhere) that I have other sites that need a home and it's much easier to have them all in one place.  Time for me to get looking!

Many thanks again, it's very much appreciated.