Entries Tagged as 'Networks'

router-traffic for CBAC

CBAC is the upgrade version of flexible access control. Since access list is not stateful control, which means, if very strict access list applied in Outside interface for inbound traffic, most of traffic initialized from Inside subnet will be blocked. CBAC help us to inspect specified outgress traffic and put state in the state table. When the traffic comes back, the Outside interface won’t block them out.

However, the interesting problem is, if the traffic initilized from local router, the inspection won’t take effect. Like we want to capture transit package by issue “no ip route-cache”, we need to add “router-traffic” option when define CBAC.

ip inspect name INSIDE_OUT tcp router-traffic

IPSec over GRE and IPSec VTI

When reviewing the topic of IPSEC over GRE Tunnel, I have observed that we have several ways to implement it. However, some posts are confusing people. For example, this post is named IPSEC over GRE Tunnel, the actual configuration is IPSec static VTI (Virtual Tunnel Interface), because the configuration under tunnel interface has one line, which indicated that the tunnel mode is changed.

tunnel mode ipsec ipv4

So, in this post, I would like to clarify some misunderstanding.

GRE as IPSec interested traffic

This is the first, and probably less-used solution for IPSec over GRE. We setup Lan-to-Lan IPSec between two physical interface of two routers. Under the crypto map, we set the interested traffic as

access-list 105 permit gre <tunnel_source_ip> <tunnel_source_mask> <tunnel_des_ip> <tunnel_des_mask>

After ping traffic between each end of the tunnel, the IPSec tunnel is setup. The following are the basic configuration of two routers.

R1

!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp key CISCO address 150.1.12.2
!
!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
!
crypto map CRYPTO_MAP 10 ipsec-isakmp
set peer 150.1.12.2
set transform-set R1_TO_R2
match address 105
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
crypto map CRYPTO_MAP
!
access-list 105 permit gre 150.1.12.0 0.0.0.255 150.1.12.0 0.0.0.255
!

R2

!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp key CISCO address 150.1.12.1
!
!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
!
crypto map CRYPTO_MAP 10 ipsec-isakmp
set peer 150.1.12.1
set transform-set R2_TO_R1
match address 105
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
crypto map CRYPTO_MAP
!
access-list 105 permit gre 150.1.12.0 0.0.0.255 150.1.12.0 0.0.0.255
!

GRE Tunnel Protection

Since we use tunnel protection command under tunnel interface, we don’t need to define crypto map, instead, we need to define ipsec profile. Then, we need apply ipsec protection profile to the tunnel interface. The following are the basic configuration. Please note that, there is no “tunnel mode ipsec ipv4” command, which means, the tunnel mode is still GRE.

R1

!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
tunnel protection ipsec profile TEST
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
!

R2

!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
tunnel protection ipsec profile TEST
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
!

Removing 4-Bytes GRE header ???

Cisco brought us IPSec VTI (virtual tunnel interface) in IOS 12.3T. The purpose of that is to have a new tunnel mode to reduce 4 bytes GRE header in the traffic. However, different tunnel mode can apply different application. Here are some considerations for IPSec VTI. The IPsec VTI is limited to IP unicast and multicast traffic only, as opposed to GRE tunnels, which have a wider application for IPsec implementation. Thus, for some non-IP traffic, we still need IPSec over GRE.

R1

!
crypto ipsec transform-set R1_TO_R2 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R1_TO_R2
!
interface Tunnel0
ip address 150.1.121.1 255.255.255.0
tunnel source 150.1.12.1
tunnel destination 150.1.12.2
tunnel protection ipsec profile TEST
tunnel mode ipsec ipv4
!
interface Serial1/0
ip address 150.1.12.1 255.255.255.0
!

R2

!
crypto ipsec transform-set R2_TO_R1 esp-aes 192 esp-sha-hmac
!
crypto ipsec profile TEST
set transform-set R2_TO_R1
!
interface Tunnel0
ip address 150.1.121.2 255.255.255.0
tunnel source 150.1.12.2
tunnel destination 150.1.12.1
tunnel protection ipsec profile TEST
tunnel mode ipsec ipv4
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.0
!

ASA Static NAT 0 0

When configure static NAT on ASA, normally we will put 0 0 at the end of line

static (inside, outside) 10.1.1.1 192.168.1.1 netmask 255.255.255.255 0 0

When we type question mark (?) for the options, it always shows

The maximum number of simultaneous tcp connections the local IP
hosts are to allow, default is 0 which means unlimited
connections. Idle connections are closed after the time
specified by the timeout conn command

I did Google it though, then I found out the real meaning of these two zeros.

The 0, 0 portions of the command means {Max Connections & Emb Limit}. When it is set to 0’s it means unlimited.

The Max Connections is for TCP connection. the Embryonic Limit means the number of connections that are not completely open. i.e. have not gone through the full 3 way handshake. Its to try and stop a DDoS attack. The security appliance uses the embryonic limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination.

