The Cisco IronPort Appliances are geared and operated by powerful collections of software’s better known as AsyncOS. The AsyncOS is a collection of base operating system (OS), device drivers, memory management, process scheduling, and all the application and scanning software. Few unique features of AsyncOS are its high performance and security.

The AsyscOS fundamentals are built on FreeBSD, low-level components are written in C programing language. However, most of the application software and the entire management interface is written in Python and use a coroutine-based model called shrapnel.

AsysncOS versions are referred as the Major.Minor.Point-Build number format as shown below.

One interesting fact about the AsyncOS software builds is. It is complete and self-contained. When an AsyncOS is upgraded from, one version to another, the entire build image is upgraded rather than individual upgrade component.

When it comes to Email Security, no other product is as powerful as Cisco IronPort. Therefore, we opted Cisco IronPort C370 as our email security gateway. Since its inception into our network, I am searching for a great reference and study guide for the Cisco IronPort products.

At the beginning, I was depending more or less on Cisco Web Site resources, which are great. However, the moment I discovered that Chris Porter is writing a book with a title “Email Security with Cisco Iron Port” I was excited. Immediately I contacted Jamie Adams at Cisco Press, as usual she arranged a copy of book for me for a review and reference.

The title “Email Security with Cisco IronPort” is tailored made for those professionals who have a good understanding of  basic networking concepts.  The author Chris Porter did an amazing job especially with the Introduction part. I really loved it, be it the overview or history of AsyncOS versions. I think the author is quite smart in addressing his readers, be they are beginners or experts of the subject. He knows how to keep them intact.

The title “Email Security with Cisco IronPort” consists of 15 chapters covering the concepts like ESA products, the WEB user interface, Command Line interface in IronPort, and much more in detail and in simple language.

The main highlight of “Email Security with Cisco IronPort” book is the configurations recommended by Chris Porter.

After reading this title, it really enriched my knowledge and made my quite competent in managing Cisco IronPort devices, I would definitely recommend this title to all those professionals who are keen to know more about Email Security with Cisco IronPort devices.

During this journey what we observed is that some vendors were reluctant to provide a proof of concept, and they tried to convince us they are in the in the magic quadrant of Gartner in that particular field, by doing, so they lost the opportunity with us. My question here is, it right to choose a product or solution just because it is in a magic quadrant of Gartner? Your feedback and comments are helpful.

Recently, I configured our Cisco IPS Sensors modules SSM-40 installed in the Cisco ASA 5540 and Cisco IPS 4270 sensor to auto update the signature behind our Blue Coat Proxy SG, upon configuration, I discovered that the auto updates failed. When I tried to know status by using Cisco IOS command.

 “show statistics host” I discovered the auto updates failed, and the command was giving the following errors

IPS#show statistics host

Auto Update Statistics

lastDirectoryReadAttempt = 19:31:09 CST Thu May 9 2013

= Read directory: https://198.133.219.25//cgi-bin/front.x/ida/locator/locator.pl

= Error: AutoUpdate exception: HTTP connection failed [1,110]   <–

lastDownloadAttempt = 19:08:10 CST Thu May 9 2013

lastInstallAttempt = 19:08:44 CST Thu May 9 2013

nextAttempt = 19:35:00 CST Thu May 9 2013

These errors generally observed in IPS sensors running 7.0(7) and 7.0(8) due to a bug “CSCub08230”. In order to overcome this problem available work around is either to download the signature update package manually from Cisco.com and apply the updates manually to the IPS sensors or to upgrade the Cisco IPS sensors to latest  update of 7.2.

The strange thing is that the IPS Sensors were communicating with the Cisco Servers they could be able to connect bypass the proxy servers as shown in my below capture.

However, they failed to update signature simply because the initial connection to the locator service is performed using the HTTPS connection, and the once sensor is authenticated by the digital certificate provided by the server. The connection is switched over to HTTP for the auto-update process. This changer over from HTTPS to HTTP is failing due to the bug “CSCub08230”

Hence, temporarily I was forced to revert my configuration and allow IPS sensors to communicate directly with Cisco servers bypassing our bluecoat proxy server.

The below example shows how to enable this feature

CiscoSwitch(config)# monitor session 1 source interface g0/1

