INE Workbook Vol 1 Security

You can set the prompts and banners through the aaa process...


aaa authentication banner ^CWelcome Bitches!^C
aaa authentication fail-message ^C Piss off fucker - your not who you say you are!^C
aaa authentication password-prompt "Please enter your password fucker:"
aaa authentication username-prompt "Who the fuck are you:"


IOS by default do not authorize console sessions, where as Catalyst IOS always authorizes the exec shell, even the console line.


Inbound IOS UDP traceroute uses port range 33434 - 33474. Path MTU discovery uses ICMP packet-too-big. You can use 'show ip port-map' to locate common TCP/UDP port-numbers.


Reflexive access-lists used to trip me up before. I now understand them, but still have some trouble putting them together. In short, you just add a reflect [ACL_NAME] to the end of your outbound permit statements. Then on your inbound ACL, simply do a evaluate [ACL_NAME] statement. Hopefully, this will finally commit reflexive ACLs to my ROM....also, if you use reflexive ACLs, you may need to account for local traffic by either statically permitting the traffic in the inbound ACL or use local policy routing to divert the local traffic across the loopback interface and make it re-enter the router. 


Ahhh....dynamic access lists. How I hate you so. First, enable absolute timeout extension.


access-list dynamic-extended


Now create an inbound ACL permitting pertinent traffic and specifying the dynamic access-list.


ip access-list extended 100
remark == Permit Telnet ==
permit tcp any any eq telnet
remark == Permit rotary line 7001 ==
permit tcp any any eq 7001
remark == Permit RIP ==
permit udp any any eq 520
remark == Dynamic ACL for WWW ==
dynamic ACCESS timeout 15 permit tcp any any eq 80
deny ip any any log


Apply the access-list.


interface FastE0/0.67
ip access-g 100 in

Now tie the username/password to the autocommand.

username ENABLE passw CISCO
username ENABLE autocommand access-enable host timeout 5

Above, the autocommand access-enable command will add the authenticated user to the dynamic access-list. The 'access-enable host timeout 5' command is hidden from the IOS parser, so commit this to memory. Without the 'host' portion, the dynamic entry will have a simply 'any any' ACL entry. Now to configure the VTY lines...

line vty 0 3
login local
line vty 0 4
rotary 1
password CISCO
login
autocommand access-enable timeout 5

Now from the above VTY config, if a user logs in with the ENABLE username on line 0 - 3, or connects via TCP 7001 with line password CISCO, they will be added to the dynamic access-list and permitted outbound WWW connections. This is really easy to understand, but hard to remember and re-assemble. In short, if you can remember the 'autocommand access-enable host timeout x' command, you can complete the dynamic access-lists. You can manually clear the dynamic entries by issuing a 'clear access-template 100 ...' command.

Packet drop with PBR is achieved by using 'set interface null0' command.

uRPF can be enabled in strict or loose mode. With strict mode (ip verify unicast source reachable-via rx) the router applies the uRPF check to the source IP address of incoming packets to ensure the source IP address matches an explicit IP route in the routing table and the next hop for this entry should point out the interface the packet was received from.

Loose mode is commonly used with more than one ISP uplink and use asymmetric routing. Loose mode (ip verify unicast source reachable-via any) checks that it has an IP route matching the source address of the packet. It does not matter whether the next hop for this route points out the receiving interface or not. uRPF can also call an access-list for packets violating the uRPF condition. You could permit exceptions, or can use the 'deny ip any any log' to log packets denied.

Access-list logged packets are process switched. To limit impact on CPU, you may want to rate-limit the amount of process-switched packets using 'ip access-list logging interval x'.

You can enable inspection of router-generated UDP traffic using the 'ip inspect name Firewall udp router-traffic' command. Traffic inspected with CBAC will be allowed through the firewall, but will be further inspected for other details. CBAC uses the ip port-map command and you can specify a host specific port map (ip port-map ftp port 80 list 98) will inspect FTP sessions to port 80 with hosts permitted by access-list 98. When the number of connections across the firewall exceeds 4000, you may want to adjust the default hash-table size to match approximately half of the maximum connections count. With 5000 sessions, the optimal hash table size would be 2048 buckets.

On to port security. The only thing that really trips me up is protect/restrict and what each mode does. One drops the offending traffic, the other drops the offending traffic and logs to syslog. How do I remember this? Think of port-security as a bouncer at a club. If the bouncer is protecting the entrance, he doesn't need to know who tries to enter, he just needs to protect. If he needs to restrict the entrance, he needs to know who is who and thus log that information. Maybe that will help someone else, or maybe I'm just "special"...moving on....with a trunk port, we can specify a total amount per physical port, as well as total amount per vlan...

switchport port-security maximum 1 vlan 146
switchport port-security maximum 1 vlan 67
switchport port-security maximum 2


You can also limit based on 'access' and 'voice' vlans.


