Протокол snmp методы сетевых атак и защиты. Протокол snmp. SNMP - удобный протокол

Delphi , Интернет и Сети, Протоколы

Все серьезные системы управления сетями используют для своей работы простой сетевой протокол управления (Simple Network Management Protocol, SNMP). На самом деле SNMP - это не просто протокол, а целая технология, призванная обеспечить управление и контроль за устройствами и приложениями в сети. С ее помощью можно контролировать абсолютно любые устройства, подключенные к компьютерной сети, например датчики пожаротушения или даже светофоры. Разумеется, SNMP можно использовать (и это активно делают) для управления сетевыми компонентами: концентраторами, серверами, маршрутизаторами и т. п. Пользуясь информацией SNMP (такой, как показатель числа пакетов в секунду и коэффициент сетевых ошибок), сетевые администраторы могут более просто управлять производительностью сети и обнаруживать и решать сетевые проблемы.

Три составляющие части технологии SNMP: структура управляющей информации (Structure of Management Information, SMI) базы управляющей информации (Management Information Base, MIB) сам протокол SNMP

Модель управления SNMP

Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают, и делают эту информацию доступной для систем управления сетями (network management systems - NMS) с помощью протокола SNMP.

Протокол SNMP v1

SNMP реализован в 1988 практически во всех широко распространенных сетевых средах: TCP/IP, IPX/SPX, AppleTalk и др. Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой Административной Базе Данных (MIB - Management Information Base). SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Этот набор включает следующие операции:

• get-request Используется для запроса одного или более параметров MIB
• get-next-request Используется для последовательного чтения значений. Обычно используется для чтения значений из таблиц. После запроса первой строки при помощи get-request get-next-request используют для чтения оставшихся строк таблицы
• set-request Используется для установки значения одной или более переменных MIB
• get-response Возвращает ответ на запрос get-request, get-next-request или set-request
• trap Уведомительное сообщение о событиях типа cold или warm restart или "падении" некоторого link"а.

Для того, чтобы проконтролировать работу некоторого устройства сети, необходимо просто получить доступ к его MIB, которая постоянно обновляется самим устройством, и проанализировать значения некоторых переменных.

Формат сообщений

Сообщения SNMP состоят из 2 частей: имени сообщества (community name) и данных (data). Имя сообщества назначает среду доступа для набора NMS, которые используют это имя. Информационная часть сообщения содержит специфичную операцию SNMP (get, set, и т.д.) и связанные с ней операнды. Операнды обозначают реализации об"екта, которые включены в данную транзакцию SNMP.

Structure of Managment Information. RFC 1208

Определяет логику адресации информации при взаимодействии агентов и менеджеров SNMP. Синтиксис описывается абстрактными правилами Abstract Syntax Notation One, ASN.1.

Managment Information Base (MIB, MIB-II). RFC 1213

MIB представляет из себя набор переменных, характеризующих состояние объекта управления. Эти переменные могут отражать такие параметры, как количество пакетов, обработанных устройством, состояние его интерфейсов, время функционирования устройства и т.п. Каждый производитель сетевого оборудования, помимо стандартных переменных, включает в MIB какие-либо параметры, специфичные для данного устройства (в поддерево private enterprise).

Как происходит адресация в MIB к некоторой ее переменной?

По своей структуре MIB представляет из себя дерево.Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root.

Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками.

Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.

Тестирование сети с помощью SNMP

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

Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1.

Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:

• отсутствие результата
• успех
• выполняется
• не поддерживается
• невозможно запустить
• прекращен
• неудачное завершение

И во-вторых, значение переменной ifExtnsTestCode (1.3.6.1.2.1.12.2.1.6) будет содержать идентификатор переменной MIB, содержащей результат теста. Результат теста определен как временной интервал в 100-наносекундных единицах между началом передачи тестового пакета и обнаружением коллизий в несущей. В принципе, на основании данного значения можно определить требуемое расстояние.

Фундаментальным новшеством в SNMPv2 является то, что элемент администрирования сети может работать в качестве менеджера, агента или менеджера и агента одновременно. Данная концепция дает возможность пользователям применять SNMP в иерархической структуре, в которой локальные менеджеры отчитываются перед менеджерами среднего звена, которые, в свою очередь, контролируются менеджером высшего уровня. Немало места отводится проблемам защищенности SNMP, пожалуй, самой уязвимой точки протокола.

Безопасность SNMP. RFC 1352.

Один из наиболее заметных недостатков SNMP v1 - отсутствие развитой системы защиты данных на уровне, необходимом для сетей масштаба предприятия.

Как сказал Mike Warfield: "SNMP stands for Security Not My Problem".

В SNMPv1 защита административной информации трактовалась слишком упрощенно: она базировалась на использовании коллективного имени (Community Name), которое, находясь в заголовке SNMP, несло в себе все возможности защиты сообщений. Данное средство (известное под названием тривиальный протокол) требовало, чтобы программа-агент и менеджер опознали одно и то же коллективное имя, прежде чем продолжить выполнение операций сетевого администрирования. В результате многие администраторы сетей ограничивались в своей работе только функциями мониторинга, запрещая выдачу команды SET, способной изменять параметры конфигурации удаленного устройства. Это привело к тому, что пользователи избегали команд SET: такое примитивное средство защиты, как коллективное имя, могло дать возможность лицам, не наделенным соответствующими полномочиями, изменять параметры, о чем пользователи могли даже и не узнать. К тому же вся критически важная информация передавалась в открытом виде,поэтому в интернете доступен даже snmp sniffer

В связи с этим были разработаны предложения по совершенствованию защиты в рамках SNMPv1, представленные в июле 1992 г.; они составили основу структуры защиты для SNMPv2.

