F5 101 – Application Delivery Fundamentals


, , , , , , , , ,


The 101-Application Delivery Fundamentals exam is the first exam required to achieve F5 Certified BIG-IP Administrator status. All candidates must take this exam to move forward in the program.

Successful completion of the 101-Application Delivery Fundamentals exam acknowledges the skills and understanding necessary for day-to-day management of Application Delivery Networks (ADNs). This exam identifies candidates that possess the knowledge that is necessary to work with F5 products and technologies.

Section 1 – OSIApplication Delivery Fundamentals

The first section of the exam concentrates on some basic networking concepts, working up the OSI model from the bottom.  Most of this information is common knowledge in the networking industry.

This section is worth 33% of the total test score.

Objective 1.01 – Explain, compare and contrast the OSI layer

OSI Model Wiki
Another OSI Model Overview

Objective 1.02 – Explain protocols and technologies specific to the data-link layer 

ARP on F5
MAC Address
Broadcast Domain
Link Aggregation Wiki
Big IP Link Aggregation

Objective 1.03 – Explain protocols and apply technologies specific to the network layer 

Routing on F5
TCP/IP Overview
IP Addressing & Subnetting
Routing Protocols
IP Packet Fragmentation
IP TTL (Time to Live)

Objective 1.04 – Explain the features and functionality of protocols and technologies specific to the transport layer

TCP Functionality
TCP Connection Setup by Virtual Server Type
TCP Profile Settings (Tunables)
UDP Functionality
UDP Profile Settings (Tunables)

Objective 1.05 – Explain the features and functionality of protocols and technologies specific to the application layer

Application Layer Traffic Managment on F5
HTTP Functionality
HTTP Status Codes
HTTP Headers
F5 HTTP White Paper
DNS Functionality
DNS Record Types
SIP Functionality
F5 SIP White Paper
FTP Functionality
SMTP Functionality
HTTP Cookies
My Name is URL

Section 2 – F5 Solutions and Technology

In this section, we get into the actual F5 Solutions.  Most engineers taking this exam will be experienced with LTM and iRules, but little else.  Hopefully, the familiarity gained from the F5 datasheets and white papers shown below will help you to understand the breadth of the F5 offerings.  Prepare to take the first step into a larger world.

This section is also worth 33% of the total test score.

Objective 2.01 – Articulate the role of F5 products

Access Policy Manager (APM)
Application Security Manager (ASM)
Local Traffic Manager (LTM)
Global Traffic Manager (GTM)
Enterprise Manager (EM)
WAN Optimization Manager (WOM)
Web Accelerator
ARX File Virtualization
F5 White Papers
F5 Datasheets

Objective 2.02 – Explain the purpose, use and advantages of iRules  

iRule Wiki (Requires Devcentral Login)

Objective 2.03 – Explain the purpose, use and advantages of iApps

iApp Wiki (Requires Devcentral Login)

Objective 2.04 – Explain the purpose, use and advantages of iControl

iControl Wiki (Requires Devcentral Login)

Objective 2.05 – Explain the purpose of and use cases for full proxy and packet forwarding / packet based architectures

Full Proxy Architecture (Lori MacVittie rules!)
Packet-Based vs Full Proxy
Auto Last Hop
Virtual Server Types

Objective 2.06 – Explain the advantages and configurations of high availability (HA)

F5 HA Basics 
Config Sync
Big IP HA Features
VLAN Failsafe

Section 3 – Load Balancing Essentials

This section is a short one compared to the previous two.  It’s worth 17% of the total test score.  If you’re going after an F5 certification, you’re probably already familiar with much of this material, so you probably won’t have to study as much for this section.  It never hurts to brush up on the algorithms and persistence methods.

Objective 3.01 – Discuss the purpose of, use cases for, and key considerations related to load balancing

Load Balancing Wiki
Load Balancing 101
Load Balancing Algorithms (Devcentral)
More on Load Balancing Algorithms
Another Load Balancing Algorithm Article
Yet Another Load Balancing Algorithm Article

Objective 3.02 – Differentiate between a client and a server
Client / Server on Wiki – Yes, I’m surprised this is even a question.

Section 4 – Security

This section is weighted at 11% of the total test score, but it feels like it should be more.

Objective 4.01 – Compare and contrast positive and negative security models

Positive Security Model
Positive vs Negative Security

Objective 4.02 – Explain the purpose and cryptographic services
SSL Certificates (Devcentral)
Certificate Chains
Public-Key Cryptography
Symmetric vs Asymmetric Encryption
Client SSL Profiles
Server SSL Profiles

Objective 4.03 – Describe the purpose and advantages of authentication

F5 Authentication 101
Single Sign On
Multi-factor Authentication

Objective 4.04 – Describe the purpose, advantages and use cases of IPsec and SSL VPN


Section 5 – Application Delivery Platforms
The final section is worth only 7% of the total test score.  The finish line is in sight!

Objective 5.01 – Describe the purpose, advantages, use cases, and challenges associated with hardware-based application delivery platforms and virtual machines

Virtualization Platforms

Objective 5.02 – Describe the purpose of the various types of advanced acceleration techniques.
Application Performance Optimization
TCP Optimization
Acceleration 101
Acceleration 102

So there you have it.  Everything you need to pass the F5 Application Delivery Fundamentals exam, and probably more.

If you use this study guide, please comment and let me know if it was helpful and how you did on the test.

Official Study Guide

Exam Blue Print

How to Connect on a Check Point SPLAT or Gaia Gateway with a SFTP/SCP Client


, , , , , , , , , , , , , ,

Check Point administrator should follow below steps in order to use SFTP (Secure File Transfer Protocol) or SCP (Secure Copy Protocol) for transferring files to/from a Check Point (CP) SecurePlatform (SPLAT) or Gaia gateway.

