Forum Discussion

skahler_85363's avatar
skahler_85363
Icon for Nimbostratus rankNimbostratus
Jun 06, 2008

iRule not always processing

I had emailed support to answer my question and the response back was that this was an iRule question and they seemed to infer I'd be best to ask here first.

 

 

I have written a very simple I rule to catch the word gadget in UserAgent string because the service I run get's nailed with badly written Windows Vista gadgets, to the tune of 1.5 million requests per hour. When I placed my servers behind the LTM with this iRule in place I was still seeing about 30,000 requests come through per day that contained gadget in the UserAgent string. It must be working because it's filtering out the lion's share of them and my logs tell me that all the requests are going through the LB and not getting around it some how.

 

 

So my question is: In what cases would the logic for an iRule not be applied to request passing through the LB?

 

 

application delivery
dev
devops
iRules

4 Replies

Sort By
  • skahler_85363's avatar
    skahler_85363
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    Here's my iRule

     

     

    when HTTP_REQUEST {

     

    if { [string match "*gadget*" [HTTP::header Referer] ] } {

     

    discard

     

    }

     

    }

     

     

    and a request coming through while it was in place

     

     

    172.20.2.106 - - [30/May/2008:00:14:13 -0500] "GET /blah.blah.com/blah.gif HTTP/1.1" 304 0 "x-gadget:///blah.htm" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"

     

     

    I apologize as the original post said User-Agent and it's Referer. There are other gadget requests out there I'm looking to block as well as x-gadget and thus the wildcards.

     

     

    It's my first iRule so maybe I'm missing something obvious
  • Andy_Herrman_22's avatar
    Andy_Herrman_22
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    Could it be a case issue? You're matching against "*gadget*", but is it possible something is coming in with "Gadget"?

     

     

    If so, you'd want to make the referer lowercase before doing the match.

     

     

    Otherwise, I don't see anything bad in your irule (assuming the referer is the only place you'd need to check).
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    I think the following a more simpler iRule:

     

     

       
   when HTTP_REQUEST {   
      if { [HTTP::header "Referer"] contains "gadget" } {   
           discard   
      }   
   }

     

    This simply means that if you have a referer that contains gadget anywhere in the header field it will discard. For example it was discard "gadget, disgadget, mothergadget, papagadget, gogogadgetchopper, etc" However, I am not sure if it's case sensitive. If it is then it the code could be written as the following:

     

       
   when HTTP_REQUEST {   
      if { [string tolower [HTTP::header "Referer"]] contains "gadget" } {   
           discard   
      }   
   }

     

     

    Click here if you want to look at HTTP::header function more closely.

     

     

    Hope this helps

     

    CB

     

  • skahler_85363's avatar
    skahler_85363
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    Thanks I like that rule better as it's a little more clean and readable in my opinion. It's what I'll use I put this back into place.

     

     

    It's not a case issue as in my access logs what is passing through matches the same case of iRule, as I'm trying to note in my log string there which is an edited (to protect the innocent ) version of an actual request.

     

     

    Another question you may be able to answer for me, is there an advantage to using reject over discard/drop in a application with high connection numbers?

     

     

    SK