Skip to content

fw ctl or checkpoint tables by any other name

Holidays are over, Checkpoint failures are back, so business as usual. Today I want to draw your attention to often overlooked information source – Checkpoint state tables. While running, the firewall creates, keeps and updates various tables it needs for correct functioning. These tables contain parameters that are mostly of use for firewall itself, but you can query them on the cli, sometimes even flush them as well.
To see all tables with its contents you type –
[Expert@Hollywood]# fw tab
To see only table names –
[Expert@Hollywood]# fw tab | grep “\-\-\-\-\-\-\-”

——– vsx_firewalled ——–
——– firewalled_list ——–
——– external_firewalled_list ——–
——– management_list ——–
——– external_management_list ——–
——– log_server_list ——–
——– tcp_services ——–
——– udp_services ——–
——– internal_interface_list ——–
——– topology_range_list ——–
——– gui_clients_list ——–
——– cp_NG_products_list ——–
——– smtp_av_user_config_match_tab ——–
——– smtp_av_scan_exclusion ——–
——– http_av_user_config_match_tab ——–
——– http_av_scan_exclusion ——–
——– pop3_av_user_config_match_tab ——–
——– pop3_av_scan_exclusion ——– Continued…

Posted in Checkpoint NG/NGX, Firewall.

Tagged with .

No comments

By Yuri – April 9, 2010

Solaris – configure ftp server

SUN Solaris FTP
SUN Solaris comes with ftp daemon based on WU-FTPd Washington University project.
While not being very enthusiastic about its vulnerabilities discovered over the years and being rather
abandoned by its developers ,still it comes by default and as long as Sun ok with that it is ok with me too.
Below I will shortly introduce configuring it for local user access as well as anonymous one.

By default FTP daemon (in.ftpd) is disabled. Here is the initial state you have it :

root@Solaris# svcs ftp
STATE STIME FMRI
disabled 7:21:44 svc:/network/ftp:default

As ftpd is inet managed daemon more information can be queried from inetadm:

root@Solaris# inetadm -l svc:/network/ftp:default
SCOPE NAME=VALUE
name=”ftp”
endpoint_type=”stream”
proto=”tcp6″
isrpc=FALSE
wait=FALSE
exec=”/usr/sbin/in.ftpd -a”
user=”root”
default bind_addr=”"
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE
default connection_backlog=10

Insecure you say , well , you are right – let’s sharpen it a bit.
Enable more detailed logging.

root@Solaris# inetadm -m svc:/network/ftp:default tcp_trace=TRUE
root@Solaris# inetadm -l svc:/network/ftp
SCOPE NAME=VALUE
name=”ftp”
endpoint_type=”stream”
proto=”tcp6″
isrpc=FALSE
wait=FALSE
exec=”/usr/sbin/in.ftpd -a”
user=”root”
default bind_addr=”"
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
tcp_trace=TRUE
default tcp_wrappers=FALSE
default connection_backlog=10

When execution option –a is given (and it is by default) then ftpd will consult /etc/ftpd/ftpaccess
file for additional restrictions and tweaks. Here are the few that are worth enabling.
Uncomment following lines to have more verbose logging available:

log transfers real,guest,anonymous inbound,outbound
xferlog format %T %Xt %R %Xn %XP %Xy %Xf %Xd %Xm %U ftp %Xa %u %Xc %Xs %Xr

Make sure these changes are applied

root@Solaris# svcadm refresh svc:/network/ftp:default

Configure anonymous access.
All the configs so far will allow only local valid users to connect by ftp and be automatically
placed in their respective home directories. To allow anonymous ftp access with dedicated chrooted for that folder there is a special set of tools to use. Actually it is just one script that does all the hard work behind the scenes – creates ftp user, creates directory tree , sets up needed permissions, sets up chrooted environment for the anonymous ftp user.

root@Solaris# ftpconfig /export/home/ftp_pub
Updating user ftp
Creating directory /export/home/ftp_pub
Updating directory /export/home/ftp_pub

That is all, now you can login anonymously and download anything from /export/home/ftp_pub/pub directory. To also allow upload there , change the upload option in “/etc/ftpd/ftpaccess” and set accordingly permissions on the Solaris level for the directory pub (777)

upload class=anonusers * /pub yes
#upload class=anonusers * * no nodirs

And finally enable it

root@Solaris# svcadm enable ftp

Posted in Solaris.

No comments

By Yuri – March 31, 2010