it is important to mention that an authorized user (for example the network security administrator) can use SSH to access a CP SPLAT/Gaia gateway in two modes:

  1. The Standard Mode which is the default mode that an administrator first accesses (via SSH) the CP SPLAT gateway by providing the “admin” user credentials. In this mode, the user is logged in with administrator permissions and can perform only a limited number of operations on the CP SPLAT gateway. The shell assigned to a user that accesses a CP SPLAT gateway (via SSH) in Standard Mode is the /bin/cpshell. For CP Gaia gateways, the /bin/cli.sh is the shell assigned for Standard Mode access (similarly to /bin/cpshell in SPLAT).
  2. The Expert Mode which provides the logged-in user with full UNIX root permissions and a full UNIX shell (/bin/bash). It is important to keep in mind that an authorized user cannot use SSH to login directly in Expert Mode. Instead, he has to login in Standard Mode as a first step, then to type the command expert and to provide the relevant password so as to enter Expert Mode. The /bin/bash shell is defined in both SPLAT and Gaia gateways.

“Why a CP SPLAT or Gaia gateway cannot be accessed by the use of a SFTP/SCP client via port 22 (SSH)” ?

The answer is simple:

If the administrator tries to access the gateway through a SFTP/SCP client, as the admin user (Standard Mode), he receives an “access denied” message since in Standard Mode,  read (e.g. directory listing) and write permissions are restricted. Moreover, if the administrator tries to access the CP SPLAT/Gaia gateway using a SFTP/SCP client, as expert user (full root permissions), access is also denied. The reason is that Expert Mode cannot be directly accessible.

In order to solve our problem, we can follow a simple procedure:

  1. Change the shell that is assigned to the admin user from /bin/cpshell (or bin/cli.sh in Gaia) that is assigned for Standard Mode access, to /bin/bash (Expert Mode)
  2. Access the CP SPLAT/Gaia gateway from a SFTP/SCP client (e.g. WinSCP) as admin and perform all required file transfers
  3. Re-assign the /bin/cpshell (or /bin/cli.sh) shell back to the admin user

The configuration for assigning different shells to the admin user is pretty straightforward. First, you need to access the CP SPLAT/Gaia gateway via SSH and then to execute the commands described below:


Then you may proceed with accessing the CP SPLAT/Gaia gateway through an SFTP/SCP client, as admin.



After performing all required file transfers to/from the CP SPLAT/Gaia gateway you will have to re-assign the /bin/cpshell (or /bin/clish for Gaia) to the admin user:


PS: If you change the default shell with the chsh command on a GAIA system, this will not survive reboot. So, to make it persistent, you have to use the following command within clish:

set user admin shell /bin/bash
 save config


But Remember, you should not make it persistent for a strictly secured environment.

Let me know if you have any questions. 🙂

Cisco IOS Firewall – Convert Router to a Firewall


, , , , , , , , , , , , , , ,

The IOS Firewall is a stateful firewall that inspects TCP and UDP packets at the application layer of the OSI model. It watches the outgoing requests (usually to the Internet) and opens reciprocal, inbound ports for the return traffic. As a stateful firewall, the IOS Firewall maintains the state of each of the TCP connections; it allows return traffic back if it allowed it out and if it matches the state information stored for that TCP packet.

The IOS Firewall recognizes many different types of common TCP and UDP traffic, including SMTP, TFTP, FTP, and others. This is important because, as you know, many of these types of traffic aren’t easy to write access control lists (ACLs) for. Those ACLs are open all the time unless you use the established keyword in your ACL. For example, FTP uses both ports 20 and 21 for data and control, and the IOS Firewall knows this.

The IOS Firewall offers these features:

  • Traffic filtering:This isn’t only at the port level but also at the application level.
  • Traffic inspection:Considered a core firewall feature, this keeps the state of the TCP connection and prevents unauthorized access.
  • Alerts and audit trails:This offers real-time alerts and syslog audit trails.
  • Intrusion prevention:It includes an intrusion detection system that covers 59 of the most common attack signatures — a very cool feature.

Why do I need an IOS Firewall if I have Cisco IOS ACLs?

Over the years, I’ve written a lot of articles about Cisco IOS ACLs. Every Cisco administrator out there needs to master ACLs because so many functions of the Cisco IOS use them.

In fact, to configure the IOS Firewall, you still need to understand how to use ACLs.

Configure the IOS Firewall

To begin, first make sure you have the proper IOS. If you have an IOS that includes the IOS Firewall, enter the ip inspect ? command at the Global Configuration Mode prompt, which will return a list of options, as shown in Figure A.


 Figure A

If the router returns the following, it means you don’t have the IOS Firewall:

% Unrecognized Command

Let’s configure the basic IOS Firewall traffic inspection and filtering. Please note that you should configure this first on a test system with test traffic — an improperly configured firewall can halt all network communications.

Follow these steps:

  1. Choose an interface.To protect your network from the Internet, choose the external WAN public interface.


  1. Configure and apply an ACL.(Here’s one reason why knowing how to work with ACLs is so important.) This ACL should blockeverything you want to permit with the IOS Firewall. Here’s the simplest example possible:
Router(config)# access-list 100 deny tcp any any
Router(config)# access-list 100 deny udp any any
Router(config)# access-list 100 deny ip any any

Next, apply this to the external interface in the inbound direction, as shown below:

Router(config)# interface FastEthernet4
Router(config-if)# ip access-group 100 in
  1. Create your firewall inspection rule.Now you need to define what protocols to inspect and monitor the statefulness of with your firewall.

