July 28, 2004 at 3:39 pm
I have a server that is running SQL Sever 2000 SP3. The IDS has been reporting attacks only when an adminstrator is logged into the box and is performing some sort of activity. This does not happen any other time or when the administrator is logged in, but does not actually do anything. I've included the summary from IDS:
Executive Summary
An attempt was made to attack a Microsoft SQL Server using certain network packets that can result in denial of service or remote compromise. Firewall changes or software upgrades may be advisable if you are running SQL Server on your network.
Technical Summary
Certain packets to UDP port 1434 (where the SQL Monitor listens) can result in Denial of Service conditions or buffer overflows resulting in remote root compromise.
SecureWorks recommends blocking any traffic to UDP port 1434 to any servers running Microsoft SQL Server or, more conservatively, all traffic to that port.
Check with Microsoft whether updates are available which fix these vulnerabilities, which are known to exist in versions up to SQL Server 2000 Service Pack 2.
Thanks,
A.J.
July 30, 2004 at 2:00 am
... dont listen on the default port.
I beleive you can 'hide' what port SQL Server listens on, which infact just alter the default port.
-- Alex
July 30, 2004 at 7:48 am
Keep in mind that there will be lots of traffic to 1434, the MS tools might be sending things to this. I belive Enterprise Manager sends some UDPs out to get the server status every xx minutes.
You should not have the IDS monitoring the traffic from INTERNAL addresses to the db. And externally it should be blocked.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
July 30, 2004 at 11:23 am
Your copy of EM is probably polling the server; turn off polling on the system through EM.
Another thing to note (we got bit on this one): do not "hide" your MSSQL 2K instances. This is documented in the KB.
One last thing - we found that when running multi-instance installations of MSSQL, even thought 1434 is blocked at the border, I can connect to and work with non-default instances of MSSQL from beyond our borders. This means that MSSQL is using ports other than 1434 for authentication when running a multi-instance system. This is not documented, and a port scan would probably reveal the ports in question. Just an interesting thing I noticed.
July 30, 2004 at 9:27 pm
If you hide your SQL Server instance it goes from tcp/1433 (by default) or whatever you had it set to and switches to tcp/2433. This is hard-coded. If you have multiple instances of SQL Server on a single system, that means you can only hide one instance. This is an unfortunate limitation of the hide option.
With that said, if you want to completely block any inbound traffic to the SQL Server Listener service, which listens on udp/1434, you can set up a quick IPSec policy on the server to do so. Keep in mind that if you have named instances on this particular SQL Server you will need to specify the port address for the instance on your clients. When you specify MyServer\MyInstance, the way the client figures out what port to talk to is it sends a request to udp/1434 asking for the instances and their listening ports. If udp/1434 is blocked, this querying for what port to use will be blocked.
K. Brian Kelley
@kbriankelley
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply