Checkpoint : SecureXL

Traffic acceleration When SecureXL is enabled, all traffic should be accelerated, except traffic that matches the following conditions: The first packets of any new TCP session, unless a "template" exists. The first packet of any new UDP session. All traffic that matches a service that uses a Resource. Certain traffic that matches a service that is inspected by a SmartDefence or Web Intelligence feature. For example, traffic on which SSH protections are activated is not accelerated. For more details, refer to sk42401: Factors that adversely affect performance in SecureXL. All traffic that is supposed to be dropped or rejected, according to the rule base. All traffic that matches a rule, whose source or destination is the Gateway itself. All traffic that matches a rule with a Security Server. All traffic that matches a rule with User Authentication or Session Authentication. Non-TCP/UDP/GRE/ESP traffic. All multicast traffic. All fragmented traffic. All traffic with IP options. RST packets, when the "Spoofed Reset Protection" feature is activated. When using ClusterXL in Load Sharing mode with 'Sticky Decision Function'. Traffic that violates stateful inspection paradigm, or that is suspected to be spoofed. IPv6 traffic Connection establishment acceleration ("templates" mechanism) In order to enhance connection establishment acceleration, a mechanism attempts to "group together" all connections that match a particular service and whose sole discriminating element is the Source Port. This type of "grouping" enables even the very first packets of a TCP handshake to be accelerated. This is very useful on short connections, in which the percentage of TCP handshake traffic is very high. The very first packets of the first connection on the same service will be forwarded to the Security Gateway's kernel, which will then create a "template" of the connection and notify the SecureXL device. Any subsequent TCP establishments on the same service (where only the source port is different) will already be accelerated (as well as any other traffic, of course). There are several conditions that will prevent a template from being created: Connections that cannot be discriminated ONLY by the source port cannot be templated. NATed traffic cannot be templated. VPN traffic cannot be templated. Complex connections (FTP, H323, etc.) cannot be templated. Non-TCP/Non-UDP traffic cannot be templated. The following rules will prevent a Connection Template from being created. All subsequent rules below such rules will not be templated as well, regardless of the rule. It is advised that all rules that can be templated, be placed at the top of the rule base (unless of course, this will violate other optimization considerations): Rule with service 'Any' Rule with a service that has a 'handler' (where a specific protocol is chosen in 'Protocol Type' field - instead of 'None' ; go to service object - right-click - Edit... - Advanced... - Protocol Type:). Rules with the following objects: Time object Port range object Dynamic object Rules with "complex" services (i.e., services that have anything specified in the "Match" field, or "Enable reply from any port" of their "Advanced" section or Source Port is defined). Rules with RPC/DCOM/DCE-RPC services. Rules with Client Authentication or Session Authentication. When SYN Defender or Small PMTU features are activated in SmartDefense/IPS.

/var/log/messages interpretation

/var/log/messages interpretation:
======================

Jun 10 01:48:15 FW00301 sshd(pam_unix)[2833]: session opened for user admin by (uid=0)

Jun 10 01:48:18 FW00301 cpshell: cmd by admin:  ifconfig -a

Jun 10 01:48:19 FW00301 cpshell: cmd by admin:  fw stat

Jun 10 01:48:19 FW00301 shell: cmd by admin: uptime

Jun 10 01:48:38 FW00301 shell: cmd by admin: cphaprob state

Jun 10 01:48:43 FW00301 cpshell: cmd by admin:  uptime

Jun 10 01:48:45 FW00301 cpshell: cmd by admin:  time

Jun 10 01:48:48 FW00301 cpshell: cmd by admin:  ver

Jun 10 01:48:49 FW00301 cpshell: cmd by admin:  uptime

Jun 10 01:48:52 FW00301 cpshell: cmd by admin:  fw ver

Jun 10 01:48:56 FW00301 shell: cmd by admin: cat /var/log/messages

In Above example. You can see the logs of command execution form admin othru cpshell and shell


Here is the explanation,

Shell - ILO user thru VSP

CPShell - User thru CLI - vty (putty in my case)

NIC status in Linux

#!/bin/bash

NICLIST=`ifconfig | egrep '^eth[0-9] ' | awk '{ print $1 }'`


for nics in $NICLIST
do
niclink=(`ethtool $nics | awk '/Duplex/ { duplex=$2 }; /Link detected/ { link=$3 }; /Speed/ { speed=$2 } END { print link " " speed " " duplex }'`)

if [ "${niclink[0]}" = "yes" ]; then
speed="${niclink[1]}"
duplex="${niclink[2]}"
fi

printf "%7s %4s %9s %5s\n" $nics ${niclink[0]} $speed $duplex


speed=""
duplex=""
done


Note : Power-1 and UTM-1 There are differences as the nic name changes

Cisco - ASA : NAT

I always had a confusion about the NAT in ASA. Today I am going to make it very clear

static (inside, outside) 203.200.138.70 192.168.1.100 netmask 255.255.255.255

when traffic intiate from inside = the SOURCE will get NATTED. ie, 192.168.1.100 will become 203.200.138.70 in the souce column

and

when traffic intiate from outside = the DESTINATION will get NATTED. ie, 203.200.138.70 will become 192.168.1.100 in dst column

=========================================================================

static (outside, inside) 203.200.138.70 192.168.1.100 netmask 255.255.255.255

When traffic intiates from outside zone, souce nat will happen ie, 192.168.1.100 wil become 203.200.138.70 in SRC column

When traffic intiates from inside zone, DST nat will happen ie, 203.200.138.70 wil become 192.168.1.100 in DST column