CiscoSwitch(config)# monitor session 1 destination interface g0/2 encapsulation replicate

Recently we were asked to configure the Polycom device to have video conferencing with external world. Our Polycom device is behind a Cisco ASA 5540 firewall as shown in the below network layout.

In order to permit H.323 video conferencing you need to follow the following steps

Step 1

Define static NAT rules

In the above example we will create a NAT rule for the external IP address 192.168.0.3 to the internal IP address 10.0.0.2 (assigned to Polycom device) using the following Cisco IOS command in ASA firewall.

static (inside,outside) 192.168.0.3 10.0.0.2 netmask 255.255.255.255

Step 2

 Create an access list to allow access to polycom device from external network, we need to allow the following ports tcp/udp to enable to video conferencing and apply the same to outside interface

H323 -udp

1720 – tcp

3230 3285 – tcp

access-list Outside_In remark Allow traffic going to polycom device

access-list Outside_In extended permit udp any host 192.168.0.3 eq 1720

access-list Outside_In extended permit tcp any host 192.168.0.3 eq h323

access-list Outside_In extended permit udp any host 192.168.0.3 range 3230 3285

access-list Outside_In extended permit tcp any host 192.168.0.3 range 3230 3243

access-group Outside_In in interface outside

Step 3

Create the Access list which will allow traffic to traverse the ASA firewall from Internal to External network, repeat the steps above, but ensure the Interface: is set to inside as shown below.

access-list Inside_In remark Allow Traffic form polycom device to outside

access-list Inside_In extended permit udp host 10.0.0.2 any range 3230 3285

access-list Inside_In extended permit tcp any host 10.0.0.2 eq h323

access-list Inside_In extended permit tcp host 10.0.0.2 any range 3230 3242

access-group Inside_In in interface inside

By following the above three steps you can enable video conference to any polycom device behind the ASA firewall.

1. 1.     Exception Reporting

All infractions of the Data Center Physical Security Policies and Procedures shall been reported to the ITKE*.  If warranted (e.g., emergency, imminent danger, etc.).

When an unauthorized individual is found in the DataCenterit must be reported immediately to the responsible ITKE* member.  If this occurs during the evening hours, IT call center or ITKE* senior staff should be contacted.  The unauthorized individual should be escorted from theDataCenter and a full written report should be immediately submitted to ITKE*.

1. 2.     Requesting Access to the Data Center

Departments / Projects that have computer equipment in the DataCentermay request access to the DataCenter.  The individuals designated by the requesting department/project will be granted access once ITKE* authorized them.  To initiate authorization for access, the manager of the department/project requesting access should direct a request to the ITKE* .  Upon approval by the Head of ITKE*, the person will fill the “Datacenter Access Request Form” and be provided with a copy of the ITKE* Data Center Access Policies and Procedures document.  A person’s department must notify the ITKE* as soon as possible so that the person’s access to the Data Center can be removed.  This is extremely important in cases where the employee was terminated for cause.  ITKE* – reserves the right not to allow entrance to the Data Centre if the Data Centre already has too many companies performing works.

RESPONSIBILITY

1. It is the responsibility of the ITKE*, End-user Departments, contractors/ vendors/representative to ensure implementation of this IPP.
2. Respective department heads are responsible for ensuring adherence to the provisions of this IPP.
3. Audit and Follow-Up Administration will monitor compliance to the provisions stipulated herein.

I hope the policies covered in these series of article will help you out to draft an effective Data Center policy.

*ITKE is used just as reference which can be replaced by your organization or department name

1.       Periodic Review and Termination / Revocation Access

2.       Access Control Log

 1.       Periodic Review and Termination / Revocation Access

Periodic (at least annual) reviews will be performed of those with any level of access to the Data Center.  ITKE* will perform these reviews.  If an individual no longer requires Data Center access, it will be terminate by Removing name from the ITKE* staff Access List.  The results of periodic reviews will be reported to the Head of ITKE*.  The report will include an updated list of those allowed access to the Data Center.

2.       Access Control Log

The Data Center Access Control Log must be properly maintained at all times.

The Log is maintained by ITKE* staff Access.  All individuals with ITKE* staff Access to the Data Center are responsible for maintaining this log. The following procedures must be followed:

