Security or Stopping Users from Wasting Time and Money

Security is one of the things that first brought me into IT.  It is just one of those fun and awesome topics.  I also liked it because there is always someone smarter than you out there and you have to stay on top of your game.  I went with R&S for my CCIE because it was just what I was doing at the time.  Security is something I will be looking at later on.  And on to the fun we go.

What I am gathering is that if you have the if-authenticated method for an authorization AAA policy and that method is used, the policy will assign the privilege that is located in the line configuration.  In other words, if you have privilege level 15 in the line configuration and if-authenticated is the method used by exec, the user will get level 15 privileges.  This can be used as a backup for TACACS too which could be a possibility on the test.

When configuring the command privilege <mode> level <#> <command>, be specific with the commands allowed.  If all commands are allowed for a specific subset, include the keyword all.  To include all the ip commands under the interface mode, use privilege interface all level 4 ip.  Also when using those commands with AAA, include the commands aaa authorization exec <method> local and under the line configuration authorization exec <method>.

I always seem to forget this and I don't know why.  To allow path MTU discovery to work, you have to allow icmp packet-too-big in and/or out.  Since traceroute sends 30 probes by default, you can set an ACL for tracoute from UDP port 33434 to 33464.  You can add in a couple of extras if need be.  The replies will either be ICMP time-excceded or ICMP port-unreachable.

Using PBR to match packets to route to Null0 is a good idea it seems.  But say you want to keep unreachable messages from getting back out.  You can add the no ip unreachables to the null interface and this will block them just as if it was a regular interface.

And here I thought that for uRPF you had to create an ACL for the addresses to block automatically.  Got that wrong.  The ACL is checked only for packets that violate RPF.  If the ACL has a permit for a violation, then the packet still goes on through.  If you add the internal subnets, you can potentially allow in spoofed traffic which is what you are really trying to avoid.

Holy Crap.  I just spent a lot of time on how to use NBAR for Content-Based Matching thinking that I was looking for some security feature.  All they want to know is can you turn on NBAR in a class-map.  I did that in the QoS section  but sure.  Let's do it again.  Frustrated not at the task but that I wasted all that time.  Well, wasted is the wrong word.  Used it in a different learning environment.

Didn't know that.  Hmm...  NBAR will classify traffic independent of the way the policy-map is set up.  It applies to both directions of the flow.  So you can apply the policy-map looking out and still catch everything coming in

The command ip access-list log-update threshold is for saying how often a packet is logged.  The command ip access-list logging interval tells the device how often to kick a packet up to be process switched.  Making that a low number and the log-update threshold higher can reduce the load on the device.  This doesn't take into consideration packets heading to the router since they are process switched anyway.

VLAN filters are ingress only.  To do outbound, you can do an access-list on an SVI.  Think of them also as route-maps in structure that then are applied to VLANs.  They also not only hit transit traffic but anything generated locally on the device as well.  And finally, always re-apply the vlan filter after making a change.  They are not dynamic and more static in nature.  After upgrading my IOL Layer 2 images, I finally got one that didn't crash.  Problem is that the previous image and this one does NOT have vlan filters.  Just awesome.

Protocol numbers for MAC access-lists suck.  After some digging, I think that I found some.
ARP - 0x806
STP - lsap 0x4242 and 0x010b
VTP - 0x2003
CDP - 0x2000
DTP - 0x2004
UDLD - 0x0111

When setting the maximum number of mac-addresses on a trunk port per VLAN, include the maximum number as well.  The VLAN portion will allow that number per VLAN but if you allow 2 addresses in, since the default maximum for the port is 1, it won't work.

Using port-security on a port connected to a device with HSRP can lead to violations unless one of two things is corrected.  One can be to increase the allowed MAC addresses to 2 to account for the extra MAC.  The other is to issue the standby use-bia address on the HSRP device.  This causes HSRP to use the burned in address for the HSRP MAC instead of the dynamically generated one.

