Как найти sql server в сети

• Download source – 6.84 Kb (Includes demo with VS2003 & VS2005 project files)

Introduction

This articles shows how to retrieve a list of PCs on the local network which are running MS SQL Server, and gets information about the instances, such as server name, instance name, version, and databases.

Background

To get a list of the nearby SQL Servers is as simple as typing “osql /L” on a command prompt. But getting them programmatically, for use inside an application, is a bit trickier. The most common use for this would be to create a connection string building form in managed code, which will be the subject of my next article.

Note also, that while the subject matter is SQL Server, the first half of this article deals mostly with sockets.

To create a list of SQL Server instances, I first tried several different methods, all of which had two things in common: they took a very long time, and they were only marginally successful at finding SQL Servers instances on the network. Eventually, I had the idea of running “osql -L” with a packet sniffer running (I used Ethereal), to see how osql was doing it.

Its method was to send out a Broadcast UDP packet on port 1434, with the contents of just a byte of 0x02, to which each server would respond. Sending such a message is quite simple:

Socket socket = new Socket(AddressFamily.InterNetwork, 
              SocketType.Dgram, ProtocolType.Udp );

    socket.SetSocketOption(SocketOptionLevel.Socket, 
              SocketOptionName.Broadcast, 1);
    socket.SetSocketOption(SocketOptionLevel.Socket, 
              SocketOptionName.ReceiveTimeout, 3000);
    




IPEndPoint ep = new IPEndPoint(IPAddress.Broadcast, 1434);
byte[] msg = new byte[] { 0x02 };
socket.SendTo(msg, ep);

It’s vitally important that you set the timeout. Without it, the Receive method will just keep waiting (forever!) until it gets something. However, since we’ll be waiting for responses from an unknown number of servers, we have to decide to give up at some point. I’ve set that point, initially, at 3 seconds. Before I realized that the Broadcast & Timeout options were available (but hidden) on the Socket class, I had this elaborate class which derived from UdpClient and implemented asynchronous receiving.

As it turns out, with the proper options set, getting a response is as simple as you’d hope.

byte[] bytBuffer = new byte[256];
socket.Receive(bytBuffer);

The Receive method will get the response from one server, so we’ll have to put that code in a loop to get all of them. Of course, once we’ve gotten a response, we need to interpret it. For this, I’ve created a simple class called SqlServerInfo, which I’ll explain further in a minute.

After we’ve received, processed and stored the response, we just keep looping until we don’t get a response within the timeout. The downside of using a timeout, is that when it is reached, the Socket throws a SocketException, which means we have to incur the overhead time to process a throw every time we call this method. This is in addition to the timeout delay itself. I was able to find a way to minimize this.

I initially set the timeout to 3 seconds. The problem here was that after each response, I’d call Receive again, and the timeout timer would start over. So the total time for the method would be: the total actual processing time + the timeout + the throw overhead. This was about 5 seconds in my tests. This seems way too long to me — remember, this is something we are going to want to do in the Page_Load of a form. One thing I noticed was that after I send the broadcast message, there would be a short delay as the message went out, the remote servers received it and prepared their responses. However, after that delay, all the responses would come in a pack. So, I decided, after I processed the first response, to reset the timeout to 0.3 seconds. This cut the total time down to about 1-2 seconds, a much more reasonable delay. (However, if there were no servers at all on the network, it would still take 3+ seconds to realize that.)

Now, back to interpreting the response we’ve gotten, which is quite simple. The first three bytes are a byte of 0x05, followed by two bytes giving the length of the rest which is straight ASCII text of pairs of items, separated by semicolons:

data item 1 name ; data item 1 value ; data item 2 name  ; data item 2 value;

or more specifically:

ServerName;DATA001;InstanceName;MSSQLSERVER;IsClustered;No;Version;8.00.194;tcp;1433

To make use of this, we’ll have to convert from a byte array of ASCII characters to a .NET string of UNICODE characters, which the framework is nice enough to provide a method for (although it does bury in under System.Text.ASCIIEncoding.ASCII). Then, separate the parts, and move the the data values to properties where they can be accessed easier.

Of course, while the information provided in the broadcast response is useful, it doesn’t provide one vitally important piece of data: the list of databases on that server. To get that, we need to use more traditional database access methods.

But, to do that, we are going to have to connect to the server, which means a connection string, which means a username & password. SqlServerInfo provides read/write properties for those as well as a boolean IntegratedSecurity option (the other properties are read-only).

Once we’ve established a connection, getting the list of catalogs is a method built right into the OleDbConnection object:

DataTable schemaTable = 
   myConnection.GetOleDbSchemaTable(OleDbSchemaGuid.Catalogs, null);

