Booches.nl

Cisco CSC-SSM-20 notes

The Cisco CSC-SSM-20 modules provide advanced scanning technologies within the Cisco ASA firewall. During installations of these modules I created some quick notes, which I would like to share with you.

Initial configuration

After inserting the Cisco CSC-SSM modules into the Cisco ASA firewall, you have two ways to configure the initial configuration. The first method is through Cisco ASDM and launching the Cisco CSC-SSM Launch Wizard under Configuration. The second method is through the Cisco ASA CLI. Below you see an example of the CLI method.

session 1 do setup ac-key base 1 <license key>
session 1 do setup ac-key plus 1 <license key>
session 1 ip address 10.10.1.1 255.255.255.0
session 1 ip gateway 10.10.1.1
session 1 do setup dns 10.10.1.10 10.10.1.11
session 1 do setup host csc-ssm1.booches.nl
session 1 do setup email-domain booches.nl
session 1 do setup ntfn-email admin@booches.nl
session 1 do setup ntfn-svr-ip 10.10.1.100
session 1 do setup ntfn-svr-port 25
session 1 do setup password <old password> <new password>
session 1 do apply-config

The above commands configure various parameters, like license keys, hostname, IP address, internal mail domain and password credentials.

Define scanning traffic

With the configuration of a service-policy within the Cisco ASA configuration, you define which traffic should be forwarded and scanned by the CSC-SSM modules. The Cisco CSC-SSM modules provide scanning for the following protocols: tcp/http, tcp/smtp, tcp/pop3 and tcp/ftp. The Cisco CSC-SSM modules have their own management interface. This interface is used by the Cisco CSC-SSM modules to check for updates or query the TrendMicro databases for web or e-mail reputation checks. I always exempt the traffic from the Cisco CSC-SSM modules from scanning, because scanning the Cisco CSC-SSM traffic could impact the performance. Below you see and example configuration of the service-policy configuration, including the exemption of the Cisco SSM traffic. The Cisco SSM modules have the IP addresses 10.10.1.1 and 10.10.1.2 in this example.

access-list csc-ssm extended deny tcp host 10.10.1.1 any eq www
access-list csc-ssm extended deny tcp host 10.10.1.1 any eq smtp
access-list csc-ssm extended deny tcp host 10.10.1.1 any eq pop3
access-list csc-ssm extended deny tcp host 10.10.1.1 any eq ftp
access-list csc-ssm extended deny tcp host 10.10.1.2 any eq ftp
access-list csc-ssm extended deny tcp host 10.10.1.2 any eq pop3
access-list csc-ssm extended deny tcp host 10.10.1.2 any eq smtp
access-list csc-ssm extended deny tcp host 10.10.1.2 any eq www
access-list csc-ssm extended permit tcp any any eq www
access-list csc-ssm extended permit tcp any any eq smtp
access-list csc-ssm extended permit tcp any any eq pop3
access-list csc-ssm extended permit tcp any any eq ftp
!
class-map cm-csc-scanning
match access-list csc-ssm
!
policy-map pm-csc-scanning
class cm-csc-scanning
csc fail-open
!
service-policy pm-csc-scanning interface inside

The policy-map uses csc fail-open, which means that all traffic is allowed through if the Cisco CSC-SSM module would (physically) fail and become unavailable. Depending on the security policy used within your organization, you can also configure the Cisco ASA to block all traffic. You should then use the command csc fail-closed.

I configured the service-policy on the inside interface. This is done for logging purposes. When you apply the service-policy to the outside interface, you will only see the outside PAT address in the http logging. Which is fairly useless if you would like to know who is accessing an “illegal” website.

Before placing the Cisco CSC-SSM module in production, be sure that the Cisco CSC-SSM module has access to the internet to query the TrendMicro database. If the Cisco CSC-SSM modules don’t have the appropriate rights to the internet the scanning feature doesn’t work properly and nobody will have access to the internet.

Failover / Synchronization

