I find it lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.
It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
You are filtering it out on your firewalls, aren't you? /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP
This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.
I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...
It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter. You are filtering it out on your firewalls, aren't you?/sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP
Exactly. From the MS Security bulletin:
The risk posed by the vulnerability could be mitigated by, if feasible, blocking port 1434 at the firewall.
What the heck was it doing open in the first place?
by Anonymous Coward writes:
on Saturday January 25, 2003 @09:08AM (#5156319)
What the heck was it doing open in the first place?
When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server 2000, only the network name of the computer running the instance and the instance name are required. When an application requests a connection to a remote computer, Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name specified in the connection. All computers running an instance of SQL Server 2000 listen on this port. When a client Dbnetlib.dll connects to this port, the server returns a packet listing all the instances running on the server. For each instance, the packet reports the server Net-Libraries and network addresses the instance is listening on. After the Dbnetlib.dll on the application computer receives this packet, it chooses a Net-Library that is enabled on both the application computer and on the instance of SQL Server, and makes a connection to the address listed for that Net-Library in the packet.
So the UDP 1434 port is open when the SQL Server is started to listen all the clients with any IP address on this port. SQL Server only receives the packet from the client on this port to determine which instance the client attempts to access and return the related information of the SQL Server to the clients. Then, the clients can create the connection to the SQL Server with the protocol enabled on the server side.
So the UDP 1434 port is open when the SQL Server is started to listen all the clients with any IP address on this port. SQL Server only receives the packet from the client on this port to determine which instance the client attempts to access and return the related information of the SQL Server to the clients. Then, the clients can create the connection to the SQL Server with the protocol enabled on the server side.
There is a difference between a port being open on the machine the service is on and the port being open to the world. You should not leave this port open to the world. If people outside your firewall need access to your internal MSSQL server, you leave TCP 1433 open to selective hosts.
As I said in a previous post... (Score:5, Informative)
It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
You are filtering it out on your firewalls, aren't you?
This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.
I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...
Re:As I said in a previous post... (Score:5, Informative)
You are filtering it out on your firewalls, aren't you?
Exactly. From the MS Security bulletin:
The risk posed by the vulnerability could be mitigated by, if feasible, blocking port 1434 at the firewall.
What the heck was it doing open in the first place?
Re:As I said in a previous post... (Score:5, Informative)
When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server
2000, only the network name of the computer running the instance and the instance
name are required. When an application requests a connection to a remote computer,
Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name
specified in the connection. All computers running an instance of SQL Server 2000
listen on this port. When a client Dbnetlib.dll connects to this port, the server
returns a packet listing all the instances running on the server. For each instance,
the packet reports the server Net-Libraries and network addresses the instance is
listening on. After the Dbnetlib.dll on the application computer receives this
packet, it chooses a Net-Library that is enabled on both the application computer and
on the instance of SQL Server, and makes a connection to the address listed for that
Net-Library in the packet.
So the UDP 1434 port is open when the SQL Server is started to listen all the clients
with any IP address on this port. SQL Server only receives the packet from the client
on this port to determine which instance the client attempts to access and return the
related information of the SQL Server to the clients. Then, the clients can create
the connection to the SQL Server with the protocol enabled on the server side.
Re:As I said in a previous post... (Score:5, Informative)
with any IP address on this port. SQL Server only receives the packet from the client
on this port to determine which instance the client attempts to access and return the
related information of the SQL Server to the clients. Then, the clients can create
the connection to the SQL Server with the protocol enabled on the server side.
There is a difference between a port being open on the machine the service is on and the port being open to the world. You should not leave this port open to the world. If people outside your firewall need access to your internal MSSQL server, you leave TCP 1433 open to selective hosts.