Рубрика:
Сети /
Сети
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Андрей Бирюков
Как собирать сетевую статистику
Наличие сведений о сетевой статистике может оказаться весьма полезным, так как позволяет оценить состояние сети и запланировать ее модификацию, а также вовремя заметить возникновение проблем. Предлагаем вам несколько способов сбора сетевой статистики и применения полученных данных на практике.
Суть проблем
Современные локальные сети имеют, как правило, довольно сложную структуру и часто являются гетерогенными, то есть состоят из сетевого оборудования различных производителей и разнообразных устройств, выполняющих специальные функции. В связи с этим в сети присутствует разнородный трафик, который необходимо правильно классифицировать, в противном случае существует риск того, что можно пропустить критическое изменение в сетевом трафике определенного вида, что в свою очередь влечет потерю или задержку критически важных для бизнеса данных. После проведения классификации необходимо собрать статистику для каждого класса, для того чтобы иметь представление о том, какие пакеты проходят через сеть, на какие периоды времени приходятся пиковые нагрузки, сколько пакетов теряется или приходит с ошибками и так далее.
Для того чтобы предложить принцип классификации, рассмотрим основы сетевых технологий, в частности, иерархическую модель ISO OSI. Как известно, она делит сетевое взаимодействие на семь уровней:
- Физический
- Канальный
- Сетевой
- Транспортный
- Сеансовый
- Уровень представлений
- Уровень приложений
Рассмотрим все эти уровни по порядку. Работа на физическом уровне нас мало интересует, так как определить, насколько хорошо работает канал, можно лишь с помощью специального оборудования, например тестера. Исключением может являться DSL-оборудование (модемы, DSLAM и т. д.), с помощью встроенных в него функций можно получать информацию о состоянии интерфейса, статистику по коллизиям и другую информацию. Как получить эту информацию по тому или иному конкретному оборудованию, вы можете узнать в документации к соответствующей модели.
В отличие от физического уровня канальный (в англоязычной литературе именующийся Data Link) гораздо более информативен. Его рассмотрим подробнее чуть позже.
Сбор статистики по сетевому и транспортному уровням – основная тема этой сегодня, и большинство примеров будет связано именно с этими уровнями.
Оставшиеся три уровня рассматриваться не будут. Причин этому несколько, во-первых, многообразие различных протоколов, работающих на верхнем уровне модели OSI, во-вторых, связанная с этим многообразием сложность в сборе соответствующей статистики, в частности, отсутствие средств для учета пакетов, отправленных определенным протоколом высокого уровня. Вообще для сбора статистики для определенных протоколов высокого уровня существуют специальные утилиты, созданные самими разработчиками данного приложения.
Определившись с тем, какие статистические данные и для каких протоколов требуется собрать, теперь определимся с тем, для каких устройств что нужно собирать. Как уже упоминалось выше, локальная сеть содержит в себе целый ряд различного оборудования, например сервера, маршрутизаторы, коммутаторы, межсетевые экраны и т. д. Но при этом каждая группа устройств функционирует на определенном уровне модели, маршрутизаторы на сетевом, коммутаторы на канальном, сервера на уровне приложений. Я буду рассматривать сбор статистики на определенных устройствах, для конкретных протоколов.
Статистика на сетевом оборудовании
Сейчас на рынке можно встретить сетевое оборудование от различных производителей, обладающих аналогичным функционалом для своего класса устройств. В связи с этим при рассмотрении примеров я не буду привязываться только к одному производителю, а буду использовать общие для всех производителей стандарты и технологии. Поэтому прежде чем приступить к описанию конкретных примеров, рассмотрим средства сбора статистики.
Syslog
Сообщения Syslog являются средством, с помощью которого устройство сообщает о состоянии запущенных процессов, служб и интерфейсов. Фактически те системные сообщения, создаваемые устройством (также именуемые логами, журналами событий), отправляемые на хост, на котором запущена служба Syslog, (в общем случае это может быть машина, работающая под управлением Linux), c которого уже можно собирать статистику за определенный период. Эти сообщения могут быть как информационные, так и сообщения об ошибках, все зависит от настройки протоколирования на конкретном устройстве. Какую статистику можно собрать с помощью Syslog?
Например, в случае если какой-либо порт отключился и устройство потеряло соединение с определенной сетью. Еще одним примером использования Syslog является журналирование списков доступа Access Lists. Списки доступа определяют, каким хостам и подсетям разрешен доступ к определенным ресурсам посредством заданных протоколов через соответствующие порты. Хорошим тоном при построении ACL является правило «все, что не разрешено, то запрещено». Руководствуясь этим, ваш список доступа должен содержать правило, которое запрещает весь трафик, который не был разрешен (на некотором оборудовании, приоритет правил определяется их очередностью в списке, на другом – присвоенным значением приоретизации). Возвращаясь к задаче сбора статистики, отправляем информацию обо всех запрещенных пакетах, на службу syslog на специально выделенном для этого хосте. Причем можно протоколировать как сведения о пакетах, шедших из Интернета во внутреннюю сеть, так и наоборот. В первом случае мы поможет соберем сведения о попытках несанкционированного проникновения в сеть. Во втором случае большое количество пакетов, исходящих из внутренней сети на закрытые порты, может свидетельствовать о том, что на некоторых машинах пользователей установлено программное обеспечение, несоответствующее корпоративной политике безопасности, и, возможно, есть смысл побеседовать с некоторыми пользователями или администраторами.
Однако кроме сбора статистики по запрещенным пакетам иногда имеет смысл собирать информацию и по разрешенным. Приведу пример. Предположим, при попытке отправить письмо из своей сети, внешнему пользователю, ваш почтовый сервер получил сообщение об ошибке 550 (сервис недоступен) или 450 (сервис временно недоступен), но при этом сервер получателя нормально пингуется. Это может означать, что ваш внешний IP-адрес попал в черные списки сетей, из которых идет рассылка нежелательной почты (спама). Сейчас нередко спам рассылается без ведома владельца компьютера с помощью троянских программ, которые, заразив машину, превращают ее небольшой SMTP-сервер, c которого начинают автоматически рассылать спам во внешнюю сеть. Для того чтобы определить зараженную рабочую станцию, достаточно просто посмотреть в файле журнала Syslog, с какого узла были отправлены SMTP-сообщения на заблокировавший сервер. Вообще лучше всего запретить соединения по 25 порту всем узлам, кроме корпоративного почтового сервера, но, к сожалению, это, как правило, не делается, хотя следовало бы.
Данная служба использует протокол UDP, также она реализована практически на всех моделях современного сетевого оборудования.
Служба SNMP
Другое средство – это служба SNMP, которая позволяет не только получать информацию об устройстве, но и управлять им. С его помощью можно получать сведения о количестве полученных и потерянных пакетов на интерфейсе, состоянии различных протоколов динамической маршрутизации. Но для более удобного визуального представления можно воспользоваться специальными приложениями для сбора статистики с помощью SNMP. В качестве средства визуализации статистики лучше всего использовать программы MRTG [1] для Linux/FreeBSD (см. рис. 1), а в случае Windows PRTG [2].
Рисунок 1. Статистика, построенная с помощью MRTG
Данные программы просты в использовании, для их работы достаточно указать лишь IP-адрес устройства и community.
Итак, начнем с коммутаторов. Какую статистическую информацию можно получить с этих устройств? Прежде всего с помощью SNMP и MRTG можно собирать и визуализировать данные о состоянии интерфейсов. На основании этих сведений можно делать выводы о степени загруженности каналов, разнице между объемом отправленных и полученных пакетов. Предвижу вопрос читателей о том, как эта информация может пригодиться? К примеру, вы можете составить представление о штатной нагрузке на сеть, в случае ее непредвиденного роста, начать поиск источника трафика до того, как сеть окажется полностью неработоспособной.
MRTG
Следующей группой устройств, о которой хотелось бы рассказать, являются маршрутизаторы. По аналогии с коммутаторами, с маршрутизаторов можно собирать статистику с помощью MRTG. Однако эти устройства выполняют также целый ряд функций сетевого уровня, которые могут представлять интерес для сбора статистики. Например, уже упоминавшиеся протоколы динамической маршрутизации: RIP, OSPF, BGP. Все эти протоколы работают на сетевом (L3) уровне и обрабатываются маршрутизаторами. Получить статистическую информацию по состоянию пакетов для определенного протокола маршрутизации можно с помощью средств SNMP, обратившись к соответствующей ветке и применив базу MIB данного производителя оборудования.
Итак, с помощью приведенных выше средств, можно осуществить сбор статистики на сетевом оборудовании, которая затем может оказаться полезной при обнаружении различных проблем, возникающих в локальной сети.
Мониторинг серверов
Выше рассматривались примеры сбора статистики на маршрутизаторах и коммутаторах, устройствах, функционирующих на нижних уровнях эталонной модели OSI. Сервера и рабочие станции ориентированы на верхние уровни, прежде всего на уровень приложений, который в этой статье не рассматривается. Однако возможны ситуации, в которых требуется сетевая статистика по протоколам нижнего уровня. Например, в случае, если сервер выполняет роль маршрутизатора, связывая несколько сетей, подключенных к различным интерфейсам. Собирать статистику можно также несколькими способами.
Во-первых, для того чтобы осуществлять сбор статистики на сетевом интерфейсе сервера, можно воспользоваться штатным средством Windows – счетчиками производительности (см. рис. 2).
Рисунок 2. Результат работы счетчика производительности
Запустить эти счетчики можно из консоли «Панель управления», далее «Администрирование» и «Производительность». В этой консоли имеется несколько средств для наблюдения за состоянием системы: «Системный монитор», «Журналы счетчиков», «Журналы трассировки» и «Оповещения».
«Системный монитор» представляет данные о состоянии различных устройств и приложений в виде графика, строящегося в режиме реального времени.
«Журналы счетчиков» – это средство, аналогичное «Системному монитору» с той лишь разницей, что здесь результаты мониторинга не выводятся на экран в виде графика, а сохраняются в файле.
«Оповещения» – это средство, позволяющее системе реагировать на определенные события. Например, в случае если количество пакетов, поступивших на сетевой интерфейс в течение текущего сеанса работы, превосходит определенное пороговое значение, то можно сделать запись в журнале событий (Event Log), отправить сообщение по сети, запустить журнал производительности или приложение. Это средство может быть полезно в случае, если на интерфейс поступает большое количество пакетов с ошибками или неопознанных пакетов, в случае превышении порогового значения, например 10000, можно отправлять сообщение на экран с указанием времени и даты, а также делать запись в журнал событий. С помощью этих оповещений можно поставить в известность системного администратора, который сможет предотвратить возникновение проблем еще до их появления.
Другим средством, с помощью которого можно собирать сетевую статистику, является сценарий Windows Script Host, который будет собирать информацию о количестве полученных и переданных пакетов, а также о пакетах, содержащих ошибки.
Механизм действия такого сценария довольно прост, оригинальную версию можно найти в источнике [5]. Но я предлагаю его немного модифицировать, для того чтобы сделать пригодным для практического использования. Для того чтобы автоматизировать процесс сбора сведений, я буду собирать данные в документ формата Excel, в котором первая страница посвящена статистике по TCP, вторая – по UDP и третья – по IP. При этом получать будем следующие данные.
Для TCP:
- Connection Failures – счетчик неудачных соединений;
- Connection Active Connection Established – количество активных соединений;
- Connection Passive – количество пассивных соединений;
- Connection Reset Segments Per Second – отброшено сегментов за секунду;
- Segments Received Per Second – получено сегментов за секунду;
- Segments Retransmited Per Second – транслировано сегментов за секунду;
- Segments Sent Per Second – отправлено сегментов за секунду.
Для UDP:
- Datagrams No Port Per Second – получено датаграмм на неверный порт в секунду;
- Datagrams Per Second – отправлено датаграмм в секунду;
- Datagrams Received Errors – получено с ошибками;
- Datagrams Received Per Second – датаграмм получено в секунду.
Для IP:
- Datagrams Forwarded Per Second – датаграмм передано за секунду;
- Datagrams Discarded – отклонено;
- Datagrams Received Header Errors – получено с ошибками в заголовке;
- Datagrams Received Per Second – датаграмм получено за секунду;
- Datagrams Received Unknown port – получено на неизвестный порт;
- Datagrams Sent Per Second – датаграмм отправлено за секунду;
- Fragments Per Second – всего фрагментов (частей датаграмм) за секунду;
- Fragments Failures – фрагменты с ошибками;
- Fragments Datagrams Per Second – фрагменты датаграмм за секунду;
- Fragments Reassembly Failures – неудачные попытки пересборки фрагментов;
- Fragments Created Per Second – создано фрагментов за секунду;
- Fragments Reassembly Per Second – фрагментов пересобрано за секунду;
- Fragments received Per Second – получено фрагментов за секунду.
Эта статистика нуждается в некотором пояснении. Для протокола TCP единицей измерения являются сегменты, также здесь фигурируют соединения (Connections), так как данный протокол использует при работе установку соединения. Для UDP в контексте данного сценария единицей измерения является датаграмма. А для протокола IP кроме датаграмм также учитываются и их фрагменты, что позволяет учитывать также статистику по обработке частей данных, передаваемых этим протоколом.
Следует отметить, что в источнике [5] также имеются примеры сценариев для сбора статистики по IPSec и по протоколам IP телефонии. Так что при необходимости их тоже можно включить в приведенный далее сценарий.
Далее приведу пример сценария, выполняющего все эти действия с необходимыми комментариями.
Листинг 1. Сценарий, собирающий статистику по протоколам
strComputer = "." // используется локальная машина
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
set objRefresher = CreateObject("WbemScripting.SWbemRefresher")
// объекты, необходимые для запуска сценария
Set colItems = objRefresher.AddEnum _
(objWMIService, "Win32_PerfFormattedData_TCPIP_TCP").objectSet
// объект, с помощью которого собираются данные по TCP
Set colItems1 = objRefresher.AddEnum _
(objWMIService, "Win32_PerfFormattedData_TCPIP_UDP").objectSet
// объект, с помощью которого собираются данные по UDP
Set colItems2 = objRefresher.AddEnum _
(objWMIService, "Win32_PerfFormattedData_TCPIP_IP").objectSet
// объект, с помощью которого собираются данные по IP
objRefresher.Refresh // обновление счетчиков
Const xlDiagonalDown = 5
Const xlDiagonalUp = 6
Const xlNone = -4142
Const xlContinuous = 1
Const xlThin = 4
Const xlThick = 4
Const xlEdgeLeft = 7
Const xlEdgeTop = 8
Const xlEdgeBottom = 9
Const xlEdgeRight = 10
Const xlInsideVertical = 11
Const xlInsideHorizontal = 12
Const xlAutomatic = -4105
Const xlCenter = -4108
Const ForReading = 1
Const ForWriting = 5
// набор констант, необходимых для создания документа Excel
Set oE = CreateObject("Excel.Application")
oE.Visible = false
oE.Workbooks.Add
// создаем новый документ Excel
oE.DisplayAlerts = False
'oE.Sheets(4).Delete
oE.DisplayAlerts = True
// определяем количество страниц
Set s = oE.Sheets(1)
s.Name = "Статистика по TCP"
// название для первой страницы
Set s1 = oE.Sheets(2)
s1.Name = "Статистика по UDP"
// название для второй страницы
Set s2 = oE.Sheets(3)
s2.Name = "Статистика по IP"
// название для третьей страницы
// далее перечисляются названия столбцов
s.Rows(1).RowHeight = 2 * s.StandardHeight
s.Cells(1,1) = "Статистика по протоколу TCP"
s.Cells(2,1) = "Время"
s.Cells(2,2) = "Connection Failures"
s.Cells(2,3) = "Connection Active"
s.Cells(2,4) = "Connection Established"
s.Cells(2,5) = "Connection Passive"
s.Cells(2,6) = "Connection Reset"
s.Cells(2,7) = "Segments Per Second"
s.Cells(2,8) = "Segments Received Per Second"
s.Cells(2,9) = "Segments Retransmited Per Second"
s.Cells(2,10) = "Segments Sent Per Second"
s.Columns("A:B").Columns.AutoFit
With s.Range("A1:B1")
.MergeCells = True
.VerticalAlignment = xlCenter
.HorizontalAlignment = xlCenter
.Font.Size=14
End With
s1.Rows(1).RowHeight = 2 * s1.StandardHeight
s1.Cells(1,1) = "Статистика по протоколу UDP"
s1.Cells(2,1) = "Время"
s1.Cells(2,2) = "Datagrams No Port Per Second"
s1.Cells(2,3) = "Datagrams Per Second"
s1.Cells(2,4) = "Datagrams Received Errors"
s1.Cells(2,5) = "Datagrams Received Per Second"
s1.Columns("A:B").Columns.AutoFit
With s1.Range("A1:B1")
.MergeCells = True
.VerticalAlignment = xlCenter
.HorizontalAlignment = xlCenter
.Font.Size=14
End With
s2.Rows(1).RowHeight = 2 * s2.StandardHeight
s2.Cells(1,1) = "Статистика по протоколу IP"
s2.Cells(2,1) = "Время"
s2.Cells(2,2) = "Datagrams Forwarded Per Second"
s2.Cells(2,3) = "Datagrams Discarded"
s2.Cells(2,4) = "Datagrams Received Header Errors"
s2.Cells(2,5) = "Datagrams Received Per Second"
s2.Cells(2,6) = "Datagrams Received Unknown port"
s2.Cells(2,7) = "Datagrams Sent Per Second"
s2.Cells(2,8) = "Fragments Per Second"
s2.Cells(2,9) = "Fragments Failures"
s2.Cells(2,10) = "Fragments Datagrams Per Second"
s2.Cells(2,11) = "Fragments Reassembly Failures"
s2.Cells(2,12) = "Fragments Created Per Second"
s2.Cells(2,13) = "Fragments Reassembly Per Second"
s2.Cells(2,14) = "Fragments received Per Second"
s2.Columns("A:B").Columns.AutoFit
With s2.Range("A1:B1")
.MergeCells = True
.VerticalAlignment = xlCenter
.HorizontalAlignment = xlCenter
.Font.Size=14
End With
// в данном цикле производится сбор статистических данных
f=3 // начинается заполнение с третьей строки
For i = 1 to 5
// в данном примере пять итераций, в реальном сценарии необходимо намного больше
// каждый элемент для статистики по TCP
For Each objItem in colItems
// дата и времы занесения записи
s.Cells(f,1)=Now
s.Cells(f,2)=objItem.ConnectionFailures
s.Cells(f,3)=objItem.ConnectionsActive
s.Cells(f,4)=objItem.ConnectionsEstablished
s.Cells(f,5)=objItem.ConnectionsPassive
s.Cells(f,6)=objItem.ConnectionsReset
s.Cells(f,7)=objItem.SegmentsPersec
s.Cells(f,8)=objItem.SegmentsReceivedPersec
s.Cells(f,9)= ?
objItem.SegmentsRetransmittedPersec
s.Cells(f,10)=objItem.SegmentsSentPersec
Next
// каждый элемент для статистики по UDP
For Each objItem in colItems1
s1.Cells(f,1)=Now
s1.Cells(f,2)=objItem.DatagramsNoPortPersec
s1.Cells(f,3)=objItem.DatagramsPersec
s1.Cells(f,4)=objItem.DatagramsReceivedErrors
s1.Cells(f,5)=objItem.DatagramsReceivedPersec
s1.Cells(f,6)=objItem.DatagramsSentPersec
Next
// каждый элемент для статистики по IP
For Each objItem in colItems2
s2.Cells(f,1)=Now
s2.Cells(f,2)=objItem.DatagramsForwardedPersec
s2.Cells(f,3)=objItem.DatagramsOutboundDiscarded
s2.Cells(f,4)=objItem.DatagramsOutboundNoRoute
s2.Cells(f,5)=objItem.DatagramsPersec
s2.Cells(f,6)=objItem.DatagramsReceivedAddressErrors
s2.Cells(f,7)=objItem.DatagramsReceivedDeliveredPersec
s2.Cells(f,8)=objItem.DatagramsReceivedDiscarded
s2.Cells(f,9)=objItem.DatagramsReceivedHeaderErrors
s2.Cells(f,10)=objItem.DatagramsReceivedPersec
s2.Cells(f,11)=objItem.DatagramsReceivedUnknownProtocol
s2.Cells(f,12)=objItem.DatagramsSentPersec
s2.Cells(f,13)=objItem.FragmentationFailures
s2.Cells(f,14)=objItem.FragmentedDatagramsPersec
s2.Cells(f,15)=objItem.FragmentsReassembledPersec
s2.Cells(f,16)=objItem.FragmentsReceivedPersec
Next
WScript.Sleep 60000 // пауза на 60 секунд
objRefresher.Refresh
f=f+1
Next
oE.DisplayAlerts = False
// сохранение документа Excel
oE.ActiveWorkbook.SaveAs "result"
oE.DisplayAlerts = True
oE.Quit // закрытие Excel
Рекомендуемый способ развертывания данного сценария – это запуск на длительный период (порядка суток), за который собираются статистические сведения о протоколах на интерфейсе.
Какие данные можно получить с его помощью? Например, количество IP-пакетов, пришедших на ошибочный порт, слишком большое соотношение с легитимными пакетами может говорить о том, что какое-то приложение отправляет свои пакеты не по адресу. То есть можно предположить, что какое-то приложение пытается выйти в Интернет, вопреки корпоративной политике безопасности. Возможно, это троян. Большое количество пакетов с ошибками свидетельствует о наличии источника помех в сети (например, мощный электроприбор рядом с сетевым кабелем). Большое количество пассивных TCP-соединений также не слишком хорошо сказывается на пропускной способности сети.
Таким образом, приведенный WSH-сценарий может оказать помощь в поиске проблем на указанном хосте.
- http://www.mrtg.org – описание и дистрибутив MRTG.
- http://www.securitylab.ru/software/download/?page=267148&el=2596383&file=http://download2.paessler.com/download/prtg.zip – дистрибутив PRTG.
- К. Пакет. Создание сетей удаленного доступа Cisco. Cisco Press.
- D. Hucaby Building Cisco Multi Switching Networks. Cisco Press.
- http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true – коллекция WSH-сценариев для мониторинга состояния сети.
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|