Forum Discussion

Wes_98712's avatar
Wes_98712
Icon for Nimbostratus rankNimbostratus
Apr 05, 2008

Using iControl for PCI Compliance

This is going to be a vague post that I hope will lead to further in-depth technical threads. Essentially we need to be able to monitor changes to our F5's as they happen or post execution. To do this we want to segment Information Security access to the devices and allow them read access to see if the configuration of the F5's has changed. This is required for PCI compliance. Given the limited access controls available in the native TMOS we have options as follows:

 

 

1. Add the InfoSec account to provide console level access (separation of roles is at risk since the InfoSec crew will have full write access...not good).

 

2. Use the Enterprise Management appliance (we are looking at purchasing this).

 

3. Use iControl API's to monitor changes, we are on 9.3.1 HF2, so I don't know if there is a central API that we can call that states "hey the bigip.conf has changed" or "hey your darn admin made a change...even if it was to disable a node or VS).

 

 

As you can see this can be very complex. I know I can send emails or log changes to pools or VIP's based on an event to either a central logging server, or database or whatever...since the API is consumable all I have to do is find the right triggers to record events.

 

 

The question is, is there a global API available for me to consume in terms of on a scheduled basis accessing the F5's to determine if things have changed? I know with 9.4 I have the ability to call other scripts, but we aren't going to upgrade to that release just yet, we spent a few weeks dealing with issues on 9.3.0 and then on 9.3.1 HF1 which caused us to reach out to F5 professional services when the devices just horkedup and started acting like they just swallowed acid.

 

 

At any rate, vague post, but I am hoping we can dive deep into the iControl layer and realize some potential solutions to monitoring changes, with the expectation that soon we will have the enterprise management appliance in place, which I can only assume will offer some of this.

 

 

Things I am looking for:

 

 

1. iRule changes.

 

2. VS changes.

 

3. Pool changes.

 

4. Basic network configuration changes (e.g., some tard puts a new trunk in place or changes duplex settings or what not).

 

 

All of this doesn't have to be premptive, more so we just need to be able to see that hey something did change, even if it is as simple as a user logging in.

 

 

Thoughts? Comments? I am totally cool with folks telling me to go buy tripwire and bastardize the F5...but that's probably not going to happen. At least the bastardization aspect. ;-)

 

 

-Wes
dev
devops
iControl

1 Reply

Sort By
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Apr 05, 2008
    Option 1:

     

    If all you want to do is check "if" anything has changed, why don't you use the iControl System.ConfigSync interface to pull down the raw bigip.conf and bigip_base.conf files at regular intervals. You can compare them with a file diff to determine if their contents have changed (thus a system change).

     

     

    There are a couple of gotchas with this approach:

     

     

    1. This won't cover things like snmp that are not stored in the bigip.conf and bigip_base.conf files

     

     

    2. It will only show things that have been persisted to disk. bigpipe commands and iControl calls are not by default. You must issue a "b save" or the equivalent iControl call to flush the changes to disk.

     

     

    3. This will not cover users logging in. It will only cover configuration changes made.

     

     

    but it should be a very quick way to determine if anything has changed.

     

     

    Option 2:

     

     

    Again, use the System.ConfigSync commands to create .ucs archives of the entire configuration and download that with the methods in that interface. You can then do a byte-wise diff on the archive to determine file diffs. This would be more exhaustive than Option 1 but would require more overhead.

     

     

    Option 3:

     

     

    Use the iControl Event API to setup a listener to receive change notification events when they happen. Keep in mind that this may lead to some false alerts as nodes up/down due to monitors have their state changed and will be alerted via this mechanism when that wasn't actually a manual change.

     

     

    I'm sure there are some other options, but it's late and my brain is already asleep. If anything else comes to me, I'll let you know.

     

     

    If any of these options sounds interesting to you, let me know and I can provide more details on how to implement them.

     

     

    Hope this helps...

     

     

    -Joe