Let’s say you want to monitor, inspect, and filter not only TCP and UDP but also Citrix ICA, Real Audio, and FTP. You would use these inspection rules:

Router(config)# ip inspect name myfirewall tcp
Router(config)# ip inspect name myfirewall udp
Router(config)# ip inspect name myfirewall ica
Router(config)# ip inspect name myfirewall icabrowser
Router(config)# ip inspect name myfirewall realaudio
Router(config)# ip inspect name myfirewall ftp

Note: Some protocols use multiple port numbers, or the port numbers use a large range, which makes it more difficult when creating an ACL. However, because IOS Firewall works at the application layer, it can recognize these protocols much easier.


  1. Apply the inspection rule.Next you need to apply the inspection rule to your interface in the outdirection. This monitors the traffic that’s going out and dynamically creates inbound openings in your ACL, which would otherwise deny the traffic. Here’s an example:
Router(config-if)# ip inspect myfirewall out

At this point, your firewall should be active and working.

  1. Configure logging and auditing. Now you can configure logging and auditing of your firewall traffic. Assuming you’ve already configured logging, you could do something like this:
Router(config)# ip inspect audit-trail
  1. View the status of your firewall.Here are some of the commands you can use to verify the operation of the IOS Firewall:
  • show ip access-lists(This should show you the dynamic ACL entries when the firewall is opening inbound ports for the return of outbound traffic.)
  • show ip inspect name
  • show ip inspect config
  • show ip inspect interfaces
  • show ip inspect all

Of course, the best way to really test your firewall is to perform a port scan from the outside (or Internet, in this case).

For more information on configuring the Cisco IOS Firewall, check out Cisco’s official documentation: Configuring Cisco IOS Firewall (IOS 12.4).


The IOS Firewall is a very powerful feature that may already be available on your router. While this may not be a solution for Internet protection at very large enterprises, the IOS firewall is an excellent firewall for small and midsize businesses. To make IOS Firewall configuration even easier, you can also configure it with a GUI using Cisco’s SDM Firewall Policy Wizard.


-Tech Republic

CCIE Security V4 Exam Preparation Topics – Part 3


, , , , , , , , , , ,

Topic 1: System Hardening and Availability


1.3 Limit Access to the Network with Infrastructure ACLs

Devised to prevent unauthorized direct communication to network devices, infrastructure access control lists (iACLs) are one of the most critical security controls that can be implemented in networks. Infrastructure ACLs leverage the idea that nearly all network traffic traverses the network and is not destined to the network itself.

An iACL is constructed and applied in order to specify connections from hosts or networks that need to be allowed to network devices. Common examples of these types of connections are eBGP, SSH, and SNMP. After the required connections have been permitted, all other traffic to the infrastructure is explicitly denied. All transit traffic that crosses the network and is not destined to infrastructure devices is then explicitly permitted.

The protections provided by iACLs are relevant to both the management and control planes. The implementation of iACLs can be made easier through the use of distinct addressing for network infrastructure devices.

This example iACL configuration illustrates the structure that must be used as a starting point when you begin the iACL implementation process:

 ip access-list extended ACL-INFRASTRUCTURE-IN
 !--- Permit required connections for routing protocols and
 !--- network management
  permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
  permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
  permit tcp host <trusted-management-stations> any eq 22
  permit udp host <trusted-netmgmt-servers> any eq 161
 !--- Deny all other IP traffic to any network device
  deny ip any <infrastructure-address-space> <mask>
 !--- Permit transit traffic
  permit ip any any

Once created, the iACL must be applied to all interfaces that face non-infrastructure devices. This includes interfaces that connect to other organizations, remote access segments, user segments, and segments in data centers.

ICMP Packet Filtering

The Internet Control Message Protocol (ICMP) is designed as an IP control protocol. As such, the messages it conveys can have far-reaching ramifications to the TCP and IP protocols in general. While the network troubleshooting tools ping and traceroute use ICMP, external ICMP connectivity is rarely needed for the proper operation of a network.

Cisco IOS software provides functionality in order to specifically filter ICMP messages by name or type and code. This example ACL, which must be used with the access control entries (ACEs) from previous examples, allows pings from trusted management stations and NMS servers and blocks all other ICMP packets:

 ip access-list extended ACL-INFRASTRUCTURE-IN
 !--- Permit ICMP Echo (ping) from trusted management stations and servers
  permit icmp host <trusted-management-stations> any echo
  permit icmp host <trusted-netmgmt-servers> any echo
 !--- Deny all other IP traffic to any network device
  deny ip any <infrastructure-address-space> <mask>
 !--- Permit transit traffic
  permit ip any any

Filter IP Fragments

The filter process for fragmented IP packets can pose a challenge to security devices. This is because the Layer 4 information that is used in order to filter TCP and UDP packets is only present in the initial fragment. Cisco IOS software uses a specific method in order to check non-initial fragments against configured access lists. Cisco IOS software evaluates these non-initial fragments against the ACL and ignores any Layer 4 filtering information. This causes non-initial fragments to be evaluated solely on the Layer 3 portion of any configured ACE.

In this example configuration, if a TCP packet destined to on port 22 is fragmented in transit, the initial fragment is dropped as expected by the second ACE based on the Layer 4 information within the packet. However, all remaining (non-initial) fragments are allowed by the first ACE based completely on the Layer 3 information in the packet and ACE. This scenario is shown in this configuration:

 ip access-list extended ACL-FRAGMENT-EXAMPLE
  permit tcp any host eq 80
  deny tcp any host eq 22

