Forum Discussion
jondyke_46152
Nimbostratus
NimbostratusAccess Control Based On IP for specific URL
I am pretty new to irules so any help here would be appeciated. The irule below is the deafult irule for Access control based on IP from the codeshare area. Is it possible to alter this so that it controls access for a specific URL under the virtual server rather than the whole virtual server? ie. http://www.joeblogs.com/restricted/
when RULE_INIT {
v1.0 - basic ACL.
October, 2007
Tested on BigIP version 9.4.
Purpose:
Bind this rule to a network virtual server to simply allow or disallow traffic based on source IP.
This rule expects a datagroup named trustedAddresses that lists the addresses you wish to allow.
By default, traffic will be dropped.
}
when CLIENT_ACCEPTED {
if { [matchclass [IP::client_addr] equals $::trustedAddresses] }{
Uncomment the line below to turn on logging.
log local0. "Valid client IP: [IP::client_addr] - forwarding traffic"
forward
} else {
Uncomment the line below to turn on logging.
log local0. "Invalid client IP: [IP::client_addr] - discarding"
discard
}
}
24 Replies
jondyke_46152Quite possibly.
Under the data group editor:-
Name - securepaths
Under String I have added:-
class securePaths { "/testing/" }
Andy_Herrman_22Is that the datagroup editor in the BIG-IP web interface, or the iRule editor?
In either case, you should have only added /testing/, not what you listed. The editor takes care of the class definition and the quotes and everything.
Also, you might want to name it 'securePaths'. I'm not sure if the case will matter, but it's better safe than sorry.
I attached a screenshot of what you should see in the web interface for the datagroup.- Andy_Herrman_22Small tweak to the iRule to handle case properly:
when HTTP_REQUEST { if { ( [matchclass [string tolower [HTTP::uri]] starts_with $::securePaths] ) and ! ( [matchclass [IP::client_addr] equals $::trustedAddresses] ) } { log local0. "Untrusted IP ([IP::client_addr]) attempting to access secure path ([HTTP::uri])" discard } else { log local0. "Allowing connection from [IP::client_addr] to [HTTP::uri]" forward } }
I have it converting the path to lowercase. This handles people trying to go to:
http://yourdomain.com/TeStInG
or other variants to try and get around your filtering. As long as you always use lowercase when defining entries in the datagroup you'll be good. - jondyke_46152Thanks
That seems to have sort of fixed it - I can't do any more testing at present as I have gone past my SLA on the environment. The site still failed but at least I now have :-
Rule irule_restrictedbyIP HTTP_REQUEST: Allowing connection from 192.168.0.109 to /usertransport/userws.asmx
Thanks very much for all of your help on this. - Andy_Herrman_22Glad to help.
With that logging in place it should show you any time it processes a connection and what it does with it. Hopefully that will tell you what's going on when it doesn't work. - jondyke_46152I think that the logic may be a little screwed up in this irule. What I want to happen is for all traffic to be allowed to the site 'unless' they are going to one of the paths specified in the securePaths data group. When they they try to go to one of these paths they should only be allowed through if they are in the trustedAddresses data group. The rule we have seems to allow all traffic through to the site if they are not in the trustedAdresses list but if they are then they are not allowed through to any part of the site.
- Andy_Herrman_22Here's pseudocode for the iRule:
if ( (path is a secure path) AND (ip address is not trusted) ) { discard } else { forward }
If the path is not one of the secure paths then the first check will be false, causing the else clause to be executed.
If the IP address is a trusted address then the second part of the IF check will be false, causing the else clause to be executed.
So, anyone who is trusted should always be allowed in. If they aren't trusted but don't try to go to a secure path they should be allowed in.
Here's another way to write the rule that might be a little clearer, though the logic is exactly the same as the previous one.when HTTP_REQUEST { if { [matchclass [string tolower [HTTP::uri]] starts_with $::securePaths] } { if { [matchclass [IP::client_addr] equals $::trustedAddresses] } { Secure path and trusted IP log local0. "Allowing connection from [IP::client_addr] to secure path [HTTP::uri]" forward } else { Secure path but not a trusted IP log local0. "Untrusted IP ([IP::client_addr]) attempting to access secure path ([HTTP::uri])" discard } } else { Not a secure path log local0. "Allowing connection from [IP::client_addr] to [HTTP::uri]" forward } } - jondyke_46152I tried the rule above and it definately has some adverse effects. With the rule applied users cannot get to the main site regardless of thier IP or path.
- Andy_Herrman_22What's in the logs?
- That sounds....odd. I'd be interested to see what's in the ltm log as well.
Colin
