Monday, June 18, 2012

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.

Sunday, June 10, 2012

/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)


Monday, June 4, 2012

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

Monday, May 21, 2012

Upgrading F5 Big-IP from version 9.3.x or 9.4.x to 10.x

Upgrading Big-IP from version 9.3.x or 9.4.x to 10.x
======================================================
This installation was performed on a Big-IP 3600. Hardware details are as follows:
PLATFORM INFORMATION --
| Marketing Name: BIG-IP 3600
| BIOS Rev: AMIBIOS(C)2006 American Megatrends, Inc. F5 Platform: MERCURY OBJ-0272-03 BIOS S10.0 Date:04/24/2009
| base MAC: 00:00:00:00:00:00
+-> SYSTEM INFO
| Type: C103
| Chassis serial: f5-yyyy-xxxx Level 200 part: 200-0293-11 REV A
| Memory: 3.437GB
+-> HARDWARE CARDS
| | Type: pic Model: F5 cpld
| | version: 0x13
| | Type: crypto Model: Cavium NITROX-PX
| | version: CNPx-MC-SSL-MAIN-MC1-0001
+-> CPU 0
| | Type: Intel(R) Core(TM)2 Duo CPU E6400 @ 2.13GHz Speed: 2133.469MHz
| | Temp: 37degC Fan speed: 10546rpm


1. Download the iso and md5 files from the F5 website.

2. SCP to your F5 Big-IP appliance.

3. Transfer files downloaded in step 1 to the directory “/shared/images”. Create this directory if it does not exist.

4. Login to the CLI of the device using the root account. Verify the integrity of the images. Apply the following commands:

md5sum /shared/images/BIGIP-10.0.1.283.0.iso
cat /shared/images/BIGIP-10.0.1.283.0.md5

Visually check that the hash values outputs are identical.

5. Login to the CLI of the device using the root account. Install the configuration utility “image2disk” – the iso image contains the image2disk utility. Apply the following command to install the utlity:

im /shared/images/BIGIP-10.0.1.283.0.iso

The process copies over the image2disk installation utility, and then presents a status message, which lets you know that the im command is no longer supported, and tells you how to proceed.

/tmp/rpmdisk.173hO1 /shared/images
info: media has tm_install version 2.6.2, release 40.0
info: adding bin/../isolinux/install/tm_install.rpm to system...
info: media has perl-RPM2 version 0.67, release 10.0.0.4598.0
info: adding bin/../isolinux/install/perl-RPM2.rpm to system...
The im utility is no longer used to upgrade software images.
Please use 'image2disk'. For help, use 'image2disk -h'.
You must always install to an image location that is not in use.
Here is your current image-location status:
HD1.1 active no default no title BIG-IP 9.1.2 Build 40.2
HD1.2 active yes default yes title BIG-IP 9.3.1 Build 37.1


6. Determine which HD slot to install the new in using the switchboot utility. You must install the image on an inactive slot. Apply the following command:

switchboot –l

Sample output:
[root@F5:Active] / # switchboot –l
Current boot image:
HD1.1 - BIG-IP 9.4.8 Build 355.0
Default boot image:
HD1.1 - BIG-IP 9.4.8 Build 355.0
Available boot image(s):
HD1.1 - BIG-IP 9.4.8 Build 355.0
HD1.2 - BIG-IP 9.4.8 Build 355.0
[root@F5:Active] / #

7. Install the new image. This step will reformat the disk to use Logical Volume Management. Apply the following command as the root using the CLI:
image2disk --instslot=HD1.2 --format=volumes /shared/images/BIGIP-10.0.1.283.0.iso
The upgrade process installs the software on the inactive installation location (--instslot) that you specify. This process usually takes between three minutes and seven minutes.

8. Reboot the into the volume where you installed the new image:
switchboot -b HD1.2
reboot

