| Parameter | Parameter Type | Default Value | Description |
| fwdebug | int | Error flag and warning flag. If defined secure remote, only error flag. | The debug flags of the fw debug module, which eventually determine which debug messages will be printed. For instructions on how to modify the parameter before reboot, see sk26202. |
| fw_debug_kdbufsz | int | 0 | The debug buffer size. |
| fwkdbmaxlen | int | 32 MB | The debug buffer size limit. |
| fw_kdprintf_limit | int | In 30 | Controls the suppression mechanism of debug messages. If it is not "0", it indicates how many debug messages can be printed in fw_kdprintf_limit_time seconds. |
| fw_kdprintf_limit_time | int | 60 | Part of the suppression mechanism of debug messages. |
| fwmonitormaxlen | int | 100K | Half of the maximum size of the data buffer of the 'fw monitor' command. |
| fwhmem | int | 20 MB | Size of memory allocated for hash tables (hmem) in bytes. |
| fwhmemmax | u_int | 80 MB | The Maximum size in bytes that hash tables (hmem) can be extended to. |
| fw_allow_udp_port0 | Int (bool) | 1 | UDP port 0 dropped by default. |
| fw_allow_tcp_port0 | Int (bool) | 1 | TCP port 0 dropped by default |
| fw_log_udp_port0 | Int (bool) | 1 | Do we log UDP port 0 drops? |
| fw_log_tcp_port0 | Int (bool) | 1 | Do we log TCP port 0 drops? |
| fwconn_smart_conn_reuse | Int (bool) | 1 | Do we use a smart connection reuse algorithm, i.e. whenever a SYN packet is encountered on an established connection we change it to ACK and decide according to server's response. If server responds with an RST, connection is reused. Otherwise (server responds with an ACK), connection is not reused. |
| fw_log_syn_on_estab | Int (bool) | 0 | When SYN is encountered on an established connection and fwconn_smart_conn_reuse is on, server may respond with an ACK packet, which means that the client's SYN was out of state. However, the client's SYN was not necessarily a malicious action. It may have been, for instance, a client application recovering from reboot. The following variable determines whether to log the previous SYN or not. (default=0) |
| fw_trust_rst_on_port | int | "Untrusted" (-2) | Should we trust Resets if sequence verifier is off? |
| fw_accept_syn_rst | int | FW_DONT_ACCEPT_SYN_RST (-2) | This variable specifies a certain service on which SYN-RST packet is allowed. Where it is allowed, previous connection is deleted (if it existed), and a new connection is always recorded, with state BOTH_FIN and without sequence verification. |
| fw_trust_ack_resp_to_syn | Int (bool) | 0 | Determine whether to trust server's ACK that follows client's SYN. The packet will pass or drop according to the value of fw_allow_out_of_state_syn_resp. |
| Listparams | int |
| When set, all the kernel global parameters are printed to the console. |
| fw_allow_simultaneous_ping | Int (bool) | 0 | Allow simultaneous ping to virtual IP and real IP of a cluster machine by storing the ICMP sequence number as one of the connection entry parameters, in order to differentiate between the two IPs. Otherwise, the connections look the same in certain directions. Currently, the feature does not work with SXL. |
| tcp_local_start_timeout | int | 0 | Override TCP start session timeout that is defined in the GUI. |
| tcp_local_end_timeout | int | 0 | Override TCP end session timeout that is defined in the GUI. |
| fwx_max_conns | int | 25000 | Maximum entries in several NAT tables, including fwx_alloc, which is in charge of hide NAT. |
| fwx_udp_hide_high | int | 0 | When not "0", a UDP connection from this (low) port will be hidden behind high port (10000+) instead of low ports (600-1023). |
| fwx_auth_expiration | int | 120 | Expiration in fwx_auth_table, used for folding to security servers. |
| fwx_cluster_hide_for_dynamic_routing | int | 0 | Enables cluster hide for dynamic routing protocols. Changing this variable also changes fwconn_override_dynamic_routing_collision. |
| fwx_g_user_cluster_fold | int | 1 | Enables cluster fold. |
| fwx_do_nat_cache | int | 1 | Should cache be used when trying to match on address translation rules. |
| fwx_g_max_rand_alloc_attempts | int | 30 | Maximum number of attempts to allocate a port before saying there are no available ports. |
| fw_local_interface_anti_spoofing | int | 1 | Local interface anti-spoofing verifies that no packet on the inbound chain has a source IP that matches one of the Gateway's IP addresses. This can be overridden by setting this parameter to "0". |
| fw_antispoofing_enabled | int | 1 | Anti-Spoofing is defined in the topology tab of interfaces. This global parameter can globally disable Anti-Spoofing checks in the enforcement module. To disable anti-spoofing checks, set this kernel global parameter to "0". |
| dns_allowed_chars | int | 0 | The ASCII enforcement as part of the DNS protocol enforcement checks that the domain names do not contain illegal characters. These illegal characters are any character other than letters (a-z, A-Z) digits (0-9) hyphen (-) and underscore (_). This global parameter allows adding up to 4 extra characters that have decimal value less than 128. For example, in order to allow backtick (`) define dns_allowed_chars to the value "96". |
| enforce_tkey_class_any | int | 1 | The DNS enforcement verifies that the TKEY/TSIG resource record class is "ANY". If this global parameter is set to "0", this field will be ignored. |
| dns_disable_servers_check | int | 0 | When enabling DNS TCP protocol enforcement, VPN-1/FireWall-1's current implementation limits the size of TCP data in a stream. This limitation is mainly relevant to zone transfers. When the limit is met, a log will be generated with the error message, "DNS data is too long". To overcome this limitation, change this kernel global parameter value from "0" to "1". This will allow traffic between defined DNS servers to pass, without DNS verification. |
| SmartDefense Parameters | |||
| ws_debug_ip | ip | _ | This parameter can be set, in order to focus on debug messages that are related to a specific IP (destination or source). |
| enforce_notify_header | int | 0 | When activated, produces ?Illegal Notify message? log. |
| allow_dnssec_bit | int | 1 | Allows AD ('authentic data') bit in response packet. |
| dns_allowed_chars | int | 0 | User configured additional allowed characters in domain names. |
| dns_maximum_message_length_overflow | int | 2 | Maximal additional bytes in query. When exceeded, produces ?Request packet too long, potential buffer overflow? log. |
| enforce_tkey_class_any | int | 1 | When set, produces ?Bad Resource Record format, TKEY RR class is not ANY? and ?Bad Resource Record format, TSIG RR class is not ANY? logs on DNS class other than ANY. |
| dns_disable_servers_check | int | 0 | When set, allows TCP traffic between known servers to run unchecked. |
Sunday, September 26, 2010
Checkpoint Global Parameters
Warning: Check Point strongly recommends consulting Technical Support before editing the kernel global parameters. If a parameter is edited incorrectly, it may lead to serious problems.
Tuesday, September 21, 2010
Wednesday, August 4, 2010
Cisco ASA Stateful Informations, During Failover
Stateful:
When stateful failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.
The state information passed to the standby unit includes these:
The NAT translation table
The TCP connection states
The UDP connection states
The ARP table
The Layer 2 bridge table (when it runs in the transparent firewall mode)
The HTTP connection states (if HTTP replication is enabled)
The ISAKMP and IPSec SA table
The GTP PDP connection database
The information that is not passed to the standby unit when stateful failover is enabled includes these:
The HTTP connection table (unless HTTP replication is enabled)
The user authentication (uauth) table
The routing tables
State information for security service modules
When stateful failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.
The state information passed to the standby unit includes these:
The NAT translation table
The TCP connection states
The UDP connection states
The ARP table
The Layer 2 bridge table (when it runs in the transparent firewall mode)
The HTTP connection states (if HTTP replication is enabled)
The ISAKMP and IPSec SA table
The GTP PDP connection database
The information that is not passed to the standby unit when stateful failover is enabled includes these:
The HTTP connection table (unless HTTP replication is enabled)
The user authentication (uauth) table
The routing tables
State information for security service modules
Monday, July 26, 2010
Packet Flow Sequence in PIS/ASA
Packet Flow Sequence
====================
PIX/ASA - Inside (Higher Sec_Lev) to Outside (Lower SEC_Level)
---------------------------------------------------------------
Eg. Type - [Sub-Type] - Description
1. FLOW-LOOKUP - [] - Check for existing connections, if none found create a new connection.
2. ROUTE-LOOKUP - [input] - Initial Checking (Reverse Path Check, etc.)
3. ACCESS-LIST - [log] - ACL Lookup
4. CONN-SETTINGS - [] - class-map, policy-map, service-policy
5. IP-OPTIONS - [] -
6. NAT - [] - xlate
7. NAT - [host-limits] -
8. IP-OPTIONS - [] -
9. FLOW-CREATION - [] - If everything passes up until this point a connection is created.
10. ROUTE-LOOKUP - [output and adjacency]
====================
PIX/ASA - Inside (Higher Sec_Lev) to Outside (Lower SEC_Level)
---------------------------------------------------------------
Eg. Type - [Sub-Type] - Description
1. FLOW-LOOKUP - [] - Check for existing connections, if none found create a new connection.
2. ROUTE-LOOKUP - [input] - Initial Checking (Reverse Path Check, etc.)
3. ACCESS-LIST - [log] - ACL Lookup
4. CONN-SETTINGS - [] - class-map, policy-map, service-policy
5. IP-OPTIONS - [] -
6. NAT - [] - xlate
7. NAT - [host-limits] -
8. IP-OPTIONS - [] -
9. FLOW-CREATION - [] - If everything passes up until this point a connection is created.
10. ROUTE-LOOKUP - [output and adjacency]
Checkpoint Nokia / Secure Platform : Backup Methods : CMA and Gateway
NOKIA
The Nokia IP series appliance comes with an option in Voyager to perform a backup. This will backup and restore the configuration for both Nokia IPSO and firewall packages. The files backed up when using the Nokia Voyager's Backup and Restore function are listed below.
Under the $FWDIR, the following files are backed up during the backup process:
Under the $CPDIR, the following files are backed up during the backup process:
Secure Platform
Secure Platform NG with Application Intelligence and NGX provide a command line or Web GUI capability for conducting backups of your system settings and products configuration. The backup utility can store backups either locally on the SecurePlatform machine hard drive or remotely to a TFTP server or SCP server. The backup can be performed on request, or can be scheduled to take place at set intervals.
The backup files are kept in tar gzipped format (.tgz). Backup files saved locally are kept in
See the Secure Platform documentation for exact syntax for the backup command.
You can choose to export the existing Check Point configuration of your machine (including which Check Point products are installed, and all their configuration files). This can be later used to import to a clean machine (any Check Point supported OS), enabling you to replace an existing machine with another (with an identical Check Point configuration).
The exported file is saved in the
The first time installation wizard will offer to get an imported file from a TFTP server, and later will invoke the Check Point upgrade wrapper that will allow you to import the configuration from that file.
UPGRADE _EXPORT
The
You can log in to SmartDashboard and install an existing Security Policy without having to reset SIC. This process minimizes downtime in the event of catastrophic system failure.
Import and Export tools are located under
The Nokia IP series appliance comes with an option in Voyager to perform a backup. This will backup and restore the configuration for both Nokia IPSO and firewall packages. The files backed up when using the Nokia Voyager's Backup and Restore function are listed below.
Under the $FWDIR, the following files are backed up during the backup process:
$FWIR/conf/*
$FWDIR/state/*
$FWDIR/database/*
$FWDIR/lib/user.def
$FWDIR/lib/control.map
$FWDIR/etc Under the $CPDIR, the following files are backed up during the backup process:
$CPDIR/conf/*
$CPDIR/database/*
$CPDIR/registry/*
$CPDIR/etc/* Secure Platform
Secure Platform NG with Application Intelligence and NGX provide a command line or Web GUI capability for conducting backups of your system settings and products configuration. The backup utility can store backups either locally on the SecurePlatform machine hard drive or remotely to a TFTP server or SCP server. The backup can be performed on request, or can be scheduled to take place at set intervals.
The backup files are kept in tar gzipped format (.tgz). Backup files saved locally are kept in
/var/CPbackup/backups. The restore command line utility is used for restoring SecurePlatform settings and/or Product configuration from backup files.See the Secure Platform documentation for exact syntax for the backup command.
You can choose to export the existing Check Point configuration of your machine (including which Check Point products are installed, and all their configuration files). This can be later used to import to a clean machine (any Check Point supported OS), enabling you to replace an existing machine with another (with an identical Check Point configuration).
The exported file is saved in the
/var/tmp/cpexport file. You can use TFTP to transfer it to a TFTP server (use the 'sysconfig' utility, "Export Setup"). The "Import" option can only be accomplished on a clean machine. Install SecurePlatform, and use the shell for the initial setup (through 'sysconfig').The first time installation wizard will offer to get an imported file from a TFTP server, and later will invoke the Check Point upgrade wrapper that will allow you to import the configuration from that file.
UPGRADE _EXPORT
The
upgrade_export tool is used for Smartcenter server to export a copy of the rules and user databases. During the installation process, there is an option called Installation using Imported Configuration. At this point, you can select the previously exported tgz file to import, and then automatically installs the new software and utilizes the imported .tgz configuration file.You can log in to SmartDashboard and install an existing Security Policy without having to reset SIC. This process minimizes downtime in the event of catastrophic system failure.
Import and Export tools are located under
$/FWDIR/bin/upgrade_tools or on the installation CD-ROM.
Thursday, July 15, 2010
Everything Have a Reason and I Need to Know that - RST Packet from Server - TCP Stack
Last week I faced a strange issue. Thou it was a good experience, lost my sleep for for a night at-least!! The problem was with TCP 3-way Handshake.. So I took a capture in server, I could see SYN packets coming from client, SYN ACK going back from server, and finally a "RST" from server.... Here I got screwed... Why "RST" from Server.. I thought of all conditions even if I don't know the exact working of TCP stack..
I looked into wireshark, could see TCP retransmission from SYN as well as SYN ACK. I decided to read some TCP stack stufff..
Next day I got call saying the issue is resolved, but HOW?? No one is interested in looking into that (F____rs) and I hate it most when putting things in a black HOLE.. One more day and I was so restless.. Needed a reason for "RST"
Finally yesterday I found the reason, could sleep well..
So reason is as follows
When ever a SYN or SYN ACK sent, there will a timer and first time it will set for 3 seconds.. after 3 sec if no response from peer, TCP will resend the packet and the timer will be set to 6 Seconds (Double)... after 6 sec if no response from peer, TCP will resend the packet and the timer will be set to 12 Seconds (Double)... even after this no response (after 21 Sec from the first packet); the server will send a "RST" packet, which is quiet normal...
The issue was in WAN, which never delivered SYN ACK to the other end.. (Some IPSC Crypto ACL problem)
Mistakes Which I did : I should have asked for the other end Capture toooo.. :)
Anyway I am happy to find a reason..
NB: I stick to my theory in practical way, will find a reason for each and everything and it will be audited.. Because I believe in RCA (Root Cause Analysis)
I looked into wireshark, could see TCP retransmission from SYN as well as SYN ACK. I decided to read some TCP stack stufff..
Next day I got call saying the issue is resolved, but HOW?? No one is interested in looking into that (F____rs) and I hate it most when putting things in a black HOLE.. One more day and I was so restless.. Needed a reason for "RST"
Finally yesterday I found the reason, could sleep well..
So reason is as follows
When ever a SYN or SYN ACK sent, there will a timer and first time it will set for 3 seconds.. after 3 sec if no response from peer, TCP will resend the packet and the timer will be set to 6 Seconds (Double)... after 6 sec if no response from peer, TCP will resend the packet and the timer will be set to 12 Seconds (Double)... even after this no response (after 21 Sec from the first packet); the server will send a "RST" packet, which is quiet normal...
The issue was in WAN, which never delivered SYN ACK to the other end.. (Some IPSC Crypto ACL problem)
Mistakes Which I did : I should have asked for the other end Capture toooo.. :)
Anyway I am happy to find a reason..
NB: I stick to my theory in practical way, will find a reason for each and everything and it will be audited.. Because I believe in RCA (Root Cause Analysis)
Wednesday, July 7, 2010
Fnd the Cluster IP (Virtual IP ) in SPALT
How to find the Cluster IP (Virtual IP ) Associated to all interfaces in SPALT, here is the way..
cphaprob -a if
cphaprob -a if