Using the code

Everything is packaged in the class SqlServerInfo. It has one static method, Seek(), which gets the information about the SQL Server instances on the network, and returns an array of SqlServerInfo objects.

SqlServerInfo[] servers = SqlServerInfo.Seek();

Each SqlServerInfo object contains a number of properties describing that particular MS SQL Server instance. Each of these is a read-only property.

• public string ServerName
• public string InstanceName
• public bool IsClustered
• public string Version
• public int TcpPort
• public string NamedPipe
• public IPAddress Address

InstanceName is typically “MSSQLSERVER”, which is the default if it isn’t given a specific name at installation. Version should be “8.0.xxx” for SQL Server 2000. And TcpPort will typically be 1433.

Note that, although Address is a property, in the current implementation it will always be null — until I can figure a way of finding out what the server’s IP address is. The Socket.Receive method doesn’t say what machine is sending the data — it is just assumed to be the machine you just transmitted to — the naiveté of which is apparent when one sends a broadcast message. (If anyone knows how to get that information out of a Socket, please let me know.)

Next there are four Read/Write properties, which must be set to get any more information out of this class:

• public string UserId
• public string Password
• public bool IntegratedSecurity
• public int TimeOut

These establish how we are going to attempt to connect to that server. IntegratedSecurity defaults to true, and TimeOut defaults to 2 seconds, so if these work for you, you don’t have to do anything more. Setting either UserId or Password sets IntegratedSecurity to false.

The final property retrieves a list of databases available on the server.

• public StringCollection Catalogs

The first time it is called, it will attempt to connect to the server, so the above property needs to be set right.

Finally, there are two methods:

• public bool TestConnection()
• public override string ToString()

TestConnection is just as its name says — it tests if you can connect with the given userID/password.

ToString returns either the ServerName (if the InstanceName is the default) or ServerName / InstanceName. Either way it is what you need to specify as the Data Source in a connection string. As a ToString, you can set the DataSource property of a ListBox or similar control to an array of SqlServerInfo objects, and the appropriate values will be displayed.

SqlServerInfo Data = servers[0];
Console.WriteLine(Data.ToString());
Console.WriteLine("Version:", Data.Version);

Data.IntegratedSecurity = true;
foreach(string Catalog in Data.Catalogs)
{
    Console.WriteLine("    {0}", Catalog);
}

History

• 20-Nov 2005 – v 1.0 Initial release.

      В данной статье рассмотрим два варианта получения доступных в сети SQL серверов.

• С использованием стандартного класса «SqlDataSourceEnumerator» из Microsoft Net. Fraemwork; 
• С использованием WinAPI.

1)      Для получения доступных SQL серверов на локальном компьютере или в сети необходимо воспользоваться классом «SqlDataSourceEnumerator», который обеспечивает доступ к этим сведениям, предоставляя объект «DataTable» с данными обо всех видимых серверах. Для этого необходимо вызвать метод «GetDataSources», который возвращает таблицу «DataTable» со сведениями о доступных серверах:

DataTable dt = System.Data.Sql.SqlDataSourceEnumerator.Instance.GetDataSources()

      Таблица, возвращенная в результате вызова этого метода, содержит следующие столбцы, причем все эти столбцы содержат значения «string».

• «ServerName» – Имя сервера.
• «InstanceName» – Имя экземпляра сервера. Пуст, если сервер выполняется как используемый по умолчанию экземпляр.
• «IsClustered» – Указывает, является ли сервер частью кластера.
• «Version» – Версия сервера.

      Сведения о серверах из списка могут включать или не включать такие дополнительные данные, как «IsClustered» и версия (Version). Это зависит от того, каким образом был получен список. В списках серверов, полученных с помощью службы обозревателя «SQL Server», присутствует больше сведений, чем в списках серверов, найденных с помощью инфраструктуры Windows и содержащих только имена.
      Так же из-за особенностей механизма, используемого «SqlDataSourceEnumerator» для поиска источников данных в сети, этот метод не всегда возвращает полный список доступных серверов, и для последовательных вызовов содержимое списка может изменяться в зависимости от таких факторов, как время ожидания и сетевой трафик. Это может привести к тому, что при двух последовательных вызовах будут получены разные списки. В список входят только серверы, находящиеся в одной сети. Широковещательные пакеты обычно не проходят через маршрутизаторы, поэтому некоторый сервер может отсутствовать в списке, но будет стабильно работать.
      Если вы планируете применять данную функцию, чтобы дать возможность пользователю выбрать сервер из списка, обязательно предоставляйте пользователю возможность ввести отсутствующее в списке имя сервера на случай, если перечисление вернет не все доступные серверы.
      Кроме того, этот метод может выполняться довольно долго, поэтому в ситуациях, когда приоритетным является быстродействие, пользоваться им следует с осторожностью.

      В «SQL Server 2000» данные для «SqlDataSourceEnumerator» предоставляются внутренним образом. Но в версии «SQL Server 2005» эти сведения предоставляются с использованием внешней службы Windows, называемой обозревателем SQL. Применение этой службы разрешено по умолчанию, но администраторы могут ее выключать или запрещать, в результате чего соответствующий экземпляр сервера становится невидимым для указанного класса. Эта служба применяется только в версии «SQL Server 2005» и не оказывает влияния на поведение «SQL Server 2000». Оборудование и программное обеспечение так же могут налагать свои ограничения на возможность поиска экземпляров «SQL Server».
      Ниже представлен пример получения и вывода сокращенной информации обо всех найденных в сети и (или) локальных SQL серверов в элемент управления «ComboBox» и более полной информации в элемент управления «RichTextBox».