Стандартами защиты SNMPv2 определяются методы аутентификации (DAP - Digest Authentication Protocol) и обеспечения конфиденциальности (SPP -Symmetric Privacy Protocol) информации административного характера. В основе лежит концепция участника (party) - уникального набора параметров защиты, который может включать местоположение сети, протоколы аутентификации и обеспечения конфиденциальности, используемые между агентом и менеджером.

Проблемы внедрения SNMPv2

SNMPv2 сулит выгоды в плане защиты и производительности, что немаловажно для пользователей. Но некоторые компании наверняка предложат свои собственные идеи, особенно в части защиты и связей между менеджерами. Кроме того, фирмы, расширившие функциональные возможности своих баз данных MIB в средах с SNMPv1, вряд ли будут спешить с выпуском продуктов под SNMPv2.

Несомненно,пользователи захотят иметь продукты на базе SNMPv2. Но дело в том, что многие уже вложили слишком большие средства в версию SNMPv1, чтобы просто выбросить ее и начать все с нуля. Авторы SNMPv2 предвидели это и исходили из постепенности перехода на новую технологию. Предусмотрены два способа сохранения SNMPv1: использование уполномоченных агентов и двуязычных менеджеров. Уполномоченный агент выполняет преобразование форматов SNMPv1 в сообщения SNMPv2 и обратно.

Другой вариант - двуязычный менеджер, который одновременно поддерживает оба протокола (SNMPv1 и SNMPv2) и не требует преобразований. Двуязычный менеджер SNMP определяет, с каким форматом работает агент - версии 1 или версии 2, и общается на соответствующем диалекте. Таким образом, выбор версии протокола должен быть прозрачен для принимающих устройств.

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

Доступные реализации агентов и менеджеров

http://www.microsoft.com/smsmgmt/
MS SMS Netmon

http://www.winfiles.com/apps/98/net-manage.html
куча разнообразных агентов и менеджеров для Win95.

Epilogue предлагает ПО, реализующее поддержку SNMP, включающую:

• Envoy, Epilogue"s compact, fast, portable SNMP solution for OEMs
• Emissary, an SNMP MIB compiler that allows SNMP implementors to extend standard SNMP variables to support extensions to the MIBs in each managed device;
• Ambassador, a complete, portable implementation of the RMON (FastEthernet) remote monitoring agent.
• The IBM Netview for AIX feature of SystemView provides distributed or centralized management of large heterogeneous networks.
• ACE*COMM WinSNMP supports SNMPv1 & SNMPv2u in v2.0 of its industry-leading Win16 and Win32 WinSNMP implementations.
• Digital Unix POLYCENTER Manager on NetView provides client/server management of multivendor enterprise networks.
• The PowerFlag tool - агент для UPS MIB источников бесперебойного питания компании Victron B.V.
• WS_Ping ProPack v.2.10 позволяет просматривать MIB таблицы, указывать поддеревья. Для скачавания свежих версий с сервера Ipswitch можно использовать следующие данные:
• User Name: 0000037181
• Password: CQWSC
• Serial Number: WP-101333
• Openly-Available Implementations
• CMU SNMP agent (source)
  • an agent that support both SNMPv1 and SNMPv2u
  • a number command line based applications that support both SNMPv1 and SNMPv2u.
  • Carnegie-Mellon University SNMP Development Kit supporting SNMPv1/v2
• NetSCARF is a Network Statistics Collection and Reporting Facility. It allows ISPs to collect and report data about their part of the Internet, supports both SNMP version 1 and USEC.
• Scotty is a network management extension for the Tool Command Language (Tcl) which includes a portable implementation of the SNMPv1, SNMPv2c and SNMPv2u protocol. The Scotty Tcl extension includes the network management platform (Tkined) which provides a MIB browser, a network map editor as well as status monitoring, troubleshooting, network discovery and event filtering scripts.
• snmptcp v1.3 is a extensible platform for management applications which seemlessly implements SNMPv1, SNMPv2c, and SNMPv2u.
• The package runs under the X Window System on UNIX and is built from Tool Command Language (Tcl7.3/Tk3.6).In addition to a MIB compiler, the package contains some minimal applications for a number of standard MIB modules.

Атака на Windows SNMP.

Cервисы работают на следующих UDP портах (/etc/services)

• snmp 161/udp snmp
• snmp-trap 162/udp snmp

Интересные SMI Network Management Private Enterprise Codes:

Prefix: 1.3.6.1.4.1.

• 2 IBM
• 4 Unix
• 9 cisco
• 32 Santa Cruz Operation
• 42 Sun Microsystems

Небольшое распространение сканнеров UDP портов под Windows, SNMP менеджеров, а также отсутствие знаний о самом протоколе является, по всей видимости, единственной причиной малочисленности атак на устройства под управление SNMP v1, так как в реализациях этого протокола в некоторых операционные системы допущены серьезные ошибки. Подтверждения этому то и дело появляются в списках рассылки bugtraq

Уязвимость в стандартной конфиругации Windows NT SNMP Сервиса.

Позволяет удаленно конфигурировать сетевые парамерты, которые влияют на безопасность и правильное функционирования системы (если администратор сам запустил SNMP Service)

При конфигурации по умолчанию, SNMP service отвечает на стандартное community (имя) "public", которое обладает права на чтение и запись. Community - это имя, которое обладает такими же функциями, как логин и пароль в системах.

Протокол SNMP предоставляет два уровня полномочий: read-only and read-write, однако до выхода SP4 Windows NT SNMP Service не позволял конфигурировать communities по доступу, отличному от read-write!

Если попытать обезопасить SNMP Service путем переименования community для доступа, то система останется незащищенной от крякера, имеющего аккаунт на машине, так как параметры SNMP Service находятся в регистри и доступны всем пользователям на чтение. Также Windows NT SNMP Service обладает возможностью ограничить доступ для списков IP-адресов. На первый взгляд это позволяет защититься от атак неизвестных систем, однако это не является проблемой для крякеров (что необходимо понимать любому администратору), так как протокол SNMP использует UDP протокол для обмена информацией, а он является протоколом без установления соединения, поэтому возможна подмена исходящего адреса (но для этого придется переработать исходники SNMP менеджеров под Unix и изучить UDP spoofing)