Due to the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by ACLs. Fragmentation is also often used in attempts to evade detection by intrusion detection systems. It is for these reasons that IP fragments are often used in attacks, and why they must be explicitly filtered at the top of any configured iACLs. This example ACL includes comprehensive filtering of IP fragments. The functionality from this example must be used in conjunction with the functionality of the previous examples.

 ip access-list extended ACL-INFRASTRUCTURE-IN
 !--- Deny IP fragments using protocol-specific ACEs to aid in
 !--- classification of attack traffic
  deny tcp any any fragments
  deny udp any any fragments
  deny icmp any any fragments
  deny ip any any fragments
 !--- Deny all other IP traffic to any network device
  deny ip any <infrastructure-address-space> <mask>
 !--- Permit transit traffic
  permit ip any any

ACL Support for Filtering IP Options

Cisco IOS Software Release 12.3(4)T added support for the use of ACLs to filter IP packets based on the IP options that are contained in the packet. IP options present a security challenge for network devices because these options must be processed as exception packets. This requires a level of CPU effort that is not required for typical packets that traverse the network. The presence of IP options within a packet can also indicate an attempt to subvert security controls in the network or otherwise alter the transit characteristics of a packet. It is for these reasons that packets with IP options must be filtered at the edge of the network.

This example must be used with the ACEs from previous examples in order to include complete filtering of IP packets that contain IP options:

 ip access-list extended ACL-INFRASTRUCTURE-IN
 !--- Deny IP packets containing IP options
  deny ip any any option any-options
 !--- Deny all other IP traffic to any network device
  deny ip any <infrastructure-address-space> <mask>
 !--- Permit transit traffic
  permit ip any any

ACL Support to Filter on TTL Value

Cisco IOS Software Release 12.4(2)T added ACL support to filter IP packets based on the Time to Live (TTL) value. The TTL value of an IP datagram is decremented by each network device as a packet flows from source to destination. Although initial values vary by operating system, when the TTL of a packet reaches zero, the packet must be dropped. The device that decrements the TTL to zero, and therefore drops the packet, is required in order to generate and send an ICMP Time Exceeded message to the source of the packet.

The generation and transmission of these messages is an exception process. Routers can perform this function when the number of IP packets that are due to expire is low, but if the number of packets due to expire is high, generation and transmission of these messages can consume all available CPU resources. This presents a DoS attack vector. It is for this reason that devices need to be hardened against DoS attacks that utilize a high rate of IP packets that are due to expire.

It is recommended that organizations filter IP packets with low TTL values at the edge of the network. Completely filtering packets with TTL values insufficient to traverse the network mitigates the threat of TTL-based attacks.

This example ACL filters packets with TTL values less than six. This provides protection against TTL expiry attacks for networks up to five hops in width.

 ip access-list extended ACL-INFRASTRUCTURE-IN
 !--- Deny IP packets with TTL values insufficient to traverse the network
  deny ip any any ttl lt 6
 !--- Deny all other IP traffic to any network device
  deny ip any <infrastructure-address-space> <mask>
 !--- Permit transit traffic
  permit ip any any

Note: Some protocols make legitimate use of packets with low TTL values. eBGP is one such protocol.


Next Topic:  Secure Interactive Management Sessions


CCIE Security V4 Exam Preparation Topics – Part 2


, , , , , , , , , , ,

Topic 1: System Hardening and Availability

1.2 Understanding Management Plane Security Technologies and Core Concepts Covering Security Features Available to Protect the Management Plane.

The management plane consists of functions that achieve the management goals of the network. This includes interactive management sessions that use SSH, as well as statistics-gathering with SNMP or NetFlow. When you consider the security of a network device, it is critical that the management plane be protected. If a security incident is able to undermine the functions of the management plane, it can be impossible for you to recover or stabilize the network.

General Management Plane Hardening

The management plane is used in order to access, configure, and manage a device, as well as monitor its operations and the network on which it is deployed. The management plane is the plane that receives and sends traffic for operations of these functions. You must secure both the management plane and control plane of a device, because operations of the control plane directly affect operations of the management plane. This list of protocols is used by the management plane:

  • Simple Network Management Protocol
  • Telnet
  • Secure Shell Protocol
  • File Transfer Protocol
  • Trivial File Transfer Protocol
  • Secure Copy Protocol
  • NetFlow
  • Network Time Protocol
  • Syslog

Steps must be taken to ensure the survival of the management and control planes during security incidents. If one of these planes is successfully exploited, all planes can be compromised.

A)    Password Management

Passwords control access to resources or devices. As a security best practice, passwords must be managed with a TACACS+ or RADIUS authentication server. However, note that a locally configured password for privileged access is still needed in the event of failure of the TACACS+ or RADIUS services. A device can also have other password information present within its configuration, such as an NTP key, SNMP community string, or Routing Protocol key.

enable secret: The enable secret command is used in order to set the password that grants privileged administrative access to the Cisco IOS system. The enable secret command must be used, rather than the older enable password command. The enable password command uses a weak encryption algorithm.

If no enable secret is set and a password is configured for the console tty line, the console password can be used in order to receive privileged access, even from a remote virtual tty (vty) session. This action is almost certainly unwanted and is another reason to ensure configuration of an enable secret.

service password-encryption:The service password-encryption global configuration command directs the Cisco IOS software to encrypt the passwords, Challenge Handshake Authentication Protocol (CHAP) secrets, and similar data that are saved in its configuration file. Such encryption is useful in order to prevent casual observers from reading passwords, such as when they look at the screen over the muster of an administrator.

The enable secret command and the Enhanced Password Security feature use Message Digest 5 (MD5) for password hashing. This algorithm has had considerable public review and is not known to be reversible. However, the algorithm is subject to dictionary attacks.

B)   Enhanced Password Security

