11 Replies Latest reply on Oct 6, 2016 12:36 PM by christopher.t.jones123

    Detecting Port Security

    christopher.t.jones123

      i would like to develop a good method to show in compliance whether or not port security is enabled on designated ports.

       

      I attempted to make a rule that looks for a regex pattern "switchport mode access" and then added in the regex "switchport port-security" however i think my formatting is incorrect because it is just populating that the pattern is found. is there any way i can make this a little smarter?

       

      Below is a screenshot of my current rule

        • Re: Detecting Port Security
          Craig Norborg

          I think the problem is that you're checking the "Entire Config File" vs. the "Config Block", so its simply looking for either of those two anywhere in the config.   You probably want to configure up a "Config Block" for interfaces and have it iterate on those. 

           

          Of course as-is it will violate on any trunked port, as well as any access-port without port-security.   Is that what you want?   You need some way to rule out trunk ports, maybe matching on access-ports as part of the beginning of the config block?

           

          Neither of your "strings" have any regex patterns in them, things would go much quicker if you didn't use a regex type on the comparison.   Just as a general rule, if you're looking for simple strings, don't use a regex type!

            • Re: Detecting Port Security
              christopher.t.jones123

              i would like to exclude trunk ports form this. is there a way that i can do multiple blocks of config within a rule? or is this something that is not available?

               

              essentially i would like it to be something along these lines

               

              interface g0/1

              switchport mode access

              switchport port-security

               

              int g0/2

              switchport mode access

               

              int g0/3

              switchport mode trunk

               

              where it reports that int g0/1 shows as compliant and g0/2 in violation and ignores g0/3

               

              is this possible or am i asking to much from the product

               

              Thanks for your input, i appreciate it.

                • Re: Detecting Port Security
                  Craig Norborg

                  I'm going out on a limb and going to say that you cannot do multiple blocks within the same rule, but you can create multiple rules.   However, depending on your circumstances you might be able to get away with it.  In this case I'm seeing you probably only need 1 rule though.   The key to it is using a regex type for matching on the config block start and doing a multiline match.

                   

                  How I'd structure it would be to have the start of the config block be something like this, remember it has to be a regex type!

                  Config block start:

                  ^interface (Gigabit|Fast)Ethernet.*\r\n\s+switchport mode access

                  Lots of stuff going on here, so I'll explain. 

                   

                  The "^" at the beginning anchors the regular expression to the start of a line.  ie: you don't want to match the keyword interface unless it begins there, trust me that this is a good idea, it can speed things up and keep problems from occurring. 

                   

                  Next is the (Gigabit|Fast)Ethernet, which should match either GigabitEthernet or FastEthernet (can't use abbreviations in compliance rules!!).   After that is ".*" which matches >anything< to the end of the line, but we should be pretty safe in doing that at this point.   Note there is NO space before the ".*"!

                   

                  The "\r\n" should match the end of the line.  I haven't looked at this since 7.5 to see if the behavior has changed, but you might want to read this

                  Re: Compliance rules - EOL or '\r' vs '$'

                  The basics are that "\r\n" should work unless your testing the rule on a snippet of a config, in which case you need to change it to "$".

                   

                  "\s+" matches at least one occurrence of whitespace, but is good if there is more. And having the "switchport mode access" should have it ignore any trunked ports for you.

                   

                  Now, the interesting thing is, when you do this with the start of a config block, when you put in the ${ConfigBlockStartLine} it will ignore the second line in the regular expression.  So, the "switchport mode access" won't be part of that variable.   Either should work, but kind of a nice thing, keeps things cleaner.

                   

                  So, once you have your config block start done, the config block end should be "^\!", which matches lines that start with an exclamation point.

                   

                  Then, In your string matching and advanced config search, look for the "switchport port-security".  This can be a regular string match.  Have it violate if it doesn't find it.

                   

                  You can then either remediate manually, or build a remediation script to do it for you.  Something like this should work.

                   

                  ${ConfigBlockStartLine}

                  switchport port-security

                   

                  TEST THOROUGHLY!!!     Do single nodes first, not the whole batch, and have it show you the config that its generating and check it out!!   You'll find there can be a lot of unintended consequences by not doing thorough testing, esp. with something like this that can easily cut off network access to tons of folks!!

                   

                  HTH!!

                  1 of 1 people found this helpful
              • Re: Detecting Port Security
                Craig Norborg

                So, now for the potential downfalls.   I do find it interesting that you're able to go "across" EOL boundaries in the regex without explicitly telling it where the EOL is, this can be both good and dangerous.  Why you ask?

                 

                So, in here "\s+" matches whitespace, while .* matches anything - I'm guessing including the EOL.  The question would be, which whitespace is it matching, and how many EOL's are being matched by the .*?

                 

                For example, lets say you have something like this example, 6 lines total.

                 

                interface GigabitEthernet1/0/1

                 

                description This is a test

                switchport mode trunk

                interface GigabitEthernet1/0/2

                switchport mode access

                 

                So, lets say the beginning of your pattern match, which is anchored to the beginning of the line by the "^" matches Gi1/0/1.  After that you need to have at least 2 spaces, one for each of the first two "\s+" with anything (including nothing) inbetween them, as shown by the ".*"'s which match any number of anything.   So, since it can't match the "switchport mode trunk" it can continue to gobble things up until it reaches the " switchport mode access" which matches the "\s+switchport mode access" in Gi1/0/2.   However, it can do this while the beginning of the config block is still anchored on Gi1/0/1!   I have seen it do similar things for me, where one config block it would run my tests on would be lines 1-6 and the second would be lines 5-6.   Both fit the conditions you have there I believe.

                 

                The problem is, if you do an automatic remediation, it would then apply the script on the first block that starts with "interface GigabitEthernet1/0/1" and the second block which starts with "GigabitEthernet1/0/2".   If you apply port security to a trunk you could have serious issues!!!

                 

                Might be better to instead just to the config block start as something like "^interface (Gigabit|Fast)Ethernet .*\r\n" making it for sure work only on one line at a time, and have the end being the same.  Then, do a multipart "Advanced Config Search" which has to NOT see the "switchport mode trunk" and has to also not see the port-security config.

                 

                Thinking it might be safer!   Regex's can be greedy and you have to be careful with them sometimes!   Not saying it will exhibit this behavior, but its always good to take the safer approach.   How do you find out how exactly it is working?    Once again, TEST THOROUGHLY!!

                  • Re: Detecting Port Security
                    christopher.t.jones123

                    thank you for the insight again. can you please expand on a multipart "advanced config search"? i'm not sure i know what you are referring to.

                      • Re: Detecting Port Security
                        Craig Norborg

                        In the advanced config search portion of the page, right now you're looking for where the

                        "Config file" "Must Contain" "Find String" and "switchport port-security"

                         

                        Just "Add another string" and have it do something like

                        "Config file" "Must NOT Contain" "Find String" "switchport mode trunk"

                         

                        By having 2 comparisons within the config block, it should accomplish what you're looking for in a better way.  If you want to be a bit more "secure" in what you're doing, you could change it from "Find String" to a Regex pattern and anchor the strings to the beginning of the line, that way it can't be fooled if those strings end up in a description for instance...   So it would be something like "\s+switchport port-security" instead of what you have.   You could also do the EOL anchor if you wanted to also, but you might not depending on how you configure port-security.

                         

                        Let me know if that makes sense!

                        1 of 1 people found this helpful