IA (Identity Awareness) can be a pain, here are some short notes that helps in the troubleshoting. Check the smartlog that there is full access between the AD DC and the FW Gateway as the DCE-RPC uses dynamic high ports to communicate.

## Debug PFP on
pdp d s all all

## Debug PDP Off
pdp debug off

# Check logfile
tail -f /$FWDIR/log/pdpd.elg

# Check if PDPD is running
ps aux -| grep pdpd

# Try to restart it by killing, it will autorestart
killall pdpd

# Verify connectivity to AD (LDAP and WMI) that runs over DCE-RPC. 
Solution Title: How to use test_ad_connectivity to troubleshoot AD Query connectivity.
Solution ID: sk100406
Solution Link: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100406

# Check pdp
pdp connections pep

# check pep
pep s pdp a

# View and control the AD Query (ADQ) status.
adlog a dc - Displays a table specifying which Domain Controllers this Security Gateway is connected to, their connectivity status and the number of events fetched in the last hour

adlog a query all - (or 'adlog a q a' for short) - Displays all of the identity information currently known by AD Query (ADQ)
If this shows error kill the pdpd and verify that it restarts. see above

adlog a query ip 1.1.1.1 - (or 'adlog a q i 1.1.1.1' for short) - Displays the information currently known for 1.1.1.1

Deleting the ProxySG 'main' Access Log

Blue Coat SG810 Series#configure terminal
Enter configuration commands, one per line.  End with CTRL-Z.
Blue Coat SG810 Series#(config)access-log
Blue Coat SG810 Series#(config access-log)edit log main
Blue Coat SG810 Series#(config log main)commands delete-log
  ok
Blue Coat SG810 Series#(config log main)

Blue Coat SG810 Series#show access-log statistics main
Statistics:
Access Log (main) Statistics:
Log Manager Version 3
Log entry lifetime counter:     38029489
System Status:
  Log manager:                  enabled and running
  Upload client:                not connected
  Log writer:                   idle
  Log reader:                   idle
Log Information:
  Current log size:             0 bytes
  Maximum log size:             20000 MB
  Max size policy:              stop logging
  Bytes in write buffer :       184
  Tail sockets in use :         0
  Modified time:                2010-05-25 10:29:48+08:00MYT
Next Upload:
  Client type:                  bluecoat
  Next attempt:                 21 seconds
  Connect type:                 continuous upload
  Connect reason:               regular upload
  Retrying, failure count:      1
  Upload format:                gzip
Last Upload Attempt:
  Time:                         2010-05-25 10:29:48+08:00MYT
  Maximum bandwidth:            0.82 KB/sec
  Result:                       failure
Current/Last Upload File:
  Remote filename:              Not Applicable
  Remote size:                  0 bytes
Blue Coat SG810 Series#

How to create a self signed certificate with openSSL to be used with BlueCoat proxy

This short guiede will create a new keyring, a private key, and eventually a certificate.


1. generate a private key with openSSL (atleast 2048 key length)
# OpenSSL> genrsa -des3 -out mypriv.key 2048
a set key length to 2028
b when you press Enter your asked to set a pass phrase for the key, remember it.

2. open notepad and cut the content of the private mypriv.key created in step 1.

3. In the BlueCoat  proxy - Configuration - SSL - Keyrings
a create a new keyring and select 'import existing private key'. paste your key here and type the pass phrase from step 1.
b Give the keyring a name press - OK
c Apply to install the policy

4. Generate the Certificate request from the new keyring.
a open the newly created keyring.
b press 'create' in the Create Signing Request section.
c copy the content and save as csr.txt in notepad (make sure there is no blankspace or characters after at the end of the file)

4. Create the certificate (valid 1 year in this example)
# OpenSSL> x509 -req -days 365 -in c:\openssl-win64\csr.txt -signkey c:\openssl-win64\bin\mypriv.key -out c:\openssl-win64\cert.crt

5. convert cert to PEM
# OpenSSL> x509 -in c:\openssl-win64\cert.crt -out c:\openssl-win64\out.pem -outform PEM

6. put the cert in the keyring in BC
a open the out.pem file with notepad and copy the content
b open the BC keyring and select 'import' in the Certificate section, paste your content and press ok
c press 'Apply' to save the policy

The certificate is finnished and ready to be used.

Phishing fraud "TeliaSonera AB Opinionsundersökning - Windows & Chrome-användare"

This is probably one of the best phishing I've seen for a while, it claims to be from my ISP and the spelling and content is excellent. It's when you hit the last page to retrieve your gifts for participating you can tell for sure, an iPhone for $5....sure

Safe browsing

Export Checkpoint policy to HTML or XML format

Even if the SmartDashboard console is fantastic sometimes you need to play with the ruleset in different formats.

Try the Web Visualization Tool from Check Point

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk64501

Note: You don't have to reboot your computer as the last step in windows, you can temporarily add the path manually. I hate to reboot.

c:\Users\admin> set path=%path%;your_path_to_application 

tcpdump of SYNners

Shows a list of the top 10 Source IP-addresses that starts a new TCP connection (SYN).

# tcpdump -nnt -i Lan1 "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) == 0" >/var/log/tmp/lan1_syn.txt

# awk '{print $2}' /var/log/tmp/lan1_syn.txt | sed 's/.[^.]*$//'| sort -n | uniq -c | sort -n | tail -n10

LDAP Account unit - SSL fingerprint

when using secure channel on port 636 for the LDAP servers the encryption is verified by a Fingerprint against the AD servers certificate. When this certificate is updated in AD you must 'Fetch' a new fingerprint or this connection will not continue to work.

This could be a complicated task to know about and remember.

Solution:
CP solutions is to simply delete the fingerprint and leave that field blank, now you would never have this problem. The downside is you have an increased risk for man-in-the-middle attack.

Another solution would be to have 1 AD server with higher priority and keep that on standard port 389 not encrypted. Then monitor the log for traffic for that host, then you know you have problem with a encrypted AD server. This is also a security risk since all user password will be sent in clear text. So in my mind the first solution is a better choice.