ISSP \ Домен 10. Операционная безопасность. Часть 6

В этой части рассмотрены следующие вопросы:

• Тестирование уязвимостей
• Тестирование на проникновение
• Сканирование телефонных номеров
• Другие виды уязвимостей
• Что дальше?
• Резюме

11. Тестирование уязвимостей

Проведение ручного или автоматизированного (а лучше их сочетания) тестирования уязвимостей (vulnerability testing), требует наличия у компании сотрудников (либо заключения договора с консультантами), обладающих большим опытом в безопасности, а также высоким уровнем доверия. Даже самый лучший автоматизированный инструмент сканирования уязвимостей выдает результаты, которые могут быть неправильно интерпретированы (ложное срабатывание), либо выявленные уязвимости могут не иметь значения для вашей среды или быть компенсированы за счет различных защитных мер. С другой стороны, в сети может быть найдено две отдельных уязвимости, которые сами по себе несущественны, но вместе взятые они имеют критическое значение. И, конечно же, автоматизированный инструмент может пропустить отдельные уязвимости, например, уязвимости в малоизвестном элементе, имеющем большое значение для вашей среды.

ПРИМЕЧАНИЕ. Перед проведением тестирования уязвимостей, необходимо получить письменное согласие от руководства компании! Это защитит от судебного преследования тестировщика, выполняющего эту работу, и исключит любое недопонимание, т.к. все требования будут предоставлены в письменном виде и в них будет указано, что разрешается делать тестировщику, а что – нет.

Цели проведения такой оценки заключаются в следующем:

• Оценить истинное состояние безопасности среды.
• Выявить максимально возможное количество уязвимостей, оценить и приоритезировать каждую из них.
• Проверить, как системы реагируют на определенные действия и атаки, чтобы узнать не только о наличии известных уязвимостей (устаревшая версия службы, учетная запись без пароля), а также о возможности несанкционированного использования отдельных элементов среды (SQL-инъекции, переполнение буфера, использование архитектурных недостатков системы (например, в атаках социальной инженерии)).

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

Кроме того, руководство должно понимать, что результаты тестирования – это только «моментальный снимок». Поскольку в среде постоянно происходят изменения, в любой момент могут появиться новые уязвимости. Руководство также должно понимать, что возможны различные варианты оценки, каждый из которых позволяет выявить различные виды уязвимостей в среде, но каждый из них имеет свои ограничения. Такими вариантами тестирования могут быть следующие:

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

• Физическое тестирование, которое включает в себя анализ механизмов защиты здания и периметра. Например, действительно ли двери закрываются автоматически? Раздается ли сигнал тревоги, если дверь остается открытой слишком долго? Работают ли внутренние защитные системы серверных комнат, коммутационных шкафов, помещений, в которых установлены критичные системы и/или активы? Правильно ли работают считыватели смарт-карт и действительно ли доступ предоставлен только уполномоченному персоналу? Является ли угрозой «разгребание мусора» (другими словами, выполняется ли надежное уничтожение носителей конфиденциальной информации при их выводе из эксплуатации, в т.ч. уничтожение бумажных документов)? Как обстоят дела с защитой от искусственных, природных и технических угроз? Работает ли система пожаротушения? Она безопасна для людей и оборудования в здании? Установлена ли критичная электроника выше фальшполов, чтобы она смогла пережить небольшое затопление? И так далее.

• Тестирование сети и систем – возможно именно об этом думает большинство людей, когда речь заходит о тестировании уязвимостей в рамках информационной безопасности. Автоматизированный сканер уязвимостей находит известные уязвимости в системах, а в некоторых случаях (если руководство подписало разрешение на активное воздействие и приняло риски возможного возникновения перебоев в работе) пытается эксплуатировать выявленные уязвимости.