The command ip dhcp snooping trust is applied to ports that connect to either DHCP servers or other switches (uplinks).  This command also has to be on any port where a DHCP packet is received with a non-zero "giaddr".  It also causes messages received on the configured upon port to not create entries in the DHCP Snooping binding database.  Also to make an IOS DHCP server take in an all zero giaddr packets, use one of three options:
1) at the global level, use ip dhcp relay information trust-all
2) at the interface level, use ip dhcp relay information trusted
3) configure the DHCP snooper with no ip dhcp snooping information option to not insert Option 82
There is the other option of trusting where the information came from on the snooper but that doesn't really help anything on ports attached to clients.

By default a switch that is snooping will not accept DHCP packets with Option 82 coming into untrusted ports.  This can be changed with the command ip dhcp snooping information option allow-untrusted.  It still rejects packets with a giaddr of 0.  Fix this by trusting ports where that comes in to the switch.

Dynamic ARP Inspection (DAI) looks at ARP packets received on untrusted ports, which by default is all of them.  It allows the packet if it matches what is in the ARP inspection table.  While good for preventing some attacks, ARP poisoning, it can break other things, like PROXY ARP.  To trust a port, use the interface command ip arp inspection trust.  You can also configure DAI to validate source and destination MACs in ARP packets and/or validate the IP, which seems to make sure that 255.255.255.255 or 0.0.0.0 are not bound.  By default, DAI uses the DHCP bindings tables to build mapping information.  For those that use static IPs, you have to use an ARP access-list.  This list is checked first, followed by the DHCP table.  This behaviour can be changed with an explicit deny on the end of the table.  To do logging with DAI, you need to have the log keyword in the ACL and turn logging on with ip arp inspection vlan <VLAN_ID> logging acl-match <matchlog|none>.  You can also log probes and DHCP bindings.

Oh, great.  Another layer 2 security feature that throws me.  IP source guard helps to beat MitM attacks by applying a layer 3 filter to configured ports.  It is dependent upon having DHCP snooping enabled first.  Once you enable it, only packets that match the DHCP snooping database or static IP/MAC assignments are allowed.  DHCP packets are allowed so that clients can get layer 3 addresses.  It can also be combined with DAI.  When you configure IP source guard with the port-security option, you have to also have port-security enabled.  If you configure IP source guard on a trunk port, you have to have DHCP snooping trust on that port too.

Interesting.  ACLs applied to switch interfaces can only be applied to traffic coming in.  It cannot be applied to traffic leaving the interface.  Now on SVI interfaces, you can do both.  Maybe that is why they are SVI, they swing both ways.  Swinging Virtual Interfaces.

Messed that up.  Was setting up a user to be able to telnet into a router and then only allow them out to a specific router.  Instead what I did was limit all users.  I needed the access-class option for the username.  Well, shoot.

Beautiful.  The commands login on-failure and login on-success are not in the master command guide.  Just wonderful.  Luckily the commands are not that hard to figure out.

Setting up views can be great to limit commands and setting them up isn't so bad.  Just have to remember to do some initial things.  One is to enable aaa new-model.  Two is to have an enable password.  Three is for interfaces, you not only need to include the command for the interface you are allowing the view into but also to include the interface command.  Not that hard after all that.

The command ip icmp rate-limit is not in the Security section.  It is in the IP Application Services section.  It is basically saying send an unreachable every so many milliseconds.  If you use the df keyword, it specifies the number to send for each packet with the df bit set.  All others fall under the rate with the non-df bit set.

When setting up control plane policing and you need to match ARP, you can do match protocol arp.  Other NBAR matching doesn't work.  Also in the policy map, there are only two options available for the traffic: drop and police.  Police also allows the use of the rate keyword which comes in handy for limiting inbound and outbound traffic.  But that is only one option. You can still police by speed.  The configuration guide of this is under QoS and again, not under the security section.  I believe this is because of the MQC being used.

You can silently drop all packets with IP options using the command ip options drop.  If you want some, then use ACLs.  Packets with IP options are process-switched on a router and increase the proc load on the router.