While some end users are calling for ISPs to block certain ports relating to the Microsoft exploit as reported yesterday (Feared RPC worm starts to spread), most ISPs are reluctant to do so.
The vulnerability, a buffer overrun in a Windows interface that handles the RPC (Remote Procedure Call) protocol, was acknowledged by Microsoft in a security bulletin posted on July 16. Microsoft has been urging customers, as late as Monday of this week (Microsoft NZ gets serious about security flaw), to install a security patch in order to protect against attack. By yesterday a worm known by several names including Blaster and Lovesan was reported in the wild.
ICONZ's engineering manager John Russell says while blocking the port would stop the worm, there are two reasons for not blocking at an ISP level.
"Firstly because it breaks stuff. In this particular case port 135 is used for Windows file sharing and that's how the virus is moving from machine to machine."
Blocking that port would stop the worm in its tracks, however it would also mean anyone using the port for file sharing would no longer be able to do so.
"Anyone doing file sharing between branches for example would be off the air."
Port blocking also causes a long-term problem.
"What also happens is no-one bothers to patch their machines because it's being blocked by their ISP. A year or two later someone will remove the block and the whole thing will flare up again because unpatched, undiscovered machines will start infecting everyone again."
However, Ihug engineering manager Anand Lal says so few users were legitimately using port 135 that he's put a blanket block in place.
"We looked at the traffic and before the virus arrived there were only 1000 packets transmitted in two hours. After the virus there were 4 million."
Ihug decided so few customers would be affected by the temporary block that it would benefit the majority to put it in place for now.
Lal says the ISP will be able to offer blocks on a case-by-case basis shortly and would offer it as a service to corporate customers who may wish to block ports, such as those used by file sharing applications, for whatever reason.
Christchurch-based virus expert Nick FitzGerald says that port blocking is useful, but isn't the only answer to stopping the spread of the virus.
"It will only block [internet] traffic, but won't affect outsiders bringing in laptops or files on floppies."
Xtra is moving quickly to deal with the problem, but isn't blocking ports according to spokeswoman Anna Kermode, because it would risk blocking legitimate customer traffic.
"We are blocking access to TFTP sites contained in the [virus] file and this should cut back on the propagation success from any Xtra customers that are infected, as the worm payload won't be downloadable."
The Centre for Critical Infrastructure Protection (CCIP) recommends companies block ports to limit the spread of the virus.
"In addition to applying the relevant security patches, sites are encouraged to block access to TCP and UDP ports 135, 139, and 445 at the network perimeter. This will limit exposure to attacks. However, blocking at the network perimeter would still allow attackers within the perimeter of the network to exploit the vulnerability. Blocking traffic on TCP and UDP port 4444 will also assist in mitigating the spread of the worm by preventing the transfer of worm code" says the advisory.
Russell says while ICONZ machines were already patched and secured, network traffic exploded.
"We've had one guy sitting here all day basically null routing traffic from customers who are infected, ringing them up and telling them how to install the patch then letting them loose again."
The worm uses TFTP protocol to try to download its executable file "msblast.exe" to the infected machine.