Поскольку оценка безопасности является «мгновенным снимком» состояния среды, такая оценка должна проводиться на регулярной основе. Низкоприоритетные или лучше защищенные части среды, либо менее рискованные части, могут сканироваться один или два раза в год. Высокоприоритетные, наиболее ценные системы (например, серверы системы электронной коммерции, промежуточное программное обеспечение, обеспечивающее их работу) следует сканировать почти непрерывно.

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

11.1. Тестирование на проникновение

Тестирование на проникновение (penetration testing) представляет собой процесс моделирования атак на сети и системы по просьбе их владельца – руководителя высшего звена. При тестировании на проникновение тестировщик использует набор процедур и инструментов, предназначенных для тестирования и попыток обхода защитных мер системы. Целью тестирования на проникновение является оценка уровня сопротивления компании атаке и выявление любых недостатков в ее среде. Компании нужно независимо оценить эффективность своих мер безопасности, а не просто довериться обещаниям поставщиков. Хорошая компьютерная безопасность основывается на реальных фактах, а не на одном только представлении, как все должно работать.

Тестирование на проникновение имитирует те же методы, которые используют реальные злоумышленники. Нужно учитывать, что злоумышленники могут быть очень умными, творческими людьми, весьма изобретательными в своих подходах, поэтому тестирование на проникновение должно также использовать новейшие методы взлома наряду с прочной методологией проведения такого тестирования. В процессе тестирования нужно проанализировать каждый компьютер в среде, как показано на Рисунке 10-5, поскольку не стоит рассчитывать, что злоумышленник просканирует только один или два компьютера и, ненайдя в них уязвимостей, выберет другую компанию.

Рисунок 10-5. Тестирование на проникновение проводится, чтобы доказать, что злоумышленник действительно может взломать систему

Возможности сканеров уязвимостей. Сканеры уязвимостей предоставляют следующие возможности:
• Выявление активных систем в сети
• Выявление активных уязвимых служб (портов) на найденных системах
• Выявление работающих на них приложений и анализ баннеров
• Определение установленных на них операционных систем
• Выявление уязвимостей, связанных с обнаруженными операционными системами и приложениями
• Выявление неправильных настроек
• Тестироввание на соответствие с политиками использования приложений и политикам безопасности
• Подготовка основы для проведения тестирования на проникновение

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

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

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

Специалисты по безопасности перед проведением тестирования на проникновение должны получить официальный документ (письмо) от руководства компании, в котором указаны, в частности, разрешенные границы тестирования. Этот документ должен быть доступен всем членам команды, участвующим в процессе проведения тестирования. Этот документ часто называют «пропуском на выход из тюрьмы» (Get Out of Jail Free Card). Кроме того, участникам тестирования должна быть доступна контактная информация ключевого персонала компании, и «дерево вызовов» на случай, если что-то пойдет не по плану, и потребуется восстановить систему.

ПРИМЕЧАНИЕ. «Пропуск на выход из тюрьмы» – это документ, который вы можете предъявить любому, кто сочтет, что вы осуществляете незаконную деятельность, когда на самом деле вы проводите разрешенное тестирование. Нередко случались ситуации, когда эксперт (или группа экспертов) проводили тест на проникновение, а к ним подходили ничего не знающие об этом охранники, которые считали, что он оказался в неправильном месте в неправильное время.

В процессе выполнения тестирования на проникновение, команда проходит через пять этапов:

1. Исследование. Сбор информации о цели.
2. Перечисление (enumeration). Проведение сканирования портов, использование техник и инструментов для идентификации обнаруженных систем и ресурсов.
3. Выявление уязвимостей (vulnerability mapping). Выявление уязвимостей в идентифицированных системах и ресурсах.
4. Эксплуатация. Попытки получить несанкционированный доступ с помощью выявленных уязвимостей.
5. Отчет руководству. Предоставление руководству документированных результатов тестирования и предложений по устранению выявленных недостатков (контрмерам).

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

• Нулевая информация. Команда не имеет никакой информации о цели и должна начинать с нуля.
• Частичная информация. Команда имеет некоторые сведения о цели.
• Полная информация. Команда имеет полную и детальную информацию о цели.

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

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

