Solved dotDefender An error occured. Action: get_site_list Exception: Invalid Response or Action: get_xpath Exception: Invalid Response

The full error:
Can’t init python Can’t import module can’t init python Traceback (most recent call last): File “C:\Program Files\Applicure\dotDefender for IIS\cgi-bin\WebServiceLib.py”, line 1, in from WebService_Utils
import * File “C:\Program Files\Applicure\dotDefender for IIS\cgi-bin\WebService_Utils.py”, line 1, in from WebService_OS import * File “C:\Program Files\Applicure\dotDefender for
IIS\cgi-bin\WebService_OS.py”, line 53, in from win32com.client import GetObject, Dispatch File “py26-sp\Lib\site-packages\win32com\client\__init__.py”, line 11, in import gencache File
“py26-sp\Lib\site-packages\win32com\client\gencache.py”, line 662, in __init__() File “py26-sp\Lib\site-packages\win32com\client\gencache.py”, line 58, in __init__ Rebuild() File
“py26-sp\Lib\site-packages\win32com\client\gencache.py”, line 649, in Rebuild _SaveDicts() File “py26-sp\Lib\site-packages\win32com\client\gencache.py”, line 65, in _SaveDicts f =
open(os.path.join(GetGeneratePath(), “dicts.dat”), “wb”) IOError: [Errno 13] Permission denied: ‘C:\\Windows\\TEMP\\gen_py\\2.6\\dicts.dat’

Solution:
I was logged into the admin site under an account that had been added post install using the add_user_permissions_IIS7.bat script. It seems this script misses adding some permissions. In my case I granted permissions to my user to the C:\Windows\Temp\gen_py
folder. I believe I gave them write permissions.

After a recent installation of dotDefender, the following error came up:
“Internal Server Error

500

No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_dotDefender.cgi): The subprocess exited with statu s 2 (ENOENT).”

The log file for dotDefender, /usr/local/APPCure-full/log/dotDefender_bpd.log, gives further detail:

The fix was to install Crypt::Passwd::XS as such:

Update 1-29-2016

This error popped up again, and seemingly coincided to an upgrade in cPanel.  The upgraded version is WHM 54.0 (build 8).  The error was almost identical to the one above, but instead of outputting the error to the dotDefender log, it was going to the cPanel log (/usr/local/cpanel/logs/error_log) as such:

~

Can’t locate cPanel/PublicAPI.pm in @INC (@INC contains: /usr/local/cpanel /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/cpanel/Cpanel/Accounting.pm line 32.

BEGIN failed–compilation aborted at /usr/local/cpanel/Cpanel/Accounting.pm line 32.

Compilation failed in require at /usr/local/cpanel/whostmgr/docroot/cgi/addon_dotDefender.cgi line 5.

BEGIN failed–compilation aborted at /usr/local/cpanel/whostmgr/docroot/cgi/addon_dotDefender.cgi line 5.

[2016-01-28 17:35:38 -0500] info [cpsrvd] Internal Server Error: “GET /cpsess122967374/cgi/addon_dotDefender.cgi HTTP/1.1” 500 No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_dotDefender.cgi): The subprocess reported error number 2 when it ended.

~~

Speaking with cPanel support,

This should be fixed. After further review we didn’t acutally rename all of these packages, it looks to maybe only be some API calls rather than the package. This was failing because the following file was modified.

[21:37:25 cp root@7449479 ~]cPs# head /usr/local/cpanel/Cpanel/Accounting.pm

ypackage cPanel::Accounting;

It should have been this looking at another server.

[21:40:42 cp root@7449479 ~]cPs# head Accounting.pm package Cpanel::Accounting;

Once I corrected that I could load the page. I did have a token error and had to login and then got an access error but I believe as root you should have no issue now.

~~~

The updated file correcting the issue is below:

Solved the following dotDefender error:

Error text:
An error occured.

Action: get_update_best_practice_rules_configuration

Exception: Invalid Response

Internet Information Services 7.5

Error Summary
HTTP Error 403.18 – Forbidden

The specified request cannot be processed in the application pool that is configured for this resource on the Web server.

Detailed Error Information

Module
IIS Web Core

Notification
BeginRequest

Handler
StaticFile

Error Code
0x00000000

Requested URL
http://127.0.0.1:80/Rejected-By-UrlScan?~/dotDefender/dotDefenderWS.exe

Physical Path
C:\inetpub\wwwroot\Rejected-By-UrlScan

Most likely causes: •An ISAPI filter or custom module changed the URL to run in a different application pool than the original URL.
•An ISAPI extension (or custom module) used ExecuteURL (or ExecuteRequest) to run in a different application pool than the original URL.
•You have a custom error page that is located in one application pool but is referenced by a Web site in another application pool. When the URL is processed, it is determined by IIS that that it should have been processed in the first application pool, not the other pool.
•The Web site has multiple applications configured. The application this request is configured to run in is set to run in an application pool that does not exist.

Things you can try: •If you have an application that is trying to process a URL in another application pool (such as trying to process a custom error), ensure that they both run in the same application pool if appropriate.
•If you are trying to process a custom error URL that is located in another application pool, enable the custom errors Redirect feature.
•Verify that the application pool for the application exists.
•Create a tracing rule to track failed requests for this HTTP status code and see if ExecuteURL is being called. For more information about creating a tracing rule for failed requests, click here.

Links and More InformationThis error occurs if the application pool for the request does not exist, or if an ISAPI filter, ISAPI extension or HTTP module calls the ExecuteURL server support function (or ExecuteRequest) with a URL that is configured in a different application pool. Due to security reasons, a Web site in one application pool cannot make ExecuteURL requests against a URL in another application pool. If you have an application that is trying to process a URL in another application pool, ensure that they both run in the same application pool if appropriate.
View more information »
Show details Reload current node

Screen shot:

Resolve:
I went to the ISAPI Filters for the site, saw the following:
UrlScan 3.1
C:\Windows\system32\inetsrv\urlscan\urlscan.dll
Local

Removed it, site specific, and was then able to browse to the admin section as expected.

UPDATE!!!

I found a better way to fix the issue.  Create an exclusion for dotDefender within URLScan, just like the installation instructions for dotDefender lists (http://www.applicure.com/downloads/5.11/dD-installation-guide-v5%2011_IIS.pdf), odd I know.

The file is found here:
%WINDIR%\System32\Inetsrv\URLscan
And is named
UrlScan.ini

Find the section for [AlwaysAllowedUrls] and add this line below it and above the following section:
/dotDefender/dotDefenderWS.exe ; Don’t filter requests to dotDefender

My config now has the follwoing section:
~~~~~~~~~
[AlwaysAllowedUrls]
;
; URLs listed here will always be explicitly allowed by UrlScan
; and will bypass all UrlScan checks. URLs must be listed
; with a leading ‘/’ character. For example:
;
; /SampleURL.htm
;
/dotDefender/dotDefenderWS.exe ; Don’t filter requests to dotDefender
~~~~~~~~~

Okay, I keep ‘forgetting’ how to test if dotDefender is in place and able to block requests. Long story short, a URL can be fashioned as such:
http://example.com/?id=variable’or1=1
in order to be able to trip the expected response: