Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
zimmerle opened this Issue · 3 comments

3 participants

@zimmerle
Owner

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
Owner

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
Owner

Fixed by: 831e598

@zimmerle zimmerle closed this
@zimmerle zimmerle added this to the testing milestones milestone
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.