Symlink attack mitigation

Discussion in 'Installation/Configuration' started by Vega777, May 23, 2022.

  1. Vega777

    Vega777 New Member HowtoForge Supporter

    I have a question related to symlink attack mitigation. I created Debian server based on and made a test with FOX WSO tool
    I was able to get configuration files of CMS (wordpress, joomla,...) from others clients folders. (permissions - 644). It seems that the file was able to read shadow file. It create Fox-C directory with customized .htaccess with Options All to disable SymLinksIfOwnerMatch
    Am I missing something in the configuration ?
    P.S.: Don't know what exactly the tool is doing, so do not test in prod environment.
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Check the config files that you were able to read, most likely someone set them to the wrong permissions as such files may never have 644 permissions. The files containing any login data from a CMS system must be set to chmod 700 or better 600 and owned by the webID user of the site they belong to and the client group of the site they belong to. If you make them world or group readable, then other websites might be able to read their content, so it#s important that only the web user of the site the files belong to can read them.

    Then a few other things, php mode of sites should be php-fpm, suexec must be enabled in the site settings to ensure each site runs as an individual Linux user.

    Then you should consider strengthening your PHP setup by disabling functions like exec, pathrough etc. for php-fpm.

    I guess it's more likely that it was able to read /etc/passwd file, as this file is world-readable on any Linux system. The /etc/shadow file is readable by the root user only, so this should not be readable.

    SymLinksIfOwnerMatch is already the default and set for any vhost created by ISPConfig, so ISPConfig implements this symlink attack prevention by default. But you can easily limit the ability to which functions can be used in .htaccess files to prevent those functions might be overridden or disabled on the options tab of the website in ISPConfig.
  3. Vega777

    Vega777 New Member HowtoForge Supporter

    I'll consider changing default umask for pure-ftp to 600. It's hard to explain client to change permissions or at least set up cron job, changing permissions on known configuration files.

    Currently running fast-cgi + suexec. Maybe changing to php-fpm + suexec + Chroot PHP-FPM

    This is tricky - Don't want to have it as default and also not to set up for every webpage

    Need to take a look on details how to protect SymLinksIfOwnerMatch and allow most of the other options
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    You can set this on the options tab per website too in ISPConfig and using directive snippets might also be a way to make such custom configs easily available.

    Yes, that's always the problem, disabling functions there leads to filed CMS installations, that#s the reason why we do not disable too much there by default, people would simply say iSPConfig is not working if out of the box installs of popular cms fail just because the .htaccess files they deliver contain rules that violate strict setups.
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Just one more point to consider, please be aware that when using php-fpm chroot then you can't connect to MySQL anymore using 'localhost', you have to use '' then instead, which might confuse your users. the reason is that 'localhost' in PHP MySQL connections is a socket and that socket is outside of the jail when using chroot therefore you must use the localhost IP instead of the word localhost.

Share This Page