SNMP "set" операции (позволяющие менять значение переменных) могут быть произведены с подменой обратного адреса на любой, так как ответ не нужен. Однако если включено ограничение доверенных IP адресов, но придется найти аккаунт на атакуемой системе и извлечь доверенную информацию из регистри.

Благодаря сконфигурированному по умолчанию Windows NT SNMP Сервису мы можем извлечь с помощью SNMP менеджера следующую информацию:

• the LAN Manager domain name
• a list of users
• a list of shares
• a list of running services

1. Открыть HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents
2. найти значение, которое содержит SOFTWARE\Microsoft\LANManagerMIB2Agent\CurrentVersion
3. и удалить его.

• a list of active TCP connections
• a list of active UDP connections
• a list of network interfaces and their associated IP and hardware addresses
• the IP routing table and the ARP table as well as a number of networking performance statistics.

Устанавливая переменные, крякер может модифицировать таблицу роуминга, ARP таблицу, выключить сетевые интерфейсы, сбить существенные сетевые параметры типа default IP, время жизни пакетов (TTL), IP forwarding (позволит крякеру перенаправлять сетевой трафик). Это особенно опасно, если атакуемая машина является фаерволом.

За примерами далеко ходить не надо, например, если машина является domain controller или server, но получить список всех пользователей в домене можно командой C:\NTRESKIT>snmputil walk public .1.3.6.1.4.1.77.1.2.25

Если вам хочется удалить все записи в базе данных WINS (что приведет к полному отказу WinNT), то для этого необходимо выполнить ~$snmpset -v 1192.178.16.2 public .1.3.6.1.4.1.311.1.2.5.3.0 a 192.178.16.2 из набора CMU SNMP development kit under Unix.

Также есть очень любопытная деталь при установки SNMP community names в Windows NT 4.0 (SP3). Если сервис включен, а имена не сконфигурированы, то любое имя будет давать read/write привилегии. Как оказалось, это указано еще в спецификации SNMP (RFC 1157)!

Четвертый СервисПак(SP4) предоставляет следующее решение проблемы: добавление контроля доступа community как READ ONLY,READ WRITE или READE CREATE. Однако по умолчанию SP4 устанавливает READ CREATE доступ, который все еще позволяет атаковать машины. Микрософт явно заботиться об удобстве WinNT для хакеров:)

Проблема в OS Solaris версии до 2.6.

Исходя из ISS Security Advisory (November 2nd, 1998), в агенте SNMP, который по умолчанию запущен в этой системе, существуют реальные угрозы получить доступ на уровне рута, манипулировать процессами и параметрами машины.

Для доступа к MIB-информации существует скрытая "undocumented community string", которая позволит атакующему изменить большинство системных параметров.

К сожалению, само это community не называется, однако ISS Internet Scanner и ISS RealSecure real-time intrusion detection могут детектировать эту проблемы, т.е. посмотреть можно и в их исходниках

Статья Описание протокола SNMP (Simple Network Management Protocol) раздела Интернет и Сети Протоколы может быть полезна для разработчиков на Delphi и FreePascal.

Однако недавний отчет, подготовленный координационным центром CERT Coordination Center , специализирующимся на вопросах компьютерной защиты, показал, что в реализациях SNMP есть множество недостатков, из-за которых продукты более ста производителей оказываются уязвимыми для атак. При умелом использовании этих недостатков хакер может получить несанкционированный доступ с широкими привилегиями, организовать DoS-атаку или предпринять другие вредоносные действия.

Основной протокол связи в SNMP - это UDP (User Datagram Protocol). Если агенты SNMP анализируют данные с порта UDP 161 при получении запросов от NMS, то NMS анализирует поток, передаваемый через порт UDP 162 для получения асинхронных сообщений. На рис. 1 показана упрощенная архитектура SNMP-управления, где динамический порт назначает операционная система. SNMP поддерживает простейшую аутентификацию с помощью имени сообщества, которое служит в качестве пароля для получения или изменения данных, существенных для задач управления.

Исследователи из финского университета Оулу разработали тесты, которые позволяют обнаружить множество уязвимых мест в реализациях SNMPv1. Тестовые пакеты, как правило, используются для анализа протокола и порождают сообщения, которые проверяют выполнение различных ограничений архитектуры.

Исследователи обнаружили следующие уязвимые места SNMP .

• Обработка сообщений trap. Множество недостатков было выявлено в том, как различные станции NMS (network management station) декодируют и обрабатывают trap-сообщения.
• Обработка запросов. Тестирование показало наличие некорректностей при декодировании и обработке запросов SNMP различными агентами.

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

Некоторые из уязвимых мест, обнаруженные Protos, не требуют, чтобы в сообщениях SNMP присутствовало корректное имя сообщества, в силу чего использовать такие уязвимые места очень легко. Кроме того, поскольку UDP - коммуникационный протокол, не требующий установления соединения, агенты SNMP и NMS, поддерживающие trap, принимают входящие запросы и сообщения trap без каких-либо предварительных настроек сеанса. Большинство продуктов, ориентированных на SNMP, выпускаются со строками сообщества по умолчанию public («общедоступный») для доступа только на чтение и private («частный») для доступа с правами чтения и записи. Строка имени сообщества интегрирована в сообщение SNMP и передается по сети в виде обычного текста. Даже если эта строка указана корректно, она уязвима для перехвата пакетов.

Для блокирования атак, использующих эти дефекты защиты, контроля сетевого доступа также недостаточно, поскольку адреса отправителей UDP легко сфальсифицировать spoofing. Хакер может послать пакеты, указав фальшивый адрес отправителя, и вывести из строя устройство-получатель. Более того, некоторые реализации SNMP по умолчанию разрешают пересылать пакеты SNMP широковещательно. Хакеры могут легко распространить широковещательные пакеты, чтобы поразить всю сеть целиком, даже если им не известен адрес конкретного устройства и имя сообщества SNMP .