• Each time an individual with Contractors Access to the Data Center is admitted to the area, he must properly log in on the Access Control Log at the time of entrance.  The person admitting the visitor must countersign and fill out the appropriate section of the form.

• Each time an individual with Contractors Access leaves the area, he must properly log out on the Access Control Log at the time he leaves (even if only for a short time). The person with ITKE* staff Access to the area who allows the visitor to leave must fill out the “Log Out” section of the Access Control Log.  The Representatives and the accompanying persons must wear their staff ID cards and our visitor cards within the ITKE* – Data Centre.

*ITKE is used just as reference which can be replaced by your organization or department name

Well it’s been a long time you saw any update from my side on Data Center policies, in my previous article I was taking about the types of access can be provided to Data Center, let continue our journey with two things

1)      Data Center Doors

2)      Security System for Data Centers.

1.       Data Center Doors

All doors to the Data Center MUST remain locked at all times and may only be temporarily opened for periods NOT to exceed that minimally necessary in order to:

• Allow officially approved and logged entrance and exit of authorized individuals
• Permit the transfer of supplies/equipment as directly supervised by a person with ITKE* staff Access to the area
• Prop opens a door to the Data Center ONLY if it is necessary to increase Air flow into the Data Center in the case on an air conditioning failure. In this case, staff personnel with ITKE* staff Access MUST be present and limit access to the Data Center.

2.       Security System

Access control system provides the normal mechanism for control of access to the Data Center. These mechanisms are employed at the Data Center doors. The permission to access to datacenter MUST be sign from ITKE* directors. Customer MUST provide ITKE*with at least (1) one working day prior notice via e-mail any time it intends to access the ITKE*,Data Centre. Customer MUST provide ITKE*,with at least (3) three working days prior notice any time it requires onsite technical support at the ITKE* Data Centre or it intends to move-in or move-out any Customer Equipment. The Representatives and the accompanying persons MUST keep its licensed area as well as ITKE* Data Centre clean and tidy at all times. The Representatives and the accompanying persons agree to adhere to and abide by all security and safety measures established by ITKE*.

The Representatives and the accompanying persons MUST refrain from doing the following:

• Engage in any activity that is in violation of the laws or aids or assists any criminal activity while at ITKE* property or in connection with the Data Centre Services;
• Misuse or abuse any ITKE*’s property or equipment or third party equipment;
• Make any unauthorized use of or interfere with any property or equipment of any other customer;
• Harass any individual, including ITKE* personnel and representatives of other customers;
•  Use of any photographic, video, film or such other device that produces, reproduces, retains or transmits images within the premises and the licensed space.

*ITKE is used just as reference which can be replaced by your organization or department name.

We had a special request from one of our clinicians; he was trying to access one of the health care portal with the URL http://apps.xxx.xx.sa:2000/. While he was trying to access the same portal from his office it was not accessible, whereas the same portal can accessed from any other location except our office.

While troubleshooting this issue we thought may be our Bluecoat proxy SG was blocking the port 2000 but that was not the case. We were facing the same problem even with static NAT from our ASA 5540 firewall.

One thing was sure the ASA 5540 firewall was blocking the access to the URL http://apps.xxx.xx.sa:2000/. We reviewed all our access list still nothing was wrong with that.  We thought might be some policy map is blocking the access, when we disabled the default policy-map as shown below

policy-map global_policy

 class inspection_default

  inspect dns migrated_dns_map_1

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny 

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip 

  inspect xdmcp

  inspect esmtp

sec/FW01-MB-IE-001(config)# policy-map global_policy

sec/FW01-MB-IE-001(config-pmap)# no class inspection_default

The url started working. Now one thing was sure, the problem lies with policy map. We cannot disable the default policy-map which Cisco configured by default in all ASA or PIX firewall, after reading the following documents from Cisco Systems

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/inspect.html

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_overview.html

It was clear certain HTTP traffic need a special handling. When we enabled the default policy-map and added a command “inspect http”  as shown below the url can be accessed from our internal LAN.

 sec/FW01-MB-IE-001(config)# policy-map global_policy

sec/FW01-MB-IE-001(config-pmap)#  class inspection_default

sec/FW01-MB-IE-001(config-pmap-c)# inspect http