- •Введение
- •1. Распределенные атаки на информационно-телекоммуникационные системы
- •1.1. Информационно-телекоммуникационные системы в контексте обеспечения их безопасности
- •1.1.1. Понятийный аппарат в сфере обеспечения безопасности
- •1.1.2. Свойства информационно-телекоммуникационных систем
- •1.1.3. Особенности построения информационно-телекоммуникационных систем
- •1.2. Распределенные атаки типа «отказ в обслуживании» как угроза безопасности в информационно-телекоммуникационных системах
- •1.2.1. Классификация механизмов реализации dDoS-атак
- •1.2.2. Типы dDoS-атак
- •1.2.3 Противодействие dDoS-атакам
- •2. Ddos-атаки на мультисерверные информационно-телекоммуникационные системы
- •2.1. Особенности мультисерверных систем
- •Vip для реальных серверов
- •2.2. DDoS-атаки на мультисерверную систему
- •2.3. Антропогенные источники угроз реализации dDoS-атак на мультисерверные системы
- •2.4. DDoS-атаки как источник информационных рисков в мультисерверной системе
- •2.5. Модели управления рисками мультисерверных систем
- •Обоснование закона распределения ущерба при реализации dDoS-атак на мультисерверную систему
- •3. Аналитическая оценка рисков атакуемых мультисерверных систем
- •3.1. Оценка параметров риска для компонентов мультисерверных систем
- •3.2. Оценка и регулирование рисков мультисерверных систем
- •3.3. Выбор параметров функций рисков компонентов мультисерверной системы
- •4. Управление рисками атакуемых мультисерверных систем
- •4.1. Управление рисками мультисерверных систем в случае ddos-атак на их компоненты
- •4.2. Управление общим риском системы
- •4.3. Подход к параметрическому синтезу системы с заданным риском
- •4.4. Пример практических расчетов
- •Библиографический список
- •Оглавление
- •394026 Воронеж, Московский просп., 14
2. Ddos-атаки на мультисерверные информационно-телекоммуникационные системы
2.1. Особенности мультисерверных систем
Используя приведенные в первой главе способы реализации DDoS-атак на ИТКС, скорректируем параметры механизмов защиты мультисерверных систем таким образом, чтобы снизить риск реализации таких атак.
Мультисерверная работа – перспективный путь развития ИТКС, где обязательным условием для звеньев современной системы является возможность распараллеливания важных компонентов на физически различные серверные компьютеры. Этим достигается как масштабирование системы, так и обеспечение бесперебойной работы ИТКС. Кластеры компонентов, расположенные на различных серверах, автоматически перераспределяют нагрузку и продолжают нормальное функционирование в случае сбоя одного из серверных компьютеров. Балансировку нагрузки серверов обеспечивают интеллектуальные алгоритмы, которые улучшают масштабируемость, уменьшают время отклика для пользователей и способствуют более эффективному использованию вычислительной техники [92].
В современных условиях все большее число компаний переходит к мультисерверной работе, которая имеет ряд характерных преимуществ: масштабируемость, кластеризация, отказоустойчивость, балансировка загрузки серверов, разделение серверов по функциональным требованиям [91].
Системы балансировки нагрузки делятся на три категории: аппаратные устройства, сетевые коммутаторы и программные решения. В число задач балансировщиков нагрузки входит обеспечение масштабируемости вычислительных комплексов, отказоустойчивости сервисов, управление серверными подключениями и защита серверного оборудования от атак злоумышленников [89, 116]. Мультисерверная система с подсистемой балансировкой нагрузки представлена на рис. 2.1.
Рис. 2.1. Мультисерверная система с подсистемой балансировки нагрузки, где: p1,..,p5 – пользователи, R1,...,R3 – серверы.
Рассмотрим более подробно работу системы балансировки (Load balancers) нагрузки Web-серверов [91, 116]. Система балансировки нагрузки представляет собой инструментальное средство, предназначенное для переадресации клиентских запросов на наименее загруженный или более подходящий Web-сервер из группы машин, на которых хранятся копии информационного ресурса. Клиент не подозревает, что он обращается к группе серверов: все они представляются ему в виде единого виртуального сервера. Предположим, что обслуживается один сайт, и имеется два Web-сервера: Web1.acme.com с IP-адресом 193.168.36.1 и Web2.acme.com с IP-адресом 193.168.36.2. Предоставляя сайт пользователям Internet, система балансировки нагрузки (Load balancer) использует виртуальное имя компьютера (например, www.acme.com), а также виртуальный IP-адрес (например, VIP-адрес 193.168.35.10).
Чтобы связать имя виртуальной системы, и соответствующий VIP-адрес с двумя Web-серверами, необходимо опубликовать имя системы и ее VIP-адрес на сервере DNS. Система балансировки нагрузок постоянно контролирует нагрузки и степень готовности каждого из Web-серверов.
Когда на узел www.acme.com заходит посетитель, то его запрос поступает не на Web-серверы, а на систему балансировки нагрузки. Эта система принимает решение, на какой сервер направить запрос, руководствуясь такими критериями, как загрузка каждого сервера, а также соблюдая правила, сформулированные администратором. Затем система балансировки направляет запрос клиента соответствующему серверу. Как правило, она отправляет также ответ сервера клиенту. Система балансировки нагрузки выполняет следующие три задачи: контроль за нагрузкой и состоянием серверов, правильный выбор сервера, который будет отвечать на запрос клиента и управление трафиком между клиентом и сервером. Современные системы балансировки позволяют администратору определять правила выбора сервера по своему усмотрению. Можно, например, включить в эти правила такие критерии, как коэффициент загрузки центрального процессора (ЦП) и памяти, число открытых соединений TCP и количество пакетов, поступивших на интерфейсную плату того или иного сервера. Например, администратор может использовать для задания критерия следующую формулу:
Загрузка сервера = (10*уровень использования ЦП + 3* уровень использования памяти + 6*число открытых TCP-соединений +3* число переданных пакетов).
Следовательно, управлять правилами безопасности может администратор, задавая предельные значения для этих параметров.
Так как при выходе из строя системы балансировки нагрузки может оказаться неработоспособным весь узел, то при планировании и реализации инфраструктуры с выравниванием нагрузок важно принимать во внимание отказоустойчивость средств балансировки, а также выбирать решения с широкой полосой пропускания, способные обеспечить высокую производительность системы в целом.
Рассмотрим пример, когда Load balancer подключен, как показано на рис. 2.2. На этом рисунке изображены три сервера: RS1, RS2, RS3 и три приложения: Web (HTTP), FTP и SMTP, которые распределены среди этих серверов. В этом примере все три приложения стартуют на TCP-портах. Web-приложение подключено к порту 80, FTP – к порту 21, SMTP – к порту 82. Load balancer использует destination порт, чтобы распределить приложения между клиентами и выбирает подходящий сервер для каждого запроса. Процесс определения сервера, на который должен быть отправлен запрос, состоит их двух частей. Во-первых, Load balancer должен определить, является ли данный сервер работоспособным. Если сервер или приложение не находятся в рабочем состоянии, он определяет причину и возвращается к более детальному обсуждению позже. Во-вторых, Load balancer использует алгоритм распределения нагрузки или метод выбора сервера, основывающихся на условиях загрузки на них [91,116].
Рис. 2.2. Группа серверов с Load Balancer
Процесс конфигурации Load balancer в этом примере определяется следующими шагами:
– определение VIP для Load balancer: VIP=123.122.121.1;
определение приложений, которые необходимы для Load balancer: Web (HTTP), FTP и SMTP;
задание VIP для каждого реального сервера, на котором находится данное приложение: получим VIP для RS1 и RS2 для Web, RS1 –для FTP, RS2, RS3 –для SMTP. Это значит, что для VIP отведен порт 80 для RS1 и RS2; порт 21 для VIP определен на порт 21 реального сервера RS1
(табл. 2.1) и т.д.;
задание типов неработоспособности, для которых Load balancer определит условия, при которых сервер или приложение будут считаться неработоспособными;
определение метода распределения нагрузки.
Таблица 2.1