Оценка угроз

Уязвимые места могут создать условия для DoS-атаки или для прерывания обслуживания, и, в некоторых случаях, могут позволить хакеру получить доступ к устройству. Конкретные проявления меняются от продукта к продукту. Поскольку в большинстве случаев службы SNMP по умолчанию не включены, для домашних пользователей эти дефекты не представляют прямой угрозы. Однако так как SNMPv1 широко применяется в важнейших устройствах сетевой инфраструктуры, использование этих изъянов может привести к нестабильности и прерыванию работы крупномасштабной сети. В частности, если хакеры сочетают эти уязвимые места с дефектами защиты в протоколах маршрутизации Internet, таких как Border Gateway Protocol, проникновение на один магистральный маршрутизатор может привести к нестабильности всей Сети. Если большое число сетевых устройств имеет общий дефект, связанный с переполнением буфера в SNMP, то хакеры могут написать червя наподобие Code Red, который будет использовать этот изъян, что может привести к еще одной волне появления червей.

Решения

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

Сканеры SNMPv1. Некоторые организации выпустили инструментальные средства, которые сканируют сеть в поисках устройств, на которых работает протокол SNMP. SNMPing, разработанный в SANS, представляет собой инструментарий на базе Windows, который ищет демонов SNMP на порту 161 или на другом порту. SNScan, аналогичная утилита, разработанная в Foundstone, быстро и точно выявляет в сети устройства, ориентированные на SNMP.

Заплатки. Обнаружив в сети устройства, ориентированные на SNMP, целесообразно связаться с производителями этих устройств, чтобы выяснить, разработали ли они необходимые заплатки.

Отключение службы SNMP. Если для вашей сети служба SNMP не нужна, в CERT рекомендуют отключить или удалить эту службу. Однако тестирование OUSPG показало, что некоторые из потенциально уязвимых продуктов оказались восприимчивы к DoS-атакам или другим нарушающим стабильность работы сети действиям даже при отключенном SNMP.

Фильтрация на входе. Межсетевые экраны и маршрутизаторы можно настроить таким образом, чтобы они выполняли входную фильтрацию портов UDP 161 и 162, что может предотвратить инициируемые из внешней сети атаки на уязвимые устройства в локальной сети. Другие порты, поддерживающие службы, связанные с SNMP, в том числе порты TCP и UDP 161, 162, 199, 391, 750 и 1993, также могут потребовать входной фильтрации.

Выходная фильтрация. Устройства, которые предоставляют общедоступные службы, в обычной ситуации не инициируют исходящий трафик в Internet. Чтобы управлять трафиком, исходящим из сети, реализуйте выходную фильтрацию. Фильтрация исходящего трафика на портах UDP 161 и 162 на границе сети может предотвратить использование вашей системы в качестве плацдарма для атаки.

Изменение строк сообщества по умолчанию. Как уже отмечалось, большинство продуктов, ориентированных на SNMP, имеют по умолчанию строки сообщества public для доступа только на чтение и private для доступа с правом на чтение и запись. Необходимо изменить эти задаваемые по умолчанию значения строк сообществ. Новое имя сообщества, однако по-прежнему будет уязвимо для перехвата пакетов.

Обновление сигнатур. Еще одним решением может стать поддержка в актуальном состоянии сигнатур IDS. Сигнатуры, которые напрямую касаются дефектов, обнаруженных в рамках проекта Protos, теперь можно получить у многих производителей систем обнаружения вторжений. Например, Snort, сообщество разработчиков свободно распространяемых решений для обнаружения вторжений в сеть, разработало набор правил, ориентированных на обработку искаженных пакетов и созданных с помощью пакета Protos. Компания Cisco Systems обновила сигнатуру для своей системы Secure Intrusion Detection System, которую можно получить анонимно. Internet Security Systems выпустила общую сигнатуру для своих продуктов RealSecure и BlackICE.

Простота популярного протокола SNMP имеет своим следствием повышенную уязвимость. Поскольку SNMP применяется очень широко, эксплуатация сетей с уязвимыми продуктами может привести к гибельным последствиям. Сотрудники CERT, исследователи и производители предлагают ряд решений, позволяющих минимизировать потенциальные атаки, использующие эти уязвимые места.

Джуофей Джианг ([email protected]) - ведущий инженер-исследователь Института исследований в области технологий безопасности колледжа в Дартмуте. К области его научных интересов относятся компьютерные сети и безопасность, распределенные информационные системы, мобильные агенты и машинное обучение.

Guofei Jiang. Multiple Vulnerabilities in SNMP. Security & Privacy - 2002, Supplement to IEEE Computer. 2002, IEEE Computer Society, All rights reserved. Reprinted with permission.

Литература

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 3. SNMP Amplification" из номера 164-165 (июль-август 2016) выпуска журнала "Системный администратор" .

Чтобы сделать свой вклад в защиту всемирного киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из Интернет, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса SNMP .

SNMP amplification

Суть атаки заключается в том, чтобы инициировать многократно увеличенный ответ на SNMP- запрос. Изначально разработанные для автоматизации получения табличных данных при минимизации количества отправляемых пакетов BULK- запросы стали довольно эффективным инструментом проведения DDoS- атак в руках злоумышленников. Как гласит RFC3416, GetBulkRequest, р еализованный в SNMP версии 2, предназначен для возможности запросить большой объем данных, чем и пользуются атакующие, используя неправильно настроенные сервера в Интернет.

Если установить максимальное число возвращаемых строк в таблице 20000 и выполнить запрос в адрес неправильно настроенного сервера/устройства:

