IIS: Directory Structure and Pools with 32 versus 64b support.

[zimmerle]

In the IIS module overview documentation (http://www.iis.net/learn/get-started/introduction-to-iis/iis-modules-overview) the directory: "%windir%\system32\inetsrv" is used as an example, for native modules. This is the directory which we are trying to have ModSecurity installed in (Variation may happens depending on the Architecture). However, 64bits machines may have configured 32bits application pools, which leads ModSecurity not to be loaded.

The installer is detecting the machine architecture and try to guess the correct directory to install then, but it is not looking at the pool architecture. And of corse this configuration can be changed after ModSecurity got installed, leading ModSecurity to fail, and so the Application pool.

Probably the better way to handle that, is by having both versions (32 and 64b) installed making usage of the "preCondition" tag. PreCondition can be used with IIS to load a module only and only if a certain criteria is attended, which in our case, could be covered by the conditions "bitness32" or "bitness64". As example:

<globalModules>
  <add name="ManagedEngine"
image="%windir%\anotherFancyDirectory\ModSecurity-fancyVersion32.dll"
preCondition="bitness32" />
  <add name="ManagedEngine"
image="%windir%\anotherFancyDirectory\ModSecurity-fancyVersion64.dll"
preCondition="bitness64" />
</globalModules>

These are just ideas and it was not tested yet. This may be the path to avoid problems related to 32/64b selection as long as the correct paths to install ModSecurity.

More information on the preCondition as long as more information on IIS modules in general can be found here: http://programming4.us/website/5916.aspx

[corradolab]

Hi @zimmerle,

installing different modules with different bitness would work. The only issue is you cant use the same module name.You must create 2 different modules (ie ModSecurity and ModSecurity64).

The other way is leverage the WOW64 File System Redirection.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx
Any access to \Windows\system32 (from a 32 bit app on a 64 bit system) is automatically redirected to \Windows\SysWOW64.

So you can:

• copy your 64 bit dll in \Windows\system32\inetsrv\my_module.dll
• copy your 32 bit dll in \Windows\SysWOW64\inetsrv\my_module.dll
• install a single module referencing \Windows\system32\inetsrv\my_module.dll

CAUTION: All of the above should be done from a 64 bit process. If not File System Redirection will hurt you instead of help you (ie it will copy your 64 bit dll inside the 32 bit folder).

[zimmerle]

This was implemented using file system redirection and bitness property, the installer is now under tests, available at branch iis_installer: https://github.com/SpiderLabs/ModSecurity/tree/iis_installer

[zimmerle]

Fixed by: 831e598