Forum Discussion

Alexander_Stewa's avatar
Alexander_Stewa
Icon for Nimbostratus rankNimbostratus
Aug 02, 2007

Is it possible to restrict access to iControl

Is it possible to restrict access to the BigIP via iControl either by network interface (preferable), IP address, or more drastically disabling iControl all together? I was able restrict access to SSH using hosts.allow and hosts.deny, but I can't figure out how to do the same for iControl using these (or any other method).

 

 

Thanks,

 

Alex

9 Replies

  • There is no official way to restrict access to iControl. It's basically the same system as the management GUI and there is no way to restrict access to that either. With that said, there are a few options. You could:

     

     

    1. Restrict access to usernames/passwords with admin access

     

    2. Physically rename the iControlPortal.cgi in the file system

     

     

    1 is preferrable, 2 most likely will violate support contracts since you are mucking with the filesystem. In fact, by doing 2, you will disable config sync between the devices as that and other services rely on iControl for communication.

     

     

    I'm wondering why you are asking this question. Are you looking at restricting access to the Management GUI as well? If the end user has access to the iControl interfaces, they will be able to do the same things within the Management GUI as both are run on the Management interface.

     

     

    -Joe

     

  • My company is a web hosting company which is about to start supporting PHP. While username and password are nice (and configured already), we would prefer to completely disabled access to the BigIP iControl from user PHP scripts (the PHP network isolated on a seperate network interface on the BigIP, so I was hoping I could simply disabled iControl on that interface). We definately won't do 2 since we need config sync for our devices.

     

     

    Basically I am worried that any user could attempt to brute force crack our BigIP password since you are saying we can't disable iControl. That is disappointing, but I don't know what else to do. I was thinking that a user wouldn't be able to log into the BigIP web interface using a php command line browser (I could be wrong here), so iControl seemed more dangerous, but if we could disable the web interface on certain network interfaces that would have been nice too. (or if there was some kind of option like "Only allow management (iControl, web, ssh, or otherwise) over the management interface," that would work nicely as well).
  • Why not just use iptables to restrict access to port 443 to specific hosts or subnets?
  • I got the impression from several iControl examples that it could communicate over other ports than 443.

     

     

    For example

     

     

    
    if ( ("80" eq $sPort) or ("8080" eq $sPort) )
    {
    $sProtocol = "http";
    }

     

     

    Why would they include that section of code if it only worked on 443?
  • Beats me, I don't know what that's an example of. I imagine one could reconfigure the Apache web server that runs the management interface and iControl to listen on clear-text ports as well. But our BigIPs only listen on port 443 by default.

     

     

    Anyway, you could probably block any access to the BigIP self-addresses with iptables and be done with it.
  • I played with this. You can enable clear-text access to Apache by editing the httpd.conf and adding a line for the listener:

     

     

    Listen: Allows you to bind Apache to specific IP addresses and/or

     

    ports, in addition to the default. See also the

     

    directive.

     

     

    Change this to Listen on specific IP addresses as shown below to

     

    prevent Apache from glomming onto all bound IP addresses (0.0.0.0)

     

     

    Listen 12.34.56.78:80

     

     

    If you put one of your IP addresses there, with port 80, or 8080, or whatever, you will enable clear-text access via that IP and port (and through no other IP:port). The SSL access config is in

     

     

    /config/httpd/conf.d/ssl.conf

     

     

    You can modify the "Listen" line from

     

     

    Listen 443

     

     

    to

     

     

    Listen 1.1.1.1:443

     

     

    If 1.1.1.1 is your management IP, this will restrict access to the web GUI and iControl to the management interface only.

     

     

    If you wanted to leave the management GUI up, but block iControl, you could edit the httpd.conf as follows. Find this entry:

     

     

     

    Satisfy any means that a connection may satisfy either the address access

     

    restriction or the authentication restriction in order to be authorized to

     

     

    access this directory.

     

    Satisfy any

     

     

    Access is restricted to traffic from 127.*.*.*

     

    Order deny,allow

     

    Deny from all

     

    Allow from 127

     

     

    This is an exact copy of the authentication settings of the document root.

     

    If a connection is attempted from anywhere but 127.*.*.*, then it will hav

     

    e

     

    to be authenticated.

     

    AuthType Basic

     

    AuthName "BIG-IP"

     

    AuthPAM_Enabled on

     

    AuthPAM_CacheTimeout 86400

     

    require valid-user

     

     

     

     

    You can change "satisfy any" to "satisfy all", which would require the client to both provide a valid password and be on the local host. If you wanted to still allow localhost clients to make requests without authentication, you could fiddle around with the settings in this section according to the Apache manual.

     

     

    There's at least half a dozen ways to do what you want to do. I don't see why the official line is that this feature is not available!
  • Whichever way you go, don't forget to include it in your rc files so it gets blocked on boot.

     

     

    The easiest way is to just explicitly bind in ssl.conf to your management address; that'll ensure that the HTTP server doesn't bind to any other IP addresses. Otherwise you'll need to create a new startup script with the iptables rules you've created.