//Переменная для хранения информации о 
//найденных серверах.
string ServerInfo = string.Empty;

//Получение доступных SQL серверов.
DataTable dt = System.Data.Sql.SqlDataSourceEnumerator.Instance.GetDataSources();
foreach (DataRow dr in dt.Rows)
{
    //Вывод найденной информации о серверах
    //в элемент управления СomboBox.
    comboBox1.Items.Add(string.Concat(dr["ServerName"], "\", dr["InstanceName"]));

    //Добавление пустой строки после получения 
    //информации о сервере
    foreach (DataColumn col in dt.Columns)
    {
        ServerInfo += String.Format("{0,-15}: {1}", col.ColumnName, dr[col]) + Environment.NewLine;
    }

    //Добавление пустой строки после получения 
    //информации о сервере.
    ServerInfo += Environment.NewLine;                
}

//Вывод найденной информации о серверах
//в элемент управления RichTextBox.
richTextBox1.Text = ServerInfo;

2)      В данном примере необходимо добавить класс «SqlLocator» в листинг формы, где будет выполняться запуск процесса поиска и вывода найденных SQL серверов в сети.

public class SqlLocator
{
[System.Runtime.InteropServices.DllImport("odbc32.dll")]
private static extern short SQLAllocHandle(short hType, IntPtr inputHandle, out IntPtr outputHandle);
[System.Runtime.InteropServices.DllImport("odbc32.dll")]
private static extern short SQLSetEnvAttr(IntPtr henv, int attribute, IntPtr valuePtr, int strLength);
[System.Runtime.InteropServices.DllImport("odbc32.dll")]
private static extern short SQLFreeHandle(short hType, IntPtr handle);
[System.Runtime.InteropServices.DllImport("odbc32.dll", CharSet = System.Runtime.InteropServices.CharSet.Ansi)]
private static extern short SQLBrowseConnect(IntPtr hconn, StringBuilder inString,
 short inStringLength, StringBuilder outString, short outStringLength,
 out short outLengthNeeded);

private const short SQL_HANDLE_ENV = 1;
private const short SQL_HANDLE_DBC = 2;
private const int SQL_ATTR_ODBC_VERSION = 200;
private const int SQL_OV_ODBC3 = 3;
private const short SQL_SUCCESS = 0;

private const short SQL_NEED_DATA = 99;
private const short DEFAULT_RESULT_SIZE = 1024;
private const string SQL_DRIVER_STR = "DRIVER=SQL SERVER";

private SqlLocator() { }

public static string[] GetServers()
{
    string[] retval = null;
    string txt = string.Empty;
    IntPtr henv = IntPtr.Zero;
    IntPtr hconn = IntPtr.Zero;
    StringBuilder inString = new StringBuilder(SQL_DRIVER_STR);
    StringBuilder outString = new StringBuilder(DEFAULT_RESULT_SIZE);
    short inStringLength = (short)inString.Length;
    short lenNeeded = 0;

    try
    {
        if (SQL_SUCCESS == SQLAllocHandle(SQL_HANDLE_ENV, henv, out henv))
        {
            if (SQL_SUCCESS == SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (IntPtr)SQL_OV_ODBC3, 0))
            {
                if (SQL_SUCCESS == SQLAllocHandle(SQL_HANDLE_DBC, henv, out hconn))
                {
                    if (SQL_NEED_DATA == SQLBrowseConnect(hconn, inString, inStringLength, outString,
                     DEFAULT_RESULT_SIZE, out lenNeeded))
                    {
                        if (DEFAULT_RESULT_SIZE < lenNeeded)
                        {
                            outString.Capacity = lenNeeded;
                            if (SQL_NEED_DATA != SQLBrowseConnect(hconn, inString, inStringLength, outString,
                             lenNeeded, out lenNeeded))
                            {
                                throw new ApplicationException("Unabled to aquire SQL Servers from ODBC driver.");
                            }
                        }
                        txt = outString.ToString();
                        int start = txt.IndexOf("{") + 1;
                        int len = txt.IndexOf("}") - start;
                        if ((start > 0) && (len > 0))
                        {
                            txt = txt.Substring(start, len);
                        }
                        else
                        {
                            txt = string.Empty;
                        }
                    }
                }
            }
        }
    }
    catch (Exception ex)
    {                
        #if (DEBUG)
        MessageBox.Show(ex.Message, "Acquire SQL Servier List Error");
        #endif
        txt = string.Empty;
    }
    finally
    {
        if (hconn != IntPtr.Zero)
        {
            SQLFreeHandle(SQL_HANDLE_DBC, hconn);
        }
        if (henv != IntPtr.Zero)
        {
            SQLFreeHandle(SQL_HANDLE_ENV, hconn);
        }
    }

    if (txt.Length > 0)
    {
        retval = txt.Split(",".ToCharArray());
    }

    return retval;
}

     Для получения списка SQL серверов с помощью данного класса необходимо вызвать из него метод «GetServers», который возвращает строковый массив с доступными в сети серверами.

//Предварительно очищаем все элементы управления
//в которые будут выводиться данные
comboBox1.Items.Clear();
richTextBox1.Text = string.Empty;

string[] theAvailableSqlServers = SqlLocator.GetServers();
if (theAvailableSqlServers != null)
{
    comboBox1.DataSource = theAvailableSqlServers;
    foreach (string NameServer in theAvailableSqlServers)
    {
         richTextBox1.Text += NameServer + Environment.NewLine;
    }
}
else
{
    MessageBox.Show("SQL сервера не найдены!");
}

← →
tanya
 
(2005-07-29 15:47)
[0]

Как получить список имён серверов MSSQL, имеющихся в локальной сети (D7,ADO,MSSQL).
Нужно, чтобы пользователь из одного окна мог логиниться к разным базам на разных серверах, но при этом поднимать ADO-шные окна подключения или connectionstring совсем ни к чему. Как бы собрать только список имен серверов?

---

← →
Reindeer Moss Eater ©
 
(2005-07-29 15:52)
[1]

Список зарегистрированных в MSSQL-клиенте MSSQL серверов лежит в реестре. Читай отуда.

---

← →
Fay ©
 
(2005-07-29 15:54)
[2]

2 tanya   (29.07.05 15:47)
1) SQL-DMO
2) NetServerEnum