The feature Enhanced Password Security, introduced in Cisco IOS Software Release 12.2(8)T, allows an administrator to configure MD5 hashing of passwords for the username command. Prior to this feature, there were two types of passwords: Type 0, which is a cleartext password, and Type 7, which uses the algorithm from the Vigen re cipher. The Enhanced Password Security feature cannot be used with protocols that require the cleartext password to be retrievable, such as CHAP.

In order to encrypt a user password with MD5 hashing, issue the username secret global configuration command.

 username <name> secret <password>

C)   Login Password Retry Lockout

The Login Password Retry Lockout feature, added in Cisco IOS Software Release 12.3(14)T, allows you to lock out a local user account after a configured number of unsuccessful login attempts. Once a user is locked out, their account is locked until you unlock it. An authorized user who is configured with privilege level 15 cannot be locked out with this feature. The number of users with privilege level 15 must be kept to a minimum.

Note that authorized users can lock themselves out of a device if the number of unsuccessful login attempts is reached. Additionally, a malicious user can create a denial of service (DoS) condition with repeated attempts to authenticate with a valid username.

This example shows how to enable the Login Password Retry Lockout feature:

 aaa new-model
 aaa local authentication attempts max-fail <max-attempts>
 aaa authentication login default local
 username <name> secret <password>

This feature also applies to authentication methods such as CHAP and Password Authentication Protocol (PAP).

D)  No Service Password-Recovery

In Cisco IOS Software Release 12.3(14)T and later, the No Service Password-Recovery feature does not allow anyone with console access to insecurely access the device configuration and clear the password. It also does not allow malicious users to change the configuration register value and access NVRAM.

 no service password-recovery

The current password recovery procedure enables anyone with console access to access the device and its network. The No Service Password-Recovery feature prevents the completion of the Break key sequence and the entering of ROMMON during system startup.

If no service password-recovery is enabled on a device, it is recommended that an offline copy of the device configuration be saved and that a configuration archiving solution be implemented. If it is necessary to recover the password of a Cisco IOS device once this feature is enabled, the entire configuration is deleted.

E)    Disable Unused Services

As a security best practice, any unnecessary service must be disabled. These unneeded services, especially those that use User Datagram Protocol (UDP), are infrequently used for legitimate purposes, but can be used in order to launch DoS and other attacks that are otherwise prevented by packet filtering.

The TCP and UDP small services must be disabled. These services include:

  • echo (port number 7)
  • discard (port number 9)
  • daytime (port number 13)
  • chargen (port number 19)

Although abuse of the small services can be avoided or made less dangerous by anti-spoofing access lists, the services must be disabled on any device accessible within the network. The small services are disabled by default in Cisco IOS Software Releases 12.0 and later. In earlier software, the no service tcp-small-servers and no service udp-small-servers global configuration commands can be issued in order to disable them.

This is a list of additional services that must be disabled if not in use:

  • Issue the no ip finger global configuration command in order to disable Finger service. Cisco IOS software releases later than 12.1(5) and 12.1(5)T disable this service by default.
  • Issue the no ip bootp server global configuration command in order to disable Bootstrap Protocol (BOOTP).
  • In Cisco IOS Software Release 12.2(8)T and later, issue the ip dhcp bootp ignore command in global configuration mode in order to disable BOOTP. This leaves Dynamic Host Configuration Protocol (DHCP) services enabled.
  • DHCP services can be disabled if DHCP relay services are not required. Issue the no service dhcp command in global configuration mode.
  • Issue the no mop enabled command in interface configuration mode in order to disable the Maintenance Operation Protocol (MOP) service.
  • Issue the no ip domain-lookup global configuration command in order to disable Domain Name System (DNS) resolution services.
  • Issue the no service pad command in global configuration mode in order to disable Packet Assembler/Disassembler (PAD) service, which is used for X.25 networks.
  • The HTTP server can be disabled with the no ip http server command in global configuration mode, and Secure HTTP (HTTPS) server can be disabled with the no ip http secure-server global configuration command.
  • Unless Cisco IOS devices retrieve configurations from the network during startup, the no service config global configuration command must be used. This prevents the Cisco IOS device from an attempt to locate a configuration file on the network with TFTP.
  • Cisco Discovery Protocol (CDP) is a network protocol that is used in order to discover other CDP enabled devices for neighbor adjacency and network topology. CDP can be used by Network Management Systems (NMS) or during troubleshooting. CDP must be disabled on all interfaces that are connected to untrusted networks. This is accomplished with the no cdp enable interface command. Alternatively, CDP can be disabled globally with the no cdp run global configuration command. Note that CDP can be used by a malicious user for reconnaissance and network mapping.
  • Link Layer Discovery Protocol (LLDP) is an IEEE protocol that is defined in 802.1AB. LLDP is similar to CDP. However, this protocol allows interoperability between other devices that do not support CDP. LLDP must be treated in the same manner as CDP and disabled on all interfaces that connect to untrusted networks. In order to accomplish this, issue the no lldp transmit and no lldp receive interface configuration commands. Issue the no lldp run global configuration command in order to disable LLDP globally. LLDP can also be used by a malicious user for reconnaissance and network mapping.

F)    EXEC Timeout

In order to set the interval that the EXEC command interpreter waits for user input before it terminates a session, issue the exec-timeout line configuration command. The exec-timeout command must be used in order to logout sessions on vty or tty lines that are left idle. By default, sessions are disconnected after 10 minutes of inactivity.

 line con 0
  exec-timeout <minutes> [seconds]
 line vty 0 4
  exec-timeout <minutes> [seconds]

G)  Keepalives for TCP Sessions

