Showing posts with label Checkpoint Administration. Show all posts
Showing posts with label Checkpoint Administration. Show all posts

Friday, 3 May 2013

Checkpoint Top Talkers Script - Display top 50 Source/Destinations

Hi Everyone,

I've finished writing a script that should be very useful to most of you. It allows you to determine the top 50 chattiest hosts on your network based on certain criteria.

This is what it looks like when you run it:

Hello, Welcome to the Checkpoint Top Talkers display utility by Craig Dods
-----------------------------------------------
    M A I N - M E N U
-----------------------------------------------
Please note that this is for use on devices with SecureXL enabled ONLY

1.  Display the top 50 Source/Destination combos
2.  Display the top 50 Source/Destination combos with identical Destination Ports
3.  Display the top 50 Source/Destination combos with identical Source Ports
4.  Display the top 50 Sources
5.  Display the top 50 Destinations
6.  Display the top 50 Source/Destination combos on a Custom Destination Port
7.  Display the top 50 Source/Destination combos on a Custom Source Port
8.  Display the top 50 Sources on a Custom Destination Port
9.  Display the top 50 Destinations on a Custom Destination Port
10. Display the top 50 Sources on a Custom Source Port
11. Display the top 50 Destinations on a Custom Source Port
12. Display the top 20 Destination Ports
13. Display the top 20 Source Ports
14. Display Connections From A Specific Host (large list)
15. Display Connections To A Specific Host (large list)
16. Exit

As you can see, there are quite a few options to choose from.

As an example, let's say you're simply trying to find out the busiest host-to-host connections and which ports they're using. Press #2 to see the results (the formatting looks better in bash, I swear - IP's are also obfuscated):

Please Make A Selection:  2
     #      SRC IP          DST IP       DPort
   9801 192.168.222.222  192.168.111.181  514    
    532 192.168.222.222  192.168.111.181  443    
    464 192.168.222.222  192.168.111.181  443    
    455 192.168.222.222  192.168.111.181  443    
    435 192.168.222.222  192.168.111.181    53      
    431 192.168.222.222  192.168.111.181  443    
    388 192.168.222.222  192.168.111.181  443    
    374 192.168.222.222  192.168.111.181  443    
    369 192.168.222.222  192.168.111.181  443    
    342 192.168.222.222  192.168.111.181  3995
    ................................
    Press [Enter] key to continue...

Another common use case would be if you're trying to determine which host is flooding a certain type of traffic (DNS/Syslog, etc). It's easy to determine who's causing the problem by using one of the 'Custom Port' options:

Looking for hosts generating DNS requests by using option #8:

Please Make A Selection:  8
Please enter the specific Destination Port you wish to filter for:
53

     #  SRC IP on DPORT 53
    199 192.168.0.0
    142 192.168.0.0
     94 192.168.0.0
     79 192.168.0.0
     33 192.168.0.0
     32 192.168.0.0
     26 192.168.0.0
     16 192.168.0.0
     16 192.168.0.0
     13 192.168.0.0

There are obviously many more use cases than I've covered above, so please try it out and let me know how it works!

Some caveats to keep in mind:
1) This only works on devices with SecureXL enabled
2) This may not work on every device. If you find out something isn't working in your environment, let me know!
3) All of this is based on active connections. At no point are these scripts monitoring actual throughput for any host.
4) Since we're pulling the information from SecureXL tables vs the connection table, there will be some oddities such as an entry for each direction of a connection if using option #1:

Please Make A Selection:  1
     #      SRC IP          DST IP
   9095 192.168.0.1  192.168.1.1
   9095 192.168.1.1  192.168.0.1


And finally, you can find the script right here . See my post about WGET if you're not sure on how to pull it down.

WGET on Checkpoint







Friday, 22 February 2013

WGET on CheckPoint

Just a quick post here since I've been asked about the best way of transfering the scripts I host on github to a FW. The answer of course is wget :)

It's not in the default $PATH of SPLAT/GAIA, however on every version I've looked CP has hidden it somewhere on the device.

For example:
[Expert@R75-B]# wget
-bash: wget: command not found
[Expert@R75-B]# find / -name wget
/var/tmp/CD1/linux/MiniWrapperForMajor/linux/Actions/wget
/sysimg/CPwrapper/linux/MiniWrapperForMajor/linux/Actions/wget

