Port-security Lab, Easy setup / Easy Skill

[deanwebb]

Time for another lab... for this, you need:

1 manageable switch
1 other switch, unmanageable is fine - if manageable, treat it like an unmanaged switch
2 or more endpoints (more endpoints allows for more flexibility in labbing)

1. Configure port 0/1 on the manageable switch to be a normal access port.
2. Attach an endpoint to port 0/1. Show mac-address table to see the MAC address of that endpoint.

This represents a normal, desirable network. One host per port, everything working well. Now, we look at what happens when we have an undesirable situation...

3. Detach endpoint from 0/1.
4. Attach the unmanaged switch to 0/1.
5. Attach as many endpoints as possible to the unmanaged switch.
6. Show mac-address table on the managed switch and marvel at the mess you now have.
7. Consider what would happen if each of those devices chose to access the network at the same time: performance would degrade.
8. Consider what happens if a single device connects to a port and maliciously spoofs many MAC addresses (MAC address table overflows, bad things for security then follow...)

It is undesirable from both a performance as well as a security standpoint to allow multiple hosts to use the same switchport. Therefore, we will now apply port security.

9. Unplug all the devices from 0/1
10. Type in the following commands:

Code Select Expand

Switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)# interface gi0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 1
Switch(config-if)# switchport port-security violation shutdown

