.phps 403, .php.txt 500?!?

Discussion in 'General' started by deathshadow, Mar 23, 2014.

  1. deathshadow

    deathshadow New Member

    I followed the 'perfect setup debian wheezy' that's apache2 and ispconfig3... and it's working after a fashion, but I've got two bugs kind of pissing me off since I can't find a cause...

    First up, .phps files 403 -- trying to enable phps for normal operation or using a rewrite rule to point .phps files at my own handler doesn't seem to do jack -- in fact it appears that it's not even getting as far as noticing the .htaccess before it 403's.

    The log is of course the ultimately useless:
    [Sat Mar 22 17:02:05 2014] [error] [client] client denied by server configuration: /var/www/cutcodedown.com/web/template.phps

    That one expects from a 403 error.

    While the 100-cutcodedown.com.vhosts for it does indeed contain:
                    <Directory /var/www/cutcodedown.com/web>
                                    Options FollowSymLinks
                                    AllowOverride All
                                    Order allow,deny
                                    Allow from all
                    <Directory /var/www/clients/client2/web5/web>
                                    Options FollowSymLinks
                                    AllowOverride All
                                    Order allow,deny
                                    Allow from all
    It's apache 2.2 so adding that 'require' line a bunch of posts across different forums suggests takes the whole thing down (since that's a 2.4+ option only), NO, I have NOT installed mod_dosevasive (which seems to be another cause of this)...

    But worse, if I have filenames with more than one period in them, like say... template.php.txt -- instead of parsing as a txt file, it 500 errors and the log is... troubling.

    [Sat Mar 22 17:04:17 2014] [warn] [client] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
    [Sat Mar 22 17:04:17 2014] [error] [client] Premature end of script headers: template.php.txt

    ULTIMATELY I want it to run this rewriteRule I've used on dozens of hosts in the past for my own PHPS parser.

    RewriteRule \.phps$ /jdir/phpSource.php

    But I can't even get a clean install following this:

    To not 403 on .phps files -- that's out of box right at the end of it they 403, and a rewriterule to repoint ALL requests at a single file doesn't run, so it's not even getting as far as .htaccess?

    Anyone got a clue?
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Did you try to add your rewrite rule in the apache directives field of the website?
  3. deathshadow

    deathshadow New Member

    I can't even find that under ISPConfig 3... I knew where it was in 2... doesn't appear to even show under 3.

    Though it seems like 90%+ of the functionality is just GONE from 3... I'm half tempted to gut it, and dial back to lenny + 2 (which is what was mainstream last time I set up a system) given what a cripped wreck this seems to be by comparison.

    Or are the options like that hidden for some goofy reason? The 'redirect' tab something that looks kind-of like the old apache directives box shows for like a tenth of a second before the scripttardery and CSS kicks in.
  4. deathshadow

    deathshadow New Member

    Found it, was logged in as user not admin... unfortunately, no change, it's not even getting as far as processing those. (again a redirect of ALL requests is even ignored for those extensions!)
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Its exactly the same in ispconfig 2 and 3 that functions that would allow a user to take over the control of the server are only available for the admin and not the Client. And ispconfig 3 has about twice the functions of ispconfig 2.
  6. deathshadow

    deathshadow New Member

    Even so, once I found it they still do nothing for those file extensions. It doesn't even seem to be getting that far into it before it throws the 403; as in the 403 is occurring before either the .htaccess or ISPConfig's directives box is being run.

    USUALLY that's got something to do with <directories> in vHost, but damned if I can find where that's happening. I thought for a moment it might be because I had ssi and cgi disabled for that account, but no go on that either.

    I'm going through ALL the vHosts files, and even commenting out every "deny from all" and "deny, allow" from every single one of them is doing jack; what other than the allow/deny/from crap would cause JUST certain extensions to 403 and/or 500?

    The part about it trying to run .php.txt as a cgi (at least that's what the log entry looks like) is a serious whiskey tango foxtrot.

    REALLY don't want to wipe the server and start over AGAIN... but if it's going to be this big a pain in the ass for the simplest of functionality, I might have to do that and dial the clock back a few years on software versions. Of course, that's one of the reasons I use Debian in the first blasted place, so I don't have bleeding edge software that doesn't work yet.
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    Please take a look in the file:


    by default on current debian versions, this file denies access to phps files:

    <FilesMatch ".+\.phps$">
        SetHandler application/x-httpd-php-source
        # Deny access to raw php sources by default
        # To re-enable it's recommended to enable access to the files
        # only in specific virtual host or directory
        Order Deny,Allow
        Deny from all
    Thats not ispconfig specific btw, it is a debian default that has been changed from lenny to wheezy for security reasons.
  8. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    The second problem (.php.txt parsed by php) will be fixed until the next release.
    It is caused by AddHandler in Apache so we switch to SetHandler in combination with FilesMatch.
  9. deathshadow

    deathshadow New Member

    Thanks guys, that's what I needed -- was starting to think I was going nuts since my google-fu was failing me, as was going to the duck duck.

    Though I'm wondering what possible security issue having phps showing could cause -- the only issue in my mind might be the handler, at which point shouldn't they NOT ADD THE HANDLER instead of blocking access to the file?!?

    Seems really stupid -- though I'm finding with wheezy a lot of the reason I use Debian (stability, no bleeding edge not ready for primetime crap, not making new major releases that leave things broken/incomplete) has been thrown out the window... It's now just as stupid as using Ubuntu or Fedora based distributions.

    Oh, and if addHandler vs. setHandler is making a difference, I'd say the problem is likely more to do with the expression in the addHandler than addHandler itself. What file/location is causing that problem? Another set of eyes on it never hurts.

    ... and that deny, allow in the next section after the one that blocks PHPS... is even MORE stupid isn't it? What the devil possessed them to do this crap instead of, oh I don't know... fixing whatever is making them block all the files that are the entire reason to even RUN a server?!?

    *SIGH* time for me to start looking at other Distro's maybe? Gah, as it is I won't touch anything RH legacy... You take two years off, come back and everything's gone to ****.
    Last edited: Mar 25, 2014
  10. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    The AddHandler problem is not distribution-specific.
    It is mentioned in the php docs that using
    AddHandler xxxxxx .php
    will execute all .php.* with this handler.
    If you only want .php you need to do
    <FilesMatch "\.php$">
    SetHandler xxxxxx
    We changed this in ISPConfig now as it used AddHandler in the vhost template.

    Adding note:
    Using AddHandler syntax is like doing this:
    <FilesMatch "\.php">
    SetHandler xxxxxx
    notice the difference ;)

Share This Page