Fortigate BGP – configure and debug

Everyone today speaks BGP: Cisco routers, Juniper routers and ScreenOS firewalls, Fortigate does it,even SonicWall have it as planned feature So question is not whether but how. The opportunity to see how it works on Fortigate recently presented itself and here is the sum up of how I configured and debugged Fortigate BGP set up.
Task at hand: configure BGP peering with Bogon Route project by Team Cymru www.team-cymru.org/Services/Bogons/routeserver.html . More information about the Bogon Routes can be found at the source – www.team-cymru.org/Services/Bogons . But in few words they advertise to you routes that are never to be seen in your network for legitimate reasons. Those are networks not only from RFC 1918 but those reserved by RIPE for special purposes, and those unallocated to anyone as of now.
What we need to know for this set up is this:

  • They advertise all the networks with no-export community
  • also they attach 65333:888 community (as per their site)
  • they use md5 password authentication
  • they don’t expect you to advertise to them anything
  • in advertised networks next hop is their advertising router
  • their AS number is 65333

Based on all the above my Fortigate BGP peer had to :

  • enable multihop peering
  • use MD5 password authentication
  • have route-map to attach no-export community so that we don’t inadvertently advertise learned routes to other peers ( just safety net , in case BGP peer stops attaching no-export community to their routes)
  • set next hop for the learned routes to Null 0 interface.

Let’s start configuring something. Important surprise here – in Fortigate GUI you can only set 3 parameters:
As number , Peer Ip and networks to be advertised, the rest is to be done on the command line . So here it goes
1) Configuring route-map to set no-export community on learned networks and force next hop to be some reserved Ip (192.0.2.1 ) that in turn is statically routed to Null interface ,

config router route-map
edit “NO-EXPORT”
config rule
edit 3
set set-community “no-advertise”
set set-ip-nexthop 192.0.2.1
next
end
next
End

2) Configure BGP peer

(root) # show router bgp
config router bgp
set as 65002
config neighbor
edit 84.22.96.5
set ebgp-enforce-multihop enable
set remote-as 65333
set route-map-in “NO-EXPORT”
set password “yuiyui”
next
end
config redistribute “connected”
set status enable
end

3) Configure static blackhole route for the reserved IP used as the next hop for this.

(root) # sh router static
config router static
edit 3
set blackhole enable
set dst 192.0.2.1 255.255.255.255
next
End

Validation phase.
All configs are as good as the prove that it works.

List shortly all the peers

(root) # get router info bgp summary
BGP router identifier 10.250.250.2, local AS number 65002
BGP table version is 159
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
84.22.96.5   4  65333       4       6      159    0    0 00:00:48        0

Total number of neighbors 1

List all BGP neighbors and their peering state

My-FG (root) # get router info bgp neighbors
BGP neighbor is 84.22.96.5, remote AS 65333, local AS 65002, external link
  BGP version 4, remote router ID 84.22.96.5
  BGP state = Established, up for 00:00:58
  Last read 00:00:58, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received (old and new)
    Address family IPv4 Unicast: advertised and received
  Received 4 messages, 0 notifications, 0 in queue
  Sent 6 messages, 0 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 160, neighbor version 159
  Index 3, Offset 0, Mask 0x8
  Community attribute sent to this neighbor (both)
  Inbound path policy configured
  Route map for incoming advertisements is *NO-EXPORT
  0 accepted prefixes
  19 announced prefixes
  Connections established 1; dropped 0
  External BGP neighbor may be up to 255 hops away.
Local host: 10.250.250.2, Local port: 9188
Foreign host: 84.22.96.5, Foreign port: 179
Nexthop: 10.250.250.1

See the routes learned through the BGP protocol

(root) # get router info bgp network
BGP table version is 161, local router ID is 10.250.250.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 5.0.0.0          192.0.2.1                0             0 65333 65333 i
*> 14.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 23.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 31.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 36.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 37.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 39.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 42.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 49.0.0.0         192.0.2.1                0             0 65333 65333 i
*> 100.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 101.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 102.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 103.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 104.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 105.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 106.0.0.0        192.0.2.1                0             0 65333 65333 i
*> 169.254.0.0      192.0.2.1                0             0 65333 65333 i
*> 172.16.0.0/12    192.0.2.1                0             0 65333 65333 i
*> 176.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 177.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 179.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 181.0.0.0/8      192.0.2.1                0             0 65333 65333 i
*> 185.0.0.0/8      192.0.2.1                0             0 65333 65333 i