Gratuitous ARP

Gratuitous ARP could mean both gratuitous ARP request or gratuitous ARP reply. Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826) but could be used in some cases. A gratuitous ARP request is an AddressResolutionProtocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff. Ordinarily, no reply packet will occur. A gratuitous ARP reply is a reply to which no request has been made.

Gratuitous ARPs are useful for four reasons:

  • They can help detect IP conflicts. When a machine receives an ARP request containing a source IP that matches its own, then it knows there is an IP conflict.
  • They assist in the updating of other machines’ ARP tables. Clustering solutions utilize this when they move an IP from one NIC to another, or from one machine to another.
  • They inform switches of the MAC address of the machine on a given switch port, so that the switch knows that it should transmit packets sent to that MAC address on that switch port.
  • Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts.

Understanding Cisco IDS Signature Series

It is important to understand what a signature is, and what exactly a signature does. A signature is a known type of activity. It has already been detected in the wild and someone has captured the personality or traffic pattern of the attack or intrusive activity and documented it. In many ways, the signature is something akin to a fingerprint. The fingerprint is unique to a person just like the signature is unique to a certain attack or type of activity. A Cisco IDS sensor then compares traffic against the signatures it has configured and will match up this activity when it appears on your network. The parameters you set for the signature will tell the sensor how to respond to the threat. The sensor can send an alarm to your IDS management device, log the event, send e-mail alerts, or even block the suspect traffic at the router, switch, or firewall. Now we are going to discuss each of the signatures. I have taken the time to separate them into the numbered series. The signatures range from 1000 all the way into the 11000s. Besides numerically grouping signatures, the series number represents another type of grouping. They help the administrator narrow down what type of attack is generating the alarms. Are they atomic? Is the attack a string, sweep, or web site exploit? Although the numbers do cover multiple signature types, they help the administrator narrow down his search.

The following list gives a brief description of each signature series.

  • The 1000 series covers the signatures that analyze the content of IP headers.
  • The 2000 series focuses on ICMP signatures.
  • The 3000 series is all about TCP-based signatures.
  • The 4000 series is all about UPD connections and ports on the network.
  • The 5000 series is probably the largest. It covers web (HTTP) traffic.
  • The 6000 series focuses on multiprotocol signatures.
  • The 7000 series has the ARP signatures.
  • The 8000 series is string-matching signatures.
  • The 9000 series covers Back Doors.
  • The 10000 series has signatures that focus on policy enforcement.

The detailed article is in here.

ezRemeber ezVPN Configuration

When playing around Easy VPN server configuration, I felt it’s not straight forward to remember, especially from Cisco configuration guide. Later, I figured it out the way to remember those complicated configuration and very glad to share in here. Basically, the configuration is divided to 6 parts.

  1. Phase 1
  2. Phase 1.5
  3. Phase 2
  4. Dynamic-mapping
  5. Crypto-mapping
  6. Apply to the interface

Phase 1

IPSec Phase I configuration is the same as Lan to Lan (L2L) IPSec configuration. We need to define four basic parameters for crypto isakmp policy.

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

Compared to LAN to LAN IPSec, the ezVPN pre-shared key is defined in easy VPN group. The group name is ID and the pre-shared key is configured under the group settings using the command key <STRING>.

!
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL
!

However, I prefer to configure ezVPN group on Phase 1.5.

Phase 1.5

This so called phase 1.5 implements the special ISAKMP which allows the VPN client requests certain attribute values. Unlike L2L IPSec, which peers are specifically defined, the ezVPN client needs ezVPN Server to tell the attributes that clients request, such as IP address (pool), DNS Server, Split Tunnel and pre-shared key.

!
ip local pool EZVPN 172.22.0.1 172.22.0.254
!
ip access-list extended SPLIT_TUNNEL
permit ip 172.17.94.0 0.0.0.255 any
!
crypto isakmp client configuration address-pool local EZVPN
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL

Note that the per-shared key is only for Phase 1 authentication. Phase 1.5 still need authentication. ISAKMP configuration mode allows for Extended Authentication (Xauth) after the ISAKMP SA has been established. The Xauth is basically refer to AAA list in IOS.

aaa new-model
!
!
aaa authentication login CONSOLE none
aaa authentication login EZVPN local
aaa authorization network EZVPN local
!
username CISCO password 0 CISCO
!
crypto map VPN client authentication list EZVPN
crypto map VPN isakmp authorization list EZVPN

It’s interesting for me that the client authentication and isakmp authorization are actually happened on Phase 1.5, but the configuration is on the final crypto mapping.

Phase 2

The configuration is the same as L2L IPSec.

!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac

Dynamic Mapping

Before mapping crypto to isakmp-ipsec, we should create a dyanmic mapping to accept connections from any remote peer. This part is different with L2L IPSec which specify the peer address by match address <PEER ADDRESS>.