Cisco ASA appliances are mostly configured in a redundant way, like active/passive or active/active. When both Cisco ASA appliances have their own Cisco CSC-SSM module, you can configure synchronization between the Cisco CSC-SSM modules. This ensures that the configuration of both modules is always the same. I configure failover / synchronization with the following steps.

1. 1. Completely configure the primary module;
2. 2. Complete the initial configuration on the secondary module;
3. 3. Test connectivity between both modules and export the configuration of the primary module;
4. 4. Open a browser window and enter the following URL in the Address Field: https://<primary IP device address>:8443. The Logon windows appears. Log on, and choose Administration – Device Settings – Device Failover Settings.
5. 5. Open a second browser windows and enter the following URL in the Address Field: https://<secondary device IP address>:8443. As in step 4, log on and choose Administration – Device Settings – Device Failover Settings.
6. 6.On the Device Failover Settings window for the primary device, enter the IP address of the secondary device in the Peer IP address field. Enter an encryption key of one to eight alphanumeric characters in the Encryption key field. Click Save, and then click Enable. The following message appears under the windows title: Interscan for CSC SSM could not establish a connection because the failover peer device is not yet configured. Please configure the failover peer device, then try again. This message is normal behavior and appears because the peer is not yet configured.
7. 7. On the Device Failover Settings window for the secondary device, enter the IP address of the primary device in the Peer IP address field. Enter the encryption key of one to eight alphanumeric characters in the Encryption key field. The encryption key must be identical to the key entered for the primary device. Click Save, and then click Enable. The following message appears under the windows title: InterScan for CSC SSM has successfully connected with the failover peer device. Do not click at anything else at this time for the secondary device.
8. 8. On the Device Failover Settings window for the primary device, click Synchronize to peer. The message in the Status field at the bottom of the window should state the data and time of the synchronization, for example: Status: last synchronized with peer on 11/01/2010 09:12:12.

Be sure you do not click Synchronize to peer at the end of step 7, while you are still on the Device Failover Settings window for the secondary device. If you do, the configuration you have already set up on the primary device is erased. You must perform manual synchronization from the primary device, as described in step 8. The exception to the auto-synchronization feature is uploading a system patch. A patch must be applied on both the primary and the secondary device.

TrendMicro IMSVA – reject unknown recipients via LDAP

With the configuration and implementation of an anti-virus, anti-spam solution, I always check if the security appliance has the option to block unknown recipients via LDAP. This prevents unnecessary e-mail from being sent to the backend servers.

While configuring a TrendMicro IMSVA 8.0 I noticed that the LDAP option was available, as shown below.

The option can be found under Administration – IMSVA Configuration – SMTP routing. I enabled the option and configured a LDAP connection to the backend database. I started testing the LDAP check via telnet and noticed that all secondary e-mail addresses were rejected by the security appliance.

I started looking at the specific LDAP records from an user with a LDAP browser, like Softerra LDAP Browser. I noticed that all secondary e-mail addresses are under the name ProxyAddresses and the primary e-mail address falls under the name mail.

I started searching the TrendMicro knowledge base but couldn’t find a solution. I found an article about the problem, which also provided the correct solution. To enable TrendMicro IMSVA to check secondary e-mail addresses you have to login to the appliance via a SSH session and change some settings within the PostgreSQL database. You need to execute the following commands:

[root@mail ~]# cd /opt/trend/imss/PostgreSQL/bin/
[root@mail bin]# ./psql -U sa -d imss
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

imss=# update tb_global_setting set value=’proxyAddresses’ where name =’mail_attr’;

UPDATE 1
imss=# \q
[root@mail bin]#

Next I needed to reboot the server. After the reboot I did some more testing and this time all secondary e-mail addresses were accepted by the security appliance.

You can check your newly added entry in the PostgreSQL database with the following command:

imss=# select * from tb_global_setting where value=’proxyAddresses’;
section |   name    |     value      | inifile  | notes
———+———–+—————-+———-+——-
LDAP    | mail_attr | proxyAddresses | ldap.ini |
(1 row)

At the end I found the solution but I am very curious why this isn’t default behavior. I mean, I guess I am not the only one who is using secondary e-mail addresses?!?!

