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

Closed
zimmerle opened this Issue Jan 2, 2014 · 13 comments

Comments

Projects
None yet
4 participants
@zimmerle
Member

zimmerle commented Jan 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@corradolab

corradolab Jan 2, 2014

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 @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)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 3, 2014

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   

ghost commented Jan 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@corradolab

corradolab Jan 5, 2014

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 @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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 6, 2014

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....

ghost commented Jan 6, 2014

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

This comment has been minimized.

Show comment
Hide comment
@corradolab

corradolab Jan 6, 2014

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 @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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 6, 2014

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!

ghost commented Jan 6, 2014

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

This comment has been minimized.

Show comment
Hide comment
@zimmerle

zimmerle Jan 7, 2014

Member

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

Member

zimmerle commented Jan 7, 2014

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

@lewaaa

This comment has been minimized.

Show comment
Hide comment
@lewaaa

lewaaa Feb 12, 2014

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

lewaaa commented Feb 12, 2014

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

@zimmerle

This comment has been minimized.

Show comment
Hide comment
@zimmerle

zimmerle Feb 19, 2014

Member

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

Member

zimmerle commented Feb 19, 2014

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

@zimmerle

This comment has been minimized.

Show comment
Hide comment
@zimmerle

zimmerle Feb 26, 2014

Member

Fixed by: 831e598

Member

zimmerle commented Feb 26, 2014

Fixed by: 831e598

@zimmerle zimmerle closed this Feb 26, 2014

@zimmerle

This comment has been minimized.

Show comment
Hide comment
@zimmerle

This comment has been minimized.

Show comment
Hide comment
@zimmerle

zimmerle Feb 26, 2014

Member

@lewaaa have a look on this daily release that i have just shared.

Member

zimmerle commented Feb 26, 2014

@lewaaa have a look on this daily release that i have just shared.

@lewaaa

This comment has been minimized.

Show comment
Hide comment
@lewaaa

lewaaa Feb 27, 2014

Installer worked fine for me! (Win 8.1, 64b)
Thanks!

lewaaa commented Feb 27, 2014

Installer worked fine for me! (Win 8.1, 64b)
Thanks!

@zimmerle zimmerle added this to the testing milestones milestone Mar 27, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment