Finnish CERT (CERT-FI) recommends to pay special attention to certain address blocks.  They mention the DROP-list by the Spamhaus project as the most up-to-date list of malicious addresses.

It is always boring and time consuming to type long lists of addresses, so I made a quick-and-dirty script, which converts the DROP-list into StoneGate elements, and creates a group of them.  You can feed the DROP-list to this script, zip the result and import it into SMC.

Being an oldtimer, I wrote this with an ancient tool called awk, which you can find in most unix-based systems, including linux.  The most common variant is the GNU awk, gawk.  Someone would probably write this in 2 lines of Perl…

I provide this script as is, with no expressed or implied guarantees of any kind.  Use this at your own risk.  If you manage to break something with this, you have been warned and you assume full responsibility.  I have tested this on one system (Fedora Core 9) with one input, today’s DROP list from Spamhaus.org.

So, take a look at the code and decide yourself if you trust this.  Especially see the comment in the beginning.  Change the element naming convention to suit your needs and enjoy.

Today scenario is similar to the following.
Suppose you have an installed base composed of several StoneGate Engines (IPS, Firewalls) plus few 3rd party devices that you monitor thanks to new cool feature of SMC 5.0.

You would like to allow batch scripting monitoring of such devices to have data from SMC to populate other processes or software you might use.

sgElementStatus script allows you to check the status of a given element in StoneGate Management Center. Syntax is reported below, but please note that output changes depending on element type. Some examples:

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="FW-310-test"
(this is a Firewall)
Connect to Management Server: root@192.168.1.101
[1] FW-310-test: OK

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="DefGW"
(this is a Router, monitored with 3rd Party monitoring)
Connect to Management Server: root@192.168.1.101
[1] DefGW: Online

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="My-Network”

(this is a Network Element, silent output means element exist)
Connect to Management Server: root@192.168.1.101

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="Test Apache Web"
(this is a Web Server, monitored but unreachable)
Connect to Management Server: root@192.168.1.101
[1] Test Apache Web: Unreachable

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="My-non-existing-element"
(this is a fake name, not existing in SMC configuration)
Connect to Management Server: root@192.168.1.101
Script Failed
Not found: My-non-existing-element

C:\Stonesoft\StoneGate\bin>sgElementStatus.bat host=192.168.1.101 login=root pass=mypass element="DefGW-notmon"
(this is a Router, not monitored)
Connect to Management Server: root@192.168.1.101

[1] DefGW-notmon: Not Monitored

Scripts are available in Files area of StoneBlog Community for Windows and for Linux.

The scenario is when you need to verify/validate from command line is a given policy has issues if installed on a particular engine (but naturally without installing it).

The command sgPolicyCheck.[bat|sh] can be issued with the following parameters and options.

Parameters:
host=<Mgtserver address> (default: 127.0.0.1)login=<loginname> (default: root)
pass=<password> (default: password)
cluster=<cluster name> (default: "")
policy=<policy name> (default: "")
all_clusters=<use all clusters> (default: false)

An example could be:

C:\Stonesoft\StoneGate\bin>sgPolicyCheck.bat host=192.168.1.101 login=root pass=mypass cluster=FW-5000 policy="verify-this-policy"
…and the output is similar to the one reported below:

Connect to Management Server: root@191.168.1.101
Validation of Firewall Policy verify-this-policy on Single Firewall FW-5000:

6 issues found.
  6 warnings found:
    2 Missing Definitions found.
      Rule @2.0
      Rule @3.0
    2 Unreachable Rules found.
      Rule @1006.0
      Rule @981.0
    2 NAT and Routing Definitions found.
      Rule @1274.5
      Rule @1157.0

As usual, Files area of StoneBlog Community contains the script for Windows and for Linux.

Scenario could be, for instance, that you receive an alert raising the DefCon level and you want to react by activating a more restrictive policy.

The script for you today is called sgUploadFw.[sh|bat] and the syntax is:

sgUploadFw.[bat|sh] [host=hostname] [login=loginname] [pass=password] cluster=clustername [cluster=otherclustername] policy=policyname

host ==> SMC host where you want this script to be executed.
login ==> login of an Administrator Profile, who has rights to operate on given elements
pass ==> password (yes, in cleartext. It’s up to you to decide about security level you want to implement )
cluster ==> could be a single node or a cluster of engines
policy ==> the name of the policy you want to upload

Example and output:

C:\Stonesoft\StoneGate\bin>sgUploadFw.bat host=192.168.1.101 login=root pass=mypassword cluster=”FW-5000″ policy=”DefCon 1″
Finding cluster(s)
Found FW-5000
Found policy: DefCon 1
Accepted a compatible cluster: FW-5000
Starting upload
Waiting 900 seconds…

