yurisk.info » Firewall

Don't rely on SmartViewTracker only – it may lie

Yuri — Sat, 20 Jun 2009 14:11:05 +0000

Funny case of WYSIWYG misleading the uninitiated. The case involved a seemingly normally functioning firewall Checkpoint which after a client created rule to allow FTP from any to his server in DMZ (no Nat involved) refused to allow connections though. The client being quite experienced himself entered SmartViewTracker did filter on the rule (here rule 77) and saw nothing (of course Log was enabled on the rule) . OK, he thought, he canceled the filter and also started looking on the clean up rule that said Any -> Any = Drop (log enabled) and … again saw no hits at all. And at this stage he approached us with
request to check Linkproof leading to this firewall as ” it doesnt pass traffic to my FTP server”.
I did a usual thing – ssh -> fw monitor on FTP server IP and , hurra, saw
me reaching FTP server IP but on input interface only – “Aha, dropped by a rule
for sure” , then it took me another minute to prove it (to me and to the client)
with this:

Here:
194.99.73.13 – FTP server in DMZ (IP sanitazed of course)
124.92.11.33 – my IP

[Expert@firewall2070]# fw ctl zdebug drop | grep 194.99.73.13
fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by fwhold_expires Reason: held chain expired
fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by
fw_handle_first_packet Reason: Rulebase drop – rule 77

To remind – rule 77 was Any -> 194.99.73.13 (Service FTP) = Allow (log)

Why rule didn’t work is another question – but reason was messed up rulebase that cleint did, when further
down the rulebase was another rule to the same server partly overlapping this rule, the moment I disabled
second rule all started to work.

So conclusion – don’t rely on the SmartviewTracker only for debug , there can be too many
reasons why it is not logging/showing logs as should.

SSH session timeout in Checkpoint NG/NGX

Yuri — Mon, 15 Sep 2008 18:20:11 +0000

Ever got swearing when in the middle of fw monitor / debug session you got abruptly thrown on session timeout ?? Me too. While thinking naively ssh timeout is managed by sshd/ssh configs I was suprised to know CP did it their way.

Turned out here we get definitions for interactive session : cat /etc/bashrc

# By default, log out the user after three minutes of unattended prompt
export TMOUT=180
export SHELL=/bin/bash
# Take into account idle setting of cpshell, if available
if [ -f /etc/cpshell/cpshell.state ]; then
   idle=`grep idle /etc/cpshell/cpshell.state | sed s/idle=//`
   if [ $idle"UNDEFINED" = "UNDEFINED" ]; then
          idle=3
   fi
   export TMOUT=`expr $idle \* 60`
fi

So to change the default timeout for ssh session you can:

1) Set idle variable in /etc/cpshell/cpshell.state to be later multiplied

cat /etc/cpshell/cpshell.state
audit=100
idle=100
scroll=1

2) Change last export directly to whatever you wish:

export TMOUT=7000 ; in seconds

I personally when working on client’s firewall am setting it manually when long debug session is expected:

[Expert@cp]# TMOUT=700
[Expert@cp]# export TMOUT

Telnet from inside Checkpoint firewall

Yuri — Wed, 10 Sep 2008 08:00:30 +0000

Yesterday I saw a strange problem – connection from outside to Exchange in a LAN times out, while in Tracker all connections to port 25 are in green. Strange was that through VPN client-to-site and from inside LAN all worked prefectly well. So I wasn’t sure 100% it wasn’t a firewall causing this. The next best way to check it would be telnet from inside NGX (R65 in this case) to port 25 to Exchange by its LAN IP … only that Checkpoint don’t have telnet client included in their Splat . If I had enough time I’d compile telnet client statically on some Linux box with the same kernel/libraries then’d copy it to NGX for testing, but to do it ASAP I hacked a small AWK script that emulates (just enough fo ra test) telnet, below these scripts .

BTW this script made it 100% clear there was some problem with Exchange over which I had no control – from firewall its port 25 answered very erratically – once ok , 10 times connection refused. So after a double check

client found that from LAN and VPN it also wasn’t stable as he first thought .

General telnet client script :

[Expert@cp]# awk -v ip=192.168.0.1 -v port=25 -f telnet.awk

Where:

ip - IP to connect to

port – port to connect to

#!/usr/bin/awk
#This is a simple telnet emulation script purpose of which
# is to try to connect to a given IP on a given port using TCP
# and print to the terminal few lines received from the server
# if session is established. It has no functionality but to
# establish a TCP connection and print out received text from the
# server, after that it just exits.It was created to debug
# connectivity issues on Checkpoint NGX firewall that has no built
# in telnet client .
# Client
     BEGIN {
       (“/inet/tcp/0/” ip “/” port ) |& getline
       print $0
       close((“/inet/tcp/0/” ip “/” port ))
     }

Next is the same cript with add on for port 80 – to get some response from web server:

#!/usr/bin/awk
     BEGIN {
   Portandip = (“/inet/tcp/0/” ip “/” port )
   print “GET / HTTP/1.1\n\n” |& Portandip
   while ( ((“/inet/tcp/0/” ip “/” port ) |& getline)>0)
       print $0
       close((“/inet/tcp/0/” ip “/” port ))
     }

PS Thanks to Aibulat (see comments) for info, turns out there is a telnet client available on Splat cd-rom .It is just not installed by default when installing Splat.