Forum Discussion
Nathan_Meyer_39
Mar 06, 2006Historic F5 Account
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_39Historic F5 AccountThank 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_39Historic F5 AccountHi Colin,
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects