1 Reply Latest reply on Apr 30, 2015 10:48 AM by Craig Norborg

    Solarwinds Compliance reports

    dakam

      Hi fellow members, i was able to integrate solarwinds NCM and after running a cisco compliance report i received several violations in the configs with commands that were expected in my configs,

      my question is is it possible for me to update my configs with the suggested commands automatically and how can do that?

        • Re: Solarwinds Compliance reports
          Craig Norborg

          Yes, you can.  You can click the icon in the report that indicates that its not in compliance and it should bring up a "Violation Details" window that has "Execute Remediation Script on this Node" and "Execute Remediation Script on all Nodes in Violation".  Clicking on one of those should bring up the "Execute <rule name> Remediation Script" screen.

           

          Now, if there was a remediation script provided with the rule, it would show up here.  Otherwise you'll have a box with "Script" above it with nothing in it.  You can either edit the existing script in this box, or put your own commands in to fix the problem.   However, at least until you move to the latest NCM, which is only in "Release-Candidate" stage right now, you can't use remediation on things that aren't global commands very easily.

           

          That being said, many of the built in rules have many problems with them, you should choose what you work on here carefully!!   Let's take the Cisco Policy Report, the first rule "Disable Reverse-Telnet".   This rule checks for the following pattern: "line con 0.*\n(.*\n)*.*transport input none".  The question is where to begin with the problems. 

           

          Ok, first, at least on current versions of IOS, you can't even put in a "transport input" on a console port without getting an error.  These commands aren't valid on CON 0, which is what it's supposedly checking on.  Now the AUX 0 port is a different story, the command is valid on that as well as all the VTY ports, but its not valid on the console port that they are checking.  So, as-is, this rule is bogus!!   You can't write a remediation rule for it because the command is invalid on the console port!

           

          Second, the greediness of the regular expression can get ya...   Esp. the "(.*\n)*.*transport input none" portion of the rules.   Take the valid config snippet below.  Note there is no "transport input none" until you get to VTY 15.   Yet, if your config looks like this, it will pass this rule.  Why?   Essentially "(.*\n)*" says that any number of lines with any content can pass between the "line con 0" and where-ever the "transport input none" is.  So, even though the "transport input none" clearly has nothing to do with the "line con 0", this would pass this compliance rule.

           

          !

          line con 0

          exec-timeout 0 0

          logging synchronous

          line aux 0

          exec-timeout 0 1

          transport output none

          line vty 0 4

          access-class remote_access in

          exec-timeout 35791 23

          logging synchronous

          transport input ssh

          line vty 5 14

          access-class remote_access in

          exec-timeout 35791 23

          logging synchronous

          transport input telnet ssh

          line vty 15

          access-class remote_access in

          exec-timeout 500 0

          logging synchronous

          transport input none

          !

           

          Ok, and my final example.  Let's say you trust me on the fact that "transport input none" doesn't work on CON 0, but does on AUX 0.   You say "simple solution, just change the rule to check AUX 0 instead of CON 0".  Ok, fine, let's do that.   Guess what, the config snippet above has that in it.  Whats that?  You don't see the "transport input none" on AUX 0?  That's right, its the default value, so after you input it you simply see nothing in the config.    So, rather than checking for its presence, you should be checking to see if anything else exists to change the default value, rather than checking for the default value.

           

          All of the "Console Settings" checks in the "Cisco Policy Report" have problems like these.  So be careful what you're checking for, and be careful how you remediate.

          6 of 6 people found this helpful