List routes that are currently installed in the routing table that were learned by BGP .

(root) # get router info routing-table bgp
B       5.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       14.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       23.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       31.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       36.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       37.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       39.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19
B       42.0.0.0/8 [20/0] via 192.0.2.1 (recursive is directly connected, unknown), 00:00:19

After all is configured and saved (and probably doesn’t work) comes the bgp debug round.
Enable bgp debug on the appliance

#diag ip router bgp all enable

Enable debug output to console

diag debug enable

To stop this output

diagnose debug disable

To verify that debug is on

# diag ip router bgp show
BGP debugging status:
  BGP events debugging is on
  BGP debug level: INFO

If nothing after that happens try clearing all BGP sessions

#exec router clear bgp all

The good way to judge something new is to compare it with something you already know. To continue
With that logic I cross-reference debug output seen on Fortigate with the one seen on the Cisco BGP peer. That
way you can decide what is more informative and who wins the race (Cisco of course, what you thought?).

Case 1
One of the peers is configured with wrong AS number.
In Fortigate you see this:

BGP: 84.22.96.5-Outgoing [FSM] State: Idle Event: 3
BGP: 84.22.96.5-Outgoing [NETWORK] FD=15, Sock Status: 0-Success
BGP: 84.22.96.5-Outgoing [FSM] State: Connect Event: 17
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 1
BGP: 84.22.96.5-Outgoing [ENCODE] Open: Ver 4 MyAS 65002 Holdtime 180
BGP: 84.22.96.5-Outgoing [ENCODE] Open: Msg-Size 45
BGP: 84.22.96.5-Outgoing [DECODE] Msg-Hdr: type 3, length 23
BGP: %BGP-3-NOTIFICATION: received from 84.22.96.5 2/2 (OPEN Message Error/Bad Peer AS.) 2 data-bytes

Now let’s compare to the debug from Cisco

#debug ip bgp events 
Mar 24 13:14:55.572: %BGP-3-NOTIFICATION: sent to neighbor 10.250.250.2 2/2 (peer in wrong AS) 2 bytes FDEA FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 FAEA 01B4 0AFA EA02 1302 0201 1400 0100 0132 0222 0012 0222 00

Case 2
MD5 authentication is set on Cisco but not on the Fortigate. Again for comparison
debug from Fortigate and debug from Cisco
Cisco:

Jan  5 10:42:14.299: %TCP-6-BADAUTH: No MD5 digest from 10.250.250.2 (1037) to 84.22.96.5(179)

Fortigate:

84.22.96.5-Outgoing [FSM] State: Connect Event: 9
BGP: [RIB] Scanning BGP Network Routes...
84.22.96.5-Outgoing [FSM] State: Connect Event: 9
BGP: [RIB] Scanning BGP Network Routes...

Case 3 (that actually happened when I configured this Fortigate) is mismatched MD5 password on either side

Fortigate:
Doing summary listing showed peering as down :

84.22.96.5   4  65333     934    1036        0    0    0    never Connect

Cisco:

*Mar 24 13:40:28.800: BGP: Regular scanner event timer
*Mar 24 13:40:28.800: BGP: Import timer expired. Walking from 1 to 1
*Mar 24 13:40:42.764: %TCP-6-BADAUTH: Invalid MD5 digest from 10.250.250.2(11064) to 84.22.96.5(179)

Case 4 On Cisco ttl-security is enabled while on Forigate ebgp multi-hop is not .
There is no such thing as TTL security on the Fortigate by the way, all you can do to handle this state is enable ebgp-multihop and them it starts sending BGP packets with ttl = 255 .

Cisco:

Jan  7 13:01:36.992: %BGP-4-INCORRECT_TTL: Discarded message with TTL 2 from 10.250.250.2

Forigate:

BGP: 84.22.96.5-Outgoing [FSM] State: OpenConfirm Event: 11
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 4
BGP: 84.22.96.5-Outgoing [ENCODE] Keepalive: 13548 KAlive msg(s) sent
84.22.96.5-Outgoing [FSM] State: OpenConfirm Event: 10
BGP: 84.22.96.5-Outgoing [ENCODE] Msg-Hdr: Type 3
BGP: %BGP-3-NOTIFICATION: sending to 84.22.96.5 4/0 (Hold Timer Expired/Unspecified Error Subcode) 0 data-bytes
BGP: 84.22.96.5-Outgoing [FSM] State: Idle Event: 3
BGP: 84.22.96.5-Outgoing [NETWORK] FD=14, Sock Status: 111-Connection refused
BGP: 84.22.96.5-Outgoing [FSM] State: Connect Event: 18

