IIS: Pick the correct version of the AppCmd while uninstall/install modsec on IIS

[zimmerle]

The AppCmd is used twice during the installation process of ModSecurityIIS. The first time is to install the DLL as part of IIS and the second is to configure it (enable and point the correct path of the modsecurity configuration file).

There are different versions of the AppCmd, one is 64bits and other one is 32bits, however, both are part of the IIS 64. The [un]install should pick the correct one.

As reported by @corradolab on bug #624 that the installer (version 2.7.7) is picking the incorrect version of AppCmd (At least on Windows 2008 R2). @corradolab also pointed a Technet link that contains information about which AppCmd to use:
http://technet.microsoft.com/en-us/library/cc730918(v=ws.10).aspx

The Technet document suggests that on 64bits machines the 64bits version of AppCmd should be used, however, it is not clear if there is any circumstance where the installer should pick the 32bits AppCmd on a 64bits machine. This issue is to discuss that and track the progress over the fact that the installer is picking the wrong AppCmd as initially reported by @corradolab.

[corradolab]

Hi @zimmerle,

on Windows x64, AppCmd (both 64 and 32 bit) configure the one and only IIS installed (which is 64 bit).
Using the 32 bit version with modules installed in \Windows\System32 is a bad idea due to File System redirection (see #628).

AppCmd 32 bit should not be used.
It's there for compatibility only (ie 32 bit applications invoking appcmd)

Hi, the installation using AppCmd or something else or by manual editing should add the following lines to the file applicationHost.config section <globalModules> to be compatible with both 32bit and 64bit application pools at the same time:

<add name="ModSecurityIIS-32" image="%SystemRoot%\syswow64\inetsrv\ModSecurityIIS.dll" preCondition="bitness32" />
<add name="ModSecurityIIS-64" image="%SystemRoot%\system32\inetsrv\ModSecurityIIS.dll" preCondition="bitness64" />            

It should look something like this if using Appcmd:

appcmd install module /name:ModSecurityIIS-32 /image:%SystemRoot%\syswow64\inetsrv\ModSecurityIIS.dll /preCondition:bitness32   

appcmd install module /name:ModSecurityIIS-64 /image:%SystemRoot%\system32\inetsrv\ModSecurityIIS.dll /preCondition:bitness64   

[corradolab]

Hi @Susfu, your solution would work but I would go for a single module, leaving to File System Redirection the job to select the right dll (64 or 32 bit).

In example:

• copy ModSecurityIIS.dll, 64 bit version, in \Windows\system32\inetsrv
• copy ModSecurityIIS.dll, 32 bit version, in \Windows\SysWOW64\inetsrv
• appcmd install module /name:ModSecurityIIS /image:%SystemRoot%\system32\inetsrv\ModSecurityIIS.dll

All of the above using 64 bit tools.

See #628

Hi @corradolab, yes, file system redirection should take care of it, but I prefer to specify the bitness on my servers, I have a feeling that it's more "foolproof". There are some cases where IIS has loaded a 64-bit module located under system32 in a 32-bit app pool. Check this link for example: http://blogs.msdn.com/b/carloc/archive/2009/02/04/service-unavailable-in-iis7-with-32-bit-application-pool.aspx
But if you make a real test using your example wiith modsecurity and a 32-bit app pool on a 64-bit server and it works OK, then relying on file system redirection is of course simpler....

[corradolab]

Hi @Susfu, it's not possibile to load 64 bit modules in 32 processes (nor vice versa).

The link you point out does not depict a 64 bit module loaded "by error" in a 32 bit pool.
Instead IIS try to load the 32 bit module (which should be in \Windows\sysWOW64\RpcProxy) but fails because no module is available there.

Don't let the requested path (\Windows\System32\RpcProxy) fool you. If this path is requested by a 32 bit app Windows will actually look inside \Windows\sysWoW64\RpcProxy.

BTW this is the way almost all modules in IIS get loaded. The only exception are the Net Framework ones, because Net Framework modules are not in Windows\System32\Inetsrv but in Windows\Microsoft.NET, which is not redirected.

If you want to go with explict bitness I would suggest to put not the modules inside \Windows\System32\Intesrv, but in your own directory (ie \Programs Files\ModSecurity) to avoid File System Redirection to kick in while it's actually not needed.

Hi, @corradolab, I have thought about it now and agree that it is probably the missing 32-bit rpcproxy.dll that is causing IIS to crash in the case from the link. I know of course that you can't load f ex 64-bit modules in a 32-bit process, what I ment was try to load... Bitness just acts as a filter against trying to load non existing modules or the wrong modules in some cases, f ex the .NET files under \Windows that can not be selected by file system redirection.

So i guess you can trust that file system redirection is always doing it's job, good to know!

[zimmerle]

Hey, thanks. This discussions is very valuable.

I will work on #640, before this one, so i can delivery something for you to test, before our release.

If you guys or anyone else that is following this discussion is interested to contribute in the code, the file that have to be updated is the wix installer script, available at: https://github.com/SpiderLabs/ModSecurity/blob/master/iis/installer.wxs

Are there any improvements about this topic?
It would be very appreciated, if anybody could provide a fixed installer...

[zimmerle]

Installer is under test at branch iis_installer: https://github.com/SpiderLabs/ModSecurity/tree/iis_installer

[zimmerle]

Fixed by: 831e598