Booches.nl

TrendMicro IWSVA – Built-in groups and policies

While configuring a TrendMicro IMSVA appliance I tried to configure different URL filtering policies using built-in Windows Active Directory groups, like “Domain Users” in conjunction with user/group name authentication. Configuring policies with built-in groups weren’t functioning properly. The policies just weren’t matched, while I knew for sure that the user is a member of the specified group. So I started a research. After reading the documentation (IWSVA Adminstrator’s Guide) more carefully I found the solution to my problem. The Administrator’s Guide contains the following notes:

Since the ‘member’ attribute is incomplete in some built-in groups that exist in Active Directory (such as ‘Domain Users’), IWSVA will not be able to obtain membership information for these groups through LDAP search. Trend Micro recommends you create policies based on user-defined groups instead of built-in groups.

To configure IWSVA to listen on port 3268, the Microsoft Active Directory server that IWSVA uses should have the Global Catalog enabled.

Since the member attribute is not replicated to the Global Catalog for all group types, and because the memberOf attribute derives its value by referencing the member attributed (called back links and forward links, respectively), search results for members of groups, and groups which a member belongs, can very. Search results depend on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups that the user belongs to (global groups or domain local groups), and whether the users belongs to universal groups outside the local domain.

I tried to verify this information with Softerra’s LDAP browser and found the “flaw”. All users within the Active Directory are member of the Domain Users group and most of them have the Domain Users group as Primary Group. When looking at the CN=Domain Users with the LDAP browser I only see 12 members, while the Active Directory contains 700+ user accounts.

I changed the policy to match a user-defined group, which I checked with the LDAP browser first, and the matching works perfectly. I guess this is another RTFM story!

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?!?!

Citrix WebInterface 5.3 on IIS7

While configuring a Citrix NetScaler 9.2 in conjunction with WebInterface 5.3 I received the following error message when executing a published application.

An error occurred while trying to access the requested resource.

I thought to myself….no problemo, since I blogged about this problem before (source). This solution didn’t help. After changing the RequireLaunchReference value I still receive the error while opening an application. The only difference is that the event viewer message isn’t generated anymore.

After searching the internet I found another Citrix knowledge base article, called “Application Launch Failure in Web Interface 5.0 through 5.3”. This article provided me with the solution.

It looks like IIS 7 differs quite a lot from earlier versions. Citrix’s background on the problem:

It is currently suggested not to run .NET 1.1 or .NET 4.0 on a windows 2008 Web Interface server that is using Web interface 5.0 through 5.3. The .Net Framework 2.0 common language runtimes will be used in conjunction with the 3.0 and 3.5.

Don’t ask me what it is, because I don’t know. Switches, routers, firewall and other networking components don’t use Microsoft .NET…..

VMware: upgrade VMware Tools and Virtual Hardware for Microsoft ISA array

Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.

A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.

Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.