switchport port-security maximum 1 vlan access
switchport port-security maximum 2 vlan voice


With DHCP snooping, you need to trust the DHCP servers, as well as the trunk ports to DHCP server.You can disable/ignore Option 82 by three methods.
1)Instruct IOS DHCP server to accept DHCP messages with a zero 'giaddr' using the global 'ip dhcp relay information trust-all' or the interface 'ip dhcp relay information trusted'.
2)Configure the DHCP snooping feature to not insert Option82 using 'no ip dhcp-snooping information option'. 
3)Trust the port where you receive the original DHCP message. 


By default, the switch does not accept DHCP packets with a non-zero 'giaddr' on untrusted ports. In addition, it does not accept DHCP packets with Option 82 on untrusted ports. This can be changed with the 'ip dhcp snooping information allow-untrusted'.


With dynamic ARP inspection, the DHCP bindings database is used by default. For static hosts, you need to configure an ARP access-lists and apply the filter.


SW-1(config)#arp access-list VLAN146

SW-1(config-arp-nacl)#permit ip host 155.1.146.1 mac host 000f.3454.a66 log 
SW-1(config-arp-nacl)#permit ip host 155.1.146.4 mac host 0011.9315.78e0 log
SW-1(config)#ip arp inspection filter VLAN146 vlan 146

If there are no permit matches, and there is no explicit 'deny ip any mac any' statement, the feature also checks the DHCP bindings database. If there is a explicit deny, or the access-list has been applied with the 'static' keyword, then ARP inspection does not consult the DHCP snooping database.

To log packets matching the ARP ACL, issue an 'ip arp inspection vlan 146 logging acl-match [matchlog|none}' to enable/disable logging of ARP packets.

With catalyst switches, you can apply both ingress MAC and IP ACLs. You cannot filter IP traffic based on MAC address unless you utilize port-security. Man, do I really have to remember Ethertypes? ARP is 0x806.

Here is something I didn't know. You can attach an access-class to a username. So if you are told that a user can only connect to a specified router, issue the following..


R2(config)#access-list 100 permit ip any host 150.1.1.1
R2(config)#access-list 100 permit ip any host 155.1.146.1
R2(config)#access-list 100 permit ip any host 155.1.0.1  
R2(config)#access-list 100 permit ip any host 155.1.13.1
R2(config)#access-list 100 deny tcp any any eq 80 log
R2(config)#username TELNET access-class 100 

Now when user TELNET logs in to R1, he can only access R1, and any attempts to reach WWW servers will be logged. Pretty neat and simple. Just something I didn't know could be done.

Role-based CLI enhances the command authorization model and instead of using privilege levels, you define user roles. A view may be associated with a user utilizing the local database or special external AAA attribute. You must enable 'aaa new-model' for role-based access-control to work. The 'root' view always exists. You will need to switch to the root view to be able to create other views. Simply issue a 'enable view' and enter the enable password. Create a super-view (includes other views) using 'parser view SUPER super' view and attach the child views. Here is a sample...


parser view INTERFACE1
 secret 5 $1$ROi5$kTuvXkskL1UlhC8EZ0BwG/
 commands interface include all ip
 commands configure include interface
 commands exec include configure terminal
 commands exec include configure
 commands configure include interface FastEthernet0/0



R4#enable view INTERFACE1
Password: 


R4#
*Mar  1 00:13:20.031: %PARSER-6-VIEW_SWITCH: successfully set to view 'INTERFACE1'.
R4#?
Exec commands:
  configure   Enter configuration mode
  credential  load the credential info from file system
  enable      Turn on privileged commands
  exit        Exit from the EXEC
  show        Show running system information


R4#configure t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#?
Configure commands:
  do         To run exec commands in config mode
  exit       Exit from configure mode
  interface  Select an interface to configure


R4(config)#


Moving on to Router IP traffic Export. This is something new for me. It is a feature to monitor IP traffic received or sent on any WAN or LAN interface. This allows monitoring of IP traffic on non-shared interfaces such as Frame-Relay. Really, it's pretty easy and self-explanatory.



ip traffic-export profile EXPORT
  interface FastEthernet0/0
  bidirectional
  incoming access-list Filter
  outgoing access-list Filter
  mac-address c203.05b0.0001

You can set the mode, inbound or bidir. You can also filter a subset of the incoming/outgoing traffic. Then just specify where you are exporting the traffic to (connected interface and MAC) and you are done!

Control plane policing is pretty easy if you have already done MQC policing. Match with ACLs/class-maps, police rate x pps through the policy map, and apply service policy through 'control plane' configuration mode.

Now Control Plane Protection is a whole different beast. In short, the control plane has three sub-interfaces - host, transit and cef exception. Using CPPr, you can drop, filter, police and set queue limits. This is a pretty complicated beast. You can use a class-map type port-filter to match closed ports. You can also create a class-map type queue-threshold to set queue limits. Then when you apply the service policy, you have to specify the type as well. Wow. Will need to do some additional reading on this if I have time.

