I was asked the question "how I would secure switch ports" in an interview, and of course I blanked on most of it, but thought I would compile a list now that I'm not in the hot seat.
1. Not allow trunking - in cisco terms switchport mode access (if it needs to be a trunk, make sure the native vlan is not vlan 1, and you add switchport trunk allowed vlan x,y,z to only allow necessary vlans on the port.)
2. BPDU guard and/or root guard - do not allow your spanning tree to be hijacked. BPDU guard will block or restrict any port that someone attaches a spanning tree capable device to (eg. anything that sends a BPDU will shut down the port) while root guard will block it if anything off that port attempts to become your spanning tree root. This can be attached to your own switch uplinks/downlinks if you KNOW you never want the neighbor switch or any switches down that branch to ever be root.
3. no cdp enable - no sense broadcasting out to every client what switch, Management IP address, port, IOS version etc. that they are connected to.
4. DHCP snooping/ Dynamic ARP inspection - There are a few commands related to DHCP snooping that will give you a few benefits.
a. You can block any edge port that offers DHCP responses - blocking clients from running a DHCP server on your network.
b. You can tell what IP address has been dynamically assigned out a port, and if an ARP response is sent out not matching that address (eg. IP spoofing) block the port
c. limit how many DHCP requests are sent out per second
d. I think there is another command or two that can go with this for more features but I haven't studied switch since it was the BCMSN so it has been a year+
5. Port Security - limit what mac addresses are allowed to be used on a port
a. options here include statically set addresses, or sticky addresses so you don't have to type them in yourself and the switch saves the address first seen on the port.
b. You can then limit how many addresses are allowed in a port, (limit 1 etc.)
c. Obviously MAC addresses are easy to spoof if they unplugged a different device, but if it is just an open port, they aren't likely to guess a statically assigned mac address
6. shut down unused ports - I know, I'm terrible at this, but shut or disable ports that do not have a computer plugged into them. No sense letting someone walk into your IDF and plugging in any open port without you knowing about it.
7. Network Access Control - Bit more involved here - you can have it fairly simple where the machine and user need to match up with an AD or Radius authentication, to more advanced options where User A on Machine x at Time H is placed on vlan V, but if they are on a different machine or a different time, perhaps they are placed in a more restricted vlan since it isn't their normal working hours.
NAC also has options to verify the machine is up to date on patches and virus definitions before being placed on a vlan. Lots and Lots to think about before implementing NAC.
8. Black Hole Vlan - Just in-case you forget to shut the port down, assign all unused ports to a "Black Hole Vlan" or a vlan that is not routed or trunked so the user can't get anywhere if they do manage to connect.
9. VACLs, I typically do ACLs at the router, but feel free to assign VACLs to limit traffic WITHIN the vlans to further secure INTRA-VLAN traffic. (if for some terrible reason your switch management IP is on the client vlan, make sure you add a VACL and/or vty ACL to keep clients from accessing it!!!)
10. ??? I'm sure there is more, what have I missed? Feel free to comment, argue, or add more for typical edge port security.
Friday, July 15, 2011
Thursday, July 14, 2011
EIGRP stub redistribution
Q. Will the following static route be redistributed?
ip route 10.1.1.0 255.255.255.0 10.2.2.1
router eigrp 100
redistribute static 1000 1 255 1 1500
eigrp stub
A. NO - eigrp stub default is summary and connected, redistributed static routes will NOT be advertised based on that stub command. The command eigrp stub static needs to be included as well
ip route 10.1.1.0 255.255.255.0 10.2.2.1
router eigrp 100
redistribute static 1000 1 255 1 1500
eigrp stub
A. NO - eigrp stub default is summary and connected, redistributed static routes will NOT be advertised based on that stub command. The command eigrp stub static needs to be included as well
Wednesday, July 13, 2011
EIGRP Stub Networks
A stub router indicates in it's hello packet, to let other routers know it is a stub router.
Q. Why use a EIGRP Stub?
A.
1. Limit amount of convergence traffic sent over links
2. Tell other routers you will NOT be a transit path for any additional networks. (eg. if a router is in active because it lost it's path, do not query me because I won't help you)
3. Avoid possible Stuck-In-Active scenarios
Typically, only remote routers are set as stubs, and only if they are single router sites. When a route goes down, stub routers ARE NOT QUERIED to find an alternate path, hub (regular neighbor routers) answer on behalf of the stub router.
*It is useful to note, stub features do not prevent other routers from advertising routes to the stub router.
Cisco defines a stub router as one which "core transit traffic should not flow"
Configure a router as a stub with the commands
eigrp stub [receive-only|connected|static|summary]
Any combination (other than receive-only) can be placed after the stub command.
The default is both connected and summary.
receive-only restricts the router from sharing any of it's routes with another router. When would you use this? If a router only has one interface in use, perhaps you have a router in place for the sole purpose of providing DHCP, VoIP gateway, or other services.
The connected, static, and summary commands are fairly self explanitory. Note that these must be in place AND the network command or redistribute command must be in use. Adding connected does not automatically add all connected routes to EIGRP, it only allows EIGRP to advertise them to neighboring routers if it is already in the routing table.
If a true stub network is desired, the hub (regular) router is typically configured to send a default route to the spoke (stub) routers so that only a single route is passed to them.
Q. Why use a EIGRP Stub?
A.
1. Limit amount of convergence traffic sent over links
2. Tell other routers you will NOT be a transit path for any additional networks. (eg. if a router is in active because it lost it's path, do not query me because I won't help you)
3. Avoid possible Stuck-In-Active scenarios
Typically, only remote routers are set as stubs, and only if they are single router sites. When a route goes down, stub routers ARE NOT QUERIED to find an alternate path, hub (regular neighbor routers) answer on behalf of the stub router.
*It is useful to note, stub features do not prevent other routers from advertising routes to the stub router.
Cisco defines a stub router as one which "core transit traffic should not flow"
Configure a router as a stub with the commands
eigrp stub [receive-only|connected|static|summary]
Any combination (other than receive-only) can be placed after the stub command.
The default is both connected and summary.
receive-only restricts the router from sharing any of it's routes with another router. When would you use this? If a router only has one interface in use, perhaps you have a router in place for the sole purpose of providing DHCP, VoIP gateway, or other services.
The connected, static, and summary commands are fairly self explanitory. Note that these must be in place AND the network command or redistribute command must be in use. Adding connected does not automatically add all connected routes to EIGRP, it only allows EIGRP to advertise them to neighboring routers if it is already in the routing table.
If a true stub network is desired, the hub (regular) router is typically configured to send a default route to the spoke (stub) routers so that only a single route is passed to them.
Wednesday, July 6, 2011
EIGRP passive Interfaces
This may be more of a CCNA topic but lets look at passive interfaces. First we have a router. S0/0/1 is connected to another router, Fa0/0 is connected to a client vlan (no router should ever try to neighbor from here). You have two options, you could redistribute connected networks, (but this may have issues with the administrative distance being labeled as exterior EIGRP and being higher, and it is not as clean a way of doing it) or the preferred way of setting this up is using passive interfaces.
Q. Will a passive interface accept hellos?
A. No, passive interfaces do not send unicast or multicast hellos, and do not accept them either. The router will not neighbor off this interface.
This adds security/stability for your EIGRP domain, and lessens the CPU load on the router as it isn't creating hellos on a silent interface.
Q. How do I make an interface passive?
A. Two ways
Option 1:
router eigrp 1
passive-interface fa0/0
Option 2:
router eigrp 1
passive-interface default
no passive-interface s0/0/1
Unless you know you are going to place a neighbor off an interface, always make it passive. A malicious user (or un-knowledgeable Jr Tech) Could place a router off this interface (eg. off any access layer switch port) and affect your entire routing domain unless you use the passive interface command and prevent it.
It may be easier to use the second option, and make all interfaces passive unless you specifically turn them on, but make sure you make this change while consoled into the router, inputting that command remotely will likely turn your uplink interfaces passive and kill your routing/connection.
Q. How do I check if my interfaces are passive?
A. show ip eigrp interfaces will not show any passive interfaces, or show ip protocols will explicitly list all passive interfaces.
Q. Will a passive interface accept hellos?
A. No, passive interfaces do not send unicast or multicast hellos, and do not accept them either. The router will not neighbor off this interface.
This adds security/stability for your EIGRP domain, and lessens the CPU load on the router as it isn't creating hellos on a silent interface.
Q. How do I make an interface passive?
A. Two ways
Option 1:
router eigrp 1
passive-interface fa0/0
Option 2:
router eigrp 1
passive-interface default
no passive-interface s0/0/1
Unless you know you are going to place a neighbor off an interface, always make it passive. A malicious user (or un-knowledgeable Jr Tech) Could place a router off this interface (eg. off any access layer switch port) and affect your entire routing domain unless you use the passive interface command and prevent it.
It may be easier to use the second option, and make all interfaces passive unless you specifically turn them on, but make sure you make this change while consoled into the router, inputting that command remotely will likely turn your uplink interfaces passive and kill your routing/connection.
Q. How do I check if my interfaces are passive?
A. show ip eigrp interfaces will not show any passive interfaces, or show ip protocols will explicitly list all passive interfaces.
EIGRP Hello & Hold Timers
Lets take a brief look at EIGRP Hello and Hold Timers.
So, R1 and R2 want to form a Neighbor relationship.
Q. Do the timers need to match?
A. No, but if a hello timer is longer than it's hold timer, or slow links cause that you will have flapping links.
Q. How do I change the Hello and Hold Timers?
A. R1:
interface fa0/1
ip hello-interval eigrp 55 2 (where 55 is the AS number, 2 is the timer value in seconds)
ip hold-time eigrp 55 6 (cisco does not force you to make this 3 times the hello, but it is strongly recommended)
Q. So does this mean I need to make sure R2 uses a hello timer less than 6 to keep my links from flapping?
A. No, the hold time of six is sent to R2 to use. The value set on R2 will be sent to R1 to tell R1 how long to hold waiting for hello messages. The hold time set is the value actually used on the neighboring router.
If multiple routers are on this segment, they will all use this hold time while waiting for R1's next hello.
So you can interpret ip hold-time eigrp 55 6 as "tell all my neighbors with eigrp 55 to use a 6 second hold time when they listen for me".
R2 could use 10/30 as it's hello/hold-timers and the nieghborship would stay up.
Q. How can you verify your hello times?
A. show ip eigrp interface detail interface
Q. Does that show the hold timer as well?
A. No, you need to look at the show run or use show ip eigrp neighbors command and watch the countdown until it resets to it's highest value.
Q. How does the router send Hellos?
A. Routers using EIGRP send Hellos to multicast 224.0.0.10 attempting to find potential neighbors.
For general hello packet and neighboring information, read my hello packet post from last year
So, R1 and R2 want to form a Neighbor relationship.
Q. Do the timers need to match?
A. No, but if a hello timer is longer than it's hold timer, or slow links cause that you will have flapping links.
Q. How do I change the Hello and Hold Timers?
A. R1:
interface fa0/1
ip hello-interval eigrp 55 2 (where 55 is the AS number, 2 is the timer value in seconds)
ip hold-time eigrp 55 6 (cisco does not force you to make this 3 times the hello, but it is strongly recommended)
Q. So does this mean I need to make sure R2 uses a hello timer less than 6 to keep my links from flapping?
A. No, the hold time of six is sent to R2 to use. The value set on R2 will be sent to R1 to tell R1 how long to hold waiting for hello messages. The hold time set is the value actually used on the neighboring router.
If multiple routers are on this segment, they will all use this hold time while waiting for R1's next hello.
So you can interpret ip hold-time eigrp 55 6 as "tell all my neighbors with eigrp 55 to use a 6 second hold time when they listen for me".
R2 could use 10/30 as it's hello/hold-timers and the nieghborship would stay up.
Q. How can you verify your hello times?
A. show ip eigrp interface detail interface
Q. Does that show the hold timer as well?
A. No, you need to look at the show run or use show ip eigrp neighbors command and watch the countdown until it resets to it's highest value.
Q. How does the router send Hellos?
A. Routers using EIGRP send Hellos to multicast 224.0.0.10 attempting to find potential neighbors.
For general hello packet and neighboring information, read my hello packet post from last year
Subscribe to:
Posts (Atom)