The service tcp-keepalives-in and service tcp-keepalives-out global configuration commands enable a device to send TCP keepalives for TCP sessions. This configuration must be used in order to enable TCP keepalives on inbound connections to the device and outbound connections from the device. This ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are removed from the local Cisco IOS device.

 service tcp-keepalives-in
 service tcp-keepalives-out

H)  Management Interface Use

The management plane of a device is accessed in-band or out-of-band on a physical or logical management interface. Ideally, both in-band and out-of-band management access exists for each network device so that the management plane can be accessed during network outages.

One of the most common interfaces that is used for in-band access to a device is the logical loopback interface. Loopback interfaces are always up, whereas physical interfaces can change state, and the interface can potentially not be accessible. It is recommended to add a loopback interface to each device as a management interface and that it be used exclusively for the management plane. This allows the administrator to apply policies throughout the network for the management plane. Once the loopback interface is configured on a device, it can be used by management plane protocols, such as SSH, SNMP, and syslog, in order to send and receive traffic.

 interface Loopback0
  ip address

I)      Memory Threshold Notifications

The feature Memory Threshold Notification, added in Cisco IOS Software Release 12.3(4)T, allows you to mitigate low-memory conditions on a device. This feature uses two methods in order to accomplish this: Memory Threshold Notification and Memory Reservation.

Memory Threshold Notification generates a log message in order to indicate that free memory on a device has fallen lower than the configured threshold. This configuration example shows how to enable this feature with the memory free low-watermark global configuration command. This enables a device to generate a notification when available free memory falls lower than the specified threshold, and again when available free memory rises to five percent higher than the specified threshold.

 memory free low-watermark processor <threshold>
 memory free low-watermark io <threshold>

Memory Reservation is used so that sufficient memory is available for critical notifications. This configuration example demonstrates how to enable this feature. This ensures that management processes continue to function when the memory of the device is exhausted.

 memory reserve critical <value>

J)      CPU Thresholding Notification

Introduced in Cisco IOS Software Release 12.3(4)T, the CPU Thresholding Notification feature allows you to detect and be notified when the CPU load on a device crosses a configured threshold. When the threshold is crossed, the device generates and sends an SNMP trap message. Two CPU utilization thresholding methods are supported on Cisco IOS software: Rising Threshold and Falling Threshold.

This example configuration shows how to enable the Rising and Falling Thresholds that trigger a CPU threshold notification message:

 snmp-server enable traps cpu threshold
 snmp-server host <host-address> <community-string> cpu 
 process cpu threshold type <type> rising <percentage> interval <seconds> 
      [falling <percentage> interval <seconds>]
 process cpu statistics limit entry-percentage <number> [size <seconds>]

K)   Reserve Memory for Console Access

In Cisco IOS Software Release 12.4(15)T and later, the Reserve Memory for Console Access feature can be used in order to reserve enough memory to ensure console access to a Cisco IOS device for administrative and troubleshooting purposes. This feature is especially beneficial when the device runs low on memory. You can issue the memory reserve console global configuration command in order to enable this feature. This example configures a Cisco IOS device to reserve 4096 kilobytes for this purpose.

 memory reserve console 4096

L)    Memory Leak Detector

Introduced in Cisco IOS Software Release 12.3(8)T1, the Memory Leak Detector feature allows you to detect memory leaks on a device. Memory Leak Detector is able to find leaks in all memory pools, packet buffers, and chunks. Memory leaks are static or dynamic allocations of memory that do not serve any useful purpose. This feature focuses on memory allocations that are dynamic. You can use the show memory debug leaks EXEC command in order to detect if a memory leak exists.

M) Buffer Overflow: Detection and Correction of Redzone Corruption

In Cisco IOS Software Release 12.3(7)T and later, the Buffer Overflow: Detection and Correction of Redzone Corruption feature can be enabled by on a device in order to detect and correct a memory block overflow and to continue operations.

These global configuration commands can be used in order to enable this feature. Once configured, the show memory overflow command can be used in order to display the buffer overflow detection and correction statistics.

 exception memory ignore overflow io
 exception memory ignore overflow processor

N)  Enhanced Crashinfo File Collection

The Enhanced Crashinfo File Collection feature automatically deletes old crashinfo files. This feature, added in Cisco IOS Software Release 12.3(11)T, allows a device to reclaim space in order to create new crashinfo files when the device crashes. This feature also allows configuration of the number of crashinfo files to be saved.

 exception crashinfo maximum files <number-of-files>

O)  Network Time Protocol

The Network Time Protocol (NTP) is not an especially dangerous service, but any unneeded service can represent an attack vector. If NTP is used, it is important to explicitly configure a trusted time source and to use proper authentication. Accurate and reliable time is required for syslog purposes, such as during forensic investigations of potential attacks, as well as for successful VPN connectivity when depending on certificates for Phase 1 authentication.

  • NTP Time Zone – When you configure NTP, the time zone needs to be configured so that timestamps can be accurately correlated. There are usually two approaches to configure the time zone for devices in a network with a global presence. One method is to configure all network devices with the Coordinated Universal Time (UTC) (previously Greenwich Mean Time (GMT)). The other approach is to configure network devices with the local time zone. More information on this feature can be found in ?clock timezone? in the Cisco product documentation.
  • NTP Authentication – If you configure NTP authentication, it provides assurance that NTP messages are exchanged between trusted NTP peers.


Next Topic: Understanding Management Plane Security Technologies and Core Concepts Covering Security Features Available to Protect the Management Plane:- Limit Access to the Network with Infrastructure ACLs

CCIE Security V4 Exam Preparation Topics – Part 1


, , , , , , , , , , , ,

I know, every Network Security Engineer has a dream of completing CCIE Security certification. But the fact is it’s really a pain in vain. So i am trying to prepare all the CCIE security V4 topics here one-by-one for easy reading and preparation.