Тестирование может проводиться извне (из удаленного места) или изнутри (т.е. тестировщик находится в сети компании). Следует проводить оба варианта тестирования, чтобы понять как внешние, так и внутренние угрозы.

Тесты могут проводиться на основе слепого метода, двойного слепого метода, или быть целенаправленными. При тестировании слепым методом (blind test), эксперты знают только общедоступные данные перед началом тестирования. Персонал компании, занимающийся обслуживанием сети, и сотрудники безопасности знают о проводимом тестировани.

Двойной слепой метод тестирования (double-blind test) (скрытая оценка) похож на слепой метод тестирования, однако персонал компании не ставится в известность о проводимом тестировании (в т.ч. сотрудники безопасности). Это позволяет проверить не только уровень безопасности сети, но и реакцию сотрудников, реальное выполнение ими функций мониторинга журналов регистрации событий, знание процедур реагирования на инциденты и эскалации. Такой метод тестирования является наиболее реалистичной демонстрацией вероятности успеха или провала вероятной атаки.

Для целенаправленного тестирования (targeted test) могут привлекаться внешние консультанты и внутренний персонал. При этом осуществляется тестирование, ориентированное на конкретные области, представляющие интерес для компании. Например, перед внедрением нового приложения компания может решить проверить наличие в нем уязвимостей до того, как оно будет установлено в промышленную среду. Другим примером является тестирование, ориентированное на конкретные системы, участвующие, например, в выполнении операций дистанционного банковского обслуживания. Остальные системы при этом в тестировании не участвуют.

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

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

11.2. Сканирование телефонных номеров

Как было сказано ранее, инструменты для выполнения сканирования телефонных номеров (wardialing) позволяют злоумышленникам (или администраторам) автоматически набирать большие диапазоны телефонных номеров для поиска доступных модемов. Сущеcтвует ряд бесплатных и коммерческих инструментов, которые могут набирать все телефонные номера в указанном диапазоне (например, все номера от 212-55-00 до 212-55-99) и отмечать номера телефонов, с которых ответили модемы. Обычно диапазон номеров выбирается таким образом, чтобы в него входили только номера, принадлежащие компании (по возможности). Такие инструменты могут быть достаточно «умными», звоня лишь ночью, когда большинство телефонов не контролируется. Также они могут выбирать телефонные номера в случайном порядке, чтобы снизить вероятность того, что сотрудники поднимут тревогу, услышав звонки один за другим по всем телефонам. Сканирование телефонных номеров может быть проведено достаточно быстро с использованием дешевого оборудования. Разработанные для этих целей инструменты могут не только выявить модем, но и определить тип ответившей системы на основе ее отклика (аналогично тому, как это делают сканеры уязвимостей), а также попытаться автоматически произвести попытки подключения к сети, и, в случае удачи, предоставить атакующему консоль взломанной системы, готовой выполнять его команды. Следует отметить, что некоторые офисные телефонные системы (или специальные телефонные диагностические средства) могут автоматически обнаруживать модемные линии и сообщать о них соответствующим сотрудникам компании.

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

Любые факты обнаружения в процессе сканирования несанкционированно установленных модемов должны быть расследованы. Использование этих модемов должно быть либо официально разрешено (при этом должны быть предприняты все необходимые меры безопасности), либо эти модемы должны быть удалены, а установившие их сотрудники должны пройти дополнительное обучение или получить дисциплинированое взыскание.

11.3. Другие виды уязвимостей

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

Чаще всего, эксплуатируемыми уязвимостями являются:

• Недостатки на уровне ядра (kernel flaws). Это проблемы, которые возникают ниже уровня пользовательского интерфейса, они находятся глубоко внутри операционной системы. Любой недостаток в ядре, который может быть использован злоумышленником, при его эксплуатации может предоставить злоумышленнику самый полный уровень контроля над системой.

• Контрмеры. Необходимо максимально быстро устанавливать на системы патчи, выпускаемые производителями, после проведения их надлежащего тестирования.

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

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