!
crypto dynamic-map DYNAMIC 10
set transform-set 3DES_MD5
reverse-route

To let router has knowledge of the remote end-point, it must has a route on the routing table for the end-point. After issuing reverse-route command, when ezVPN session is up, there is a static route stored in the routing table. To let the other routers has knowledge of ezVPN client, we can simply redistribute static to some dynamic routing protocal such as EIGRP or OSPF.

CRYPTO Mapping

We have defined two lines crypto mapping for authorization and authentication. We need finalize all crypto mappings. Let me summarize what crypto mapping does:

  1. client authentication and isakmp authorization.
  2. client address response.
  3. ipsec-isakmp dynamic mapping.

!
crypto map VPN client configuration address respond
crypto map VPN 10 ipsec-isakmp dynamic DYNAMIC

Apply to the Interface

!
interface FastEthernet0/0
crypto map VPN

ASA Static NAT Interface

When I am dealing with ASA Static NAT interface, I am wondering what’s the order of the interfaces in the bracket. For example, one scenario is to access inside server from global accessible IP address, then we have the following configuration:

static (inside, outside) 150.1.136.100 10.0.0.1

Another scenarios is to let inside desktop to access outside DNS server as inside accessible IP address, then, the interfaces in the bracket are swapped.

static (outside, inside) 10.0.0.100 150.1.136.200

I actually try to figure out why Cisco developer made that syntax, which is not intuitive. Anyway, after take a look Cisco reference, the better explaination is like this:

static (real_interface, mapped_interface) mapped_ip real_ip

So, based on that, the static NAT is much more clearly understanding.

Vulnerability Management Axioms

The article is coming from here. I quoted part of it because it’s useful when we design vulnerability management tools.

To get anywhere with vulnerability management, Northcutt said there are five things to consider first:

  1. Vulnerabilities are the gateways through which threats are manifested.
  2. Vulnerability scans without remediation have little value.
  3. A little scanning and remediation is better than a lot of scanning and less remediation.
  4. Vulnerabilities in need of fixing must be prioritized based on which ones post the most immediate risk to the network.
  5. Security practitioners need a process that will allow them to stay on the trail of vulnerabilities so the fixes can be more frequent and effective.

Windows Vista Firewall Turn On/Off

Windows Vista has three level of firewall profile: Domain Profile, Private Profile and Public Profile. All firewall is on by default. If we want to turn off firewall for our own user, we may go to Windows Vista System Administraion -> Firewall and Advanced Security Center. We see the configuration is complicated. There are tons of rules and policies for inbound and outbound traffic. Is there any simple way to turn on or turn off the firewall for our own user? Of course, the default firewall is turn on. The answer is YES.

We can go to Control Panel -> User Account. We need to click on “Turn User Account Control on or off”.

Then, we can enable/disable User Account Control. System asks to restart. After restart, we can see the firewall policy is applied or disabled.

Windows TCP 139 and 445 Vulnerability

Although those two ports are well known for security reason for a long time, we still hope to know something in details. As we know, NFS (Netwrok File Systems) is developed by Sun. It’s mainly for sharing directories and files between UNIX machines. Microsoft invented a protocol called SMB (Sever Message Blocks), by which, people can share directories and files with other Windows machines. Microsoft is trying to rename SMB-based networking to “Windows Networking” and the protocol to “CIFS”. When we try to mount SAMBA server directory to our Linux machine, we most likely do the following command.

sudo mount -t cifs -o username=henrydu //172.17.93.105/Swap-1Day /mnt/Swap-1Day

Microsoft open a security hole to many people who haven’t set up Administrator’s password. In the early time, people can easily share others C:\WINDOWS directory:

\\172.17.93.105\ADMIN$

Even with password, malicious people still can figure out by port 139 and 445. This article is not for how to hack others by port 139 and 445. We will see how SMB and NETBIOS work.

SMB is the most popular protocols for Windows PCs lets us share files, disks, directories, printers, and (in some cases) even COM ports across a network. SMB-based networks use a variety of underlying protocols, but the most popular are “NetBIOS over TCP/IP”.

Here is a solid example. SMB-client (Hacker) send TCP 445 SYN to SMB-server (Victim). Without waiting for SYN/ACK package, it sends TCP 139 SYN to SMB-server immediately. TCP 445 is to set up SMB session and TCP 139 is to set up NETBIOS session. SMB need NETBIOS protocol. We can see from screen shot that, after TCP 139 and TCP 445 session is up, SMB protocol start to run. From package hierarchy we can see, SMB is over NETBIOS protocol.

After Microsoft noticed this security issue, TCP 139 and 445 is blocked by default. Thus, SMB-server never reply SYN package if the firewall is on. We can use NMAP to do a test.

Firewall is off.

nmap -PN -p139,445 -n -v 172.17.93.105
…..
PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Firewall is on

PORT    STATE    SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds

Therefore, please make sure these two ports are protected by firewall.