---

← →
Anatoly Podgoretsky ©
 
(2005-07-29 16:35)
[3]

Все найти нельзя, а что клиенту все равно к какому серверу подключаться, лишь бы подключиться.

---

← →
sniknik ©
 
(2005-07-29 17:05)
[4]

---

← →
AxelBlack
 
(2005-07-29 19:10)
[5]

sniknik ©   (29.07.05 17:05) [4]
+
“SQLOLEDB Enumerator”, хотя он использует NetServerEnum
+
выполнить эту команду с уже законнектенного сервера: “exec master..xp_cmdshell “osql -L””

---

← →
tanya
 
(2005-08-30 18:11)
[6]

---

← →
DiamondShark ©
 
(2005-08-30 22:28)
[7]

---

← →
Sam Stone ©
 
(2005-08-30 23:22)
[8]

А что, пользователи не знают, какой сервер тестовый, а какой рабочий? Или они так часто меняются? Если нет, то можно либо в на каком-либо компе хранить список имеющихся серверов (один раз забить ручками), либо этот список хранить на каждом компе.

---

← →
Anatoly Podgoretsky ©
 
(2005-08-31 00:02)
[9]

tanya   (30.08.05 18:11) [6]
Для этого достаточно держать список в файле, например ИНИ и совсем ни к чему опрашивать сеть. И решишь попутно и другие проблемв с идентификацией, с комментариями, все что посчитаешь нужным. Это позволит иметь удобный пользователю интерфейс.

---

← →
tanya
 
(2005-08-31 11:09)
[10]

---

← →
Nikolay M. ©
 
(2005-08-31 11:46)
[11]

---

← →
paul_k ©
 
(2005-08-31 12:39)
[12]

---

← →
tanya
 
(2005-08-31 12:59)
[13]

---

← →
paul_k ©
 
(2005-08-31 13:05)
[14]