Bonus Case Bug-not-a-feature thing on the Fortigate – when configuring MD5 password for BGP authentication you get Cross-Site vulnerability protection for free :) Don’t ask me how XSS is connected to cli configuration of BGP …

set password <2AEARep>

The string contains XSS vulnerability characters
value parse error before ”
Command fail. Return code -173

Posted in Firewall, Fortigate.

Tagged with .

1 comment

By Yuri – March 26, 2010

Scan of the week – scan by country scan by continent

Gooood morning everyone . Today I launch yet another weekly column “Scan of the week” and this will be all about scanning the Net. Tools will be many but they will not be the point, my wanting here is to show interesting/funny/unusual/useful things you can see on the Internet by going out there and exploring.
Dis+claimer – all this stuff I bring to your attention is for educational purposes only, and what may be fine and ok here and for me can easily get you somewhere else in trouble so use your discretion here .
Happy scanning.

“…Don’t know much about geography” as the song goes was ok in 1958 but can be embarrassing in our times of globalization. So let’s fill the gap using the NMAP . Say you
are investigating the issue of negative attitude towards foreigners in Russia , and as part of the research
you just have to see active members of the movement(s) in question voicing their opinions. Only that many
times access to such forums or messageboards is limited by their admins to Russian IPs only. So to get there you need a free open Russian proxy. So let’s see how to find one.

Round 1-Gimme the addresses. IP geolocation databases as it is known in the Net , or simply GeoIP databases are compilation of IP ranges per their assigned country. Take it with a bit of salt as accuracy is the issue here. The one of the most known and used free GeoIP source is Maxmind.com free database that is updated once per month (good enough for this).
The Maxmind database comes as binary proprietary format file you can work with using 3rd party tools or as CSV file I will be using here. Download it as Geolite country , unzip and you have GeoIpCountryCSV.csv . Format of the records in it goes like this -

"1.0.0.0","1.0.0.255","16777216","16777471","AP","Asia/Pacific Region"
"1.1.1.0","1.1.1.255","16843008","16843263","AU","Australia"
"1.2.3.0","1.2.3.255","16909056","16909311","AU","Australia"
"1.50.0.0","1.50.3.255","20054016","20055039","AP","Asia/Pacific Region"

The purpose here is to :

  1. Find all IP ranges that belong to the country of interest
  2. Reformat found IP ranges into the presentation suitable for the NMAP
