Re: [mod-security-users] Proxying a request based on RESPONSE_STATUS
Brought to you by:
victorhora,
zimmerletw
From: Christian B. <ch...@do...> - 2007-01-29 10:51:05
|
Am 29.01.2007 um 10:16 schrieb =E0=B7=83=E0=B7=94=E0=B6=B8=E0=B7=92=E0=B6=AD= =E0=B7=8A =E0=B6=9C=E0=B6=B8=E0=B6=9C=E0=B7=9A: > Hello, > > We already use mod_rewrite & mod_proxy to send our requests to > different application server keeping apache as the front end server. > > # Basic rewrite configurations > RewriteEngine on > RewriteLog "logs/mod_rewrite_log" > RewriteLogLevel 1 > > # Possible multiple URIs for Login page > RewriteCond %{REQUEST_URI} ^/$ [OR] > RewriteCond %{REQUEST_URI} ^/ap/?$ [OR] > RewriteCond %{REQUEST_URI} ^/ap/servlet/main$ [OR] > RewriteCond %{REQUEST_URI} ^/ap/UserLoginView$ > > # Rewrite all login URIs to a single common URI > RewriteRule ^/ap(.*)$ http://%{SERVER_NAME}:8001/ap/servlet/main > [R=3Dpermanent,L] > > # All posts are handled by one server > ProxyPass /ap/posts http://post.handler.com:8002/ap/posts > ProxyPassReverse /ap/posts http://post.handler.com:8002/ap/posts > > # All quiries are handled by another server > ProxyPass /ap/quiries http://http://post.handler.com:8003/ap/=20 > quiries > ProxyPassReverse /ap/quiries http://http://post.handler.com:=20 > 8003/ap/quiries > > So far this works fine. > > Our next requirement is to proxy a request based on the > RESPONSE_STATUS from the original application server. I thought to use > SecRule as follows to accommodate this requirement: > > # Basic mod_security configurations > SecRuleEngine On > SecRequestBodyAccess On > SecResponseBodyAccess On > SecUploadKeepFiles Off > > # Debug log > SecDebugLog logs/modsec_debug_log > SecDebugLogLevel 9 > > # Serial audit log > SecAuditEngine RelevantOnly > SecAuditLogRelevantStatus ^5 > SecAuditLogParts ABIFHZ > SecAuditLogType Serial > SecAuditLog logs/modsec_audit_log > > SecRule RESPONSE_STATUS 404 > "log,deny,phase:3,proxy:http://backup.server.com:8004" > SecRule RESPONSE_STATUS 503 > "log,deny,phase:3,proxy:http://backup.server.com:8004" > > When I use above SecRules, they are not considered since execution > escape phase 3 & 4. > =3D=3D> logs/modsec_debug_log <=3D=3D > Initialising transaction (txid JSSDXgoAAAMAABOHVacAAAAD). > Transaction context created (dcfg 8d8b200). > Starting phase REQUEST_HEADERS. > This phase consists of 0 rule(s). > Second phase starting (dcfg 8d8b200). > Input filter: This request does not have a body. > Time #1: 384 > Starting phase REQUEST_BODY. > This phase consists of 0 rule(s). > Time #2: 475 > Hook insert_filter: Adding output filter (r 8e31960). > Initialising logging. > Starting phase LOGGING. > This phase consists of 0 rule(s). > Audit log: Logging this transaction. > > If I use phase 5 to evaluate the rules as follows: > SecRule RESPONSE_STATUS 404 > "log,deny,phase:5,proxy:http://backup.server.com:8004" > SecRule RESPONSE_STATUS 503 > "log,phase:5,proxy:http://backup.server.com:8004" > > It evaluates the rules but do not do proxy the request. > It cannot as the request has already been dealt with. RESPONSE_STATUS =20= is the application servers response and thus the result of the server =20= processing the request. When phase 5 has been reached, the whole =20 response is already on the way to the client (see page 27 of the the =20 mod_security documentation at http://www.modsecurity.org/=20 documentation/modsecurity-apache/2.1.0-rc6/modsecurity2-apache-=20 reference.pdf) You probably want to try phase:3 though I am not sure if it is =20 possible to re-insert the request to mod_proxy. Regards, Chris |