Next up - Flexible Packet matching. Holy crap.....more reading, lots to learn here...moving on.

And now, zone based firewalls. This one is pretty easy to understand, you just have to put all the pieces together.A short list of steps include:

1. Define access-lists for traffic scopes
2. Defines class-maps(match protocol and optionally ACL)
3. Define policy-maps
4. Configure zones to zone-pairs, apply the policies
5. Assign zones to the interfaces

Meaningful names for all objects with prefixes such as ACL_, CMAP_PMAP, will allow you to easily separate the objects purpose. You can also police within the class-map, and set IOS FW type inspection parameters. You can also inspect protocol specific parameters. The basic zone-based firewall is pretty easy, but once you get into protocol parameters, it gets pretty messy. Man I hate this security stuff...if only there was a CCIE track for security professionals.....................................................

Now on to transparent firewall, which requires running a bridge group. The router can operate the bridge in two modes. Concurrent Routing and Bridging or Integrated Routing and Bridging. CRB mode allows the router to bridge frames between interfaces configured as members of a single bridge group. The router acts as a bridge for one set of interfaces, and a L3 router for the remaining interfaces. IRB mode allows configuring a special Bridge Virtual Interface for every bridge group. This represents the router as a L3 device within the bridge group. BVI is like a SVI in a layer 3 switch. You create bridges with 'bridge crb' or 'bridge irb'. In addition, with IRB, you need to add 'bridge x route ip' to route packets. Then simply add the interfaces to the bridge group by issuing 'bridge-group x'. Bridges by default will have STP disabled - enable with 'bridge x protocol IEEE'. For the transparent firewall, you may apply the classic firewall inspect rules and ACLS to the interface configured with the bridge group numbers.

To filter non-IP traffic, you need to apply a protocol-type access-list. These exist in the range 201 - 299 and permit traffic based on Ethertype of SNAP PID value. Apply with 'bridge-group x input-type-list '. Broadcast frames are subject to the transparent firewall. To permit DHCP, issue 'ip inspect l2-transparent dhcp-passthrough'. Overall, not too difficult. Create a bridge and apply firewall policies to the interfaces - inside,outside,dmz,etc.

You can also do zone-based firewall w/ transparent bridging. Good news! I was able to build the config myself. ZBF is a classic example of Narbik's 'tell a story' method. Remember the steps, and do them in the right order, and it will work every time! Now IOS IPS...

I would say the chance of actually seeing this on the lab is very small, but it is included for completeness. Here are the steps:

1. Download IOS IPS files
2. Creating IOS IPS configuration directory on flash
3. Configuring IOS IPS crypto key
4. Enabling IOS IPS
5. Loading IOS IPS signature package(s) to the router
6. Tuning signatures.

If you see this, the IPS files should already be loaded for you. You create the directory with the unix classic 'mkdir' command. The IOS crpyto key is used to verify the signatures. You simply needs to load Cisco's public key into the router. From there, you need to configure IOS IPS like so...

ip ips name [list ]

ip ips config location flash:

ip ips notify sdee

ip ips notify log

The above should be self-explanatory. The next step is to retire most IPS signuatures. Since the package is so big, the IOS will not be able to fit all signatures into memory. Retired signatures are not compiled in memory, disabled are compiled but not triggered - so it is important to retire the signatures.

ip ips signature-category

     category all

          retired true

     exit

     category ios_ips basic

          retired false

     exit

exit

The above will retire all signatures, and then enable the basic IPS signatures. Now you need to apply the IPS rule to the interface.

interface FastE0/0

ip ips in

The final step is loading the IOS IPS signature package. Signatures are loaded using a special destination known as IDCONF. 

copy ftp://cisco:cisco@10.0.0.100/IOS-S310-CLI.pkg idconf

This will initiate the compile process in the router memory. Use 'show ip ips signature count' to check stats on the loaded signatures. You can also tune individual signatures like so...

ip ips signature-definition

     signature 2004 0

         status

             enabled true

             retired false

         exit 

         engine 

               event-action produce-alert

         exit

         alert-severity high

         fidelity-rating 100

     exit

exit

You can also tune an entire category, use category x instead of the signature definition name above.

Finally, there is a limited Signature Event Action Processing feature. You may assign Target Value Rating to IP subnets.

ip ips event-action-rules

     target-value medium target-address 150.1.2.0/24

    exit

The risk-rating computation formula for attacks towards this IP subnet are 'medium'.

And with that being said, I have completed security. Overall, not too bad. I did learn a few new things, and was introduced to things I had not seen before. I will need to re-visit and read up on several items such as ZBF, Flexible Packet Matching, CPP/CPPr and Role Based CLI. In the mean time, I am moving on to system management, which will probably include my most-hated EEM.....