3 Replies Latest reply on Apr 6, 2012 12:22 PM by firemtn

    Smartfilter redirect fails for Google Chorme users

    firemtn

      Howdy,

       

      I have some users who prefer Chorme.  Lately the SF redirect isn't working for them.  I did some packet captures that shows some HTML  comming from the 70103 firewall proxy:

       

      GET /url?sa=t&rct=j&q=cgi%20proxy&source=web&cd=1&sqi=2&ved=0CDgQFjAA&url=http%3A%2 F%2Fwww.jmarshall.com%2Ftools%2Fcgiproxy%2F&ei=CAt_T7zxKabZiALkoayvAw&usg=AFQjCN G2sDVAaMatDdVn0E4SQotQE3iGkg HTTP/1.1

      Host: www.google.com

      Connection: keep-alive

      User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19

      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

      Referer: http://www.google.com/

      Accept-Encoding: gzip,deflate,sdch

      Accept-Language: en-US,en;q=0.8

      Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

      Cookie: PREF=ID=2d1a058ded5cb5ec:U=b4e2ec2ec55ae0d3:FF=0:TM=1333725128:LM=1333725138:S= aieCRqn0AJwsCrc7; NID=58=yzShkAzH8BpITgM6SmBiAZhxzb4qIOIC4ehmNw9rCx0LdKKpSoiUn7SQl4zQH4etNlqedtGn klj64Z5L_wZU1y29xSDzyichqiBwrUtkrv0dSQWFjNWXbPip8nM7H2IO

       

      HTTP/1.0 302 Found

      Content-Type: text/html

      Connection: close

      Content-Length: 297

      Location: http://192.168.166.10:9015/actionpage?basictype=block&epochseconds=1333725969&re questedurl=http%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3Dcgi%2520pr oxy%26source%3Dweb%26cd%3D1%26sqi%3D2%26ved%3D0CDgQFjAA%26url%3Dhttp%253A%252F%2 52Fwww.jmarshall.com%252Ftools%252Fcgiproxy%252F%26ei%3DCAt_T7zxKabZiALkoayvAw%2 6usg%3DAFQjCNG2sDVAaMatDdVn0E4SQotQE3iGkg&categorylist=102&categorydescriptionli st=Anonymizers&useripaddress=192.168.168.110&username=&actiontaken=block&actionr eason=by-category&actionreasondata=102&reputationdesc=&replayhash=YaMp6vX4iVqLPf Jl%2FmuUug%3D%3D

       

      <HTML><HEAD>

      <TITLE>Your request is being redirected</TITLE>

      </HEAD><BODY>

      <H1>Warning</H1>

      <H2>Your request is being redirected to SmartFilter</H2>

      <HR>

      <P>

      <UL>

      <LI>

      <STRONG>

      SmartFilter Redirect

      </STRONG>

      </UL>

      <P>

      Security policy does not allow your request to be completed.

      </BODY>

      </HTML>

       

      It only is Chrome users who have this problem.  I didn't see anything in the Audit that looked abnormal.  Has anyone else seen issues with Chrome and SF on Sidewinders?

       

      Thanks,

      Mike

        • 1. Re: Smartfilter redirect fails for Google Chorme users
          firemtn

          Ok,  I think I jumped the gun.  I did find an audit record that points to an issue:

           

          Apr  6 09:37:39 2012 PDT  f_http_proxy a_proxy t_attack p_minor

          pid: 76063 ruid: 0 euid: 0 pgid: 76063 logid: 0 cmd: 'httpp'

          domain: SFrp edomain: SFrp hostname: swex2.firemountain.local

          category: appdef_violation event: request header

          netsessid: 4f7f1bd30006dcb9 srcip: 192.168.168.110 srcport: 17529

          srcburb: internal dst_local_port: 9015 protocol: 6 src_local_port: 0

          dstip: 127.0.0.1 dstport: 9015 dstburb: Firewall

          attackip: 192.168.168.110 attackburb: internal

          rule_name: SmartFilter Redirect

          reason: Request denied with request header Origin.

           

          Could there be something wanky it the request header that breaks SF?

          • 2. Re: Smartfilter redirect fails for Google Chorme users

            Hello,

             

            According to the audit message above, the client (Chrome browser) is sending a header called "Origin" which is blocked by the application defense for Smartfilter Redirect.

             

            To work around this, you could go into the application defense for Smartfilter redirect and disable the "request header" options.

             

            -Matt

            • 3. Re: Smartfilter redirect fails for Google Chorme users
              firemtn

              That's sound advice Matt.  In App Defense->HTTP->SF Redirect->HTTP request->Denied Deader Action, I just selected the "Allow page through without denied headers" option.

               

              Good call!

               

              Thanks,

              Mike