awk -F, ‘/RU/ { gsub(/”/,”",$0); print $1 “-” $2} ‘ GeoIPCountryWhois.csv > IPs.data
head IPs.data
62.5.128.0-62.5.255.255
62.12.80.0-62.12.81.255
62.16.32.0-62.16.66.255

- After I found all Russian IPs reformat it to the NMAP eatable form

awk -F\. ‘{split($4,aaa,”-”); print $1″-”aaa[2]“.”$2″-”$5 “.” $3″-”$6″.”aaa[1]“-”$7}’ IPs.data > scan.me
 head scan.me
62-62.5-5.128-255.0-255
62-62.12-12.80-81.0-255
62-62.16-16.32-66.0-255
62-62.16-16.68-127.0-255
62-62.32-32.64-95.0-255

Round 2 – find me some proxy Here I will use LUA script from NSE repository of the nmap called http-open-proxy

nmap -n -PN -oN proxy-check.grep –script=http-open-proxy -iL scan.me -p 8080,3128

That completes this opening article of the Scan of the week united with Awk weekly . Hope you found it educational enough and see you next time.

Posted in Awk weekly, Scan of the week.

No comments

By Yuri – March 22, 2010

Install native telnet client on Checkpoint firewall

Some time ago Telnet from inside Checkpoint firewall I wrote how to use awk to imitate telnet in Checkpoint firewall. Later in comments to that post the reader pointed out that there is a native telnet client located on the Splat installation iso image.
That’s true , only I think you not always have installation image at hand. For that you can instead use
standalone download SecurePlatformAddOn_R55.tgz While it states R55 in its name the telnet client software it has inside works well even with R70 and also on Splat platforms with 2.6 kernel. Indeed the telnet client that comes with the R70 installation image is bigger by file size but bears the same version name anyway.
In addition there is another useful utility in this package – well known wget. So consider installing it too.
After downloading it go by the usual RPM package install procedure – unzip, untar , rpm –Uvh <name>

Posted in Checkpoint NG/NGX.

Tagged with .

No comments

By Yuri – March 20, 2010

Traffic shaping in Checkpoint the Linux way

Quite often I need to work on the Checkpoint firewall access to which in SmartDashboard is close to impossible due to the overloaded internet connection to the firewall and there is no out of band access alternative.
Other times doing debug produces huge files (we talk gigabytes here) and if I download such files from the firewall through scp as is it will use up all the bandwidth of the line causing slowness to the client.
For such and alike cases there is a perfect tool provided by Linux kernel – Quality of service (QOS), which allows us to limit used bandwidth with very flexible filter criteria. QOS in Linux is subject enough complicated and extensive not to be dealt in a short post , so I just present some ready to use copy-paste configs just for that.For in-depth coverage see lartc.org/howto
And of course if your firewall has Floodguard license and feature installed (Checkpoint implementation of Quality of service) then you can achieve the same through rules in QOS tab in Smartdashboard.

1) Limiting myself – when downloading some huge file from the firewall I want to limit my traffic to some specific rate.
Here:
eth0 – outgoing interface;
100Mbit – physical rate of the interface;
300Kbit – rate limit I impose on traffic destined to my management station where I download the file;
39.139.3.4 – my management IP.

tc qdisc add dev eth0 root handle 33: htb
tc class add dev eth0 parent 33: classid 33:10 htb rate 100mbit
tc class add dev eth0 parent 33:10 classid 33:200 htb rate 300Kbit
tc filter add dev eth0 parent 33: protocol ip prio 2 u32 match ip dst 39.139.3.4/32 flowid 33:200

2) Line is overloaded and I cant connect with SmartDashboard but still have ssh access.
Here:
30Kbit – rate limit I impose on ANY traffic except to my management IP , see next rule;
200Kbit – rate limit on traffic to my management station.

tc qdisc add dev eth0 root handle 33: htb
tc class add dev eth0 parent 33: classid 33:10 htb rate 100mbit
tc class add dev eth0 parent 33:10 classid 33:100 htb rate 30Kbit
tc filter add dev eth0 protocol ip parent 33:0 prio 5 u32 match ip dst any flowid 33:100
tc class add dev eth0 parent 33:10 classid 33:200 htb rate 200Kbit
tc filter add dev eth0 parent 33: protocol ip prio 2 u32 match ip dst 39.139.3.4/32 flowid 33:200

NOTE QOS in Linux as presented here works on egress , i.e. it can limit traffic leaving the interface .
Script above therefore limits what would be upload leaving to the Internet from the firewall.
To limit some heavy download the same technique should be applied on Internal,facing the LAN, interface. Usually nevertheless the moment you throttle the upload modern applications will detect it and slow down download as well , but your mileage may vary.

Posted in Checkpoint NG/NGX.

Tagged with .

No comments

By Yuri – March 13, 2010

awk weekly – rule hits statistics . Checkpoint again

I know , I know, I have to get out of this Checkpoint-only land and am working on this ,but for today again comes the awk travelling diary on the Checkpoint firewall roads. As I mentioned before once you export firewall logs into human-readable format you can do lots of interesting things – for example script that gives statistics of how many times each Security rule was hit .
Be aware that this counts explicit Security rules only – i.e. the ones you see in Security tab of the Smartdashboard. No other rules you usually see in Smartview Tracker are counted – e.g. SmartDefense,Web Filtering etc. Also afterwards I sort it by number of hits to see what rules are used most:

awk -F\; ‘ {match($0,/rule: +([0-9]+)/,rules);rule_count[rules[1]]++} END {for (rule_number in rule_count) print ” Rule number: ” rule_number ” Hits: ” rule_count[rule_number]}’ ./fw.log.txt | sort -n -k5 
Rule number:  Hits: 1197330  Ignore this line as it counts non-matched lines I dont want to filter with additional conditions and added time processing
 Rule number: 2 Hits: 9
 Rule number: 5 Hits: 366
 Rule number: 11 Hits: 12296
 Rule number: 9 Hits: 14457
 Rule number: 0 Hits: 17094
 Rule number: 1 Hits: 44066
 Rule number: 7 Hits: 233643
 Rule number: 10 Hits: 366275
 Rule number: 6 Hits: 424639