If you want to pull one of my scripts down directly (and assuming you've got a name server in /etc/resolv.conf...), just use the binary in one of the results from find like so:

Tada:
[Expert@R75-B]# /sysimg/CPwrapper/linux/MiniWrapperForMajor/linux/Actions/wget https://raw.github.com/craigdods/scripts/master/interface_rebuild_splat.sh
--10:14:27--  https://raw.github.com/craigdods/scripts/master/interface_rebuild_splat.sh
           => `interface_rebuild_splat.sh.1'
Resolving raw.github.com... done.
Connecting to raw.github.com[199.27.72.133]:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 748 [text/plain]

100%[=================================================================================================================================================================================================>] 748          730.47K/s    ETA 00:00

10:14:27 (730.47 KB/s) - `interface_rebuild_splat.sh.1' saved [748/748]



Tuesday, 11 December 2012

How to calculate the total amount of FireWall Logs per second

### Posting this here for the time being since the support site's SK is broken..

Edit: Not sure why CP runs this with three separate strings...just copy/paste this and you'll get your numbers (sleeps for 120 seconds):

SLEEP_TIME=120;SIZE_BEFORE=$(ls -l $FWDIR/log/fw.logptr | awk '{print $5}') ; sleep $SLEEP_TIME ; SIZE_AFTER=$(ls -l $FWDIR/log/fw.logptr | awk '{print $5}');expr \( $SIZE_AFTER - $SIZE_BEFORE \) \/ \( 4 \* $SLEEP_TIME \)

#######

Follow these steps to calculate/count the total amount of all FireWall Logs per second that arrive to this Security Management Server from all its managed Security Gateways:
  1. Connect to CLI on Security Management Server - over SSH, or console.

    Note:
    On Multi-Domain Management Server, go to the context of the relevant Domain Management Server: [Expert@HostName]# mdsenv [Domain_Name|Domain_IP]
  2. Go to the Log directory:

    [Expert@HostName]# cd $FWDIR/log
  3. Check by how much the size of the Pointer File grows during specific time
    (the time should be high enough to accumulate enough logs - e.g., 120 sec, 180 sec, etc):

    [Expert@HostName]# ls -l fw.logptr ; sleep SLEEP_TIME ; ls -l fw.logptr
  4. Calculate the log rate per this formula:

    RATE = ( SIZE_AFTER - SIZE_BEFORE ) / ( 4 * SLEEP_TIME )

    Use these three commands to automate the calculations:

    [Expert@HostName]# SLEEP_TIME=number_of_seconds

    [Expert@HostName]# SIZE_BEFORE=$(ls -l fw.logptr | awk '{print $5}') ; sleep $SLEEP_TIME ; SIZE_AFTER=$(ls -l fw.logptr | awk '{print $5}')

    [Expert@HostName]# expr \( $SIZE_AFTER - $SIZE_BEFORE \) \/ \( 4 \* $SLEEP_TIME \)


    Note: if the rate value has to be used in a shell script, then use this syntax:
    [Expert@HostName]# RATE=$(expr \( $SIZE_AFTER - $SIZE_BEFORE \) \/ \( 4 \* $SLEEP_TIME \))

Friday, 23 November 2012

SPLAT + GAIA : Inaccessible via Console/SSH/GUI

Hi Everyone,

Over the last few months I've seen a large amount of SPLAT appliances become completely inaccessible via "normal" methods (R71->R75). Upon further investigation it seems all of them are suffering from the same problem, however it's quite strange as all three methods use separate authentication schemes.

##It should be noted that *only* CP-branded appliances have been experiencing the issue, open servers seem to be safe from this.

Edit:: Upon further investigation, it appears that all SPLAT and GAIA devices can be affected by this bug.


Doing a debug of an SSH authentication attempt we can see the firewall immediately close the connection via a FIN, without ever presenting the 'reprompt' as if you typed the wrong password:

SSH attempt with the -vv flags:
admin@<firewall_IP>'s password:
debug2: we sent a password packet, wait for reply
Connection closed by
<host_IP>

TCPDUMP:

<firewall_IP>.22 > <host_IP>.33506: F 1393:1393(0) ack 1269 win 79 <nop,nop,timestamp 3558805529 352019454> (DF)

After trying multiple ways of "breaking in", we gave up and rebooted one of the devices and attempted to access it via maintenance mode, which was succesful.

Looking at /var/log/messages, we can see faillog is broken in some way:

cp_pam_tally[23237]: /var/log/faillog is either world writable or not a normal file


Looking at the file in detail, we saw that it is completely corrupted (filled with ascii/hex symbols).

Replacing the file with a fresh, empty copy (or simply removing it entirely) corrects the issue.

However, next time /usr/bin/faillog is called to do a rollover, the file becomes corrupted once again, and all access is lost...

To prevent this from happening, I've implemented a 'manual' rollover to prevent faillog from doing it itself via CRON (obviously from maintenance mode after the issue occured):

To create a cron entry:
crontab -e

The editor on SPLAT is still VI(m), so press 'i' to enter input mode, and type:

* * * * * /bin/bash /home/admin/faillog_rollover.sh

This will have crond run the faillog_rollover.sh script every minute, which you can grab here (chmod +x it):

faillog_rollover.sh

Make sure to adjust the path for the script in crontab if you don't place it in /home/admin/

CheckPoint R&D is also aware of the issue and are working on a corrected faillog binary (shadow-utils really), however for the time being this is definitely an easy fix. Until the fixed binary is included in a normal release however, I'd *highly* recommend having this cron job installed on any SPLAT-based Appliance, since fixing the issue once it's occured via maintenance mode isn't the easiest thing to schedule.

Follow Up: CP has released a fixed shadow-utils RPM that addresses the issue, however they have confirmed GAIA is currently susceptible, and that the rollover fix will be incorporated into the next release of GAIA.

Thanks for reading,









Wednesday, 15 August 2012

GAIA CLISH Basics (Interfaces,Routes,Bonds,Saving)

Here are some really 'basic' GAIA CLISH commands everyone should know


Basic Configuration for an interface via CLISH (ifconfig/ethtool still work within expert-shell in case you prefer those):

Configure the interface with an appropriate ipv4 address and netmask
GAIA1> set interface eth2 ipv4-address 10.100.100.1 mask-length 24
Interace comments
GAIA1> set interface eth2 comments "Internal Interface"
Interface speed hardcoding (use 'auto-negotation on' instead if required)
GAIA1> set interface eth2 link-speed 1000M/full
Turn the interface "on" and active
GAIA1> set interface eth2 state on
Show current information
GAIA1> show interface eth2      
link-speed 1000M/full
ipv6-autoconfig Not configured
speed 1000M
mac-addr 00:0c:29:38:9f:6d
state on
duplex full
type ethernet
comments {Internal Interface}
mtu 1500
auto-negotiation Not configured
ipv4-address 10.100.100.1/24
ipv6-address Not Configured

Statistics:
TX bytes:0 packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 packets:0 errors:0 dropped:0 overruns:0 frame:0


Adding static routes in GAIA CLISH:

Destination of 10.100.101/24 via 10.100.100.2
GAIA1> set static-route 10.100.101.0/24 nexthop gateway address 10.100.100.2 on

GAIA1> show route
Codes: C - Connected, S - Static, R - RIP, B - BGP,
       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

S     0.0.0.0/0           via 192.168.0.1, eth0, cost 0, age 2413 
C     10.100.100.0/24     is directly connected, eth2 
S     10.100.101.0/24     via 10.100.100.2, eth2, cost 0, age 37 
S     10.100.102.0/24     via 10.100.100.2, eth2, cost 0, age 20 
S     10.100.103.0/24     via 10.100.100.2, eth2, cost 0, age 17 
S     10.100.104.0/24     via 10.100.100.2, eth2, cost 0, age 14 
S     10.100.105.0/24     via 10.100.100.2, eth2, cost 0, age 11 
S     10.100.106.0/24     via 10.100.100.2, eth2, cost 0, age 8 
S     10.100.107.0/24     via 10.100.100.2, eth2, cost 0, age 5 
S     10.100.108.0/24     via 10.100.100.2, eth2, cost 0, age 2 
C     127.0.0.0/8         is directly connected, lo 
C     192.168.0.0/24      is directly connected, eth0


Creating a bond from CLISH:

#Create the bond and assign a slave interface in one command:
GAIA1> add bonding group 0 interface eth1
 Enter an interface to add to the bond group.
 Only ethernet interfaces can be added to a bond group.
 The interface shouldn't have any IP addresses or aliases configured.
 Hit tab to obtain the available interfaces that can be added to the bond group.
# Set the "mode" of the Bond (I choose 8023ad here - aka LACP)
GAIA1> set bonding group 0 mode 8023AD
# Set the bond's primary interface:
GAIA1> set bonding group 0 primary eth1
# View your bond:
GAIA1> show bonding group 0
Bond Configuration
    xmit-hash-policy layer2
    down-delay 200
    primary eth1
    lacp-rate slow
    mode 8023AD
    up-delay 200
    mii-interval 100
    Bond Interfaces
        eth1

# This information is also available via Expert mode via /proc:
[Expert@GAIA1]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 17
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:0c:29:38:9f:63
Aggregator ID: 1


Saving your configuration:

GAIA1> save config

Friday, 6 July 2012

SPLAT/GAIA: How to determine bond status (link/LACP etc)

Hi Everyone,

Had this question asked today: "How do you determine if your LACP (or XOR) bond is up and running and what state is it in?

Since ethtool and ifconfig don't provide you LACP details, you have to check via /proc like so (removed MACs for privacy):


Looking at bond0 here:
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 32773
        Partner Mac Address: **************

Slave Interface: eth2
MII Status: up
Link Failure Count: 1
Permanent HW addr: **************
Aggregator ID: 2

Slave Interface: eth3
MII Status: up
Link Failure Count: 0
Permanent HW addr: **************
Aggregator ID: 2

Slave Interface: eth4
MII Status: down
Link Failure Count: 0
Permanent HW addr: **************
Aggregator ID: 3

Slave Interface: eth5
MII Status: down
Link Failure Count: 1
Permanent HW addr: **************
Aggregator ID: 1

You can also configure how Checkpoint monitors the bonds with cphaconf show_bond
# cphaconf show_bond -a

                                      |Slaves     |Slaves |Slaves  
Bond name  |Mode               |State |configured |in use |required
-----------+-------------------+------+-----------+-------+--------
bond0      | Load Sharing      | UP   | 4         | 4     | 3      
bond1      | Load Sharing      | UP   | 4         | 4     | 3      

Legend:
-------
UP!               - Bond interface state is UP, yet attention is required
Slaves configured - number of slave interfaces configured on the bond
Slaves in use     - number of operational slaves
Slaves required   - minimal number of operational slaves required for bond to be UP

The steps found with sk69180 should also be followed to ensure slave interfaces have been added correctly.

Saturday, 26 November 2011

CheckPoint: How to Export a list of VPN Users for Auditors

Hi Everyone,

Apologies for not uploading anything interesting as of late. My time has been almost entirely consumed with learning Juniper, which I may create a separate page for sometime in the future to detail those experiences.

Anyways, I've had a few requests for an easy way to supply auditors a list of VPN user details without having to resort to manually grep'ing through $FWDIR/conf/fwauth.NDB to generate a usable report.

While it's not as easy as say, Cisco's 'show run | i users', it's pretty close:


[Expert@R75-A]# fwm dbexport -f /tmp/users_dump.xls

You'll notice that the results you need are formatted *terribly* in the initial output. Each user will look something like this:
[Expert@R75-A]# cat /tmp/users_dump.xls
Milton;    black;    {Awesome_Employees};    {Any};    {Any};    Internal Password;    00:00;    23:59;    31-dec-2030;    {MON,TUE,WED,THU,FRI,SAT,SUN};    Auth;    YIH14pBTDJvJ6;    ;    ;    ;    ;    ;    Any;    {};    {,,None};    ;    ESP;    SHA1;    3DES;    ;    {DES,3DES};    {MD5,SHA1};    {signatures};    ;    Any;    ;    false;    ;   
However, if you import this file into Excel/Libre Calculator and specify "Separated by" with Tab, Semicolon, and Space, it becomes perfectly readable and ready to submit to the auditor.

I'm running low on idea's at the moment, so if you'd like to know how to do anything CheckPoint related, let me know!

Cheers,


Friday, 21 October 2011

ByteRange Filter Denial of Service Vulnerability in Check Point Products

Hello everyone,

A security update just came in that you should be aware of:

Check Point has acknowledged a vulnerability in multiple Check Point products, which could be exploited to cause a DoS (Denial of Service). This vulnerability is the Apache ByteRange Filter vulnerability, CVE-2011-3192, reported earlier this year. Because this affects network filtering and protection devices, this flaw has the potential to impact other network devices dependent on that filter, resulting in a much larger DoS. Please refer to the Check Point advisory for the list of impacted products. Users of Check Point devices should check with the vendor and apply any updates as soon as possible.

Hotfixes have been released for:
  • Connectra R66.1, R66.1n
  • R71.40, R75.20
  • DLP-1 R71.20



https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65222
http://httpd.apache.org/security/CVE-2011-3192.txt
http://secunia.com/advisories/46474/
http://secunia.com/SA45606/

Friday, 30 September 2011

UTM-1: How to bypass the WebGUI during the initial install

Before I begin I should note that this does not 'always' work, and is not supported by TAC.

However, if you are successful with it, you can run sysconfig/cpconfig immediately instead of having to go through the initial install procedure via the WebGUI.

I know anyone who is stuck doing remote deployments/wipes with UTM-1's knows the pain this requirement can cause :)

To 'get out of jail', simply run the following from expert mode:

touch /opt/spwm/conf/wizard_accepted


Once completed, sysconfig/cpconfig will now work.

Enjoy!

SPLAT: How to automatically enter "Expert Mode" when logging in

I suppose it's pretty fitting that I include this.

Make sure you're in expert mode when you run this:

Verify your current shell (substitute 'admin' for your user):
cat /etc/passwd |grep admin
admin:x:0:0::/home/admin:/bin/cpshell

Change your shell to bash:
chsh -s /bin/bash admin
Changing shell for admin.
Shell changed.

Verify the change has taken place:
cat /etc/passwd |grep admin
admin:x:0:0::/home/admin:/bin/bash

Now, when you exit/login again, you'll immediately get dropped into expert mode:

login as: admin
admin@192.168.0.50's password:
Last login: Fri Sep 30 14:28:08 2011 from 192.168.0.10
[Expert@R75-A]#

Keep in mind this does have security implications - it's just nice to have in a lab environment :)

Friday, 16 September 2011

IPSO: How to Backup and Restore via CLISH?

This will backup all of the OS information/configuration like Routes, Proxy Arps, Interface configuration etc:

The following will create a new backup in /var/backup/

clish -c "set backup manual filename your_desired_filename"
clish -c "set backup manual on"

To Restore:
clish -c "set restore manual /path_to_backup_file.tgz"

Tuesday, 6 September 2011

FWMonitor: How to filter by network range

Pretty simple idea, however wildcards don't work in the generic 'src/dst' statements unfortunately.

Let's say I want to capture all traffic sourced from 192.168.0.0/24 destined to the 10.15.15.0/24 over port 80, I'd use the following syntax:

fw monitor -e "firstblock={<192.168.0.0,192.168.0.255>};secondblock={<10.15.15.0,10.15.15.255>}; accept (src in firstblock, dst in secondblock, sport=80);"

The first IP Block is the starting IP for the network, and the second is the last IP in the block. You can define as many 'groups' as you'd like. Just make sure that the rest of the 'accept' statement ends up between two parent parenthesis.

Thursday, 1 September 2011

How to remove a static route in SPLAT without using SYSCONFIG

It's pretty simple:

Consult the routing table to verify the routing information of your to-be-deleted route with one of the two following commands:
route | grep ip_of_your_route
or
netstat -nr | grep ip_of_your_route

An example is below:
netstat -nr |grep 192.168.72.75
192.168.72.75 172.16.25.45 255.255.255.255 UGH    0 0        0 eth5

Delete the route (help for the command can be found with 'route --help'):
route del -net 192.168.72.75 netmask 255.255.255.255 gw 172.16.25.45

Verify the route has been deleted (you should not see the original route anymore):
netstat -nr |grep 192.168.72.75

Save the changes (in case the route was pulled from sysconfig/netconf.C):
route --save