The Fir3net II Project

General Info - General Info

The project to build Fir3net II has been started. The main issue we are facing is funds and are looking for your donations to help us reach our goal of £400.
The £400 will cover setup costs, the ability to purchase custom built code and some inital hosting costs. Once built Fir3net II will once again be a completey free site which will include a number of new features such as an,

• improved layout
• improved menu system
• enhanced search functionaility
• forum
• subscription to article updates.
• ability for users to upload articles
• additional RSS, feedburner and tweet addons

In order to donate to this project please visist our donation page. We hope to bring your Fir3net II in the not too distant future.

Regards - Fir3net.com

How do I configure shared licensing on an ASA ?

Firewalls - Cisco - ASA

A shared license lets you purchase a large number of SSL VPN sessions and share the sessions as needed amongst a group of security appliances by configuring one of the security appliances as a shared licensing server, and the rest as shared licensing participants.
Further information on shared licensing can be found here

Below shows the steps on how to configure a Shared License server.

1. Install Cisco license key, run the commands:

activation-key key
reload

2. Configure license server :

license-server enable interface (Inside interface)             
license-server secret   ‘your-password’
license-server port port  50554      
license-server refresh-interval 100                          
wr mem

3.  Configure shared license ASA’s.

license-server address  X.X.X.X  secret [password] port 50554
wr mem

4.  Confirming shared license  - show shared license

hostname >  show shared license
Primary License Server : 10.3.32.20
  Version              : 1
  Status               : Inactive

Shared license utilization:
  SSLVPN:
    Total for network :     5000
    Available         :     5000
    Utilized          :        0
  This device:
    Platform limit    :      250
    Current usage     :        0
    High usage        :        0
  Messages Tx/Rx/Error:
    Registration    : 0 / 0 / 0
    Get             : 0 / 0 / 0
          Release         : 0 / 0 / 0
          Transfer        : 0 / 0 / 0

NSM fails to update device but shows successful

Firewalls - Juniper - Netscreen

What is ASP and how do I troubleshoot ASP drops on an ASA ?

Firewalls - Cisco - ASA

What is the Accelerated Security Path ?

The Accelerated Security Path (ASP) on the ASA appliance comprises of 2 components; The Fast Path and The Session Management Path. In addition to the Accelerated Security Paths there is also the Control Plane Path which is also covered below.

The Session Management Path

When a new connection reaches the ASA gateway the first packet is sent to the “Session Management Path”.  This path is responsible for

    * Performing the access list checks
    * Performing route lookups
    * Allocating NAT translations (xlates)
    * Establishing sessions in the "fast path"

The Fast Path

If the connection is already established, the security appliance does not need to re-check packets and the packets are sent to the Fast Path. The Fast Path is responsible for the following tasks:

    * IP checksum verification
    * Session lookup
    * TCP sequence number check
    * NAT translations based on existing sessions
    * Layer 3 and Layer 4 header adjustments

For UDP or other connectionless protocols, the security appliance creates connection state information so that it can also use the fast path.

Some established session packets must continue to go through the session management path or the control plane path. Generally packets that require HTTP packet inspection or content filtering will go through to the session management. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection. But Data packets for protocols that require Layer 7 inspection can still go through the Fast Path.

The Control Plane Path

Some packets which require adjustments or changes to be made to the packets headers at a Layer 7 level. Or Layer 7 inspection engines which are required for dynamic port based protocols such as FTP and H.323 etc  are passed to the Control Plane Path.

How do I Debug ASP Drops ?

There are 3 main ways to confirm whether your ASA appliance has dropped packets at the ASP stage. These are:

   1. Viewing the ASP statistics
   2. Viewing the ASA Logs
   3. Running an ASP Drop packet capture

Viewing the ASP statistics

In order to view the ASP drop statistics you can run the command “sh asp drop”.

asa-firewall# sh asp drop
Frame drop:
  Invalid TCP Length (invalid-tcp-hdr-length)                                 20
  First TCP packet not SYN (tcp-not-syn)                                  902518
  Bad TCP flags (bad-tcp-flags)                                               39
Last clearing: 19:45:39 UTC Jan 18 2010 by user
Flow drop:
  NAT failed (nat-failed)                                                    218
  Inspection failure (inspect-fail)                                        29170
  SSL received close alert (ssl-received-close-alert)                          4
 
Last clearing: 19:45:39 UTC Jan 18 2010 by user

This will give you an overview view of the type of drops being encountered. But does not provided the necessary information to isolate and troubleshoot particular hosts.

You can also clear these counters using the "clear asp drop" command.

Viewing the ASA Logs

