Thus far the best mitigation is to block inbound and outbound traffic
destined to the UDP port 1434. You must be careful to minimize the impact on
mission critical services 1434/UDP and 1433/TCP which are legitimately used by
Microsoft SQL Server. Before the traffic is blocked to these ports, completely
make sure that the possible implications to your network are understood. Once
the UDP port 1434 is blocked completely, the spread of the worm in its current
form is contained. The affected systems are still infected and able to spread
within the contained section of the network, therefore Cisco advises that all
affected servers be patched in accordance with Microsoft's
For information about strategies to protect against Distributed Denial
of Service attacks, refer to http://www.cisco.com/warp/public/707/newsflash.html.
Note: These workarounds previously blocked both ports 1433 and 1434,
although there is no evidence that if you block port 1433 this has any effect
on the attack.Cisco has been alerted that mission critical services, such as IP
phone networks, require traffic to flow on port 1433 and has corrected the
recommended access control lists (ACLs) accordingly.
Caution: As with any configuration change in a network, ,you must evaluate the
impact of this configuration.before you make the change.
This workaround applies to most router platforms unless a platform is
Note: In order to track the source addresses, you must usethe Sampled
NetFlow, rather than "log" statements in ACLs as the high traffic in
combination with the log statement can overwhelm the router.
access-list 115 deny udpUDP any any eq 1434
access-list 115 permit
ip any any int
ip access-group 115 in
ip access-group 115 out
The worm attempts to send packets to random IP addresses, some of which
possibly do not exist. When that occurs, the router replies with an "ICMP
unreachable" packet. In some cases, areply to a large number of requests with
invalid IP addresses can result in degradation of the router's performance. To
prevent such an occurrences, issue these commands:
Router(config)# interface <interface>
Router(if-config)# no ip unreachables
Caution: Some configurations, such as certain types of tunnel structures,
require the use of ip unreachables. If the router
must be able to send "ICMP unreachable" packets, you can rate limit the number
of replies with the help of this command:
Router(config)# ip icmp rate-limit unreachable <millisecond>
In Cisco IOS 12.0 and later, the default rate limit is set to two
packets per second.
Receive ACL Feature On a Cisco 12000 (GSR) series
router, packets destined to the router's IP addresses are punted to the gigabit
route processor (GRP) in order to process. In order to protect the GRP, receive
ACLs (rACLs) can be applied. The rACLs filter traffic destined to the GRP and
only traffic explicitly permitted is processed by the GRP; the denied traffic
is dropped. In general, rACLs do not affect transit traffic (traffic that flows
through a router), only traffic destined to the router itself.
The rACLs are an extremely effective countermeasure to mitigate the
effects of excessive attack traffic destined to the GRP. For more information,
Receive Access Control Lists.
For simplicity and consistency, Cisco advises you the use of IOS ACLs
on the Cisco Catalyst 4000 with a Sup3 and Hybrid and Native configurations of
the Cisco Catalyst 6500. Additionally, Cisco advises the use of no
ipIP unreachables command.
If you have already applied for the VACL configuration originally found
in this page, it is effective and does not need to be changed. The Catalyst
6000 can use IOS ACLs; but for some configurations, VACLs are indicated.
Note: As you make configuration changes, use caution when you use VACLs in
conjunction with IOS ACLs.
set security acl ip WORM deny udp any any eq
set security acl ip WORM permit any
commit security acl WORM
set security acl map WORM
show security acl info all
clear security acl WORM
commit security acl WORM
MLS statistics can help track down infected hosts. NetFlow must be
enabled in full flow to see source and destination ports, as in this
switch> (enable) sh mls statistics entry ip
Destination IP Source IP Prot DstPrt SrcPrt Stat-Pkts Stat-Bytes
---------------- --------------- ----- ------ ------ ---------- ---------------
10.81.176.91 172.16.34.35 UDP 1434 2776 0 0
172.31.171.82 172.16.34.35 UDP 1434 2776 0 0
188.8.131.52 172.16.188.61 UDP 1434 3460 1 404
172.17.136.55 172.16.34.135 UDP 1434 2917 0 0
Apply the IOS ACL on switch virtual interfaces (SVIs), which are Layer
3 interfaces to VLANs; on physical Layer 3 interfaces; and on Layer 3
EtherChannel interfaces in both the inbound and outbound direction. You must
make sure that no ip unreachable is configured on
Apply the IOS ACL to Layer 2 interfaces on the switch only if an IOS
ACL is not also applied to the input of a Layer 3 interface (an error message
is generated upon attempts to do so). For Layer2, interfaces the IOS ACL is
supported on the physical interfaces only and not on EtherChannel interfaces.
It can be applied on the inbound direction only.
Apply the IOS ACL to the interface. Note that ACL's are only supported
in the inbound direction. In ordee to apply ACLs to physical interfaces, the
enhanced software image (EI) must be installed.
These are Layer 2 switches with no Layer 3 ACLs support.
Generally the PIX blocks this worm attempt unless it is explicitly
configured to permit access to MS-SQL services as in these examples:
access-list acl_out permit UDP any host <address> eq 1434
or in previous versions of the PIX software:
conduit permit UDP any any eq 1434
These commands permit this worm to connect to the server at
<address>. If it is not possible to patch the
affected servers, Cisco advises you to close those ports by setting the
statements to deny instead of
permit, or removing the commands completely.
Additionally, customers must deny outbound attempts to these ports:
access-list acl_inside deny udp any any eq 1434
or the corresponding outbound lists, but Cisco strongly advises ACLs in
lieu of outbound lists.
If a Cisco Secure Intrusion Detection System (CSIDs) is in use, a
signature update file is available at
Alternatively, a custom signature string can be added to address this
worm. Brief instructions are included here:
Tune Signature Parameters : CSIDS Signature Wizard
Current Signature: Engine STRING.UDP SIGID 2nnnn (any number between 20000 and 50000)
SigName: SQL Slammer
0 - Edit ALL Parameters
1 - AlarmInterval =
2 - AlarmThrottle = FireAll
3 - ChokeThreshold =
4 - Direction = ToService
5 - FlipAddr =
6 - LimitSummary =
7 - MaxInspectLength = 360
8 - MinHits =
9 - MinMatchLength =
10 * RegexString = \x04\x01\x01\x01\x01\x01.*[.][Dd][Ll][Ll]
11 - ResetAfterIdle = 15
12 * ServicePorts = 1434
13 - SigComment =
14 - SigName = SQL Slammer
15 - SigStringInfo =
16 - ThrottleInterval = 15
17 - WantFrag =