Your comments and suggestions are really appreciated.



Topic 1: System Hardening and Availability


1.1   Understanding Types of Traffic Planes on a Cisco Router (Control, Management and Data)

This article contains information to help you secure your Cisco IOS® system devices, which increases the overall security of your network. Structured around the three planes into which functions of a network device can be categorized, this document provides an overview of each included feature and references to related documentation.

The three functional planes of a network – the management plane, control plane, and data plane – each provide different functionality that needs to be protected.

  • Management Plane – The management plane manages traffic that is sent to the Cisco IOS device and is made up of applications and protocols such as Secure Shell (SSH) and Simple Network Management Protocol (SNMP).
  • Control Plane – The control plane of a network device processes the traffic that is paramount to maintain the functionality of the network infrastructure. The control plane consists of applications and protocols between network devices, which includes the Border Gateway Protocol (BGP), as well as the Interior Gateway Protocols (IGPs) such as the Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF).
  • Data Plane – The data plane forwards data through a network device. The data plane does not include traffic that is sent to the local Cisco IOS device.


Next Topic: Understanding Management Plane Security Technologies and Core Concepts Covering Security Features Available to Protect the Management Plane.

Heartbleed Threat Alert


, , , , , ,


Recently, a major security vulnerability named “Heartbleed” has made headlines around the world. This is a severe vulnerability stemming from a coding mistake in a widely-used security utility called OpenSSL.

The bug affects the encryption technology designed to protect your sensitive data on the Internet, like usernames, passwords and emails.

This is a flaw in the OpenSSL encryption code, not a virus that can be stopped by McAfee or other consumer security software. Because this vulnerability takes advantage of servers, and not consumer devices, businesses need to update to the latest version of OpenSSL to mitigate and address the dangers posed.

The severity of the Heartbleed vulnerability cannot be overstated: several major enterprises use OpenSSL, and are likely affected by this vulnerability as well. The dangers posed by this vulnerability are very real and could affect you if exploited.

So what do you need to do?

  • Right now, the best thing you can do is wait to be notified about affected services and patches or you can.
  • If you’d like to investigate whether or not a website you frequent has been affected, you can use this tool.
  • Reset your password for every online service affected by Heartbleed. But beware:you should only change your password after the afflicted business has fixed its servers to remove the Heartbleed vulnerability. Changing your passwords before a company’s servers are updated will not protect your credentials from being leaked.

You’re likely affected either directly or indirectly by the bug, which was found by a member of Google’s security team and a software firm named Codenomicon.

The bad news: There’s not a lot you can do about it now. It’s the responsibility of Internet companies to update their servers to deal with Heartbleed, and once they do, you can take action.

The issue involves network software called OpenSSL, which is an open-source set of libraries for encrypting online services. In theory, a cybercriminal could have exploited Heartbleed by making network requests that could piece together your sensitive data.

The good news: There isn’t any indication that a hacker caught wind of this; it seems the researchers were the first to locate the problem.

But the scary part is that attackers could have infiltrated these websites, extracted the information they wanted and left no trace of their presence. Thus, it’s hard to determine whether someone ever exploited the bug, or if your account information was compromised.


What to do

First, check which sites you use are affected. If you don’t want to read through the long list of websites with the security flaw, the password security firm LastPass has set up a Heartbleed Checker, which lets you enter the URL of any website to check its vulnerability to the bug and if the site has issued a patch.

Next, change your passwords for major accounts — email, banking and social media logins — on sites that were affected by Heartbleed but patched the problem. That patch should also include reissuing any digital certificates that might be vulnerable. However, if the site or service hasn’t patched the flaw yet, there’s no point to changing your password. Instead, ask the company when it expects to push out a fix to deal with Heartbleed.

A big cause for concern is related to sites that have your sensitive information, such as Yahoo and OKCupid (most people aren’t logging into NASA.gov with private data). Both companies have since issued a patch to fix the security hole, so users with accounts with those companies — including Yahoo Mail, Flickr and so on — should update their passwords immediately.

It’s important to wait to get the “all clear” sign from a company or service before changing, especially now that this bug is out in the open. Changing a password before the bug is fully patched wont’ make things any better.

Facebook and Twitter use OpenSSL web servers, though it’s still unclear whether or not they were vulnerable to the issue.Facebook reportedly issued a security patch, as did Google.

Other websites that have issued an OpenSSL software security update include WordPress, Amazon Web Services and Akamai.

Some websites not considered vulnerable include AOL, Foursquare and Evernote, among others.

“It’s a big deal for Internet users, especially when it comes to protecting financial information,” Joe Siegrist, CEO and cofounder of LastPass, told. “Some financial organizations are using more conservative web security choices like Microsoft, which is not vulnerable to the bug, so users should check and see if their bank has been affected.”

Make sure to keep an eye on sensitive online accounts, especially banking and email, for suspicious activity for the next week or so.

Heartbleed checker tools:



lets hope for the best.  🙂



Checkpoint OS- GAiA


, , , , , , ,

Check Point Gaia is the next generation Secure Operating System for all Check Point Appliances, Open Servers and Virtualized Gateways.

Gaia combines the best features from IPSO and SecurePlatform (SPLAT) into a single unified OS providing greater efficiency and robust performance. By upgrading to Gaia, customers will benefit from improved appliance connection capacity and reduced operating costs. With Gaia, IP Appliance customers will gain the ability to leverage the full breadth and power of all Check Point Software Blades.

Gaia secures IPv6 networks utilizing the Check Point Acceleration & Clustering technology and it protects the most dynamic network and virtualized environments by supporting 5 different dynamic routing protocols. As a 64-Bit OS, Gaia increases the connection capacity of existing appliances supporting up-to 10M concurrent connections for select 2012 Models.

