Безопасное управление и отчетность

«Хотите записать данные? Тогда попробуйте сначала их прочитать». Простая мысль, не так ли? Любой специалист по сетевой безопасности наверняка высказывал ее хотя бы однажды. И все же запись и чтение информации, поступающей со ста с лишним устройств, представляет собой сложную задачу. Какие записи являются наиболее важными? Как отделить важные сообщения от рутинных уведомлений? Как обеспечить защиту данных во время передачи? Как синхронизировать метки времени, если множество устройств одновременно регистрируют атаку? Какую информацию нужно предоставлять правоохранительным органам, ведущим расследование? Как справиться с огромным объемом данных, которые генерирует большая сеть? Для эффективного управления журналами событий (лог-файлами) вам нужно найти ответ на каждый из этих вопросов. На уровне сетевого управления можно предложить другой набор вопросов. Как управлять устройством в безопасном режиме? Как передавать содержание на серверы общего доступа, чтобы исключить искажение данных во время передачи? Как отслеживать изменения в устройствах, чтобы исправить положение в случае атаки или сетевого сбоя? С архитектурной точки зрения, первым шагом в реализации любой стратегии управления и отчетности является управление сетевыми системами по выделенной сети (out-of-band — OOB). Как видно из названия, это означает, что для управления используется сеть, по которой не передается производственный трафик. По возможности, устройства должны иметь прямой локальный доступ к такой сети. Если такой возможности нет (по географическим или системным причинам), подключение устройств должно происходить через производственную сеть по частному зашифрованному туннелю. Этот туннель должен быть настроен на связь только через определенные порты, предназначенные для управления и отчетности.

Кроме того, туннель должен блокироваться так, чтобы открывать или закрывать его могли только определенные хосты. Убедитесь в том, что дополнительная сеть (OOB) не имеет своих собственных проблем с безопасностью. Более подробную информацию можно получить в разделе «Модуль управления». После развертывания сети управления ООВ работа с лог-файлами и отчетностью становится более простой и логичной. При этом большинство сетевых устройств будут генерировать системные данные (syslog data), имеющие огромную ценность для диагностики сетевых проблем и анализа угроз безопасности. Эти данные можно передавать одному или нескольким хостам, отвечающим за анализ системных данных в сети управления. В зависимости от устройства, можно выбирать разные уровни регистрации данных, чтобы в лог-файлы поступало необходимое количество информации. Кроме того, вам необходимо помечать данные, относящиеся к тому или иному устройству, чтобы обеспечить точное и детальное рассмотрение и анализ данных. К примеру, во время атаки данные, предоставляемые коммутаторами Уровня 2, могут быть не столь интересны, как данные, предоставляемые системой обнаружения атак (IDS). Специализированные приложения, такие как IDS, часто пользуются собственными протоколами для передачи уведомлений об атаках. Обычно данные подобного типа должны сохраняться на отдельных хостах управления, которые лучше приспособлены для обработки таких уведомлений. Обобщение данных об атаке может дать представление об общем состоянии безопасности сети. Чтобы синхронизировать лог-сообщения о времени, необходимо синхронизировать системное время на хостах и сетевых устройствах. Точное время на всех устройствах можно поддерживать с помощью протокола сетевого времени NTP (Network Time Protocol), если устройства его поддерживают. При отражении атак счет времени идет на секунды, и поэтому очень важно определить точную последовательность событий.

При управлении, к которому в настоящем документе мы относим все, что делает с устройством администратор, за исключением отчетности и записей в лог-файлы, существуют другие проблемы и решения.

Так же, как и в случае с записями в лог-файлы и отчетностью, сеть ООВ позволяет передавать информацию в контролируемой защищенной среде, где ее невозможно исказить. И все же, если есть возможность использовать дополнительные средства защиты, такие как SSL (secure socket layer) или SSH (secure shell), то они позволяют повысить уровень защищенности. К протоколу управления SNMP нужно относиться с величайшей осторожностью, так как этот протокол имеет свои точки уязвимости. Подумайте о том, чтобы предоставить доступ к устройствам по SNMP только на чтение. При этом к паролю для доступа к переменным SNMP (SNMP community string) следует относиться с таким же вниманием, как к корневому паролю на критически важном Unix-хосте.

Управление изменениями конфигурации также имеет отношение к безопасности. Когда сеть подвергается атаке, очень важно знать состояние критически важных сетевых устройств и сроки их последней модификации. План управления изменениями конфигурации должен быть составной частью вашей политики безопасности. Как минимум, следует записывать все изменения с помощью имеющихся на устройствах систем аутентификации и архивировать конфигурации через FTP или TFTP.