Posted in Awk weekly, Checkpoint NG/NGX.

Tagged with .

No comments

By Yuri – March 13, 2010

awk weekly – Checkpoint Anti Spam statistics or viva la Open Relays

Goooood day everyone again,
today I have had another fight with the spam cartel that my client fell victim of. Once upon a time there was not so powerful UTM providing internet to not so crowded office in not so security-aware Central Europe.
All would be good and well if not this problem – they could not send emails outside as the IP of the firewall entered every imaginable blacklist on the Earth. Hmm, but the firewall has AntiSpam subscription service up and running.
LAN is blocked on port 25 outbound except the Exchange. Antivirus is everywhere so low chance of spam coming from LAN. In SmartView Tracker lots of SMTP rule logs in red – spam entering Exchange is blocked .

So what the …? tcpdump with -w option for 5 minutes was all I needed to see that Exchange was open relay and kindly offered to relay spam from everyone to everywhere.
To really measure the impact of the event I had to have some statistics and Checkpoint didn’t help me much with that , eventhough this UTM has also SmartView Monitor license it is not suited for the task. So I exported fw.log on the UTM into text human-awk-readable format , that took some 40 mins on 300 Mb log file and produced text file of 475 Mb, and then did whatever I wanted with the data using awk.
Now get some action:
Script 1 – Find all mails rejected in direction from LAN (interface Internal, remember it is UTM) to the Internet (interface External) , then gather statistics of how many mails came from what ip [less relevant here as all mails come from Exchnage, but in environment where hosts send mails directly outside it is] and show us :

# awk -F\; ‘/Internal to External/ && /reject/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spammer_ips in IPS) print spammer_ips ” ” IPS[spammer_ips]}’ | sort -n -k2,2
192.168.14.12 402804

Yahooooo! In the timeframe of 28 hours there were blocked 402804 mails as spam coming from Exchange!
Not bad at all – all this without any malware installed on the client side [my educated by Wireshark guess here as I dont have access to the Exchange],just amazing!

Now let’s have a look at overal number of mails that was accepted and sent outside to the Internet :
Script 2 – Find all mails accepted in direction from LAN (interface Internal) to the Internet (interface External) , then gather statistics of how many mails came from what ip and show us :

# awk -F\; ‘/Internal to External/ && /accept/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spammer_ips in IPS) print spammer_ips ” ” IPS[spammer_ips]}’ | sort -n -k2,2
192.168.14.12 257940

Wow! in addition to 402804 mails blocked by Checkpoint firewall as spam 257940 mails were sent out as clean, given that this is a very small office hardly sending 300 mails a day we get ratio of 39% spam passing through the Checkpoint Antispam , pity . Antispam blocking rate of 61% ? In 21st century ? Wake up !

Just for statistics I also calculated how many spam emails were blocked from outside inbound:
Script 3 – gather how many mails from outside coming in were rejected by Checkpoint as spam.

# awk -F\; ‘/External to Internal/ && /reject/ {print $2}’ ./fw.log.txt | wc
# 5593 11186 112648

So only 5593 incoming spam emails and almost half a million outgoing ones – that’s what I call effectiveness.
Script 4 – gather statistics on blocked emails and IPs it came from:

# awk -F\; ‘/External to Internal/ && /reject/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spam_ips in IPS) print spam_ips ” ” IPS[spam_ips]}’ | sort -n -k2,2

And here are some results

93.81.26.2 75
91.121.114.1 81
220.168.57.1 87
58.9.205.2 129
122.102.101.1 149
58.137.99.7 160
189.35.231.6 189
60.248.174.6 631

PS I know Checkpoint folks visit here , so if you think I get some data wrong – don’t be shy to correct me,all fixes are gladly welcome.

Posted in Awk weekly, Checkpoint NG/NGX.

2 comments

By Yuri – March 8, 2010

Abra – the new toy from the Checkpoint

