For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

David_Noonan_67's avatar
David_Noonan_67
Icon for Nimbostratus rankNimbostratus
Sep 20, 2011

Would this rule cause user problems?

I want to use HSL to log connections but I want one URI to get a slightly modified log entry. I can up with this modification of a working rule. The original logged on SERVER_CONNECTED but that didn't seem to let me access HTTP:uri, hence the change to HTTP_REQUEST.

 

 

I'm under the impression that if I don't include a redirect or rewrite or do anything to the traffic then it should do the logging in the irule and proceed with it's normal operation. Is that incorrect?

 

 

About 4-5 minutes after I applied the iRule the servers apparently showed down. I've since learned that the tests failing were both going to the VIP and going directly to the server (bypassing the irule) but before we put the rule back I have to validate that it wasn't the source of the problem.

 

 

Thanks

 

 

when HTTP_REQUEST {

 

set HSL [HSL::open -proto UDP -pool syslog-pool]

 

set FrontEnd "[IP::client_addr]:[TCP::client_port] <-> [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"

 

set BackEnd "[IP::local_addr]:[TCP::local_port] <-> [serverside {IP::remote_addr}]:[TCP::server_port]"

 

set Uri [HTTP::uri]

 

if {$Uri equals "/foobar/foobarweb/login.aspx"} {

 

HSL::send $hsl "<190> HSL: FooBar: $FrontEnd | $BackEnd"

 

}

 

else {

 

Log connection details as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info

 

HSL::send $HSL "<190> HSL: $FrontEnd | $BackEnd"

 

}

 

}

 

 

application delivery
dev
devops
iRules

6 Replies

  • David_Noonan_67's avatar
    David_Noonan_67
    Icon for Nimbostratus rankNimbostratus
    Sep 20, 2011
    The iRule below is also applied to that VS but I don't think the two conflict (unless it's bad to have multiple HTTP_REQUEST events being called.

     

     

    when HTTP_REQUEST {

     

    set fqdn_name [HTTP::host]

     

    }

     

    when HTTP_RESPONSE {

     

    if { [HTTP::is_redirect] }{

     

    if { [HTTP::header Location] starts_with "/" }{

     

    HTTP::header replace Location "https://$fqdn_name[HTTP::header Location]"

     

    } else {

     

    HTTP::header replace Location "[string map {'http://' 'https://'} [HTTP::header Location]]"

     

    }

     

    }

     

    }
  • David_Noonan_67's avatar
    David_Noonan_67
    Icon for Nimbostratus rankNimbostratus
    Sep 20, 2011
    Anyone? I'm just looking for confirmation that there's nothing in that irule combination that would interrupt traffic.

     

     

    Thanks
  • Brian_69413's avatar
    Brian_69413
    Icon for Nimbostratus rankNimbostratus
    Sep 20, 2011
    I am not familiar with HSL, but theoretically no logging statements should interfere with user traffic. I do think it is bad practice to use variable names that coincide with functions. I have used multiple iRules with HTTP_REQUEST events, but I have never seen anything official on whether that is OK.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Sep 20, 2011
    Hi David,

    A server hasn't been selected in HTTP_REQUEST so you can't access the server IP in that event. I'd move the HSL::send command to SERVER_CONNECTED and save the values you need for any HTTP request command values to local variables in HTTP_REQUEST.

    Here's an example: 

    
when CLIENT_ACCEPTED {
  set hsl_conn [HSL::open -proto UDP -pool syslog-pool]
}
when HTTP_REQUEST {
  set FrontEnd "[IP::client_addr]:[TCP::client_port] <-> [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
  set Uri [string tolower [HTTP::uri]]
}
when SERVER_CONNECTED {
  set BackEnd  "[IP::local_addr]:[TCP::local_port] <-> [serverside {IP::remote_addr}]:[TCP::server_port]"
  if {$Uri equals "/foobar/foobarweb/login.aspx"} {
    HSL::send $hsl_conn "<190> HSL: FooBar: $FrontEnd | $BackEnd"
  }
  else {
     Log connection details as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info
    HSL::send $hsl_conn "<190> HSL: $FrontEnd | $BackEnd"
  }
}

    Also, you could add logic to your HTTP redirect rewriting rule to handle a null or non-existent host header. You could set some default value if it's not present in the request.

    The two iRules should work find on the same virtual server.

    Aaron
  • David_Noonan_67's avatar
    David_Noonan_67
    Icon for Nimbostratus rankNimbostratus
    Sep 21, 2011
    Thanks, Aaron. I'll rewrite the iRule per your suggestions. Is there a guide/tutorial explaining BIG-IP events? I'm thinking of the order they happen and how to write scripts that cross events.

     

     

    Brian,

     

    I agree on the variable naming and don't remember why I did it that way since in other rules I've at least done something like "vUri" to distinguish the variable. I was probably in a hurry and willing to pay for it later. :-) (more likely not thinking about later)

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Sep 21, 2011
    Here is a post with info on events:

     

    http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/24619/showtab/groupforums/Default.aspx24622

     

     

    Very loosely, the HTTP:: commands are only available in HTTP events. Server related commands like IP::server_addr and TCP::server_port won't work until a serverside connection has been established in the SERVER_CONNECTED event.

     

     

    Aaron