Forum Discussion

Nathan_Meyer_39's avatar
Nathan_Meyer_39
Historic F5 Account
Mar 06, 2006

ACL Rule to separate external from internal

The purpose of the rule is to add an extra layer of protection against stupid human administrator mistakes. The pair of BigIPs will be Load Balancing both external facing apps on servers in DMZ networks and internal facing apps. The intention is to make it a standard practice to enable this rule on all Virtual Servers. Possible mistakes that it could catch include assigning an internal pool to an external virtual server or accidentally adding an internal server to an external pool. This is not intended to guard against a malicious intentional act to expose internal data as the rule could simply be removed from the VIP.

 

 

The proposed rule is pasted below. I am looking for feedback on the rule itself, any syntax errors, and ways to make it more efficient.

 

 

For example, would the rule run faster and consume less resources if the "IF, Elseif, Else" statement was broken into 2 separate IF statements? Would that prevent processing of the "elseif" client_addr variable or is the substitution the same when its part of an "elseif" or a separate "IF" statement?

 

 

Would it be faster and more efficient to have an earlier event such as "when client_accepted" to evaluate that the client is internal or external and then terminate the rule or continue to the LB_SELECTED event to check the server address? The majority of the VIPs are external so the majority of the clients and servers should be external.

 

 

Also, is the REJECT statement the best way to get rid of those connections?

 

 

Is it possible for this rule to run with FastL4 or FastHTTP profiles?

 

 

iRule: Secure_Internal_Data

 

----------------------------------------------------------------------

 

RULE NAME: Secure_Internal_Data

 

AKA: catch stupid errors

 

 

Objective: Provide extra layer of security to keep external clients from

 

accessing internal data via misconfiguration

 

 

Guard against External facing VIPs Load Balanced to internal pools

 

Guard against Putting internal servers into external pools

 

 

Function 1: Allow all data requests to servers in the DMZ

 

Function 2: Allow all data requests from internal clients

 

Function 3: REJECT External client requests for Internal Server data

 

 

Requires data class dmznet which is address type list of dmz networks

 

Requires data class internalnet which is address type list of internal networks

 

 

Trigger rule after LB server is selected so server addresss can be resolved

 

 

when LB_SELECTED {

 

 

If LB Server IP is in the DMZ, allow access, terminate rule processing

 

If LB server is not in the DMZ, assume it is an internal data server

 

 

if { [matchclass [LB::server addr] equals $::dmznet] } {

 

return

 

log local0. "Allowed request for data on server [LB::server addr] found in dmznet list"

 

 

If the client IP is from an internal subnet, allow access. Terminate rule processing.

 

if the client IP is NOT from an internal subnet, assume it is an External client

 

 

} elseif { [matchclass [IP::client_addr] equals $::internalnet] } {

 

return

 

log local0. "Allowed data from internal client [IP::client_addr] found in internalnet list"

 

 

If rule is still processing at this point, assume server is Internal and client is external.

 

Reject Connection and Log it.

 

 

} else {

 

reject

 

log local0. "SECURITY ALERT!! External client [IP::client_addr] requested data from Internal server [LB::server addr]"

 

}

 

}

 

 

----------- iRule End -------------------

2 Replies

  • Nathan_Meyer_39's avatar
    Nathan_Meyer_39
    Historic F5 Account
    Thank you Colin. I very much appreciate your quick response to my quesions. This was my first serious iRule. Hopefully we'll have full validation of the functional tests in the next day or so.

     

     

    - Nathan Meyer

     

  • Nathan_Meyer_39's avatar
    Nathan_Meyer_39
    Historic F5 Account
    Hi Colin,

     

     

    After a bit of testing I realized I needed to move my log statements so they precede the RETURN or REJECT statements.

     

     

    When I went onsite to test the iRule, it worked flawlessly. The sysadmin was very happy with it. He got even more excited when I showed him the log file. He planned to take the log entries to the security team to prove that it was working.

     

     

    Attached is the updated, final version of the iRule. I'll also post it on code share.

     

     

    -------------------------------------------------------------------------------------