http://www.sql.ru/forum/actualthread.aspx?tid=741&hl=adsi

---

← →
Nikolay M. ©
 
(2005-08-31 13:19)
[15]

---

← →
Anatoly Podgoretsky ©
 
(2005-08-31 13:37)
[16]

---

← →
tanya
 
(2005-08-31 14:02)
[17]

2 Nikolay M. [15]

> Если все так просто, тогда зачем в [10] вопрос о нахождении
> системных БД?

Николай, я в [10] спрашивала о наличии у этих объектов какого-нибудь свойства, определяющего, что это системные базы. Но не уточнила, что спрашиваю про свойства, кроме имени 🙂

---

← →
tanya
 
(2005-08-31 14:25)
[18]

---

← →
Nikolay M. ©
 
(2005-08-31 14:59)
[19]

> tanya   (31.08.05 14:02) [17]
> Николай, я в [10] спрашивала о наличии у этих объектов какого-нибудь
> свойства, определяющего, что это системные базы. Но не уточнила,
> что спрашиваю про свойства, кроме имени 🙂

AFAIK, у базы такого свойства нет.

---

← →
Nikolay M. ©
 
(2005-08-31 14:59)
[20]

> tanya   (31.08.05 14:02) [17]
> Николай, я в [10] спрашивала о наличии у этих объектов какого-нибудь
> свойства, определяющего, что это системные базы. Но не уточнила,
> что спрашиваю про свойства, кроме имени 🙂

AFAIK, у базы такого свойства нет.

---

← →
Anatoly Podgoretsky ©
 
(2005-08-31 15:46)
[21]

tanya   (31.08.05 14:25) [18]
Ну разве про подобное я спорю, ты просто по ходу уточняешь задачу. Если речь про пользователей то это одно, а инструмент для администраторов это другое. Я говорю про первое. Не надо пользователю вываливать список всех доступных серверов, ему лучше дать список только нужного и с комментарием характеристикой.

---

← →
tanya
 
(2005-08-31 19:10)
[22]

---

Сегодня расскажу вам о лучших способах поиска и взлома сервера базы данных MSSQL. Речь пойдет, как о локальных, так и удаленных методах обнаружения серверов MS-SQL.

Еще по теме: Поиск открытых баз данных с помощью поисковиков

Microsoft SQL Server (MS-SQL) — менеджер реляционных баз данных, созданный Microsoft. На большом предприятии или в организации используется несколько баз данных, что часто приводит к проблемам в плане безопасности.

Поиск и взлом MSSQL

Существуют различные методы и инструменты для обнаружения серверов MS-SQL. Вам как пентестеру надо знать все.

Metasploit

Использование Metasploit для поиска серверов MS-SQL — один из лучших удаленных методов. Metasploit — это мощный фреймворк. Подробнее о Metasploit в статье «Как пользоваться Metasploit Framework».

Как вы можете видеть на изображении выше, используя подходящий эксплойт, можно с легкостью найти MSSQL.

Nmap

Следующий метод обнаружить сервер MS-SQL — использование сканера Nmap. Это отличный инструмент для тестирования на проникновение. Этот метод также является удаленным. Просто откройте консоль в Kali и введите команду:

SQLPing

SQLPing — инструмент для ОС Windows, который помогает обнаруживать сервер MS-SQL в сети. Этот инструмент будет полезен любителям Windows. Его можно скачать здесь.

После скачивания, откройте SQLPing. На вкладке «Skan» в левой части окна укажите диапазон IP-адресов.

Кроме того, этот инструмент помогает подобрать имя пользователя и пароль сервера с помощью брутфорса, используя словарь. Указать путь к словарю можно на вкладке «Skan», как показано на изображении выше:

Найти сервер MS-SQL в сети с помощью инструмента SQLPing —  дело плевое.

Nessus

Nessus — бесплатный удаленный сканер. Для поиска и последующего взлома сервера MS-SQL, перейдите на вкладку уязвимостей и установите фильтр для порта 1433, поскольку это порт по умолчанию используется сервером MS-SQL.

После сканирования, Nessus отобразит результат.

PowerUpSQL

PowerUpsql больше подойдет для пентеста локальной сети. Чтобы использовать этот инструмент, откройте Windows PowerShell и введите команды:

Командная строка

Использование командной строки также является локальным, но весьма полезным методом. Это самый простой метод для обнаружения сервера MS-SQL в локальной сети. Вводим одну из команд:

osql -L

Заключение

Это самые эффективные способы обнаружения серверов баз данных MS-SQL в сети как удаленно, так и локально.

Еще по теме: Разграничение прав доступа в базе данных