:~$ snmpbulkget -c public -v 2c -C r20000 192.168.10.129 1.3.6.1

ответ выдаст приблизительно следующее:

iso.3.6.1.2.1.1.1.0 = STRING: "SNMP4J-Agent - Windows 2003 - x86 - 5.2"

< пропущено 290 строк >

iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12.123.123.12 = No more variables left in this MIB View (It is past the end of the MIB tree)

При этом запущенный tcpdump покажет размер возвращенного пакета:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129.snmp: GetBulk(25) N=0 M=20000 .iso.org.dod.internet

21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565:

В ответ на запрос размером около 70 байт с учетом заголовков сервер возвращает ответ размером порядка 10 килобайт, то есть, почти в 150 раз больше. Коэффициент усиления не фиксирован и может принимать как большее (достигая 1700 раз), так и меньшее значение, в зависимости от типа ОС и параметров конфигурации устройства. Если при формировании подобного запроса использовать подмену IP- адреса отправителя на адрес жертвы и высокую интенсивность обращений к уязвимому серверу — DDoS- атака готова.

Причина

Суть проблемы заключается, как правило, не в уязвимости, не в настройке количества отдаваемых значений на один GetBulkRequest, а в том, что значение SNMP community установлено по умолчанию: public – read-only или, что еще хуже, private – read-write. Протокол SNMP версий 1 и 2 основан на UDP, используется для мониторинга и управления, а в качестве аутентификационного параметра доступа к управляемому оборудованию использует значение community, которое может быть задано только для чтения ( read-only ) либо с возможностью записи ( read-write ). Зачастую в системах при активации сервиса SNMP устанавливается значение по умолчанию — public для read-only и private для read-write. Даже если абстрагироваться от возможности использования некорректно настроенного сервера в качестве рефлектора для усиления атак SNMP, то очевидна угроза получения информации о сервере, установленном на нем ПО и его версиях, при использовании значения public по умолчанию для read-only. Практически безграничный привилегированный доступ с правами администратора к устройству дает read-write community private . Даже если не будет производиться вредоносных изменений, интенсивные запросы с использованием протокола SNMP могут вызвать значительную нагрузку на вычислительные ресурсы опрашиваемого сервера, чем повлиять на качество предоставляемых им сервисов.

Защита

Специфические для SNMP рекомендации по обеспечению безопасности сервера либо сетевого оборудования можно разделить на такие направления:

1. Архитектурное: разрешение обработки запросов только на интерфейсах, недоступных из недоверенных сетей.

2. Смена community на более трудноугадываемое.

3. Ограничение IP- адресов управляющих станций.

4. Ограничение ветки OID, доступной для получения/изменения по SNMP.

5 . Минимизация либо отказ от использования community на чтение и запись.

6 . Переход на SNMP версии 3 с использованием дополнительных параметров аутентификации и шифрования.

7. Отключение SNMP, если не используется.

Как выполнить эти действия на разных операционных системах?

В конфигурационном файле сервиса snmp настраиваются следующие параметры:

agentAddress udp:10.0.0.1:161 # IP- адрес, протокол и порт, принимающий запросы SNMP

Если Unix- сервер по сути является маршрутизатором и архитектурно имеет несколько интерфейсов, для безопасности необходимо оставить доступным по SNMP только интерфейс, достуный из доверенного сегмента, но не из Интернет. Имя community для доступа задается параметром rocommunity (read-only ) либо rwcommunity (read-write), также возможно задать подсеть, доступ из которой разрешен, и ветку OID, доступную для работы указанной подсети с заданными правами строки community. Например, для того, чтобы разрешить системам мониторинга из подсети 10.0.0.0/24 доступ к информации по интерфейсам ( OID 1.3.6.1.2.1.2 ), используя строку доступа MaKe_It_SeCuRe с правами только для чтения, конфигурационный фрагмент будет выглядеть следующим образом:

rocommunity MaKe_It_SeCuRe 10.0.0.0/24 .1.3.6.1.2.1.2

В частных случаях использования разнообразных Unix- систем вышеуказанная строка может иметь несколько видоизмененный синтаксис за счет использования других параметров и иерархической структуры компонентов конфигурационного файла. Подробное описание можно найти, набрав команду

man snmpd.conf

Но если задача состоит в том, чтобы максимально быстро обеспечить безопасность сервиса snmpd, который до этого был настроен неправильно предшественником, можно создать резервную копию snmpd.conf, в новый конфигурационный файл внести ограничения по подсети систем мониторинга и изменить community. В Debian это будет выглядеть следующим образом:

# cd < директория с snmpd.conf>

# mv snmpd.conf snmpd.conf.backup

# echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf

# /etc/init.d/snmpd restart

После этого доступ по SNMP к серверу будет только у подсети 10.0.0.0/24 с использованием нового community, при этом все сервера, на которых не изменено community на новое, перестанут получать ответы на запросы, как и злоумышленники.

Более безопасным будет переход на использование SNMPv3, в котором существует возможность варьирования параметров аутентификации. Кроме того, в отличие от версий 1 и 2c, SNMPv3 позволяет обеспечить шифрование трафика между системой мониторинга и опрашиваемым оборудованием. Для создания пользователя с правами только на чтение, аутентификацией и шифрованием трафика, в конфигурационный файл snmpd.conf необходимо добавить:

createUser v3user SHA "some_AuThPaSs" AES some_privpass

authuser read v3user authpriv 1.3.6.1.2.1 . 2

Соответственно, пользователь v3user получит права read-only для просмотра ветки 1.3.6.1.2.1.2 по SNMP.

Проверить корректность конфигурации можно после рестарта сервиса SNMP на сервере 192.168.10.128 командой, выполненной на клиенте:

$ snmpwalk -v 3 -A some_AuThPaSs -X some_privpass -a SHA -x AES -u v3user -l authPriv 192.168.10.128 1

