Reversible vs. Non-Reversible Encryption

Cisco devices can store passwords using either a reversible (Type 7) or non-reversible (Type 4 or 5, enabled by the “secret” keyword) encryption.

Reversible encryption has the ability to decrypt the stored password, which can then be compared to the password a user wishing to authenticate provides. Cisco Type 7 passwords are stored using reversible encryption. When you configure a password with “service password-encryption” enabled in the config, the device runs a calculation against the password, creating a string that contains the encrypted password. It is not a simple substitution cipher, but it is easily decrypted, and can even be decrypted on a router. Continue reading

Practical OSI Layers – Part 2

In the previous post, we took a look at the basics of the OSI and TCP/IP model layers. In this post we are going to take a closer look at end to end routing of a packet, and the interaction between layers 2 and 3 as a packet is passed between routers to it’s ultimate destination. The following is the general process to route between endpoints. Some operating systems may behave a little different that described, but this is the general process.

This post will use this network, with a telnet session from R1 to R3. R1 is connected to R2 via a serial link running PPP, and R2 is connected to R3 via an Ethernet segment. Continue reading

Decrypting router passwords with a router

The command “show key chain” shows the decrypted key strings, and because of that, can be used to decrypt other type 7 passwords:

R1(config)#username cisco password cisco
R1(config)#do show run | include password 7
username cisco password 7 05080F1C2243
 password 7 ****
R1(config)#key chain CRACK
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string 7 05080F1C2243
R1(config-keychain-key)#do show key chain
Key-chain CRACK:
    key 1 — text “cisco”
        accept lifetime (always valid) – (always valid) [valid now]
        send lifetime (always valid) – (always valid) [valid now]
R1(config-keychain-key)#

Exchange and Zone-Based firewalls

I ran into some issues with Exchange running through Zone-based firewalls, where the servers would not pass mail between them. This appears to be related to SMTP inspection rejecting the ESMTP commands Exchange uses. The problem can be resolved by creating a class for SMTP between your mailservers, and configuring it with a pass action, instead of inspect. Just remember that you need to create rules in both directions, and the class must be before any classes that would inspect the traffic.

A Simple config would look something like this, with the mail servers at 172.16.1.10 and 172.17.1.10.

ip access-list extended ACL-FIREWALL-EXCHANGE
 permit tcp 172.0.1.10 0.255.0.0 172.0.1.10 0.255.0.0 eq 25
 permit tcp 172.0.1.10 0.255.0.0 eq 25 172.0.1.10 0.255.0.0
 ! The access-list matches traffic to or from either mail server 

class-map CLASS-FIREWALL-EXCHANGE
 match access-group name ACL-FIREWALL-EXCHANGE

class-map CLASS-FIREWALL-ALLOWED-PROTOCOLS
 match protocol HTTP
 match protocol HTTPS
 match protocol FTP 

policy-map type inspect POL-MAP-LAN-TO-WAN
 class  CLASS-FIREWALL-EXCHANGE
  pass
 class  CLASS-FIREWALL-ALLOWED-PROTOCOLS
  inspect 
 class class-default
  drop 

policy-map type inspect POL-MAP-WAN-TO-LAN
 class  CLASS-FIREWALL-EXCHANGE
  pass
 class  CLASS-FIREWALL-ALLOWED-PROTOCOLS
  inspect 
 class class-default
  drop 

zone security WAN
zone security LAN
zone-pair security WAN-TO-LAN source WAN destination LAN
 service-policy type inspect POL-MAP-FIREWALL-OUTBOUND
zone-pair security LAN_TO_WAN source LAN destination WAN
 service-policy type inspect POL-MAP-LAN-TO-WAN

interface e0/0
 zone-member security LAN

interface s0/0
 zone-member security WAN