Checkpoint announced availability (for inquiries yet,sale date is set on 31 of March) of their new project Abra – secured virtualized desktop solution. I myself haven’t seen nor tried this so can only judge from different sources. In essence we talk here about USB stick of approx. 4 Gb or 8 Gb that includes virtual image of the applications you need to do the work and optionally to connect securely to your workplace (to the Checkpoint gateway of course).
The testing (I know of) was done on their own employees that were given those Abra-sticks to work from home.
The way it works is pretty simple – you have encrypted (so they say) virtual desktop environment on stick ,
which you connect to any PC and upon entering user/pass can work using pre-installed and pre-configured
software on it . The sticks that Checkpoint gave to their workers contained Windows XP with set of usual software – browser, Microsoft Office etc. , also VPN client .
In short nothing new on the market except encryption – do a search on Virtual desktop infrastructure and you’ll get the idea. What interesting here is how they are planning to integrate this new buzz-project with all the rest of their line. Because otherwise it isn’t even worth trying to market it (put on USB VMware Player with windows XP and you get the same but without encryption).
The webpage from the CP is here:
Check Point Abra | Check Point Software
To see what people think about that you may go here:
CPUG.ORG discussion on Abra
If you have Partner level access to the Checkpoint site you may hear the Webcast presenting the Abra for the first time:
webcast archives
NOTE: see the comments for a more correct (than mine) view of this new product

Posted in Checkpoint NG/NGX.

Tagged with .

2 comments

By Yuri – March 3, 2010

Cisco IPS sensor – initial setup

Hello everyone. As I proceed in my studies towards the CCIE Security lab I’m starting a new category on the site – Cisco IPS. I will be posting all the things I learn about this gear, even the basics as I noted that on the Internet Cisco IPS sensors
are not much talked about and while not sure why this is so, I’ll try to fill the gap.In all cases I am using CIsco IPS sensor 4235 unless specified otherwise

Initial Configuration.
By default , out of the box the sensor has the following defaults:

Management IP: 10.1.9.201/24
Default gateway: 10.1.9.1 Allowed access: from the network 10.1.9.201/24
Telnet access: disabled
HTTPS: port 443

As most likely your network has different network address the first thing to do is change management IP, default gateway and allowed management access network(s)/IP. You do so by connecting with console to it .
You can configure these basic network settings in 2 ways: enter all the configuration commands on CLI (if you know them) or run interactive menu-type setup by issuing on the CLI: #setup . I’ll show both ways but let’s start with the setup menu.
A short remark – IPS sensor is the one of not so many devices in the Cisco family that configuring/managing/communicating with it using its GUI interface is the recommended and preferred way . It is much more intuitive, simple, produces the very same configuration at the device as done in CLI. The only time you may need to do stuff with CLI is initial setup and debug.

Configuring minimal required settings through setup menu:

  1. Connect to the device by terminal
  2. enter default user/password: cisco/cisco (or see the documentation coming with the device);
  3. run:
    sensor# setup

- First you are presented with the whole configuration currently set, just hit Space key until it reaches the end and asks whether you want to enter the setup dialog , print yes and Enter:

Continue with configuration dialog?[yes]:
Enter host name[sensor]: IPS4235  Here I set hostname to IPS4235
Enter IP interface[10.1.9.201/24,10.1.9.1]: 10.0.0.33/24,10.0.0.254   Pay attention to the syntax of specifying the management IP its subnet mask and default gateway
Enter telnet-server status[disabled]: enable     I say yes here but you are advised to say no on production devices
Enter web-server port[443]:         Default https listening port
Modify current access list?[no]: yes
Current access list entries:
  No entries
Permit: 10.0.0.100/32                 I allow management access to the device form this specific station 
Permit:                       Hit Enter to move to the next menu item
Modify system clock settings?[no]: no
Modify summer time settings?[no]: no
Modify system timezone?[no]: no
Modify interface/virtual sensor configuration?[no]: no
Modify default threat prevention settings?[no]:
------cut here------------
exit exit

Upon finishing all the menu items in the dialog you are presented with the configuration you just entered :

The following configuration was entered.
service host
network-settings
host-ip 10.0.0.33/24,10.0.0.254
host-name IPS4235
telnet-option enabled
access-list 10.0.0.100/32
ftp-timeout 300
no login-banner-text
exit
time-zone-settings
exit
summertime-option disabled
ntp-option disabled
exit
service web-server port 443

At the end of the output you are given the following choices:

[0] Go to the command prompt without saving this config.
[1] Return back to the setup without saving this config.
[2] Save this configuration and exit setup.
 Enter your selection[2]:   2

Then device asks to reboot in order for the changes to take effect – confirm that.
After reboot you may enter the sensor using supported browser by the management IP: https://10.0.0.33
Also make sure the station you are connecting from has Java virtual machine installed as the GUI is entirely based on it.

Posted in Cisco IPS.

No comments

By Yuri – February 28, 2010