load different robots in the same one "server" block<br> <br> location ~ /robots.txt<br>
{<br>
if ($host = 'first.domain') {<br>
rewrite ^/robots\.txt /path/to/another/robots.txt last;<br>
}<br>
}<br><br>zhys9<br><div><includetail><div> </div><div> </div><div style="color: rgb(0, 0, 0);"><div style="font-size: 12px; font-family: Arial Narrow; padding: 2px 0pt;">------------------ Original ------------------</div><div style="font-size: 12px; background: none repeat scroll 0% 0% rgb(239, 239, 239); padding: 8px;"><div id="menu_sender"><b>From: </b> "nginx-request"<nginx-request@nginx.org>;</div><div><b>Date: </b> Sat, May 22, 2010 01:33 AM</div><div><b>To: </b> "nginx"<nginx@nginx.org>; </div><div></div><div><b>Subject: </b> nginx Digest, Vol 7, Issue 47</div></div><div> </div>
Send nginx mailing list submissions to<br> nginx@nginx.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://nginx.org/mailman/listinfo/nginx<br>or, via email, send a message with subject or body 'help' to<br> nginx-request@nginx.org<br><br>You can reach the person managing the list at<br> nginx-owner@nginx.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of nginx digest..."<br><br><br>Today's Topics:<br><br> 1. Re: loading a different robots.txt file for a different sub<br> domain? (Ray)<br> 2. Re: loading a different robots.txt file for a different sub<br> domain? (Ray)<br> 3. Re: loading a different robots.txt file for a different sub<br> domain? (Ilan Berkner)<br> 4. Re: loading a different robots.txt file for a different sub<br> domain? (Igor Sysoev)<br> 5. nginx 0day exploit for nginx + fastcgi PHP (Avleen Vig)<br> 6. Re: nginx 0day exploit for nginx + fastcgi PHP (Avleen Vig)<br> 7. Re: nginx 0day exploit for nginx + fastcgi PHP (Michael Shadle)<br> 8. Re: nginx 0day exploit for nginx + fastcgi PHP (Michael Shadle)<br> 9. Re: nginx 0day exploit for nginx + fastcgi PHP (Igor Sysoev)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Fri, 21 May 2010 21:53:45 +0800<br>From: Ray <gunblad3@gmail.com><br>To: nginx@nginx.org<br>Cc: nginx@sysoev.ru<br>Subject: Re: loading a different robots.txt file for a different sub<br> domain?<br>Message-ID:<br> <AANLkTilS4qcF-LEDsGXyml1zu2YspTj6wSrRQHGq48-N@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Yes.<br><br>server {<br> listen 80 default;<br> server_name www;<br><br> location /robots.txt {<br> alias /path/to/the/file1;<br> }<br>}<br><br>server {<br> listen 80;<br> server_name server2;<br><br> location /robots.txt {<br> alias /path/to/the/file2;<br> }<br>}<br><br><br>Ray.<br><br><br>On Fri, May 21, 2010 at 9:43 PM, Ilan Berkner <iberkner@gmail.com> wrote:<br>> Hi All,<br>> We have 2 sub-domain groups setup for processing incoming requests:<br>> 1. "server2"<br>> 2. all others, for example: "www"<br>> The 2 sub-domains share the same directory for delivery of static files<br>> (html, images, swf, etc.) but use different PHP backends.<br>> Is there a way, using nginx configuration to load a different robots.txt<br>> file when requested for one group vs. the other?<br>> Thanks!<br>><br>><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br>><br>><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Fri, 21 May 2010 21:53:45 +0800<br>From: Ray <gunblad3@gmail.com><br>To: nginx@nginx.org<br>Cc: nginx@sysoev.ru<br>Subject: Re: loading a different robots.txt file for a different sub<br> domain?<br>Message-ID:<br> <AANLkTilS4qcF-LEDsGXyml1zu2YspTj6wSrRQHGq48-N@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Yes.<br><br>server {<br> listen 80 default;<br> server_name www;<br><br> location /robots.txt {<br> alias /path/to/the/file1;<br> }<br>}<br><br>server {<br> listen 80;<br> server_name server2;<br><br> location /robots.txt {<br> alias /path/to/the/file2;<br> }<br>}<br><br><br>Ray.<br><br><br>On Fri, May 21, 2010 at 9:43 PM, Ilan Berkner <iberkner@gmail.com> wrote:<br>> Hi All,<br>> We have 2 sub-domain groups setup for processing incoming requests:<br>> 1. "server2"<br>> 2. all others, for example: "www"<br>> The 2 sub-domains share the same directory for delivery of static files<br>> (html, images, swf, etc.) but use different PHP backends.<br>> Is there a way, using nginx configuration to load a different robots.txt<br>> file when requested for one group vs. the other?<br>> Thanks!<br>><br>><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br>><br>><br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Fri, 21 May 2010 10:03:10 -0400<br>From: Ilan Berkner <iberkner@gmail.com><br>To: nginx@nginx.org<br>Subject: Re: loading a different robots.txt file for a different sub<br> domain?<br>Message-ID:<br> <AANLkTikoFCyB0tcDBCeXAeO-fhYM290irFASrg9h90Q1@mail.gmail.com><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Worked like a charm, thanks!<br><br><br>On Fri, May 21, 2010 at 9:53 AM, Ray <gunblad3@gmail.com> wrote:<br><br>> Yes.<br>><br>> server {<br>> listen 80 default;<br>> server_name www;<br>><br>> location /robots.txt {<br>> alias /path/to/the/file1;<br>> }<br>> }<br>><br>> server {<br>> listen 80;<br>> server_name server2;<br>><br>> location /robots.txt {<br>> alias /path/to/the/file2;<br>> }<br>> }<br>><br>><br>> Ray.<br>><br>><br>> On Fri, May 21, 2010 at 9:43 PM, Ilan Berkner <iberkner@gmail.com> wrote:<br>> > Hi All,<br>> > We have 2 sub-domain groups setup for processing incoming requests:<br>> > 1. "server2"<br>> > 2. all others, for example: "www"<br>> > The 2 sub-domains share the same directory for delivery of static files<br>> > (html, images, swf, etc.) but use different PHP backends.<br>> > Is there a way, using nginx configuration to load a different robots.txt<br>> > file when requested for one group vs. the other?<br>> > Thanks!<br>> ><br>> ><br>> > _______________________________________________<br>> > nginx mailing list<br>> > nginx@nginx.org<br>> > http://nginx.org/mailman/listinfo/nginx<br>> ><br>> ><br>><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://nginx.org/pipermail/nginx/attachments/20100521/dc7ff991/attachment-0001.html><br><br>------------------------------<br><br>Message: 4<br>Date: Fri, 21 May 2010 18:24:01 +0400<br>From: Igor Sysoev <igor@sysoev.ru><br>To: nginx@nginx.org<br>Subject: Re: loading a different robots.txt file for a different sub<br> domain?<br>Message-ID: <20100521142401.GD72328@rambler-co.ru><br>Content-Type: text/plain; charset=koi8-r<br><br>On Fri, May 21, 2010 at 10:03:10AM -0400, Ilan Berkner wrote:<br><br>> Worked like a charm, thanks!<br><br>You may also use:<br> location = /robots.txt {<br> <br>> On Fri, May 21, 2010 at 9:53 AM, Ray <gunblad3@gmail.com> wrote:<br>> <br>> > Yes.<br>> ><br>> > server {<br>> > listen 80 default;<br>> > server_name www;<br>> ><br>> > location /robots.txt {<br>> > alias /path/to/the/file1;<br>> > }<br>> > }<br>> ><br>> > server {<br>> > listen 80;<br>> > server_name server2;<br>> ><br>> > location /robots.txt {<br>> > alias /path/to/the/file2;<br>> > }<br>> > }<br>> ><br>> ><br>> > Ray.<br>> ><br>> ><br>> > On Fri, May 21, 2010 at 9:43 PM, Ilan Berkner <iberkner@gmail.com> wrote:<br>> > > Hi All,<br>> > > We have 2 sub-domain groups setup for processing incoming requests:<br>> > > 1. "server2"<br>> > > 2. all others, for example: "www"<br>> > > The 2 sub-domains share the same directory for delivery of static files<br>> > > (html, images, swf, etc.) but use different PHP backends.<br>> > > Is there a way, using nginx configuration to load a different robots.txt<br>> > > file when requested for one group vs. the other?<br>> > > Thanks!<br>> > ><br>> > ><br>> > > _______________________________________________<br>> > > nginx mailing list<br>> > > nginx@nginx.org<br>> > > http://nginx.org/mailman/listinfo/nginx<br>> > ><br>> > ><br>> ><br>> > _______________________________________________<br>> > nginx mailing list<br>> > nginx@nginx.org<br>> > http://nginx.org/mailman/listinfo/nginx<br>> ><br><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br><br><br>-- <br>Igor Sysoev<br>http://sysoev.ru/en/<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Fri, 21 May 2010 10:07:00 -0700<br>From: Avleen Vig <avleen@gmail.com><br>To: nginx@sysoev.ru<br>Subject: nginx 0day exploit for nginx + fastcgi PHP<br>Message-ID:<br> <AANLkTilDMa5NUSbwpGgBn3TDeG46ft-2fPwU9obxN8hA@mail.gmail.com><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>This is currently doing the rounds, so I thought it pertinent to post<br>it here too.<br><br>http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475<br><br>I don't know what nginx should do to fix this, but there are two<br>workarounds given.<br>If you allow file uploads (especially things like images) and use PHP<br>FastCGI in the back end, you should take a loot at this now.<br>The exploit allows for any arbitrary file which is uploaded, to be<br>executed as PHP.<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 21 May 2010 10:27:14 -0700<br>From: Avleen Vig <avleen@gmail.com><br>To: nginx@sysoev.ru<br>Subject: Re: nginx 0day exploit for nginx + fastcgi PHP<br>Message-ID:<br> <AANLkTik8cJNceX3z-E7NLs4ZYEZ11Y51XUETLVO_7MAA@mail.gmail.com><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>On Fri, May 21, 2010 at 10:07 AM, Avleen Vig <avleen@gmail.com> wrote:<br>> This is currently doing the rounds, so I thought it pertinent to post<br>> it here too.<br>><br>> http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475<br>><br>> I don't know what nginx should do to fix this, but there are two<br>> workarounds given.<br>> If you allow file uploads (especially things like images) and use PHP<br>> FastCGI in the back end, you should take a loot at this now.<br>> The exploit allows for any arbitrary file which is uploaded, to be<br>> executed as PHP.<br><br>I should add that this isn't a bug in the traditional broken-code sense.<br>More that this is a gaping configuration hole which is now widely<br>published, and could lead to many people being exploited.<br><br><br><br>------------------------------<br><br>Message: 7<br>Date: Fri, 21 May 2010 10:28:16 -0700<br>From: Michael Shadle <mike503@gmail.com><br>To: nginx@nginx.org<br>Cc: nginx@sysoev.ru<br>Subject: Re: nginx 0day exploit for nginx + fastcgi PHP<br>Message-ID:<br> <AANLkTimrR_aMpB2hhatNaDRkixYO-8LQDOmw5zPOoRrH@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Question is, what functionality is lost by changing<br><br>cgi.fix_pathinfo = 0<br><br>Looks like the other workaround is something like this:<br><br>if ( $fastcgi_script_name ~ \..*\/.*php ) {<br> return 403;<br>}<br><br>Which i basically saying what exactly? If there is a period and slash<br>somewhere prior to the last "filename" to return a 403?<br><br>Ideally while this is being thought out it would be cool to fix the<br>common "no input file specified" issue that a lot of people have -<br>have it return a 404 instead. Not sure if it's a simple php.ini change<br>(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?<br><br><br>On Fri, May 21, 2010 at 10:07 AM, Avleen Vig <avleen@gmail.com> wrote:<br>> This is currently doing the rounds, so I thought it pertinent to post<br>> it here too.<br>><br>> http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475<br>><br>> I don't know what nginx should do to fix this, but there are two<br>> workarounds given.<br>> If you allow file uploads (especially things like images) and use PHP<br>> FastCGI in the back end, you should take a loot at this now.<br>> The exploit allows for any arbitrary file which is uploaded, to be<br>> executed as PHP.<br>><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br>><br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Fri, 21 May 2010 10:28:16 -0700<br>From: Michael Shadle <mike503@gmail.com><br>To: nginx@nginx.org<br>Cc: nginx@sysoev.ru<br>Subject: Re: nginx 0day exploit for nginx + fastcgi PHP<br>Message-ID:<br> <AANLkTimrR_aMpB2hhatNaDRkixYO-8LQDOmw5zPOoRrH@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Question is, what functionality is lost by changing<br><br>cgi.fix_pathinfo = 0<br><br>Looks like the other workaround is something like this:<br><br>if ( $fastcgi_script_name ~ \..*\/.*php ) {<br> return 403;<br>}<br><br>Which i basically saying what exactly? If there is a period and slash<br>somewhere prior to the last "filename" to return a 403?<br><br>Ideally while this is being thought out it would be cool to fix the<br>common "no input file specified" issue that a lot of people have -<br>have it return a 404 instead. Not sure if it's a simple php.ini change<br>(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?<br><br><br>On Fri, May 21, 2010 at 10:07 AM, Avleen Vig <avleen@gmail.com> wrote:<br>> This is currently doing the rounds, so I thought it pertinent to post<br>> it here too.<br>><br>> http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475<br>><br>> I don't know what nginx should do to fix this, but there are two<br>> workarounds given.<br>> If you allow file uploads (especially things like images) and use PHP<br>> FastCGI in the back end, you should take a loot at this now.<br>> The exploit allows for any arbitrary file which is uploaded, to be<br>> executed as PHP.<br>><br>> _______________________________________________<br>> nginx mailing list<br>> nginx@nginx.org<br>> http://nginx.org/mailman/listinfo/nginx<br>><br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Fri, 21 May 2010 21:33:02 +0400<br>From: Igor Sysoev <igor@sysoev.ru><br>To: nginx@nginx.org<br>Subject: Re: nginx 0day exploit for nginx + fastcgi PHP<br>Message-ID: <20100521173302.GF72328@rambler-co.ru><br>Content-Type: text/plain; charset=koi8-r<br><br>On Fri, May 21, 2010 at 10:07:00AM -0700, Avleen Vig wrote:<br><br>> This is currently doing the rounds, so I thought it pertinent to post<br>> it here too.<br>> <br>> http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475<br>> <br>> I don't know what nginx should do to fix this, but there are two<br>> workarounds given.<br>> If you allow file uploads (especially things like images) and use PHP<br>> FastCGI in the back end, you should take a loot at this now.<br>> The exploit allows for any arbitrary file which is uploaded, to be<br>> executed as PHP.<br><br>I do not see why this is treated as nginx bug ?<br>Why is anyone able at all to upload images to /scripts directory ?<br>Why does PHP have cgi.fix_pathinfo option ?<br>BTW, I'm just curious how does lighttpd resolve this issue ?<br><br>Also instead of<br><br>if ( $fastcgi_script_name ~ \..*\/.*php ) {<br> return 403;<br>}<br><br>it should be worked around as<br><br>location ~ \..*/.*\.php$ {<br> return 403;<br>}<br><br>location ~ \.php$ {<br> return 403;<br>}<br><br><br>-- <br>Igor Sysoev<br>http://sysoev.ru/en/<br><br><br><br>------------------------------<br><br>_______________________________________________<br>nginx mailing list<br>nginx@nginx.org<br>http://nginx.org/mailman/listinfo/nginx<br><br><br>End of nginx Digest, Vol 7, Issue 47<br>************************************<br></div></includetail></div>