Installing Hotfixes 10.x
1. Download the Hot fix files from F5:
• Hotfix-BIGIP-10.0.1-402.7-HF4.iso
• Hotfix-BIGIP-10.0.1-402.7-HF4.md5

2. SCP to the device and copy the downloaded hot fix files to the directory “/shared/images”. Login to the CLI and verify the files are recognised by the device. Apply the following command:
bigpipe software list
Sample output:
[admin@F5:Active] images # bigpipe software list
software {
desired {
HD1.1 {}
HD1.2 {
product "BIG-IP"
version "10.0.1"
build "283.0"
active enable
}
HD1.3 {}
}
hotfixes "Hotfix-BIGIP-10.0.1-402.7-HF4.iso"
images "BIGIP-10.0.1.283.0.iso"
}
[admin@F5:Active] images #
3. Verify the integrity of the files. Apply the following commands:
md5sum /shared/images/Hotfix-BIGIP-10.0.1-402.7-HF4.iso
cat /shared/images/Hotfix-BIGIP-10.0.1-402.7-HF4.md5

Visually check the hash values are the same from the output.

4. Verify the disk formatting scheme used by the device. Apply the following command:

lvscan
Sample output:
[admin@F5:Active] images # lvscan
lvscan -- ACTIVE "/dev/vg-db-sda/dat.share.1" [30 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/dat.log.1" [7 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.1.root" [256 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.1._config" [512 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.1._var" [3.25 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.1._usr" [1 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.2.root" [256 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.2._config" [512 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.2._var" [3.25 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.2._usr" [1 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.3.root" [256 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.3._config" [512 MB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.3._var" [3.25 GB] contiguous
lvscan -- ACTIVE "/dev/vg-db-sda/set.3._usr" [1 GB] contiguous
lvscan -- 14 logical volumes with 52 GB total in 2 volume groups
lvscan -- 14 active logical volumes

[admin@F5:Active] images #

5. The Big-IP image and hotfix file into a volume which is NOT active. Check which volume is active – apply the following command:
bigpipe software
Sample output:
[admin@F5:Active] images # bigpipe software
SOFTWARE
+-> SOFTWARE STATUS
| Key Slot Product Version Build Active Status
| HD1.1 0 none none none no complete
| HD1.2 0 BIG-IP 10.0.1 283.0 yes complete
| HD1.3 0 none none none no complete
[admin@F5:Active] images #

6. Install the Big-IP image and hotfix file into the inactive volume.

a) First install the Big-IP image. Apply the following command:
bigpipe software desired HD1.3 product BIG-IP version 10.0.1 build 283.0
Sample Output:
[admin@F5:Active] images # bigpipe software desired HD1.3 product BIG-IP version 10.0.1 build 283.0
[admin@F5:Active] images # bigpipe software
SOFTWARE
+-> SOFTWARE STATUS
| Key Slot Product Version Build Active Status
| HD1.1 0 none none none no complete
| HD1.2 0 BIG-IP 10.0.1 283.0 yes complete
| HD1.3 0 BIG-IP 10.0.1 283.0 no installing 0.000 pct
[admin@F5:Active] images # bigpipe software
SOFTWARE
+-> SOFTWARE STATUS
| Key Slot Product Version Build Active Status
| HD1.1 0 none none none no complete
| HD1.2 0 BIG-IP 10.0.1 283.0 yes complete
| HD1.3 0 BIG-IP 10.0.1 283.0 no installing 3.000 pct
[admin@F5:Active] images #
[admin@F5:Active] images # bigpipe software
SOFTWARE
+-> SOFTWARE STATUS
| Key Slot Product Version Build Active Status
| HD1.1 0 none none none no complete
| HD1.2 0 BIG-IP 10.0.1 283.0 yes complete
| HD1.3 0 BIG-IP 10.0.1 283.0 no complete

b) Apply the hotfix onto the Big-IP image. Apply the following commands:
bigpipe software desired HD1.3 product BIG-IP version 10.0.1 build 402.7
Sample Output:
[admin@F5:Active] images # bigpipe software desired HD1.3 product BIG-IP version 10.0.1 build 402.7
[admin@F5:Active] images # bigpipe software
SOFTWARE
+-> SOFTWARE STATUS
| Key Slot Product Version Build Active Status
| HD1.1 0 none none none no complete
| HD1.2 0 BIG-IP 10.0.1 283.0 yes complete
| HD1.3 0 BIG-IP 10.0.1 402.7 no installing hotfix
[admin@F5:Active] images #

c) Boot into the volume containing the hotfix. Apply the following command:

switchboot -b HD1.3
reboot

Sample Output:
[admin@F5:Active] images # switchboot -b HD1.3
[admin@F5:Active] images # reboot

Broadcast message from root (pts/0) (Tue Jan 25 12:00:58 2011):

The system is going down for reboot NOW!
[admin@F5:Active] images #

References
F5: Manual Chapter: Using the image2disk and diskinit Utilities
F5: SOL11496

Sunday, March 4, 2012

Checkpoint : Splat - Disable CD/DVD Rom

How to disable the cd rom from CLI cd /lib/modules/2.6.18-92cp/kernel/drivers/cdrom mv cdrom.ko cdrom.ko.orig Reboot or modprobe -r sr_mod

Saturday, March 3, 2012

Cluster XL HA - Going ACTIVE/ACTIVE - BOTH ACTIVE

HA Cluster XL - Going ACTIVE/ACTIVE=============
Model : Power-1/UTM-1/Secure Platform
Things need to be checked to make the pairs identical and to avoid Active / Active stituation and an outage
1. Check Cable of Sync - it should be either cross cable (I have seen the use of a convertor in straight cable to make the cable cross, this can be used) or straight cable thru a dedicated switch/Vlan - THIS IS MOST important
2. Check the cluster XL method - broadcast /multicast , it should be same in both the members
Verify :
[Expert@gehfgmuswaudc31]# cat $FWDIR/boot/ha_boot.conf ha_installed 1 ccp_mode broadcast [Expert@gehfgmuswaudc31]#
in above example it is broadcast mode, even the default is multicast, in cisco gear I found issues with multicast having a low priority and packet dropped eventually in busy networks.
To make it broadcast mode "cphaconf set_ccp broadcast" To make it multicast mode "cphaconf set_ccp multicast"
You will find error logs in tracker when interface is flapping, you must set the mode to broadcast
3. check the values in $FWDIR/boot/modules/fwkern.conf, this value should be same in all members
verify :
[Expert@gehfgmuswaudc31]# cat /opt/CPsuite-R70/fw1/boot/modules/fwkern.conf fwha_mac_magic=0x1f fwha_mac_forward_magic=0x20
5. Disable all interfaces which are not used
you can either disable in webui or use the CLI command as follows
ifconfig down ifconfig --save
You may require reboot after this
I have observed that some case, need to explicitly tell clusterXL about the unused interafces - sk30060 - I never used it, always diabled interfaces
ie , declare the interface which are not used in the below file cpstop
$FWDIR/conf/discntd.if
cpstart
to get the interface name, use command : fw getifs
6. Check CoreXL disabled or enabled in all boxes - coreXL can be enabled in boxes with have min 4 core or more. Licenses should be there for those many cores
- So better disable it if not used in all boxes
7. If the above steps do not resolve the reported behavior, then open ticket with CP with following info
A) make sure the cluster is enabled on both members
B) make sure the problem is replicated
C) collect at the same time CPinfo file from both members
D) collect at the same time CPinfo file from MGMT server
E) run the following debug on both members for 5 minutes
# fw ctl debug 0 # fw ctl debug -buf 32000 # fw ctl debug -m cluster + conf if pnote stat # fw ctl kdebug -T -f 1>> /var/log/debug.txt 2>> /var/log/debug.txt let the debug run for 5 minutes press CTRL+C # fw ctl debug 0
Collect /var/log/debug.txt from each member