Thursday, October 8, 2020

tcpdump - capture files

Scripts

touch debug_start.sh 

#!/bin/bash
tcpdump  -s 0 -enni any  host 10.115.10.11  and port '(68 or 67)' -w  /home/admin/DHCP.pcap

touch debug_stop.sh 
killall tcpdump
#!/bin/bash

./debug_start.sh 
Keep the script running until we catch the dhcp failure
To stop the script run the debug_stop.sh
.debug_stop.sh

Expert@myvpn:0]# ls -lt DHCP.pcap
-rw-rw---- 1 admin root 24576 Oct  8 07:46 DHCP.pcap
 
[Expert@myvpn:0]# ps -aef | grep tcpdump
pcap      1857  1855  0 07:31 pts/6    00:00:00 tcpdump -s 0 -enni any host 10.115.1.11 and port (68 or
admin    12142 12024  0 07:48 pts/6    00:00:00 grep tcpdump
[Expert@myvpn:0]#
 
 

 

vpnd monitor

#! /bin/bash
#VPND Monitor
logfile="/var/log/vpnd_monitor.txt"
interval=7

while :
do
        vpnd=`pidof vpnd`
        echo "=========================================" >> $logfile
        echo "Date : `date`" >> $logfile
        echo "PID: $vpnd" >> $logfile
        echo Visitor mode table: `fw tab -t tcpt_external_ip -s | tail -1` >> $logfile
        echo "VPND open file descriptors: `ls -la /proc/$vpnd/fd | wc -l`" >> $logfile
        echo "Top 5 memory consumers:" >> $logfile
        echo "`ps -e -orss=,args=,%mem= | sort -b -k1,1nr | head -5`" >> $logfile
        echo "" >> $logfile

        echo "Top 5 CPU consumers:" >> $logfile
        echo "`ps -e -o pcpu,cpu,args | sort -b -k1,1nr | head -5`" >> $logfile
        echo "" >> $logfile

        echo "VPND CPU/memory usage:" >> $logfile
        echo "`ps -p $vpnd -o %cpu,%mem`" >> $logfile

        echo "================================" >> $logfile
        sleep 7
done



Wednesday, October 7, 2020

Checkpoint Updatable Objects and Domain Objects

 


The list of Microsoft domains that will be queried from the updatable objects for Microsoft Office365:

https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
 
The domains being queried are on this list. 

Requests are doubled by adding www. prefix to each query causing alot of NXDomain result. 

This can be fix this with a kernel parameter to prevent these lookups:

To prevent nxdomain set kernel 
add_www_prefix_to_domain_name to 0 on the fly:

fw ctl set int add_www_prefix_to_domain_name 0

And to make the change permanent (survive reboot) add a line to 

$FWDIR/boot/modules/fwkern.conf:
add_www_prefix_to_domain_name=0

And, to further reduce the queries you can consider modifying 

rad_kernel_domain_cache_refresh_interval to double it's current value. 

By doing these changes you could reduce the queries related to FQDN domain objects + updatable objects, to approximately 25% of their current level. 

R77.30 Domain Objects / R80+ Non-FQDN Domain Object

All new connections going through the rulebase, every rule with these object the Firewall will do a reverse DNS lookup for the destination IP to see if the response matches the object. This is regardless of which member is Active as the Standby can send its own traffic to be checked via the rule base.

R80+ FQDN Domain Objects
After each policy install and every 30-60 seconds after that the Firewall will perform a DNS lookup for the Domain Objects.

Updatable Objects
The Firewall will obtain a list of domains from our servers related to the service of the Updatable Object. From there all domains are treated like FQDN Domain Objects where they are checked after policy install and 30-60 seconds after that.

For both R80+ FQDN Domain Objects and Updatable Object both members will perform the check and all DNS servers configured will be queried to make sure all IPs releated to the Domain is cached for the rules. If there is no response, response is late (over 1 second), wsdnsd is problematic, or received a fault from the server then the request is made again