Automated eSafe backup

After configuring an eSafe appliance you have the option to export the configuration through the management interface, but you have to do this manually. eSafe has also a build in command line option to create a backup of the required files.

The command line allows backing up and restoring files using standard backup/restore commands. The command line option creates a tar.gz file; the same file that is created when backing up via the eSafe Appliance Manager.

I did some simple scripting to create a backup file, which is copied to a FTP server daily at 05:00 AM. When using the build in backup feature, the tar.gz file is created in the folder /var/esafe. I created two additional files (backup.sh and ftp_file) to automate the backup proces.

Below you see the content of both files:

backup.sh

#/bin/bash

cd /var/esafe
# Remove old backups
rm -rf *.tar.gz

# Create the backup with build-in eSafe backup
/opt/eSafe/esgapi –createbackup

# FTP files to Management server
ftp -inv </var/esafe/ftp_file &

ftp_file

# FTP files to Management server
open 10.10.1.10
user username password
lcd /var/esafe
cd /backup/esafe
put *.tar.gz
bye
quit

These commands create the necessary tar.gz backup file and copies this file to the FTP server. The last step is configuring the crontab to execute the command daily at 05:00 AM.

crontab

# Backup eSafe configuration
# Backup is copied via FTP to Management server
0 5 * * * bash /var/esafe/backup.sh

I guess the script couldn’t be more easy, but it works perfectly (for me).

When running the build in backup command (/opt/eSafe/esgapi –-createbackup) eSafe looks in the file /opt/eSafe/backup.list to determine the files to backup. You could decide to extend this list with the location of the Anti-Spam & URL filtering database (/opt/eSafe/eSafeCR/ConfigFilter/ofdb/*.fdb). This saves some downloading time when restoring an eSafe appliance.

LDAP and eSafe Gateway

eSafe Gateway can be used for scanning incoming and outgoing SMTP connections for virusses and SPAM. Normally eSafe Gateway doesn’t check incoming mail addresses against a directory like Active Directory or Novell Directory Services.

This means that all mail addresses for a trusted domain are forwarded to the internal mail server. In the most ideal situation unknown mail addresses should be blocked at the eSafe Gateway. This feature will take away load off the internal mail server, because this mail server doesn’t have to generate NDR (Non-Delivery Reports) messages. Beside that, the eSafe Gateway also doesn’t have to process the NDR’s. LDAP (Lightweight Directory Access Protocol) provides this functionality.

With LDAP configured, the eSafe Gateway will synchronize all known mail objects from the directory services with the eSafe Gateway. By this, the eSafe Gateway knows all valid mail objects and can block invalid mail objects. There are some issues when configuring a LDAP query with Active Directory. By default Active Directory only allows 1000 objects in one query. Some customers have more mail object, so this settings needs to be added. Inside Active Directory, you should edit the LDAP Policy setting MaxPageSize. Look here for more information about editing the MaxPageSize variable.

Some organizations use PublicFolders in conjunction with Microsoft. These PublicFolders can be mail-enabled and should be added in the LDAP filter configuration inside eSafe Gateway. This is done by changing the default filter

(&(|(objectClass=person)(objectClass=contact)(objectClass=organizationalPerson))(!(objectClass=computer)))

in

(&(|(objectClass=person)(objectClass=contact)(objectClass=organizationalPerson)(objectClass=publicFolder))(!(objectClass=computer)))

This results in adding the mail object PublicFolder to the LDAP query.

Barracuda User Creation

I have a customer running a Barracuda SPAM firewall 300. The customer has the specific request that only the administrator can look at Quarantine messages and users shouldn’t get their own Quarantine inbox. To accomplish this I have configured the Quarantine Type: Global.

I see that all Quarantine messages are delivered in the globally configured mailbox. But sometimes the Barracadu still automatically creates an Account Address under the Users tab. The user from that Account has than the ability to look at their own quarantine messages. I thought it would help to configure the option New User Quarantine State to No, but this has no affect.

Does somebody know who to disable the function to automatically create User Accounts on the Barracuda SPAM firewall 300…??