Contacting nodes of FW-5000
Connection ok on firewall FW-5000
Preparing configuration for FW-5000
Policy snapshot started
Policy snapshot created.
Uploading configuration on FW-5000
New configuration generated for firewall FW-5000
New configuration uploaded to firewall FW-5000
Rule @1279.6 has Source NAT translated to ipaddresses that corresponds to an int
erface address
Applying configuration on FW-5000
New configuration activated on firewall FW-5000
Checking connectivity on FW-5000
Contact with firewall FW-5000 confirmed
Policy installation successful for FW-5000

upload finished

To download the script for Windows click here, while the version for Linux is available here.

Both scripts will remain available in StoneBlog Community, Files area.

Scripts linked to this posts will remain available in StoneBlog Community under StoneFiles repository for free download.

Useless to remind that these are unsupported scripts, although I’ve tested them up to latest release and they work nicely

First script I’d like to share is about automating some commands to StoneGate Firewall/VPN or IPS Engine.

They all require to have at least the GUI (not WebStart) on the executing client.

Syntax is

sgOnOff.[bat|sh] [-host hostname] [-login loginname] [-pass password] -node cluster-node-name -cmd commandname

-host ==> SMC host where you want this script to be executed.

-login ==> login of an Administrator Profile, who has rights to operate on given elements

-pass ==> password (yes, in cleartext. It’s up to you to decide about security level you want to implement )

-node ==> this is the single node name. In a cluster it is a cluster node name as appears in SMC.

-cmd ==> the command you want to send, for example online or offline

For example:

sgOnOff.bat –host 10.1.1.10 –login superuser –pass mypassword –node “FW-310-test Single Node” –cmd offline

The batch files are available for both Windows and Linux platforms.

Sometimes the firewall sees information that are unrelated specifically to network security; still, these information could be very useful to be centrally collected.

This post shows how it is possible to use StoneGate Central Log Processing to collect this information centrally.

Let’s set a need to be taken as a sample: collect information about network clients at remote location using their MAC address.

The base assumption is that the firewall has the information we’re looking for since it maintains an ARP table, whose content can be queried using CLI command ip n on StoneGate engine.
Sample output from this command would be:
192.168.1.1 dev eth1 lladdr 00:0c:ee:93:11:e5 STALE
192.168.34.80 dev eth0 lladdr 00:21:70:18:9f:cf REACHABLE
192.168.34.100 dev eth0 lladdr 00:0c:ee:b8:1f:56 REACHABLE
192.168.34.210 dev eth0 lladdr 00:0c:ee:b8:1f:56 REACHABLE
1192.168.1.40 dev eth1 lladdr 00:50:56:a9:66:25 REACHABLE

By using some shell scripting,
ip n | awk ‘{print $1 " – " $5 ";"}’

we could easily retrieve a better formatted information, like:
192.168.1.1 – 00:0c:ee:93:11:e5;
192.168.34.80 – 00:21:70:18:9f:cf;
192.168.34.100 – 00:0c:ee:b8:1f:56;
192.168..34.210 – 00:0c:ee:b8:1f:56;
10.1.1.140 – 00:50:56:a9:66:25;

Done this, we could use command sg-logger on StoneGate engine to forward the information to Log Server using the same channel used for standard logs.
The syntax is:
sg-logger – Sends log message

Usage:
  sg-logger -f facility_number -t type_number [-e event_number] [-i "info_string"] [-s] [-h]

Options:
  -f Set facility
  -t Set type
  -e Set event (Default: 0 (H2A_LOG_EVENT_UNDEFINED))
  -i Set info string for log message (Default: "")
  -s Dump information on option numbers to stdout
  -h Show this help message

Let’s now bundle everything in a script that considers only information on eth0:
#!/bin/bash
#Script to send arp table to StoneGate log server
IP_ARP="`ip n | grep eth0 | awk ‘{print $1 " – " $5 ";"}’`"
N=0
STRING_A=""
for i in  $IP_ARP; do
STRING_A="$STRING_A $i"
if [ $N -ge 50 ]; then
echo "IN"
sg-logger -f 8 -t 6 -i "ARP from $HOSTNAME: $STRING_A"
N=0
STRING_A=""
else
let N=$N+1;
fi
done
sg-logger -f 8 -t 6 -i "$ARP from $HOSTNAME: $STRING_A"
exit 0

Launching this script (remember to set execute permissions) will generate an entry in Log Browser with the information needed in info field.

Should you need to run this regularly, you can set it as a script in Tester tab in StoneGate Engine’s properties.

Enjoy!