Limiting Ingress Traffic for W32.SQLExp.Worm

Reducing UDP-GSP Load and CPU Consumption

W32.SQLExp.Worm has the unintended payload of performing a Denial of Service (DoS) due to the large number of packets it sends out. For the best results, block all incoming UDP/1434, UDP/1433 traffic to all destination addresses other than the MicrosoftSQL servers that are accessible at your external router level. This will relieve most of the load on your firewall.

If you do not have access rights to configure your Internet router, follow the steps below to incorporate an interface filter. This will prevent the traffic from overwhelming the security gateway proxies, dropping malicious requests at the firewall's kernel level.

Warning: Interface filters are extremely restrictive. Incorrect configuration will result in denying legitimate requests through a firewall. If you are unfamiliar with the use and creation of filters, refer to your Implementation Guide and Reference Guide for information on this topic.

To Incorporate an Interface Filter

Following step 1 will not block the worm to your internal MSSQL servers. If at all possible, skip this step and create the ordered sequence filter using only filters b and c described below. Symantec is currently working on a fix to recognize the worm at the gateway so you can safely allow MSSql traffic to your internal MSSql servers.

Step 1

• Create host network entities for Microsoft SQL servers and the external firewall address. If you do not allow Microsoft SQL traffic in either direction you may skip this step. The host entities should use the IP addresses of the requested addresses used in your Redirected Services for Microsoft SQL. If you are not using Redirects, then the host entities should be configured using the actual Microsoft SQL server IP addresses. Add these to a Group network entity.
  
  If you know the addresses of clients accessing your servers you can configure a group for those entities and use this as entity A in the first filter of the ordered sequence. (This is more secure).
  
  You may also need to include virtual client IP addresses if internal hosts are going out with IP addresses other than external gateway address, as well as real IP addresses for hosts or subnets that are going out transparently, to this Group entity. Otherwise, SYN ACK will be denied for return Microsoft SQL packets on outbound requests from inside.

Step 2

• Create 2 protocols. For this example, the protocols have been named mssql1, mssql2, & msql3:
• Base Protocol UDP, Destination: 1433, source: 0-65535 (mssql1)
• Base Protocol UDP, Destination: 1434, source: 0-65535 (mssql2)

Step 3

For Symantec Enterprise Firewall (v6.5, v7.0), SGS 1.0, VelociRaptor v1.1, 1.5:

• Create 3 individual filters:



• An "allow" filter for Universe (entity A) to your Group network entity from step 1(entity B) - for the two protocols you created. Mssql1 (A->B) and mssql1 (B->A), Mssql2 (A->B) and mssql2 (B->A)
• A "Deny" filter for Universe (entity A) to Universe (entity B) - for the two protocols you created. Mssql1 (A->B) , Mssql2 (A->B)
• An "Allow" filter for filter for Universe(entity A) to Universe(entity B) - for service (A->B) All

• Create 3 individual filters:



• An "allow" filter for Universe (entity A) to your Group network entity from step 1(entity B) - for the two protocols you created. Mssql1 (A->B) and mssql1 (B->A), Mssql2 (A->B) and mssql2 (B->A)
• A "Deny" filter for Universe (entity A) to Universe (entity B) - for the two protocols you created. Mssql1 (A->B) , Mssql2 (A->B)
• An Allow filter for filter for Universe(entity A) to Universe(entity B)TCP (A->B) , UDP (A->B), and any IP/ICMP protocols (A-B).

Create a Filter Group (Solaris) or an Ordered Sequence Filter (NT/Win2K). Add these 3 filters to the Filter Group in the exact order above from top to bottom--the Filter is sequenced, which means that the first match will take effect.

Apply this Filter Group to the External Interface as an INPUT Filter; Save and Reconfigure the Firewall.

If you could have infected clients on your internal network you should configure a similar filter, to be applied to any internal interfaces.

If you allow outbound Microsoft SQL traffic you will need to create group entities. Group A, for internal clients that make outbound MSSql requests, and Group B, for the MSSql destination servers. Configure the filter in the same manner as above using these two new groups for the first filter in the sequence. Apply this filter to any internal interfaces as an input filter and save and reconfigure the firewall.

Note: If you already have the Nimda filter applied you can simply modify the external filter to include the MSSql ports.

Copyright (c) 2003 by Symantec Corp.

Permission to redistribute this alert electronically is granted as long as it is not edited in any way unless authorized by Symantec Security Response. Reprinting the whole or part of this alert in any medium other than electronically requires permission from symsecurity@symantec.com.