• Символические ссылки (symbolic links). Хотя возможности доступа злоумышленника к просмотру или изменению содержания критичных системных файлов и данных могут быть заблокированы, если программа использует символическую ссылку (файл-заглушка, который перенаправляет приложение/пользователя в другое место, где хранится реальный файл), а злоумышленник имеет возможность внесения изменений в содержимое этой символической ссылки, он может получить несанкционированный доступ к системе (символические ссылки используются в системах Linux и Unix). Это может позволить злоумышленнику повредить важные данные и/или получить привилегированный доступ к системе. Примером может быть использование символической ссылки для удаления файла паролей или замены в нем отдельных строк, задающих пустой или заведомо известный злоумышленнику пароль для нужной ему учетной записи (например, root).

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

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

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

• Состояние гонки (race conditions). Это состояние вызывается ошибкой в архитектуре многозадачной системы, при которой работа системы зависит от того, в каком порядке выполняются части ее кода. Примером может быть открытие временных файлов при работе в привилегированном режиме без обеспечения невозможности перезаписи этих файлов неуполномоченным пользователем или процессом, либо создание экземпляра функции динамически загружаемой библиотеки без обеспечения безопасности указателя, содержащего путь к файлу динамической библиотеки. Все это может позволить злоумышленнику нарушить работу программы (работающей с повышенными привилегиями) или заставить ее выполнять команды злоумышленника.

• Контрмеры. Использование безопасных практик программирования, автоматизированных сканеров исходных кодов, проведение тестирования безопасности приложений – все это может помочь сократить уязвимости такого рода.

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

• Контрмеры. Выполнение проверки целостности файлов, в процессе которой должны также проверяться действующие разрешения для файлов и каталогов. Это позволит своевременно выявить несанкционированно измененные файлы или недопустимые разрешения доступа.

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

11.4. Что дальше?

После завершения тестирования, интерпретации его результатов и расстановки приоритетов мероприятий по устранению выявленных недостатков, руководство получит подробный список способов, с помощью которых компания может быть успешно атакована. Это является входными данными для корректировки и реализации следующего этапа стратегии повышения безопасности. У любой компании существуют ограничения по бюджету и человеческим ресурсам, поэтому ни одна компания не может полностью устранить все свои риски – она может их только снизить до приемлемого уровня. Обеспечение баланса между рисками, риск-аппетитом компании и затратами на возможное снижение рисков, позволит компании принять наиболее правильные решения по расходу своих ограниченных ресурсов. Необходимо организовать контроль, который позволит убедиться, что риски снижены до приемлемого уровня, а расходы на защитные средства надлежащим образом отслеживаются и сравниваются с первоначальной сметой. Каждый случай, когда реальная стоимость значительно отличается от ожидаемой (как в положительную, так и в отрицательную сторону), должен детально анализироваться, а процесс внедрения должен приостанавливаться на время проведения анализа. Вполне возможно, что повысившаяся стоимость контрмер потребует пересмотра решения по их внедрению, и компания выберет принятие соответствующих рисков, либо их снижение альтернативным способом.

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

В Таблице 10-3 приведен пример графика проведения тестирования, который должны совместно разработать Департамент эксплуатации и Департамент безопасности, и в дальнейшем следовать ему.

Таблица 10-3. Пример графика проведения тестирования для Департаментов эксплуатации и безопасности

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

Ссылки по теме:

• NIST Security Self-Assessment Guide for Information Technology Systems, by Marianne Swanson, NIST Special Publication 800-26 (Nov. 2001)
• Computer Security course, Module 16, “Vulnerability Analysis,” Polytechnic University (Nov. 2003)
• “DDoS: A Look Back from 2003,” presentation by Dave Dittrich, University of Washington
• “Password Cracking, Sniffing, and Man-in-the-Middle,” Prof. Henry Owen, Georgia Tech University

12. Резюме

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

<<< Предыдущий раздел • Содержание • Следующий раздел >>>