Gaia simplifies management with segregation of duties by enabling role-based administrative access. Furthermore, Gaia greatly increases operation efficiency by offering Automatic Software Update.

The feature-rich Web interface allows for search of any command or property in a second.

Gaia provides backward compatibility with IPSO and SPLAT CLI-style commands making it an easy transition for existing Check Point customers.

main features of Gaia

  • Support for all Check Point appliances.
  • Support for all Open servers appearing on the Check Point Hardware Compatibility List.
  • High Connection Capacity through 64-bit support on select appliances.
  • New Web UI portal providing full control of the system, with search capability and web based terminal.
  • Unified command line shell which is backward compatible with Clish and cpshell.
  • IPv6 native support, including acceleration, ClusterXL ,Web UI and command line shell.
  • ClusterXL and VRRPRole Based Administration – fine grained control of Administrator’s privileges.
  • RADIUS and TACACS+ support.


The following appliances are supported by Gaia:

  • 2012 appliances – 21400, 12600, 12400, 12200, 4800, 4600, 4200, 2200
  • Power-1 – 11000, 9070, 5070
  • UTM-1 – 3070, 2070, 1070, 570, 270, 130
  • Smart-1 – 150, 50, 25, 25B, 5
  • IP Appliances – IP2450, IP1280, IP690, IP560, IP390, IP290, IP282, IP150

Gaia supports all the Open Servers that SecurePlatform supports. You can check the Hardware Compatibility List on the Check Point public site.


If you feel this article helped you to get some learning, please support by clicking below.


IP-Monitoring in SRX cluster


, , , , , , , , ,

In an SRX chassis cluster setup, in addition to interface monitoring you can also use
IP monitoring to monitor the health of your upstream path.


Above is a simple topology to explain how ip monitoring works. In this setup node0 and node1 are part of an srx chassis cluster. reth0.0 interface is part of the redundancy group 1 (RG1)

Currently node0 is the primary for RG1 as you can see from the output below;

root@node0> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1
 node0 100 primary no no
 node1 99 secondary no no

Redundancy group: 1 , Failover count: 1
 node0 100 primary no no
 node1 99 secondary no no

Now lets configure IP monitoring to detect any failure in network layer.

root@node0# show chassis cluster redundancy-group 1 ip-monitoring
global-weight 100;
global-threshold 200;
retry-interval 3;
retry-count 5;
family {
 inet { {
 weight 200;
 interface reth0.0 secondary-ip-address;

The config above instructs SRX:

  • Monitor IP address by sending ICMP packets at 3 seconds (retry-interval) interval.
  • If 5 consecutive attempts (retry-count) fail, mark the IP address unreachable.
  • then deduct the weight 200 from the global-threshold value (i.e 200)
  • and if the result of this deduction is 0, then deduct global-weight 100 from the RG1 threshold (255)

Configured secondary-ip-address shouldn’t be the primary IP address on reth0.0 as far as the documentation is concerned but it must be on the same subnet. In a nutshell, primary node is using reth0.0 interface address ( as the source and secondary node is using the IP (with MAC address of the secondary node child interface)

After configuring this ip-monitoring, here is the status. IP is reachable.

root@srx0> show chassis cluster ip-monitoring status

Redundancy group: 1

IP address Status Failure count Reason reachable 0 n/a


Redundancy group: 1

IP address Status Failure count Reason reachable 0 n/a

Now I disable ICMP responses on the gateway, to simulate a failure and
ip address is marked as unreachable.

root@srx0> show chassis cluster ip-monitoring status
Redundancy group: 1
IP address Status Failure count Reason unreachable 1 unknown
Redundancy group: 1
IP address Status Failure count Reason reachable 0 n/a

When we check the cluster information, we can see that threshold is 155 now.
Because our global weight is 100 for this monitored IP address (255-100=155)

root@srx0> show chassis cluster information
Redundancy mode:
 Configured mode: active-active
 Operational mode: active-active

Redundancy group: 0, Threshold: 255, Monitoring failures: none
 Sep 19 14:34:43.366 : hold->secondary, reason: Hold timer expired
 Sep 19 14:34:59.817 : secondary->primary, reason: Better priority (100/99)

Redundancy group: 1, Threshold: 155, Monitoring failures: ip-monitoring
 Sep 19 14:34:43.379 : hold->secondary, reason: Hold timer expired
 Sep 19 14:34:59.852 : secondary->primary, reason: Remote yeild (0/0)

You might have noticed that there is no failover yet, since for failover to happen, RG1 threshold must reach 0 which isn’t the case on this simulation.

Now, I change the config and set the IP weight to 200 and global to 255 to simulate a failover;

global-weight 255;
global-threshold 200;
retry-interval 3;
retry-count 5;
family {
 inet { {
 weight 200;
 interface reth0.0 secondary-ip-address;

After a network failure, node1 becomes primary this time.

root@srx0> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1
 node0 100 primary no no
 node1 99 secondary no no

Redundancy group: 1 , Failover count: 46
 node0 100 secondary no no
 node1 99 primary no no

You might see the high failure count 46 in the output. This happened after I made simulation mistake 🙂
I thought that I can just block ICMP from on the Linux GW device as such;

iptables -A INPUT -p icmp -s -j DROP
and it should trigger a failover. Yes, assumption was correct, it should trigger a failover as node1 is able to ping from 11.99 but once the failover occurs, node1 becomes primary and now it starts pinging from 11.100 which fails again and causes another failover. This caused a sort of dead lock in the cluster but,

I have learned something in there 🙂


If you feel this article helped you to get some learning, please support by clicking below.