From port to start the enterprise to prevent the attack of SQL worm virus

SQL worms have always been a headache for corporate network administrators, many times if the Etherpeek for ports 1433, 1434 grab packets will find that many users do not have SQL Server installed on the computer, but can still monitor the worm through 1433 ports to the outside a large number of contracts. In general, Microsoft's desktop database MSDE may also infect the worm.

Look at the Sqlsnake worms, also known as Spida and Digispid, who have been scanning tens of 1433 of thousands of Internet-connected computer systems for their first appearances, in an attempt to find a system that runs Microsoft SQL without setting the appropriate password on the system administrator account. There is another virus, even if there is no database installed on the PC will be infected. This time the client PC can only be protected from the network layer if there is no way to solve it.

Generally speaking, UDP port 1434 is used for listening, can filter out the UDP1434 on the network device, and TCP port 1433 is the port that the SQL Server needs to communicate normally, and it can't filter out the whole network.

However, in general, the network segment of the database is very small, so that we can open the network segment of the database 1433 ports, and then filter the entire network of 1433, so as to reduce the failure to deal with the point, but also achieved the purpose.

Look at the ACL below, the core three-layer switch S8016 for 1433, 1434 ACLs, and other devices similar.

Note: Full network of UDP 1434, open 10.145.7.0 network segment TCP port 1433.

rule-map　intervlan　rule72　tcp　any　any　　eq　1433
rule-map　intervlan　rule73　tcp　any　any　eq　1434
rule-map　intervlan　rule69　tcp　any　10.145.7.0　0.0.0.255　eq　1433
eacl　acl-jxic　rule69　permit　priority　34083
eacl　acl-jxic　rule72　deny　priority　34088
eacl　acl-jxic　rule73　deny　priority　34090

After using Etherpeek grab bag A look, the SQL worm No, equipment also no alarm, done!