11. Now plug in the unmanaged switch and two other devices. Note the condition with a show ip interface brief. (Port should be in an error-disabled state.)
12. Remove the switch and plug in an single endpoint. Is the port usable now? (No, it's still err-disabled. Check and see.)
13. Do a shut/no shut on the interface. The single endpoint should be functional now.

Areas to explore:
A. What if the port-security maximum is greater than one? What happens then?
B. What if the security violation action is restrict, rather than shutdown?
C. Is there a way to specify a particular MAC address for a port? If so, what are the commands? (Try with one endpoint, then connect another.)
D. Is there a way to have the switch "learn" a MAC address to use with a particular port? If so, what are the commands?
E. Is there a way to have a port in err-disabled state automatically recover? If so, what are the commands? What happens if the conditions that cause the port to be err-disabled continue after the port recovers from the err-disabled state?

[flipmode]

Thanks Dean! Always nice to have a lab to do after learning about a topic.

[deanwebb]

You're welcome. If you have any requests for other labs, let me know.

[Rllavona13]

A. If the port security is set the max of 1 when the switch see 2 or more mac address the port security will shutdown the interface because you specify that in the violation option.

B. If the violation action is set to restrict the port will drop the packets unlike the action of 'protect' this action will increment the counter of the security violation.

C. I dont have a switch right now with me you can specify the switchport port-security mac-address <mac address>

D. You can set the switchport to learn mac address with the sticky option. I guess is switchport port-security mac-address sticky (here the first mac address it stores is the one will work without  violation, if learn two or more it will be put in err-disabled)

E. Yes you can, you have to enable errdisable recovery but you have to specify what reason you want to enable the feature, in this case you have to specify errdisable psecure-violation ny default the recovery that you have enabled will be recover from err-disabled after 5 minutes, if the switch keep learning more mac address it keep happen the same violation action. Unless you fix the number to a higher value of course higher than your learned mac address


Am i right?




Sent from my SM-G928P using Tapatalk

[deanwebb]

A. If the port security is set the max of 1 when the switch see 2 or more mac address the port security will shutdown the interface because you specify that in the violation option.

B. If the violation action is set to restrict the port will drop the packets unlike the action of 'protect' this action will increment the counter of the security violation.

C. I dont have a switch right now with me you can specify the switchport port-security mac-address <mac address>

D. You can set the switchport to learn mac address with the sticky option. I guess is switchport port-security mac-address sticky (here the first mac address it stores is the one will work without  violation, if learn two or more it will be put in err-disabled)

E. Yes you can, you have to enable errdisable recovery but you have to specify what reason you want to enable the feature, in this case you have to specify errdisable psecure-violation ny default the recovery that you have enabled will be recover from err-disabled after 5 minutes, if the switch keep learning more mac address it keep happen the same violation action. Unless you fix the number to a higher value of course higher than your learned mac address


Am i right?




Sent from my SM-G928P using Tapatalk

Most of it is right, but there are some mistakes... check your answers to the questions, and maybe check the questions again.

[Rllavona13]

A. If the port security is set the max of 1 when the switch see 2 or more mac address the port security will shutdown the interface because you specify that in the violation option.

B. If the violation action is set to restrict the port will drop the packets unlike the action of 'protect' this action will increment the counter of the security violation.

C. I dont have a switch right now with me you can specify the switchport port-security mac-address <mac address>

D. You can set the switchport to learn mac address with the sticky option. I guess is switchport port-security mac-address sticky (here the first mac address it stores is the one will work without  violation, if learn two or more it will be put in err-disabled)

E. Yes you can, you have to enable errdisable recovery but you have to specify what reason you want to enable the feature, in this case you have to specify errdisable psecure-violation ny default the recovery that you have enabled will be recover from err-disabled after 5 minutes, if the switch keep learning more mac address it keep happen the same violation action. Unless you fix the number to a higher value of course higher than your learned mac address


Am i right?




Sent from my SM-G928P using Tapatalk

Most of it is right, but there are some mistakes... check your answers to the questions, and maybe check the questions again.

Got it Thanks


Sent from my iPhone using Tapatalk

[Dieselboy]

Hi Dean - Question about .1X port-security and the certificate used there:

Ideally, you would have an internal Certificate Authority and then push or install the client certs on each node requiring to be plugged in to a switch. No one else in the world would have certs from your own CA, so they would not be able to gain network access.

I was thinking about what would happen if you did not use your own CA but instead used a trusted CA like Thawte or similar, to make the certs. I think this would work and save you the trouble of needing to push or install those certs on each endpoint, because endpoints already have been updated with the trusted CA's root certs. But unfortunately, the downside is that every endpoint in the world is updated too, and so the .1X security would be a waste of time because any endpoint could be successfully connected to your network 

[wintermute000]

trusted CAs stopped issuing certs for internal domains around 12-24 months ago.

I know because a client of mine had a comodo signed cert for their wireless.local domain which comodo refused to renew.

however, I think your reasoning is backward. If you used Thawte to sign your certs, your clients would trust your server, but your server would still not trust your clients unless you got thawte to sign a cert for each individual client account/machine. The clients still need a cert signed by a CA that the dot1x trusts. dot1x automagically trusts thawte, however, thawte never issued the client a client cert

[Dieselboy]

Ah okay. I'll look into this some more then. I didn't even think about server trusting clients (obviously I'm rusty on this topic). I don't run a CA and don't want to as it's quite risky.

Regarding certs for internal domains, I actioned a cert for an internal system just last week from a trusted CA. Although you are correct in that CA's don't issue certs for "internal" domains, before setting up the domain here I did some research to find out what the best practices were. I found quite a lot of info that advised the internal domain should be a subdomain of the external TLD domain, so this is what I've set up here. I have no problems attaining certs from CA's for internal stuff. My internal domain is something like i.domain.com (actually the first letter represents our site location in Australia, with the mindset that if I need to split the AD forest then I can create another domain for the other site with similar naming convention).

References:

• http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx
• https://blog.varonis.com/active-directory-domain-naming-best-practices/

[wintermute000]

Ah okay. I'll look into this some more then. I didn't even think about server trusting clients (obviously I'm rusty on this topic). I don't run a CA and don't want to as it's quite risky.

Regarding certs for internal domains, I actioned a cert for an internal system just last week from a trusted CA. Although you are correct in that CA's don't issue certs for "internal" domains, before setting up the domain here I did some research to find out what the best practices were. I found quite a lot of info that advised the internal domain should be a subdomain of the external TLD domain, so this is what I've set up here. I have no problems attaining certs from CA's for internal stuff. My internal domain is something like i.domain.com (actually the first letter represents our site location in Australia, with the mindset that if I need to split the AD forest then I can create another domain for the other site with similar naming convention).

References:

   
• http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx
• https://blog.varonis.com/active-directory-domain-naming-best-practices/

You don't have to expose your root CA. keep your root CA secured and delegate signing to a subordinate CA. If the subordinate CA is compromised, they still do not have the root private keys.

re : dot1x EAP-TLS whether wired or wireless, the heart of the mechanism is the radius server authenticating the supplicant based on the certificate being signed by a CA that the radius server trusts. As an additional level of security, you can set the clients to authenticate the radius server in return. This is best practice to avoid honeypots/MITM etc.


HOWEVER if you want to use say PEAP you don't have to use client certs and rely on username / pw but you'll then invoke the wrath of Deanwebb. You're also unable to revoke devices / users etc. without locking out their account entirely. You can still enforce the client to check the server cert.


For guest wireless webauth, its common practice to use a 'real' domain with a real cert simply to avoid having guest clients get the SSL warning page. note I'm not talking about dot1x.

for more light reading... http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html#wp386948


Thanks for the domain info. So its OK if your internal domain is actually a 'real' domain. I suppose that makes sense.

[deanwebb]

Yes, PEAP invokes my wrath.

And if an external CA is involved, then communications need to be opened up to that external CA for everything to work. I found that out with our guest wireless portal that uses a cert from an outside vendor. No guest would trust it until we opened port 80 and 443 to ca.vendor.com basically.

Should the external vendor allow you to set up a CA for their certs on your premises, then it will behave as an internal CA. Just install the root and intermediate certs on everything, should be good to go.

[Dieselboy]

Yes, PEAP invokes my wrath.

And if an external CA is involved, then communications need to be opened up to that external CA for everything to work. I found that out with our guest wireless portal that uses a cert from an outside vendor. No guest would trust it until we opened port 80 and 443 to ca.vendor.com basically.

Is that for the CRL checking? Can't you disable that / tell clients not to bother checking CRLs? I needed to do that to one of my systems when I couldn't get SSO to work. I had to run a command on the SSO server to say "don't bother checking the CRL". After I done that, everything worked. Took me ages to work out from the Event Viewer logs what was happening.

[deanwebb]

It's for CRL checking and also first-time validation. No, you do not want to switch off CRL checking. That is BAD. Like crossing the streams bad. This is you after you turn off CRL checking and the guy next to you hacks your PC:



Open up the 80/443 ports to the CA and all should be well.

[Dieselboy]

Fair enough

In my case it was a self-signed cert and there was no CRL list anyway if I remember rightly.

[wintermute000]

Can you configure a standalone CRL or does it have to be a CA? Is there a specific subordinate CA role?