При этом, несмотря на то, что опрашиваться будет все дерево, начиная с 1, сервер отдаст только разрешенную ветку 1.3.6.1.2.1. 2 , которая будет задана в конфигурации.

При отказе от SNMP v1/v2c в пользу SNMPv3 необходимо также удалить из конфигурационного файла фрагменты настройки, не имеющие отношение к SNMPv3.

Если же SNMP для мониторинга сервера не используется, наиболее верным решением будет удаление пакета snmpd.

В Cisco IOS отсутствует возможность выбора интерфейса, который будет обрабатывать запросы SNMP. Ограничение выполняется с помощью списков доступа ( access-control list, ACL ) . Предположим, разрешенной будет подсеть 10.0.0.0/24. Создается ACL:

(config)#access-list 10 permit 10.0.0.0 0.0.0.255

который затем применяется к соответствующему community для SNMP v1/v2c, в данном примере MaKe_It_SeCuRe с правом доступа только на чтение :

(config)#snmp-server community MaKe_It_SeCuRe RO 10

Ограничение к веткам SNMP OID применяется с помощью view

(config)# snmp-server view IFACES 1.3.6.1.2.1. 2 included

после чего к созданному view прикрепляется community:

(config)#snmp-server community MaKe_It_SeCuRe view IFACES RO 10

Для того, чтобы использовать SNMPv3 с необходимыми ограничениями (аутентификация и шифрование, только чтение, доступ из подсети 10.0.0.0/24 к ветке интерфейсов, обозначенной во view IFACES) , необходимо создать группу (SECURE) с доступом на чтение только к OID из view IFACES и необходимостью аутентификации с шифрованием, привязав ее к созданному ранее access-list 10 :

(config)# snmp-server group SECURE v3 priv read IFACES access 10

затем добавить в группу учетную запись пользователя (v3user) , задав ему пароли на аутентификацию и шифрование, а также алгоритм шифрования (в данном случае AES128 ):

(config)# snmp-server user v3user SECURE v3 auth sha Strong_Password priv aes 128 Priv_Password

Итого, защитить свои сервера и сеть от несанкционированного доступа с использвоанием протокола SNMP, уменьшить количество DDoS-атак типа SNMP amplification и минимизировать участие в них своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений:

Управление оборудованием только из доверенного сегмента сети . Ограничение посредством привязки сервиса к определенному интерфейсу либо с помощью списков доступа.

Изменение значений SNMP community по умолчанию (public и private) на трудноугадываемые .

Ограничение ветки OID, доступной для получения/изменения по SNMP.

Использование только SNMPv 3 с применением дополнительных параметров аутентификации и шифрования.

Отключение сервиса SNMP с удалением кофигурации — в случае принятия решения о полном отказе от SNMP.

И если так поступит каждый администратор серверов, доступных из сети Интернет, цифровой мир приблизится еще на один шаг к совершенству .

SNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.

Агент в протоколе SNMP - это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB и тем самым дает им возможность реализовывать функции по управлению и наблюдению за устройством.

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

SNMP - это протокол типа «запрос-ответ» , то есть на каждый запрос, поступивший от менеджера, агент должен передать ответ. Особенностью протокола являет­ся его чрезвычайная простота - он включает в себя всего несколько команд.

Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.

Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.

С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.

Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.

Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.

Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.

СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1. ТЕОРЕТИЧЕСКОЕ ОБОСНОВАНИЕ ПРОБЛЕМЫ ИССЛЕДОВАНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP
1.1 НЕОБХОДИМОСТЬ ИЗУЧЕНИЯ МЕТОДОВ АТАК НА ПРОТОКОЛ SNMP 5
1.2 ПРОТОКОЛ SNMP: ОПИСАНИЕ, ПРЕДНАЗНАЧЕНИЕ 7
2. АНАЛИЗ АТАК НА ПРОТОКОЛ SNMP И СПОСОБОВ ПРОТИВОДЕЙСТВИЯ
2.1 ТЕХНИКИ АТАК НА ПРОТОКОЛ SNMP И СПОСОБЫ ИХ ПРЕДОТВРАЩЕНИЯ 11
2.2 СПОСОБЫ ПРОТИВОДЕЙСТВИЯ АТАКАМ НА ПРОТОКОЛ SNMP 15
ЗАКЛЮЧЕНИЕ 20
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 21

Фрагмент для ознакомления

