Detecting Port Security

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!

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.

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!!

awesome. i'll give this a shot and let you know how it works.

Really appreciate the insight and education.

i looks like it works in a very general term. Im gonna need to go through and get a good test switch so i can test this a little more.

heres what i had to get it to work for my environment

Still testing it to make sure it's working. Thanks so much for pointing me in the right direction

had to modify this one a little bit from my last post after testing it a little more and finding some inconsistencies.

Because the "Description" line and the "Switchport access vlan XXX" line come before the "switchport mode access" line it was causing it to not find the block config on any of the devices. i was able to figure out how to get it working with the following regex

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

from running this on a regex tester it basically looks like the (2) additional ".\s+" causes it to accept any value in the first (2) lines but still requires the "switchport mode access" to be found before considering for compliance.

May not work for every environment but just leaving this here in case anyone is thinking about looking at the same thing. Thanks again to cnorborg for pointing me in the right direction. Below is a screenshot

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!!

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.

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!