Via your Syslog server you will be able to view the logs showing the dropped connections. This will provide the reason along with the source and destination addresses. An example is shown below for an MSS Excedded ASP drop,

%ASA-4-419001: Dropping TCP packet from outside:192.168.9.2/80 to inside:192.168.9.30/1025, reason: MSS exceeded, MSS 460, data 1440

Running an ASP drop packet capture

This is in my opinion the most concise and efficient way of troubleshooting your ASP dropped traffic.
To enable a packet capture on all traffic for all asp-drop types use the following command :

asa-firewall# capture asp-drop type asp-drop all

To then see your buffer for the asp-drop capture run the following command. You can see from the highlighted sections the reason for the drop.

asa-firewall# sh capture asp-drop

2 packets captured
   1: 15:15:00.682154 197.2.1.29.2616 > 87.200.42.101.443: S 1239395083:1239395083(0) win 65535 <mss 1260,nop,nop,sackOK> Drop-reason: (acl-drop) Flow is denied by configured rule
   4: 15:15:00.750830 10.70.0.162.3812 > 168.252.3.41.15: S 3523756300:3523756300(0) win 65535 <mss 1360,nop,nop,sackOK> Drop-reason: (rpf-violated) Reverse-path verify failed

Checkpoint Logging Troubleshooting Guide

Firewalls - Checkpoint

Below are some basic guidelines for troubleshooting Checkpoint Logging issues.

Please note : This guide does not cover issues with any OPSEC LEA based issues.
Please note : The FWD (Firewall Daemon) is responsible for sending and receiving the Checkpoint Logs on port tcp/257.

Are the logs being sent to the manager ?

Ok, so first of all are the logs being sent to the Smart Centre Manager or the necessary Log Manager ? We can check this by confirming whether the gateway is sending the log packets via the FW Log port tcp/257 upon the gateway and the manager. To do this use either or both of the following commands,

• netstat -an | grep 257 - This will show the state of the TCP sockets. 
• tcpdump -ni [interface name] port 257 - This will show a packet capture of the FW Log packets on the subsequent interface.

If the gateway is not sending the logs then this can be down to one of the following issues,

1. SIC is not established.
2. The Logging configuration for the Gateway is not configured correctly.
3. The SmartCentre/Log Manager is not listening on port tcp/257.
4. There is an issue with FWD on the gateway. In some instances you may need to restart FWD via a cpstart. Though the root cause could be down to a number of factors.

The SmartCentre / Log Manager is not receiving the logs

If the gateway is sending the logs but the SmartCentre / Log Manager is not receiving them then either a device between the 2 nodes is blocking the packets or there is a routing issue.

Why are the logs not being displayed within SmartView tracker ?

Ok so the manager is receiving the logs but you may still not see them within the SmartView tracker this will be down to either the FWD (Firewall Daemon) or the log files being corrupted.

Log Files Corrupted

If the log files are corrupted you should expect to see no logs within the SmartView Tracker. If this is the case you will need to action the following steps :

1. Close the Log Viewer/SmartView Tracker and Policy Editor/SmartDashboard.
2. Execute the fwstop or cpstop command (depending on the version) from the command line.
3. Remove all files starting with fw.log and fw.logptr from the $FWDIR\log directory.
4. Execute the fwstart or cpstart (depending on the version) command.

Full details can be found at Checkpoints KB within Solution ID sk6432.

Only some of the logs are not being displayed

If only some of the logs are not being displayed then this could point to an issue with the trust between the manager and the gateway.
To confirm the issue you will need to debug FWD using the following steps.

root@cp-mgnt# fw debug fwd on TDERROR_ALL_ALL=5
root@cp-mgnt# tail -f $FWDIR/log/fwd.elg
root@cp-mgnt# tail -f $FWDIR/log/fwd.elg  | grep -i "Certificate is revoked"
root@cp-mgnt# fw debug fwd off

Within these steps we first enable the debug. Then we run a live tail on the log file. And then we run a grep on the live tail for a specific error. The live tail allows us to view the end of the log file in real time. We finally turn off the debug.

Below shows an example of an error with the SIC trust between the Gateway and Manager obtained from the $FWDIR/log/fwd.elg,

[FWD 2177 1]@cp-mgnt[22 Jan 14:47:32] fwCert_ValCerts: Certificate is revoked. CN=cp-fw1,O=cp-mgnt..bizt7z
[FWD 2177 1]@cp-mgnt[22 Jan 14:47:41] fwCert_ValCerts: Certificate is revoked. CN=cp-fw2,O=cp-mgnt..bizt7z

In this instance resetting SIC would resolve this issue.