Рисунок 3 -Экранная форма утилиты SoftPerfectNetworkScannerЗаплаткиПроизводители многих сетевых устройств разрабатывают так называемые заплатки, использование которых необходимо при обнаружении в системе уязвимостей. Таким образом, обнаружив в сети устройства, ориентированные на SNMP, целесообразно связаться с производителями этих устройств, чтобы выяснить, разработали ли они необходимые заплатки.Отключение службы SNMPМногие специалисты склоняются к мнению, что при отсутствии необходимости в службе SNMP ее следует отключить или удалить. Приведем алгоритм отключения службы SNMP в операционной системе Windows:Выбор меню Пуск – Панель управления – Администрирование – Службы (см. рис. 4). Выбор службы SNMP. Если служба запущена, нажимаем на кнопку “Остановить”, а затем выбираем “Тип запуска” – “Отключена”.Рисунок 4 – Отключение службы SNMPСтоит заметить, что некоторые из потенциально уязвимых продуктов остаются восприимчивыми к DoS-атакам или другим нарушающим стабильность работы сети действиям даже при отключенном SNMP.Фильтрация на входеФильтрация на входе основывается на настройке межсетевых экранов и маршрутизаторов так, чтобы они выполняли входную фильтрацию портов UDP 161 и 162. Это позволит предотвратить инициируемые из внешней сети атаки на уязвимые устройства в локальной сети. Другие порты, поддерживающие службы, связанные с SNMP, в том числе порты TCP и UDP 161, 162, 199, 391, 750 и 1993, также могут потребовать входной фильтрации.Фильтрация на выходеДля эффективной защиты возможна организация выходной фильтрации, которая направлена на управление трафиком, исходящем из сети.Фильтрация исходящего трафика на портах UDP 161 и 162 на границе сети может предотвратить использование вашей системы в качестве плацдарма для атаки.Системы обнаружения и предотвращения вторженийСистема обнаружения вторжений (СОВ) (англ. IntrusionDetectionSystem (IDS)) представляет собой программное или аппаратное средство, которое обнаруживает события несанкционированного проникновения (вторжения или сетевой атаки) в компьютерную систему или сеть .Без IDS становится немыслима инфраструктура сетевой безопасности. Дополняя межсетевые экраны, которые функционирую на основе правил безопасности, IDS осуществляют мониторинг и наблюдение за подозрительной активностью. Они позволяют выявить нарушителей, проникших за межсетевой экран, и сообщить об этом администратору, который, примет необходимое решение для поддержания безопасности. Методы выявления вторжений не гарантируют полную безопасность системы.В результате использования IDS достигаются следующие цели:выявление сетевой атаки или вторжения;составление прогноза о вероятных будущих атаках и определение слабых мест системы для предотвращения их использования. Во многих случаях злоумышленник выполняет стадию подготовки, например, зондирует (сканирует) сеть или тестирует ее иным способом, чтобы обнаружить уязвимости системы;осуществление документирования известных угроз;слежение за качеством выполняемого администрирования с точки зрения безопасности, в частности, в крупных и сложных сетях;получение ценной информации о случившихся проникновениях, чтобы восстановить и исправить факторы, приведшие к проникновению;выявление местоположения источника атаки с точки зрения внешней сети (внешние или внутренние атаки), что позволяет принять верные решения при расстановке узлов сети.В общем случае IDS содержит:подсистему наблюдения, которая собирает информацию о событиях, имеющих отношение к безопасности защищаемой сети или системы;подсистему анализа, которая обнаруживает подозрительные действия и сетевые атаки;хранилище, которое хранит первичные события и результаты анализа;консоль управления для настройки IDS, наблюдения за состоянием защищаемой системы и IDS, изучения обнаруженных подсистемой анализа ситуаций.Подводя итог, отметим, чтопростота популярного протокола SNMP имеет своим следствием повышенную уязвимость. Поскольку SNMP применяется очень широко, эксплуатация сетей с уязвимыми продуктами может привести к гибельным последствиям. Поэтому для эффективного применения протокола SNMP следует применять различные способы предотвращения атак и строить комплексную систему защиты.ЗАКЛЮЧЕНИЕИсследование посвящено вопросам обеспечения безопасности организации сетевого взаимодействия посредством протокола SNMP. В процессе работы были выявлены особенности названного протокола и возможные проблемы его использования. Для обоснования проблемы приведены статистические данные, подтверждающие высокую вероятность реализации сетевых атак. Кроме того, теоретическая часть содержит сведения о структуре протокола, схему запросов/откликов и этапы получения ответов на запросы.В рамках курсовой работы проведен анализ возможных атак на протокол SNMP, среди которых можно выделить Dos-атаки, атаки типа «Переполнение буфера» и использующие уязвимости форматной строки. Конечно, потенциально возможных угроз гораздо больше, но их обзор предусматривает более глубокое и всесторонне исследование.Для построения системы защиты сетевого взаимодействия абонентов сети были рассмотрены способы предотвращения атак на протокол SNMPи отмечено, что эффективным будет применение комплекса средств.На основе анализа выявлено, что протоколSNMP достаточно уязвим и, если все-таки принято решение о его использовании, следует разработать политику безопасности и придерживаться всех ее принципов.Таким образом, можно сделать вывод о достижении цели и решении задач, определенных во введении.СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВНормативно-правовые актыФедеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите информации Список специализированной и научной литературыБланк-Эдельман Д. Perl для системного администрирования, М.: символ-Плюс, 2009.- 478с.Бородакий В.Ю. Практика и перспективы создания защищенного информационно-вычислительного облака на основе МСС ОГВ / В.Ю. Бородакий, А.Ю. Добродеев, П.А. Нащекин // Актуальные проблемы развития технологических систем государственной охраны, специальной связи и специального информационного обеспечения: VIII Всероссийская межведомственная научная конференция: материалы и доклады (Орел, 13–14 февраля 2013 г.). – В 10 ч. Ч.4 / Под общ.ред. В.В. Мизерова. – Орел: Академия ФСО России, 2013.Гришина Н. В. Организация комплексной системы защиты информации. -- М.: Гелиос АРВ, 2009. -- 256 с,Дуглас Р. Мауро Основы SNMP, 2-е издание/Дуглас Р. Мауро, Кевин Дж. Шмидт – М.:Символ-Плюс, 2012.-725с.Кульгин М.В. Компьютерные сети. Практика построения. Для профессионалов, СПб.: Питер, 2003.-462с.Мулюха В.А. Методы и средства защиты компьютерной информации. Межсетевое экранирование: Учебное пособие/ Мулюха В.А., Новопашенный А.Г., Подгурский Ю.Е.- СПб.: Издательство СПбГПУ, 2010. - 91 c.Олифер В. Г.,Олифер Н. П. Компьютерные сети. Принципы, технологии, протоколы. - 4-е. - СПб: Питер, 2010. -902с. Технологии коммутации и маршрутизации в локальных компьютерных сетях: учебное пособие / СмирноваЕ. В. и др.; ред. А.В. Пролетарского. – М. : Изд-во МГТУ им. Н.Э. Баумана, 2013. – 389с.Фленов М. Linux глазами Хакера, СПб:BHV-Санкт-Петербург, 2005. – 544 с.Хореев П.В. Методы и средства защиты информации в компьютерных системах. – М.: издательский центр "Академия", 2005. –205 с.Хорошко В. А., Чекатков А. А. Методы и средства защиты информации, К.: Юниор, 2003. - 504с.Интернет-источникиIDS/IPS - Системы обнаружения и предотвращения вторжений [Электронный ресурс] URL: http://netconfig.ru/server/ids-ips/.Анализ Интернет-угроз в 2014 году. DDoS-атаки. Взлом веб-сайтов.[Электронный ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdfКолищак А. Уязвимость форматной строки [Электронный ресурс]. URL: https://securityvulns.ru/articles/fsbug.aspПервая миля, № 04, 2013 [Электронный ресурс]. URL: http://www.lastmile.su/journal/article/3823Семейство стандартов SNMP [Электронный ресурс]. URL: https://ru.wikibooks.org/wiki /Семейство_стандартов_SNMPИностраннаялитература"CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March)

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Нормативно-правовые акты
1. Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите информации
Список специализированной и научной литературы
2. Бланк-Эдельман Д. Perl для системного администрирования, М.: символ-Плюс, 2009.- 478с.
3. Бородакий В.Ю. Практика и перспективы создания защищенного информационно-вычислительного облака на основе МСС ОГВ / В.Ю. Бородакий, А.Ю. Добродеев, П.А. Нащекин // Актуальные проблемы развития технологических систем государственной охраны, специальной связи и специального информационного обеспечения: VIII Всероссийская межведомственная научная конференция: материалы и доклады (Орел, 13–14 февраля 2013 г.). – В 10 ч. Ч.4 / Под общ.ред. В.В. Мизерова. – Орел: Академия ФСО России, 2013.
4. Гришина Н. В. Организация комплексной системы защиты информации. -- М.: Гелиос АРВ, 2009. -- 256 с,
5. Дуглас Р. Мауро Основы SNMP, 2-е издание/Дуглас Р. Мауро, Кевин Дж. Шмидт – М.:Символ-Плюс, 2012.-725с.
6. Кульгин М.В. Компьютерные сети. Практика построения. Для профессионалов, СПб.: Питер, 2003.-462с.
7. Мулюха В.А. Методы и средства защиты компьютерной информации. Межсетевое экранирование: Учебное пособие/ Мулюха В.А., Новопашенный А.Г., Подгурский Ю.Е.- СПб.: Издательство СПбГПУ, 2010. - 91 c.
8. Олифер В. Г.,Олифер Н. П. Компьютерные сети. Принципы, технологии, протоколы. - 4-е. - СПб: Питер, 2010. -902с.
9. Технологии коммутации и маршрутизации в локальных компьютерных сетях: учебное пособие / СмирноваЕ. В. и др.; ред. А.В. Пролетарского. – М. : Изд-во МГТУ им. Н.Э. Баумана, 2013. – 389с.
10. Фленов М. Linux глазами Хакера, СПб:BHV-Санкт-Петербург, 2005. – 544 с.
11. Хореев П.В. Методы и средства защиты информации в компьютерных системах. – М.: издательский центр "Академия", 2005. –205 с.
12. Хорошко В. А., Чекатков А. А. Методы и средства защиты информации, К.: Юниор, 2003. - 504с.
Интернет-источники
13. IDS/IPS - Системы обнаружения и предотвращения вторжений [Электронный ресурс] URL: http://netconfig.ru/server/ids-ips/.
14. Анализ Интернет-угроз в 2014 году. DDoS-атаки. Взлом веб-сайтов.[Электронный ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Колищак А. Уязвимость форматной строки [Электронный ресурс]. URL: https://securityvulns.ru/articles/fsbug.asp
16. Первая миля, № 04, 2013 [Электронный ресурс]. URL: http://www.lastmile.su/journal/article/3823
17. Семейство стандартов SNMP [Электронный ресурс]. URL: https://ru.wikibooks.org/wiki /Семейство_стандартов_SNMP
Иностраннаялитература
18. "CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March)

Размещено на http :// www . allbest . ru /

Размещено на http :// www . allbest . ru /

обзор техник сетевых атак на сетевом уровне модели OSI и методы противодействия

ВВЕДЕНИЕ

сетевые атаки троянского вируса

Любая информация имеет три основных свойства:

· Конфиденциальность.

· Целостность.

· Доступность.

Объяснить каждый из этих свойств.

Конфиденциальная информация-это сведения, которые находятся во владении, пользовании или распоряжении отдельных физических или юридических лиц и распространяются по их желанию в соответствии с его положениями условиями.

Целостность информации (целостность данных) - термин в информатике и теории телекоммуникаций, который означает, что данные полны, условие того, что данные не были изменены при выполнении любой операции над ними, будь то передача, хранение или представление.

Доступность информации-состояние информации (ресурсов автоматизированной информационной системы), в котором субъекты, имеющие права доступа, могут реализовывать их беспрепятственно. Права доступа: право на чтение, изменение, копирование, уничтожение информации, а также право на изменение, использование, уничтожение ресурсов.

Существуют три основных способа защиты информации, которые расположены в порядке их важности:

· Организационные методы защиты информации. Организационная защита информации является организационным началом, так называемым "ядром" в общей системе защиты конфиденциальной информации предприятия. От полноты и качества решения руководством предприятия и должностными лицами организационных задач зависит эффективность функционирования системы защиты информации в целом. Роль и место организационной защиты информации в общей системе мер, направленных на защиту конфиденциальной информации предприятия, определяются исключительной важности для принятия руководством своевременных и верных управленческих решений с учетом имеющихся в его распоряжении сил, средств, методов и способов защиты информации и на основе действующего нормативно-методического аппарата.

· Технические методы защиты информации. Эти методы предполагают наличие в устройств и технических средств обработки информации, средств специальных технических решений, обеспечивающих защиту и контроль информации. И, кроме того, методы защиты информации, то есть совокупность алгоритмов и программ, обеспечивающих разграничение доступа и исключение несанкционированного использования информации.