Forum Discussion

P_Shepherd_1790's avatar
P_Shepherd_1790
Icon for Nimbostratus rankNimbostratus
Sep 11, 2018

iRule to block access to folders within IIS

Hi

I have an issue with an iRule working in a Virtual LAB environment but when applied to the live environment it behaves differently. The difference between the Virtual LAB and the live is the IP addressing.

The iRule that I have composed is to block access to folders on the backend IIS servers based on the contents of the URI. There are three folders on the servers that are not to be accessed from outside of the organisation. To add complexity to the issue there is a connection to a third party that has the client connections NAT'd behind an IP address that forms part of our internal network.

So the iRule must...

1. block access to the folders from IP address 10.x.x.x/32 (the third Party NAT'd address)

2. allow access to the folders from all other internal IP addresses.

3. block access to the folders from all other IP addresses.

I have set this up in a Virtual LAB using the following IP addressing.

Internal Networks: 10.10.200.0/24; 10.10.201.0/24

Host acting as 3rd Party NAT: 10.10.200.6

External Network: 80.80.80.0/24

All connectivity is fine and without the iRule access to the folders is granted. When I apply the iRule access is blocked to the 3rd party NAT host and the External host on 80.80.80.0/24. Other hosts on the 10.10.200.0/24 and 10.10.201.0/24 can access the web site within the folders as defined in the URI.

So all is well. Until this is applied to the live environment when the iRule does not allow anything through. It blocks all attempts to access even when the folders are not within the URI.

The differences between the Virtual lab and the live environment are...

Lab is VM; live is physical box

lab is HTTP; live is HTTPS

IP addressing is different in the lab but logically the same.

Lab backend servers are Ubuntu running apache2. Live servers are Windows running IIS.

Below is the iRule from the lab. (the only thing that changes in this rule when put into the live environmetn is the IP address of the NAT host)

when HTTP_REQUEST {

if {([HTTP::uri] contains "_vti_bin" || [HTTP::uri] contains "_layouts" || [HTTP::uri] contains "_windows") and [IP::addr [IP::remote_addr] equals 10.10.200.6/32 ] } {
    log local0. "dropped connection my ip address: [IP::remote_addr]"
    reject

} {

if {([HTTP::uri] contains "_vti_bin" || [HTTP::uri] contains "_layouts" || [HTTP::uri] contains "_windows" ) and not [IP::addr [IP::remote_addr] equals 10.0.0.0/8 ] } {
    log local0. "dropped connection my ip address: [IP::remote_addr]"
    reject
    }
} 
}

any help will be greatly appreciated.

3 Replies

  • I have now run this up as HTTPS in the lab and it functions as expected so I can now rule that out.

     

  • You could do this more simply using datagroups. Define your folders in one datagroup 'folder_dg' and your internal ip addresses in another 'internal_ips'

    The iRule will check if the URI contains anything in the datagroup 'folder_dg', if the IP is not internal (not in the internal_ip) datagroup. The connection will be rejected. You do not need to define the NAT IPs as you want to block all other IPs anyway

    For example:

    ltm data-group internal folder_dg {
        records {
            _vti_bin {}
            _layouts {}
            _windows {}
        }
        type string
    }
    
    ltm data-group internal internal_ips {
        records {
            10.10.200.0/24 {}
            10.10.201.0/24 {}
        }
        type ip
    }
    
    when HTTP_REQUEST {
        if {[class match [HTTP::uri] contains folder_dg]} {
            if {!([class match [IP::addr [IP::client_addr]] equals internal_ips])} {
                reject
            }
        }
    }
    
  • Thank you for your answer.

     

    We have now rebuilt the LAB but this time with the backend servers as they would be in the live environment, and the iRule fails. Why? Because the backend servers do a redirect to a web page that contained within it's uri "_layouts". The server team kindly committed to tell me that little gem.

     

    So after some editing by changing the folder references to "/_layouts/"; "/_windows/" and "/_vti_bin/" we were able to get the desired effect.