80012

Разработка системы защиты от распределенных атак на отказ в обслуживании типа HTTP-flood

Дипломная

Информатика, кибернетика и программирование

Программный продукт, взаимодействуя с веб-серверами Nginx (as frontend service) и Apache (as backend service) на основе операционной системы Debian Lenny 2.6., будет принимать решение о блокировании нежелательных запросов, и отправлять на блокировку межсетевому экрану netfilter (iptables). Система предназначена для выделенных серверов или виртуальных выделенных серверов (VPS – Virtual Private Server).

Русский

2015-02-15

1.15 MB

19 чел.

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

(Технический Университет)

Кафедра Информационно-коммуникационные технологии

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту (работе)

На тему «Разработка системы защиты от распределенных атак на отказ в обслуживании типа HTTP-flood»

Студентка Кудрявцева Алина Сергеевна  _________________________________________

Руководитель проекта Игнатьев Иван Сергеевич_____________________________

Допущен к защите_________________2010 г.

                                        КОНСУЛЬТАНТЫ ПРОЕКТА:

Специальная часть________________________________________________А.Г.Харламов

Охрана труда___________________________________________________________А.Ф.Завальнюк

Зав. Кафедрой____________________________________________________В.Н.Азаров

МОСКВА 2010 г.

  1.  
    Аннотация

Данный проект ставит своей целью создание интеллектуальной программной защиты от DDoS-атак типа «HTTP-flood». Произведен анализ существующих решений защиты на программном уровне и на основании полученных знаний принято решение разработать программу, которая будет классифицировать HTTP-запросы, отделяя легитимных пользователей от атакующих. Основными особенностями разрабатываемой системы будет являться:  

  •  Открытость исходного кода;
  •  Легкая интегрируемость на любую Linux платформу;
  •  Интеллектуальность системы, за счет анализа аномалий в сетевом трафике.

Программный продукт, взаимодействуя с веб-серверами Nginx (as frontend service) и Apache (as backend service) на основе операционной системы Debian Lenny 2.6., будет принимать решение о блокировании нежелательных запросов, и отправлять на блокировку межсетевому экрану netfilter (iptables). Система предназначена для выделенных серверов или виртуальных выделенных серверов (VPS – Virtual Private Server).

  1.  
    Содержание

[1]
Аннотация

[2]
Содержание

[3]
Введение

[3.1] Актуальность

[3.2] Новизна

[4]
Общая часть

[4.1] Обзор DoS-атак

[4.2] Крупнейшие DDoS-сети

[4.3] След в истории (последствия атак)

[4.4] Классификация DDoS атак

[4.5]
Методы защиты от DDoS-атак

[4.5.1] Маршрутизация в «черные дыры»

[4.5.2] Списки контроля доступа

[4.5.3] Межсетевые экраны

[4.5.4] Реакция на атаки DDoS-атаки, инициируемая вручную

[4.5.5] Другие стратегии

[4.6]
Анализ аномалий в сети

[4.7]
Пример архитектуры защиты от DDoS-атак

[4.8]
Анализ рынка

[4.8.1] Коммерческие решения

[4.8.1.1] Решение от компании Cisco для защиты от DDoS-атак

[4.8.1.2] Ados – система защиты веб-сервера от DDoS-атак

[4.8.2] Некоммерческие Unix продукты для защиты от HTTP flood

[4.8.2.1] Стандартный способ обнаружения атаки HTTP-flood

[4.8.2.2] Фильтрация пакетов по URL с помощью расширения iptables

[4.8.2.3] Фильтрация запросов из «нежелательных» стран

[4.8.2.4] Модуль apache mod_evasive для защиты от HTTP-flood

[4.8.2.5] Борьба с HTTP-flood средствами веб-сервера Nginx

[4.9]
Наивный Байесовский классификатор

[4.9.1] Математическая постановка задачи

[4.10]
Вывод

[5]
Специальная часть проекта

[5.1] Проектирование системы классификации запросов

[5.2]
Настройка веб-сервера

[5.2.1] Настройка веб-сервера Nginx в связке с Apache на Debian Lenny

[5.2.2]
Настройка модуль для записи статистики apache в СУБД MySQL

[5.2.3] Вывод

[5.3] Обнаружение атаки на веб-сервер

[5.4]
Схема функционирования системы

[5.5]
Алгоритм классификации запросов

[5.5.1] Расчет вероятностей

[5.6]
Программа классификации запросов

[6]
Охрана труда

[6.1] Введение

[6.2] Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияние на пользователей

[6.3] Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов

[7]
Вывод

[8]
Список используемой литературы

[9] Зобнин Е. Устоять любой ценой. Методы борьбы с DoS/DDoS-атаками:

[10] Фоменко З. Классификация DoS-атак: http://www.xakep.ru/magazine/xs/021/012/1.asp

  1.  
    Введение
    1.  Актуальность

Атаки с распределенным отказом в обслуживании – это реальная и растущая угроза, с которой сталкиваются компании во всем мире. Эти атаки реализуются большим количеством программных агентов, размещенных на хостах, которые злоумышленник скомпрометировал ранее. Реализация этих атак может привести не только к выходу из строя отдельных хостов и служб, но и остановить работу корневых DNS-серверов и вызвать частичное или полное прекращение работы Интернета. В связи с критичностью и нетривиальностью данного класса атак, построение эффективных средств защиты от них представляет собой сложную научно-техническую проблему. На уровне маршрутизаторов защиту от DDoS-атак уже достаточно успешно реализовали компании Cisco Systems и Arbor Networks. Но в целом проблема DDoS-атак на сегодняшний день по-прежнему очень остро стоит для большинства компаний.

  1.  Новизна

В данном проекте предлагается простое, доступное и гибкое решение проблемы DDoS-атак типа «HTTP-flood». В его основу положен популярный алгоритм анализа данных – байесовский алгоритм. Этот метод давно и эффективно используется в спам-фильтрах, которые используются повсеместно, как в бизнесе, так и домашними пользователями. В основе байесовcкого алгоритма положены элементарные законы теории вероятностей и дискретной математики и потому его реализация не представляется сложной.

  1.  
    Общая часть
    1.  Обзор DoS-атак

DoS-атака (от англ. Denial of Service, отказ в обслуживании) — атака на вычислительную систему с целью вывести её из строя, то есть создание таких условий, при которых легитимные (правомерные) пользователи системы не могут получить доступ к предоставляемым системой ресурсам, либо этот доступ затруднён. [1]

Атаку на отказ в обслуживании можно провести тремя способами:

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

Конечно, один компьютер не может переполнить канал сервера, поэтому для этого используется распределенная атака (DDoS-атака, от англ. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании»).[3]

DDoS-атака имеет иерархическую структуру – трехуровневую модель, состоящую из следующих элементов:

  •  консоли управления, т.е. головного компьютера, подающего сигнал о том, что началась атака;
  •  «компьютеров–демонов», которые, получив сигнал от консоли управления, передают его «зомбированным машинам»;
  •  атакующих агентов – управляемых зараженных компьютеров, посылающих запросы на конечную мишень.

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

«Зомби-сеть» создается путем заражения компьютеров (как правило, это домашняя машина, подключенная к выделенному каналу)  троянской программой. Эта программа попадает на компьютер пользователя, чаще всего, при неосторожном обращении с электронной почтой, например, открытии вложений в письмо, или при посещении зараженного сайта, когда злоумышленник может, используя уязвимости браузера или операционной системы, установить на компьютер пользователя вредоносную программу. Такая программа может в течение долгого времени ничем деструктивным себя не проявлять. Часто владелец компьютера даже не подозревает, что его машина заражена и полностью подконтрольна кому-то невидимому.

Команда к атаке отдается, например, в чате. Хозяин пишет фразу, которая содержит адрес сайта-жертвы. Сеть «зомби-машин» начинает работать. Запросы идут из многих точек Сети, идут с высокой частотой, и сайт, который они атакуют, начинает не справляться с большим потоком обычных запросов, перестает отвечать на легитимные запросы и, наконец, зависает.[3]

Рис.1 Архитектора DDoS-сети

  1.  Крупнейшие DDoS-сети 
  •  Kraken – 400 тысяч компьютеров.
  •  Srizbi – 315 тысяч компьютеров.
  •  Bobax – 185 тысяч компьютеров.
  •  Rustock – 150 тысяч компьютеров.
  •  Storm – 100 тысяч компьютеров.
  •  Psybot – 100 тысяч ADSL-маршрутизаторов, основанных на Linux.
  •  Ботнет BBC – 22 тысячи компьютеров. Экспериментальный ботнет, созданный компанией BBC.
    1.  След в истории (последствия атак)
  •  2000 год – «вне зоны действия» оказались web-сайты Yahoo, CNN, eBay и др. (атака принесла совокупные убытки в размере $1,2 млрд.)
  •  2001 год – DDoS-атака на web-сайт Microsoft (компания потеряла около $500 млн. всего за несколько дней);
  •  2002 год – атака на корневые DNS-серверы интернета. На некоторое время были выведены из строя 7 из 13 серверов;
  •  2003 года – DDoS-нападение на LiveJournal.com. Два дня сервис находился в парализованном состоянии, лишь иногда подавая признаки жизни;
  •  2009 – Google и Adobe подверглись DDoS атакам из-за уязвимости Internet Explorer.

По статистике Департамента ИБ компании ТТК в 2005 году было зафиксировано 26, в 2006 году – 53, в 2007 – 114 DDoS-атак, т.е. наблюдается более чем двукратный ежегодный рост DDoS-нападений. Причем, растет как частота, так и длительность атак.[6]

  1.  Классификация DDoS атак 
  •  Насыщение полосы пропускания (bandwidth consumption)

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

  •  Недостаток ресурсов (resource starvation)

Атаки, направленные на захват критических системных ресурсов: процессорное время, место на диске, память и т.д. Resource starvation часто очень похож на bandwidth consumption: взломщик отсылают множество запросов на сервер. Но на этот раз пакеты не забивают канал хоста-жертвы, а занимают, скажем, все его процессорное время. Ведь на обработку каждого пакета сервер затрачивает некоторое процессорное усилие. Результат – все остальные процессы висят, пользователи не могут получить доступа к сервисам.

  •  Ошибки программирования (programming flaw)

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

  •  Маршрутизация и DNS 

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

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

  •  Flood (Флуд или Поток/Затопление)

Этот тип можно отнести к предыдущим DoS, но выделим его отдельно. С некоторого количества машин посылают жертве максимально возможное количество запросов (например, запросы на соединение). От этого жертва не успевает отвечать на каждый запрос, и в итоге не отвечает на пользовательские запросы, т.е. перестаёт нормально функционировать. Можно выделить следующие типы Flood:

SYN Flood — при данном виде атаки на атакуемый узел направляется большое количество SYN-пакетов по протоколу TCP. При этом на атакуемом сервере через короткое время исчерпывается количество открытых сокетов и сервер перестаёт отвечать.

UDP Flood — этот тип флуда атакует не компьютер-цель, а его канал связи. Провайдеры резонно предполагают, что UDP более приоритетен, чем TCP. Большим количеством UDP-пакетов разного размера вызывается перегрузка канала связи, и сервер, работающий по протоколу TCP, перестаёт отвечать.

ICMP Flood или Ping Flood – То же самое, что SYN Flood только пакетами ICMP. Система должна ответить на такой пакет, тем самым создаётся большое количество пакетов, которые снижают производительность канала.

Identification Flood (Ident Flood) – Похож на ICMP Flood, но ответ на запрос на порт 113 типа identd занимает у системы больше времени, поэтому атака более эффективна.

DNS Flood – атака направлена на DNS сервера. Их наводняют DNS запросы, на которые сервер не успевает отвечать, таким образом, на Ваши запросы он так же ответить не сможет. Как следствие, Вы не можете посещать Интернет сайты.

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

Boink (Bonk, Teardrop) – Жертве посылается огромное количество сильно фрагментированных пакетов, но при этом фрагменты большого размера. Для каждого фрагментированного пакета выделяется специальный буфер, в который в последствии будут помещены другие фрагменты, чтобы потом сложить их воедино. Огромное количество больших фрагментов переполняют буфера и могут спровоцировать зависание или аварийную остановку.

HTTP flood (POST, GET) – Один из самых распространенных на сегодняшний день способов «флуда». Основан на бесконечной посылке HTTP-сообщений на 80й порт с целью загрузить веб-сервер настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто целью «флуда» становится не корень веб-сервера, а один из скриптов, выполняющих ресурсоемкие задачи или работающий с базой данных.[7]

  1.  
    Методы защиты от DDoS-атак

Борьба с распределенными DoS-атаками – дело достаточно непростое. Во-первых, очень трудно установить организатора атаки, а пользователи, чьи компьютеры генерируют паразитический трафик, как правило, даже не подозревают, что их машины стали инструментом в руках злоумышленников. Во-вторых, практически невозможно отличить вредоносный трафик от легитимного, поскольку по сути это те же самые запросы, что и от обычных пользователей, но в неизмеримо большем количестве.

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

  1.  Маршрутизация в «черные дыры»

Процесс маршрутизации в «черные дыры» применяется провайдером услуг для блокировки всего трафика, адресованного на целевой объект, в как можно более ранней точке. «Снятый с маршрута» трафик маршрутизируется в «черную дыру» для защиты сети провайдера и других его клиентов. Маршрутизацию в «черные дыры» нельзя назвать удачным решением, поскольку вместе со злоумышленным трафиком атаки отбраковываются и благонадежные пакеты. Жертвы полностью лишаются своего трафика, и хакер празднует победу.

  1.  Списки контроля доступа 

Многие полагают, что маршрутизаторы, на которых применяются списки контроля доступа (ACL) для фильтрации «нежелательного» трафика, обеспечивают защиту от атак DDoS. Действительно, списки ACL могут защитить от простых и известных атак DDoS, например, от ICMP-атак, фильтрация второстепенных, неиспользуемых протоколов.

Однако на сегодняшний день в атаках DDoS, как правило, используются корректные действующие протоколы, которые необходимы для присутствия в сети Интернет, и поэтому фильтрация протоколов становится менее эффективным средством защиты. Маршрутизаторы также могут блокировать зоны с некорректными IP-адресами, однако хакеры, чтобы их не обнаружили, обычно подделывают корректные IP-адреса. В целом, хотя списки ACL на маршрутизаторах служат первой линией обороны от базовых атак, они не оптимизированы для защиты от следующих сложных атак DDoS:

  •  SYN, SYN-ACK, FIN и другие лавинные атаки. Списки ACL не могут заблокировать атаку SYN с произвольным выбором объектов спуфинга (проставление в поле обратного адреса IP-пакета неверного адреса) или атаки ACK и RST на 80-й порт Веб-сервера, при которых поддельные IP-адреса источника постоянно меняются, поскольку для этого потребовалось бы вручную отследить и идентифицировать каждый подделанный источник, а эта задача практически невыполнима. Единственный возможный вариант здесь состоит в том, что заблокировать весь сервер, а именно в этом и состоит задача хакера.
  •  Proxy – Поскольку списки ACL не могут отличить друг от друга «благонадежные» и «злоумышленные» SYN, поступающие из одного исходного IP или Proxy, то, пытаясь остановить сфокусированную атаку со спуфингом, они вынуждены, по определению, блокировать весь трафик клиентов жертвы, поступающий из определенного исходного IP или Proxy (модуля доступа).
  •  DNS или протокол пограничного шлюза (Border Gateway Protocol, BGP) – Когда запускаются атаки с произвольным выбором объектов спуфинга на сервер DNS или на маршрутизатор BGP, списки ACL, как и в случае с лавинными атаками SYN, не могут отследить быстро меняющийся объем трафика с произвольно выбранными объектами спуфинга. Кроме этого, списки ACL не в состоянии отличить поддельные адреса от корректных.
  •  Атаки на уровне приложений (клиентские) – Хотя списки ACL теоретически могут блокировать клиентские атаки, например, атаки с ошибочными соединениями HTTP и с полуоткрытыми соединениями HTTP (при условии, что есть возможность точно идентифицировать источник атаки и конкретные не подделанные источники), пользователям потребуется конфигурировать сотни, а в некоторых случаях и тысячи списков ACL для каждой потенциальной жертвы.
    1.  Межсетевые экраны

Хотя межсетевые экраны играют исключительно важную роль в системе безопасности любой компании, они не созданы именно как инструмент предотвращения атак DDoS. Фактически, у межсетевых экранов есть ряд исходных свойств, которые не позволяют им обеспечить полную защиту от самых изощренных современных атак DDoS. Прежде всего, это отсутствие механизма выявления аномалий. Межсетевые экраны в первую очередь предназначены для контроля доступа в частные сети, и они отлично справляются с этой задачей. Один из путей выполнения этой задачи – отслеживание сеансов, которые инициированы изнутри (на «чистой» стороне) и адресованы на внешний сервис, и последующий прием только особых откликов от ожидаемых источников на внешней стороне. Однако такая схема не действует применительно к таким сервисам как Web, DNS, и к другим сервисам, которые должны быть открыты для общего доступа, чтобы была обеспечена возможность принимать запросы. В подобных случаях межсетевые экраны выполняют операцию, которая называется «открыванием канала»: они пропускают трафик HTTP на IP-адрес веб-сервера. Хотя такой подход и обеспечивает некоторую защиту, поскольку разрешены лишь определенные протоколы, адресуемые на определенные адреса, он не слишком эффективен в борьбе с атаками DDoS, поскольку хакеры могут без труда воспользоваться «разрешенным» протоколом (в данном случае HTTP) для переноса трафика атаки. Отсутствие возможностей для выявления аномалий означает, что межсетевые экраны не могут распознать ситуацию, в которой носителем атаки служат корректные разрешенные протоколы.

Также в межсетевых экранах отсутствуют ресурсы борьбы со спуфингом. Если выявлена атака DDoS, межсетевые экраны могут заблокировать конкретный поток трафика, связанный с атакой, но не могут применить меры антиспуфинга, чтобы отделить хороший, «благонадежный» трафик от плохого, а именно эта операция важна для защиты от атак, в которых используется большой объем подделанных IP-адресов.

  1.  Реакция на атаки DDoS-атаки, инициируемая вручную

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

  1.  Другие стратегии

Специалисты компаний могут использовать для противостояния атакам DDoS различные стратегии, в частности, применение резервных ресурсов, т.е. закупку резервной полосы пропускания или резервных сетевых устройств, которые помогут справиться с любым пиковым ростом спроса. Такой подход не отличается высокой рентабельностью, особенно из-за того, что необходимо вводить резервные сетевые интерфейсы и устройства. И, независимо от первоначального эффекта, для того чтобы одолеть эти дополнительные мощности хакерам понадобится лишь увеличить масштабы атаки. [2]

  1.  
    Анализ аномалий в сети

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

Наиболее эффективный способ обнаружить DDoS-атаку основан на накоплении статистических данных о прохождении трафика в сети. Составив картину нормального состояния сети, всегда можно отследить возникновение какой-либо аномалии в сетевом трафике.

В качестве источника данных для статистики можно использовать сам трафик или некоторую статистическую информацию о нем. Для этого используются либо дополнительные сенсоры, устанавливаемые на сеть, либо информация, которую могут предоставить существующие сетевые элементы. В случае снятия такой информации непосредственно с маршрутизаторов обычно используется протокол Netflow. Этот протокол был в свое время разработан для оптимизации работы маршрутизаторов, его задача заключалась в том, чтобы не обрабатывать каждый пакет, а перенаправлять его как можно быстрее, если он соответствовал требованиям потока. Протокол оказался неэффективным для решения основной задачи, но очень пригодился для борьбы с DDoS-атаками и шире — для анализа работы сети в целом. Такие способности протоколу дает заложенная в него возможность формировать таблицу, в которой в динамическом режиме прописываются все статистические данные по пришедшим потокам и пакетам: откуда пришел пакет, куда он направляется, какой у него протокол, порт, какое количество данных передано. Причем имеется возможность экспорта статистических данных во внешние системы для последующего анализа.

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

После обнаружения факта аномалии происходит ее классификация и определяется, насколько она серьезна. Если DDoS-атака не грозит возникновением проблем в сети, то лучше наблюдать и ничего не предпринимать, так как возникает вероятность не пустить на ресурс законного пользователя.[5]

  1.  
    Пример архитектуры защиты от DDoS-атак

Общая схема противодействия DDoS-атакам представлена на рис.2.

Рис.2. Схема противодействия DDoS-атакам

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

В нормальном режиме работы данные устройства не должны оказывать никакого влияния на проходящий трафик. В случае же атаки устройство «очистки» задерживает трафик, идентифицируемый как DDoS-пакеты, не допуская его попадания в относительно узкополосные клиентские каналы и на клиентские ресурсы, тем самым не прерывая предоставление клиенту основной услуги.[9]

  1.  
    Анализ рынка

На рынке существуют два основных вендора, предлагающих специализированные системы для борьбы с DDoS-атаками операторского класса (Cisco Systems и Arbor Networks), а также ряд продуктов, пригодных для решения данной задачи в меньших объемах или ориентированных на частные случаи. В зависимости от популярности сайта и мощности атак защита может стоить от тысяч до десятков тысяч долларов в месяц. Например, оборудование от компании Cisco Systems, будет стоить около $40 000. [5]

  1.  Коммерческие решения
    1.  Решение от компании Cisco для защиты от DDoS-атак

Технология Cisco Clean PIPes предполагает использование модулей Cisco Anomaly Detector и Cisco Guard, а также различные системы статистического анализа сетевого трафика, основанные на данных, получаемых с маршрутизаторов по протоколу Cisco Netflow. При этом Anomaly Detector и системы статистического анализа трафика выступают в качестве систем обнаружения DDoS-атак, а Cisco Guard как средство противодействия уже обнаруженной атаке. В отличие от других способов защиты от DDoS-атак, решение Cisco Clean PIPes по защите от DDoS-атак позволяет не просто блокировать атакующие адреса, а отделить вредоносный трафик от обычного. Защиту сети от DDoS обеспечивают три основнве функции, которые предлагает решение:

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

Подавление – процесс «чистки» трафика (анти-спуфинг, распознавание аномалий, проверка пакетов и «очистка»: отбрасывание «плохого» трафика и разрешение прохождения «хорошего» до конечного назначения).

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

Рис. 3 Схема работы компонентов Cisco Clean PIPes

Cisco Clean PIPes – комплексное глобальное решение, включающее системы обнаружения аномалий и подавления DDoS-атак. В отличие от существующих способов защиты от DDoS-атак решение Cisco Clean PIPes может точно отличать «вредоносный» трафик, направляемый на важный хост или приложение, от «легитимного». В процессе реализации проекта решение развертывается рядом с маршрутизаторами и коммутаторами и легко масштабируется, благодаря чему устраняются любые точки возможного сбоя и не ухудшается быстродействие и надежность существующих сетевых компонентов. Основной недостаток такого решения – высокая цена, только очень крупные компании могут себе позволить установку оборудования от Cisco.

Доступно по:

https://www.cisco.com/web/RU/netsol/ns480/networking_solutions_sub_solution_home.html

  1.  Ados – система защиты веб-сервера от DDoS-атак 

Главным рабочим процессом Ados является демон ados_daemon, который получает доступ к TCP пакетам, посылаемым HTTP клиентами, до их обработки TCP/IP стеком в ядре, и может либо пропустить пакет, либо отвергнуть его. Решение о судьбе пакета принимается по результатам поиска IP-адреса источника пакета в списках IP-адресов, формируемых в процессе работы Ados (или загружаемых при старте демона). Таких списков поддерживается 3:

  •  Ban list (банлист, черный список): IP-адреса, пакеты с которых блокируются. Этот список имеет наивысший приоритет.
  •  White list (белый список): IP-адреса, которые не записываются в банлист независимо от характера и частоты приходящих с них HTTP-запросов.
  •  Track list (треклист): IP-адреса, с которых зарегистрированы HTTP-запросы, но решение по которым еще не принято.

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

При регистрации первого запроса с какого-либо IP информация об этом IP и количестве запросов каждого класса с него помещается в трек-лист и сохраняется в течение некоторого промежутка времени (track period, период анализа). Каждый запрос с данного IP, зарегистрированный за период анализа, увеличивает счетчик запросов соответствующего класса. По окончании периода анализа вычисляется «усредненная частота запросов»:

rate = (C1*W1+C2*W2+...+Cn*Wn)/track_period,

Ci – количество запросов одного класса,

Wi – вес этого класса

которая сравнивается с порогом срабатывания flt_rate_threshold (задается в конфигурации). При превышении порога IP помещается в бан-лист, если он не присутствует в белом списке.

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

Ados – система недорогой, но универсальный метод борьбы с атаками DDoS.

Доступно по: http://www.ddosu.net/addos-description

  1.  Некоммерческие Unix продукты для защиты от HTTP flood

Существует 2 вида защит – средствами веб-сервера (например, Apache или Nginx) и средствами дополнительных модулей (например, средствами php, perl, bash). Хороший результат может дать комбинация этих способов.

  1.  Стандартный способ обнаружения атаки HTTP-flood

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

Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт:

# ps aux | grep HTTPd | wc -l

# netstat -na | grep ":80\ " | wc -l

Значения, в несколько раз превышающие среднестатистические, дают основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:

# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less

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

# tcpdump -n -i eth0 -w attack.log dst port 80 and host IP_сервера

Запишет в файл attack.log все запросы на 80 порт. Показателем будет служить большой поток однообразных пакетов от разных IP, направленных на один сервис (например, корень веб-сервера или определенный cgi-скрипт).

# tcpdump -nr attack.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}\.[0-9]{1,}' |sort |uniq -c |sort -rn | head -20

Выведет 2 столбца, в первом количество подключений, во втором IP адрес. Чем больше подключений для одного IP тем вероятнее что это бот.[7]

  1.  Фильтрация пакетов по URL с помощью расширения iptables

В iptables реализовано расширение string, которое позволяет выполнять фильтрацию пакетов, основываясь на анализе содержимого области данных пакета.

Если атака идет на одну страницу сайта, например, посылаются запросы вида "GET /dir/site.php HTTP/1.0", то по этому критерию можно отбрасывать все запросы, идущие на эту страницу:

#iptables -I INPUT -p tcp --dport 80 -m string --string "GET /dir/site.php HTTP/1.0" --algo kmp -j DROP

Таким образом, сайт защищен от DDOS-атаки и сохраняет работоспособность, пусть и ценой временного отключения страницы.[7]

  1.  Фильтрация запросов из «нежелательных» стран

Если сайт ориентирован на вполне конкретную языковую группу, например на русскоязычных пользователей Интернета, атаку на него можно значительно ослабить, если сервер перестанет обрабатывать запросы из «нежелательных» стран.[10]

Фильтровать трафик по странам можно с помощью iptables и расширения  geoip.

Пример пользования:

#iptables -A INPUT --dport 25 -m geoIP --src-cc RU -j ACCEPT

#iptables -A INPUT --dport 25 -j LOG --log-prefix "Blocked smtp from not RU:"

#iptables -A INPUT --dport 25 -j REJECT

  1.  Модуль apache mod_evasive для защиты от HTTP-flood 

Часто для защиты от неинтенсивных атак на сайт используется модуль apache mod_evasive. Этот модуль при превышении определенного числа запросов к сайту с одного IP-адреса, временно блокирует атакующего, выдавая в ответ на запросы ошибку 403 Forbidden. При незначительных атаках на сайт это позволяет снизить нагрузку.

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

Mod_evasive может вызывать внешний скрипт. Таким образом можно организовать блокирование IP-адреса атакующего на уровне фаервола.[11]

  1.  Борьба с HTTP-flood средствами веб-сервера Nginx
    1.  Использование «cookie» для обнаружения «ботов»

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

Сначала нужно спрятать основной веб-сервер, например повесив на 8080 порт, а на его место поставить быстрый Nginx, и сконфигурировать страницу-заглушку. В качестве примера подойдет стандартный конфиг nginx, единственное, что нужно сделать — добавить «cookie», дописав в конфиге nginx:

add_header Set-Cookie "type=this-is-not-bot";

На самой странице-заглушке можно написать нечто вроде «Извините, сайт под DDOS, включите «cookie» в браузере и нажмите на ссылку для перехода».[12]

Когда посетитель откроет такую страницу, то при следующем запросе он передаст «cookie», на основе которой можно направить трафик к спрятанному веб-серверу:

#iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string "this-is-not-bot" --algo kmp -j REDIRECT --to-ports 8080

  1.  Ограничение количества соединений с одного IP-адреса

В Nginx реализован модуль ngx_http_limit_zone_module, который позволяет ограничивать количество соединений для заданной сессии или, как частный случай, с одного IP адреса.

Можно сделать предположение о том, что хорошие клиенты делают не более 2х одновременных запросов к одной странице сайта. Считать клиентов, открывших более 3х одновременных соединений, атакующими ботами и банить их IP адресы на фаерволе.

Для реализации поиска ботов надо создать специальную обработку запросов  в Nginx:

error_log /var/log/nginx/error.log;

<…>

location =/ {

limit_conn one 3;

root /var/www/domain.ru;

}

IP-адреса, с которых было открыто более 3х одновременных подключений, будут записаны в error.log с сообщением limiting connections by zone. На основе лога ошибок можно построить blacklist IP атакующего ботнета.

Рис.4. Схема фильтрации адресов, превышающих лимит соединений

Доступно по: http://habrahabr.ru/blogs/infosecurity/84172/

  1.   Фильтрацию пакетов по URL

Фильтрацию пакетов по URL можно реализовать средствами Nginx. Например, по критерию POST index.php?action=login с пустым реферером (URL источника запроса) можно реализовать так:

set $add 1;

location /index.php {

limit_except GET POST {

deny all;

}

set $ban “”;

if ($HTTP_referer = “” ) {set $ban $ban$add;}

if ($request_method = POST ) {set $ban $ban$add;}

if ($query_string = “action=login” ){set $ban $ban$add;}

if ($ban = 111 ) {

access_log /var/log/nginx/ban IP;

return 404;

}

proxy_pass HTTP://127.0.0.1:8000; #проксируем на apache

}

  1.  
    Наивный Байесовский классификатор

Байесовский классификатор – это классификатор, использующий теорему Байеса для определения вероятности принадлежности наблюдения (элемента выборки) к одному из классов C при условии того, что зависимые переменные принимают заданные значения: P(C|F1 ,...,Fn ). То есть, если на основе значений переменных можно однозначно определить, какому классу относится наблюдение, байесовский классификатор сообщит, что вероятность принадлежности к этому классу равна 1. В промежуточных же случаях, когда наблюдение может с разной вероятностью принадлежать к различным классам, результатом работы классификатора будет вектор, компоненты которого являются вероятностями принадлежности к тому или иному классу.

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

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

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

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

  1.  Математическая постановка задачи

Множество пар «запрос, класс» X x Y является вероятностным пространством с неизвестной вероятностной мерой P. Имеется конечная обучающая выборка наблюдений , сгенерированная согласно вероятностной мере P. Требуется построить функцию a: X  Y, способную классифицировать произвольный запрос x  X .

  1.  
    Вывод

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

Сетевые администраторы придумали много способ защиты, но все они не универсальны и не решаются сразу всех задач при отражении сколько-нибудь мощного DDoS:

  •  Сохранить работоспособность сервиса;
  •  Отразить максимальное количество ботов и минимум легитимных пользователей;
  •  Не допустить блокировки адресов поисковых систем;

Поэтому принято решение разработать систему, которая будет учитывать все преимущества данных методов, а именно система будет:

  •  обучаться на «хорошем» трафике,
  •  учитывать с какого IP-адреса идет запрос,  
  •  учитывать количество запросов с одного IP-адреса,  
  •  учитывать страну, из которой идет запрос,
  •  учитывать метод запроса,
  •  учитывать адрес подсети,
  •  страницу, которая запрашивается с данного IP-адреса,
  •  страницу входа на сайт,
  •  тип браузера,
  •  тип операционной системы.
  1.  
    Специальная часть проекта
    1.  Проектирование системы классификации запросов

При большом количестве запросов по HTTP протоколу веб-сервер Apache не успевает корректно обрабатывать запросы и может выйти из строя. Для получения дополнительных ресурсов для обработки большего количества запросов, в последнее время широко используется двухуровневая архитектура обработки запросов с двумя веб-серверами: frontend и backend, где в качестве frontend сервера используется Nginx – HTTP-сервер и IMAP/POP3 прокси-сервер для UNIX-подобных платформ. На данный момент nginx работает на большом количестве высоконагруженных сайтов (среди них — Рамблер, Яндекс, В Контакте, wordpress.com, Wrike и другие).

Cуществуют три модели работы сервера:

  1.  Последовательная. Сервер открывает слушающий сокет и ждет, когда появится соединение (во время ожидания он находится в заблокированном состоянии). Когда приходит соединение, сервер обрабатывает его в том же контексте, закрывает соединение и снова ждет соединения. Очевидно, это далеко не самый лучший способ, особенно когда работа с клиентом ведется достаточно долго и подключений много. Кроме того, у последовательной модели есть еще много недостатков (например, невозможность использования нескольких процессоров), и в реальных условиях она практически не используется.
  2.  Многопроцессная (многопоточная). Сервер открывает слушающий сокет. Когда приходит соединение, он принимает его, после чего создает (или берет из пула заранее созданных) новый процесс или поток, который может сколь угодно долго работать с соединением, а по окончании работы завершиться или вернуться в пул. Главный поток тем временем готов принять новое соединение. Это наиболее популярная модель, потому что она относительно просто реализуется, позволяет выполнять сложные и долгие вычисления для каждого клиента и использовать все доступные процессоры. Пример ее использования – веб-сервер Apache. Однако у этого подхода есть и недостатки: при большом количестве одновременных подключений создается очень много потоков (или, что еще хуже, процессов), и операционная система тратит много ресурсов на переключения контекста. Особенно плохо, когда клиенты очень медленно принимают контент. Получаются сотни потоков или процессов, занятых только отправкой данных медленным клиентам, что создает дополнительную нагрузку на планировщик ОС, увеличивает число прерываний и потребляет достаточно много памяти.
  3.  Неблокируемые сокеты/конечный автомат. Сервер работает в рамках одного потока, но использует неблокируемые сокеты и механизм поллинга (периодический опрос сервера). Т.е. сервер на каждой итерации бесконечного цикла выбирает из всех сокетов тот, что готов для приема/отправки данных с помощью вызова select(). После того, как сокет выбран, сервер отправляет на него данные или читает их, но не ждет подтверждения, а переходит в начальное состояние и ждет события на другом сокете или же обрабатывает следующий, в котором событие произошло во время обработки предыдущего. Данная модель очень эффективно использует процессор и память, но достаточно сложна в реализации. Кроме того, в рамках этой модели обработка события на сокете должна происходить очень быстро – иначе в очереди будет скапливаться много событий, и в конце концов она переполнится. Именно по такой модели работает Nginx. Кроме того, он позволяет запускать несколько рабочих процессов (так называемых workers), т.е. может использовать несколько процессоров.

Таким образом, перед веб-сервером Apache размещаем легкий и быстрый веб-сервер Nginx и даем ему возможность обслуживать запросы к статическим файлам, а запросы к динамическим файлам проксировать к главному серверу. При таком решении сервер Apache не создает дополнительных процессов для обработки статических страниц и файлов и  отдает результаты обработки динамических запросов frontend-серверу очень быстро, что позволяет ему освободить ресурсы для использования в обработке других запросов. Frontend-сервер же может ждать сколь угодно долго, пока клиент заберет свой «ответ» и закроет соединение, а backend-сервер не тратит ресурсы для этого.[15]

Диаграмма конфигурации веб-сервера выглядит следующим образом:

Рис. 5. Диаграмма конфигурации веб-сервера

Благодаря двухуровневой архитектуре, существенно меньше расходуется ресурсов ОС и памяти и веб-сервер может обработать больше обращений. Но с увеличением мощности атаки создается множество  потоков/процессов на Apache, которые не успевают  генерировать контент и отдавать его Nginx, поэтому между frontend-сервером и backend-сервером разместим программу, которая будет классифицировать запросы, поступающие на веб-сервер Nginx, и отбрасывать DDoS-ботов, не пропуская их в последствии к Apache.  

Диаграмма конфигурации веб-сервера с Antiddos-демоном:

Рис.6. Диаграмма конфигурации веб-сервера с Antiddos-демоном

При обращении пользователя запрос поступает на  frontend-сервер, и там либо обрабатывается и возвращается ответ пользователю, либо передается дальше в систему – на программу классификации запросов (antiddos-daemon) и на веб-сервер Apache. Программа оценивает запрос в соответствие с классификацией по интеллектуальному алгоритму, учитывающему запросы пользователей до атаки на веб-сервер, и в зависимости от результата классификации запрещает обработку запросов от данного пользователя при помощи межсетевого экрана, либо не препятствует нормальной работе серверов.  

  1.  
    Настройка веб-сервера
    1.  Настройка веб-сервера Nginx в связке с Apache на Debian Lenny

Основная задача – настроить Nginx на прослушивание запросов с внешних адресов на 80-м порту, обработка статических запросов, и проксирование остальных запросов на веб-сервер Apache на локальный адрес и порт 81 (192.168.0.1:81).

Установка необходимого программного обеспечения:

>apt-get install nginx apache2

Также необходимо установить пакет libapache2-mod-rpaf, чтобы в apache-log записывались реальные IP-адреса пользователя, а не адрес frontend-сервера.

>apt-get install libapache2-mod-rpaf

Конфигурационный файл Nginx (/etc/nginx/nginx.conf) оставим в первоначальном виде (логи запросов записываются в /var/log/nginx/access.log).

Создаем настройки для поддерживаемых ресурсов в /etc/nginx/sites-available/default:

server {

       listen   80;

       server_name domain.ru www.domain.ru;

       access_log  /var/logs/nginx-access.log;

       location / {

               proxy_pass         HTTP://192.168.0.1:81/; # переадресация запросов на apache

               proxy_redirect     off;

               proxy_set_header   Host             $host;

               # Эти настройки необходимы, чтобы из скриптов было видно реальные IP #пользователя, а не фронт-части

               proxy_set_header   X-Real-IP        $remote_addr;

               proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

               client_max_body_size       10m;

               client_body_buffer_size    128k;

               proxy_connect_timeout      90;

               proxy_send_timeout         90;

               proxy_read_timeout         90;

               proxy_buffer_size          4k;

               proxy_buffers              4 32k;

               proxy_busy_buffers_size    64k;

               proxy_temp_file_write_size 64k;

       }

}

Далее настраиваем apache на прослушивание 81го порта с внутреннего интерфейса, поправив /etc/apache2/ports.conf:

NameVirtualHost *:81

Listen 192.168.0.1:81

И необходимо подправить настройки хостов apache в /etc/apache2/sites-available/default, заменив 80й порт на 81:

<VirtualHost *:81>

Таким образом попасть на Apache теперь можно только через Nginx, т.е. снаружи Apache недоступен.

  1.  
    Настройка модуль для записи статистики apache в СУБД MySQL

Обучение классификатора запросов производится по логам веб-сервера Apache. Для увеличения быстродействия работы программы классификации запросов, при выборке из логов, будем записывать access log в СУБД MySQL. Для этого надо установить модуль mysql libapache2-mod-log-sql-mysql.

#apt-get install apache2 mysql-server mysql-client libapache2-mod-log-sql-mysql

После установки, создаём базу данных:

#mysql -uroot -p -hlocalhost

#create database apachelogs;

Редактируем конфигурационный файл Apache:

#vi /etc/apache2/sites-available/default

LogSQLLoginInfo mysql://loguser:loguser_rootroot@localhost/apachelogs    

# Хост, имя пользователя, пароль для соединения с mysql

LogSQLCreateTables on        # Создавать или нет таблицу, для хранения логов

LogSQLDBParam socketfile /var/run/mysqld/mysqld.sock       # Сокет MySQL

LogSQLTransferLogFormat AbHhmRSsTUuvI     # что писать, а что нет в #таблицу с логами

<VirtualHost *:81>

       ServerAdmin webmaster@localhost

       DocumentRoot /var/www/

       <Directory /var/www/>

               Options Indexes MultiViews

               AllowOverride None

               Order allow,deny

               allow from all

       </Directory>

       LogSQLTransferLogTable web1_access_log       # имя таблицы, в которую писать логи

</VirtualHost>

LogSQLLoginInfo mysql://loguser:loguser_rootroot@localhost/apachelogs   (Директива содержит параметры подключения к базе данных)

LogSQLCreateTables on        

(Указывает модулю mod_log_sql создавать таблицы, если они не существуют)

LogSQLDBParam socketfile /var/run/mysqld/mysqld.sock

(Определяет сокет MySQL)

LogSQLTransferLogFormat AHhmRprSstUuv   

(Директива определяет какие колонки создавать в таблице)

Записываем только те колонки, которые будем использовать для анализа запросов:

?

Что означает

Имя колонки

Тип колонки

Пример

A

User agent

agent

varchar(255)

Mozilla/4.0(compat;MSIE 6.0;Windows)

H

HTTP протокол

request_protocol

varchar(255)

HTTP/1.1

h

Имя удален. Хоста

remote_host

varchar(255)

blah.foobar.com

m

Метод запроса

request_method

varchar(255)

GET

P

PID процесса

child_pid

Smallint unsigned

3215

p

HTTP порт

server_port

Smallint unsigned

80

R

Реферер

referer

varchar(255)

HTTP://www.biglinks4u.com/page.html

r

Полный запрос

request_line

varchar(255)

GET /foo.htm HTTP/1.1

S

Время в UNIX

time_stamp

int unsigned

1005598029

s

Статус запроса

status

Smallint unsigned

404

t

Время

request_time

char(28)

[02/May/2010:15:01:26 -0800]

U

Краткий запрос

request_uri

varchar(255)

/books-cycroad.html

u

Логин (из авторизации)

remote_user

varchar(255)

bobby

v

Виртуальный хост

virtual_host

varchar(255)

www.lissyara.su

LogSQLTransferLogTable web1_access_log

(Определяет имя таблицы, директива прописывается в виртуальном хосте конфигурации – таким образом, можно задать различные таблицы журнала доступа для каждого виртуального хоста).

После внесения всех изменений в конфигурационные файлы, перезапускаем Apache:

#/etc/init.d/apache2 reload

Для проверки создания таблицы, входим на сервер MySQL:

#mysql -uroot -hlocalhost -prootroot

mysql> use apachelogs;

mysql> show tables;

+----------------------+

| Tables_in_apachelogs |

+----------------------+

| web1_access_log      |

+----------------------+

1 row in set (0.00 sec)

Выберем для примера все колонки таблицы, где «время в UNIX» равно «1265021581»:

mysql> SELECT * FROM web1_access_log WHERE time_stamp=1265021581;

+--------------------+------------------------+-----------------------+-------------------------------------------

agent | request_protocol | remote_host | request_method | child_pid | server_port | referrer | request_line | time_stamp | status | request_time | request_uri | remote_user | virtual_host

+--------------------+------------------------+-----------------------+-------------------------------------------

+--------------------+------------------------+-----------------------+---------------------------------

Mozilla/5.0 (Windows; U; Windows NT 5.1) | HTTP/1.0 | 192.168.1.15 | GET | 51 | NULL | – | NULL |  1265021581 | 200 | [01/Feb/2010:13:53:00 +0300] | /mysql_test.php/ | NULL | debian.localdomain |

1 rows in set (0.00 sec)

Так как выборка будет часто осуществляться по полям «время в UNIX» и «Имя удаленного хоста», то присвоим первичный ключ данным столбцам:

mysql>ALTER TABLE  web1_access_log ADD INDEX(time_stamp, remote_host) 

  1.  Вывод

Произведена настройка связки веб-сервера Nginx c Apache так, что Nginx теперь выступает как прокси-сервер, весь трафик идущий на Apache  проходит через frontend-сервер. Веб-сервера Nginx и Apache установлены на двух разных машинах. Программа классификации запросов устанавливается на frontend-сервере и обращается к базе данных с логами Apache на вторую машину. Таким образом, система будет работать до тех пор, пока будет выдерживать нагрузку веб-сервер Nginx, с чем он справляется при правильной настройке отлично. В настоящее время практически не производится DDoS-атак такой мощности, способные забить память и вывести из строя данный прокси-сервер.

 

  1.  Обнаружение атаки на веб-сервер

Обнаружение атаки происходит на основе анализа статистических данных, полученных при функционировании веб-сервера в штатном режиме.

В состав системы обнаружения атаки входят следующие файлы:

  •  netstatone.sh – программа считает количество запросов на 80й порт и записывает результат в файл netstat.txt
  •  netstat.txt – текстовый файл, в котором содержатся результаты выполнения программы netstatone.sh
  •  mean.pl – программа считает среднее значение чисел в файле netstat.txt и записывает результат в meanscores.txt
  •  meanscores.txt – текстовый файл, в котором содержатся результаты выполнения программы mean.pl
  •  netstat.sh – программа считает количество запросов на 80й порт и сравнивается это значение со средним, если оно превышает среднее в k раз, программа запускает daemon.pl (программа классификации запросов).

Программы netstatone.sh и netstat.sh реализованы на языке программирования Bash. Количество запросов на 80й порт считается с помощью команды netstat, которая показывать состояние всех активных сокетов:

netstatna | grep “ .80” | wcl 

Программа mean.pl написана на языке PERL. Программа открывает netstat.txt и считает среднее значение чисел в файле, результат выполнения при каждом запуске перезаписывается в файл meanscores.txt. Число, хранящееся в meanscores.txt, является главным критерием принятия решения о запуске классификатора запросов.

Схема обнаружения атаки на веб-сервер:

Рис.7. Обнаружение атаки на веб-сервер

С помощью системы выполнения программ (crontab) происходит регулярный запуск программ netstatone.sh, mean.pl и netstatone.sh, когда система работает в штатном режиме. Cайты в разное время суток посещают разное количество клиентов. Для более объективного подсчета среднего значения принято запускать программу netstatone.sh каждые 5 часов. Mean.pl будет просматривать файл netstat.txt раз в сутки для подсчета среднего значения. А программа netstat.sh будет выполняться каждую минуту и при необходимости запускать daemon.pl.

#crontab -e

SHELL=/bin/bash

PATH=/usr/local/sbin:/usr/local/bin:/sbi:/bin:/usr/sbin:/usr/bin

HOME=/home/root1/diplom/

MAILTO=alina@ht-systems.ru

#m h dom mon dow command

# запускать каждую минуту, каждый день

* * * *  *     $HOME/netstat.sh

# запускать раз в пять часов

* */5 * *  *     $HOME/netstat.sh >> $HOME/netstat.txt 2>&1

# запускать в 02 часа 00 минут

0 2 * *  *     $HOME/netstat.sh >> $HOME/meanscores.txt 2>&1

  1.  
    Схема функционирования системы

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

  •  Клиент инициирует запрос к веб-серверу. IP-адрес HTTP-заголовка, поступающего на 80й порт, проверяется в правилах Netfilter,  если такой адрес существует в правилах на отбрасывание, то пакет удаляется межсетевым экраном, если IP-адреса нет в правилах пакет проходит дальше к веб-серверу Nginx.
  •  Nginx принимает соединение от клиента и читает от него весь запрос. Если запрашивается статический контент, Nginx сам обрабатывает запрос и отдает запрашиваемую страницы клиенту
  •  Если запрашивается динамическая страничка (например, запрос к php-скрипту), Nginx открывает соединение к Apache. Последний выполняет свою работу (генерирует динамический контент), после чего отдает свой ответ Nginx, который его буферизует в памяти или временном файле. Тем временем, Apache освобождает ресурсы.
  •  Далее Nginx медленно отдает контент клиенту, тратя при этом на порядки меньше ресурсов, чем Apache.
  •  Браузер клиента получает ответ, закрывает соединение с сервером и отображает запрошенную страницу.
  •  Nginx записывает все обращения к сайту в журнал доступа (access.log).
  •  Запущенная программа классификации запросов ждет новой записи в журнал. Выхватывает запись и сравнивает с запросами  из журнала доступа веб-сервера Apache (выбираются запросы до начала атаки)
  •  Если запрос «похож» на запросы к серверу до атаки, то он пропускается, если «не похож» IP-адрес из заголовка запроса передается межсетевому экрану на удаление.

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

Рис.8. Диаграмма потока данных

  1.  
    Алгоритм классификации запросов

Задача классификации запросов заключается в определении, к какому классу отнести запрос:

  •  класс DDoS-ботов
  •  класс легитимных пользователей

Основная цель – классифицировать новые запросы по мере их поступления, то есть нужно решить к какому классу они принадлежат, используя информацию о принадлежности к классу легитимных пользователей уже имеющихся запросов. Выборка запросов, будет осуществляться из журналов доступа веб-сервера Apache (apache.log).

Рассматривается условная вероятность принадлежности запроса классу,  при том, что он обладает признаками :

По теореме Байеса:

По определению условной вероятности:

В соответствии с «наивным» байесовским подходом предполагается, что события  независимы для любых :

Соответственно, вероятность отнесения запроса классу, можно вычислить по формуле:

В соответствии с «наивным» байесовским алгоритмом, вероятность принадлежности запроса классу определяется по формуле:

,   где

– атрибуты заголовка HTTP-запроса:

  •  IP адрес, с которого входят на сайт (IP);
  •  Страница, которая запрашивается с данного IP-адреса (url);
  •  Страница входа на сайт (referer);
  •  Тип браузера (user_agent);
  •  Тип операционной системы (os);
  •  Страна, из которой идет запрос (country);
  •  Метод запроса (method).

Классификация запросов происходит по двум классам – DDoS-боты (С) и легитимные пользователи (), поэтому в соответствии с формулой Байеса имеем:

разделив одно выражение на другое, будем иметь:

Взяв логарифм всех этих степеней, имеем:

 

Наконец, запрос может быть классифицирован следующим образом: это DDoS-бот, если >0, иначе это легитимный пользователь.

  1.  Расчет вероятностей

Безусловную вероятность справедливости гипотезы, т.е. насколько вероятна причина вообще, можно вычислить по формуле:

,    где

количество запросов к веб-серверу в текущий момент,

– количество запросов к веб-серверу в среднем.

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

  •  Вероятность, что данную страницу запрашивает легитимный пользователь:

,   где

количество запросов на данную страницу,

- общее число запросов из обучающей выборки.

  •  Вероятность, что с запрашиваемой страницы обращается легитимный пользователь

,   где

- количество запросов с этой страницы,

– общее число запросов из обучающей выборки.

  •  Вероятность, что данный метод запроса (GET, POST) в HTTP-заголовке запрашивает легитимный пользователей:

,   где

- количество запросов этого метода,

– общее число запросов из обучающей выборки.

  •  Вероятность, что с данного IP-адреса обращается легитимный пользователь:

где

t – задается пользователем в конфигурационном файле,

- количество запросов к веб-серверу в текущий момент,

количество запросов к веб-серверу в среднем,

- количество запросов во время атаки на веб-сервер,

количество запросов с данного IP-адреса во время атаки на веб-сервер.

Начало атаки на веб-сервер считается с момента запуска программы классификации запросов.

  •  Вероятность того, с данной операционной системы (os) и типом браузера (user_agent) обращается легитимный пользователь константная и назначается в пользователем в конфигурационном файле.

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

  1.  
    Программа классификации запросов

Программа классификации запросов состоит из 3х файлов:

  •  config.pl – в нем содержится конфигурационная информация (сервер, логин и пароль к БД c логами Apache, пути до файлов системы и внешних программ – iptables, и ряд констант)
  •  daemon.pl – программа классификации запросов
  •  ipddos.txt – текстовый файл, содержащий заблокированные IP-адреса
  •  control.sh – программа, проверяющая, запущен ли демон daemon.pl, если запущен, повторно не запускается.

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

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

В программе daemon.pl реализован следующий алгоритм:

  1.  ожидается запись новой строки в access.log веб-сервера Nginx
    1.  строка считывается и каждый атрибут строки присваивается переменной
    2.  проверяет, если IP-адрес содержится в файле ipddos.txt, то запрос не обрабатывается
    3.  подключается к базе данных, содержащей логии веб-сервера Apache, и производит выборку тех значений, которые содержатся в запросе
    4.  производит подсчет вероятностей классификации атрибутов запроса как как «хорошего» запросов
    5.  производит подсчет вероятностей классификации атрибутов запроса как как DDoS-бота запросов
    6.  производит подсчет полной вероятности классификации запроса по «наивной» теореме Байеса
    7.  если запрос классифицируется как DDoS-бот, IP-адрес из заголовка запроса записывается в файл ipddos.txt и передается файерволу на блокировку:

/sbin/iptables –A INPUT –i eth1 –p tcp –dport 80 --source $ip –j DROP

  1.  возвращается на обработку нового запроса (п.1)

В результате выполнения данного алгоритма при атаке типа «HTTP-flood» достигается защита системы от перегрузки запросами, благодаря разделению по Байесу пользовательских запросов на легитимные и нелегитимные и фильтрации нежелательных запросов.

  1.  
    Охрана труда
    1.  Введение

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

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

Любой производственный процесс, в том числе работа с ЭВМ, сопряжен с появлением опасных и вредных факторов.

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

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

В данном разделе дипломного проекта будет произведен  расчет информационной нагрузки оператора ЭВМ и спроектировано оптимальное рабочее место с точки зрения эргономики.

  1.  Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияние на пользователей

При работе над дипломом использовались:

  1.  Сеть 380 В/220 В;
  2.  Помещения без повышенной опасности (сухие, температура +5 - 30 градусов Цельсия, относительная влажность меньше или равна 60%, коэффициент заполнения менее 0,2);
  3.  Компьютер (монитор LG Flatron(ЭЛТ), системный блок, клавиатура, мышь), принтер, сканер, соответствующий ТСО-95.

Характеристики монитора LG Flatron 775FT(ЭЛТ): разрешение по горизонтали (max) 1280 пикселей; разрешение по вертикали (max) - 1024 пикселей; легко регулируемые контрастность и яркость; частота кадровой развертки при максимальном разрешении   - 50-160 Гц; частота строчной развертки при максимальном разрешении - 30-70 кГц.

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

Из анализа этих рисков видна необходимость соблюдать правила безопасности на рабочем месте и предусмотреть меры защиты от вредоносных факторов.

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

Вычислительная техника питается от сети 220В 50Гц, а безопасное напряжение U < 40В, поэтому появляется опасный фактор – поражение электрическим током.

Воздействие тока на человека, при прохождении через тело, бывает:

  1.  Термическое - нагрев тканей, окружающей среды.
  2.  Электролитическое - разложение крови плазмы.
  3.  Биологическое - раздражение нервных окончаний тканей, судорожное сокращение мышц.
  4.  Механическое - разрыв тканей, получение ушибов, вывихов.

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

Результатом воздействия электрического тока на человека могут быть местные электротравмы - электрические ожоги, электрические знаки, металлизация кожи, уплотнение кожи, механические повреждения и электроофтальмия, - и общие травмы - электроудары. Наиболее опасным переменным током является ток 20 - 100 Гц. Так как компьютер питается от сети переменного тока частотой 50 Гц, то этот ток является опасным для человека.  

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

Особенно электростатический эффект наблюдается у компьютеров, которые находятся в помещении с полами, покрытыми синтетическими коврами.

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

Электромагнитные поля с частотой 60 Гц и выше могут инициировать изменения в клетках животных (вплоть до нарушения синтеза ДНК). В отличие от рентгеновского излучения, электромагнитные волны обладают необычным свойством: опасность их воздействия при снижении интенсивности не уменьшается,  мало того, некоторые поля действуют на клетки тела только при малых интенсивностях или на конкретных частотах.

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

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

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

Во время работы компьютера дисплей создает ультрафиолетовое излучение, при  повышении плотности которого >10 Вт/м2, оно становиться  для человека вредным фактором. Его воздействие особенно сказывается при длительной работе с компьютером.

Ультрафиолетовое излучение - электромагнитное излучение в области, которая примыкает к коротким волнам и лежит в диапазоне длин волн ~ 200 - 400 нм.

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

  1.  200 - 280 нм - бактерицидная область спектра.
  2.  280 - 315 нм - Зрительная область спектра (самая вредная).
  3.  315 - 400 нм - Оздоровительная область спектра.

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

Энергетической характеристикой является плотность потока мощности [Вт/м2]. Биологический эффект воздействия определяется внесистемной единицей эр: 1 эр - это поток (280 - 315 нм), который соответствует потоку мощностью 1 Вт.

Воздействие ультрафиолетового излучения сказывается при длительной работе за компьютером. Максимальная доза облучения:  7.5 мэр*ч/м2 за рабочую смену;  60 мэр*ч/м2 в сутки

  1.  Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов

Защиту от поражения электротоком осуществляют: обеспечением недоступности токоведущих частей от случайных прикосновений; электрическим разделением сети; устранением опасности поражения при появлении напряжения на частях машины; применением специальных электрозащитных средств.

Зануление - это преднамеренное электрическое соединение с нулевым защитным проводником металлических нетоковедущих частей ЭЛУ, которые могут оказаться под напряжением. Применяется в 3-хфазных сетях с заземленной нейтралью при напряжении менее 1000В. Основа принципа защиты занулением: защита человека осуществляется тем, что при замыкании одной из фаз на заземляющий корпус, в цепи появляется ток замыкания, который отключает от потребителя сеть. Ток короткого замыкания еще до срабатывания защиты вызывает перераспределение в сети, приводящее к снижению напряжения на корпусе относительно земли.  где НЗП - нулевой защитный проводник.

Техническим средством защиты от поражения электрического тока является зануление, схема подключения ЭВМ показана на рис. 9.

Рис. 9. Схема подключения ЭВМ

По заданным параметрам определим возможный Jк.з.:

(1),

где:

Jк.з. - ток короткого замыкания [А];

Uф - фазовое напряжение [B];

rm - сопротивление катушек трансформатора [Ом];

rнзп - сопротивление нулевого защитного проводника [Ом];

Uф = 220 В;  Ом ( по паспорту).

                                                      (2),

где:

- удельное сопротивление материала проводника [Ом*м];

l - длина проводника [м];

s – площадь поперечного сечения проводника [мм2].

По заданным параметрам определим возможный :

рмедь= 0,0175 Ом*м

=400 м  ;  =150 м  ;  =50 м ;

;      9,1

По величине  определяет с каким  необходимо в цепь питания включать автомат.

(формула 3), где K – качество автомата.

 

Отсюда следует, что для отключения ПЭВМ от сети в случае короткого замыкания или других неисправностей в цепь питания ПЭВМ необходимо ставить автомат с   Jном= 8 А. 

При повышении напряженности поля Е>15 кВ/м, статическое электричество может привести к сбою в работе ПВЭМ , вплоть до исчезновения информации с ячеек памяти, т.к. элементы вычислительной техники питаются от U = 3-12В.

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

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

Следует использовать:

  1.  Контурное заземление;
  2.  Экраны для снятия статического электричества;
  3.  Использовать антистатическое покрытие полов;
  4.  Влажная уборка помещения.

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

Для снижения уровня воздействия электромагнитных полей НЧ желательно пользоваться следующими мерами:

  1.  экранирование экрана монитора. Поверхность экрана покрывается слоем оксида олова, либо в стекло ЭЛТ добавляется оксид свинца;
  2.  удаление рабочего места от источника электромагнитного поля. Оператор должен находиться на расстоянии вытянутой руки от экрана монитора;
  3.  рациональное размещение оборудования. Необходимо располагать ПЭВМ на расстоянии не менее 1.22 м от боковых и задних стенок других мониторов;
  4.  ограничение времени работы за ПЭВМ. Время непрерывной работы должно составлять не более 4 ч в сутки. За неделю суммарное время работы не должно превышать 20 ч.

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

Эргономические требования к рабочим местам ПЭВМ.

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

  1.  снижать утомляемость;
  2.  увеличивать условия зрительной работы;
  3.  способствовать повышению производительности труда и качества продукции;
  4.  оказывать благоприятное воздействие на психику;
  5.  уменьшать уровень травматизма и повышать безопасность труда.

К освещению предъявляются следующие требования:

  1.  В рабочей зоне освещение должно быть в такой мере, чтобы рабочий имел возможность хорошо видеть процесс работы не напрягая зрение и не наклоняясь (менее чем на 0,5 метра до глаз) к объекту.
  2.  Освещение не должно создавать резких теней, бликов и оказывать слепящее действие. Глаза должны быть защищены от прямых источников света.
  3.  Спектральный состав света должен быть приближен к естественному свету.
  4.  Уровень освещенности должен быть достаточен и соответствовать условиям зрительной работы.
  5.  Уровень освещенности должен обеспечивать равномерность и устойчивость уровня освещенности.
  6.  Освещение не должно создавать блескости как самих источников света, так и предметов, находящихся в рабочей зоне.

Требования к освещению в вычислительных центрах:

  1.  Местное освещение не рекомендуется. Используется общее освещение. Максимальная освещенность 400 лк, блескость менее 15 ед., пульсация менее 10%.
  2.  Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк.
  3.  Следует ограничивать прямую блесткость от источников освещения, при этом яркость светящихся поверхностей (окна, светильники и др.), находящихся в поле зрения, не должна быть более 200 кд/ кв.м.
  4.  Следует ограничивать неравномерность распределения яркости в поле зрения монитором и ПЭВМ, при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1 - 5:1, а между рабочими поверхностями и поверхностями стен и оборудования 10:1.
  5.  Лампы рекомендуется использовать белого света, холодного белого света, наиболее близкие к естественному свету. Мощность ламп 36-40 ВТ, температура 3000-4200 градусов Кельвина, тогда они не дают высокого ультрафиолетового излучения.
  6.  Основной поток естественного света должен быть слева. Солнечные лучи и блики не должны попадать в поле зрения работающего с ПЭВМ.

При выполнении основной работы на мониторах и ПЭВМ, уровень звука не должен превышать 65 дБА. На рабочих местах в помещениях для размещения шумных агрегатов вычислительных машин (АЦПУ, принтеры и др.) уровень звука не должен превышать 75 дБА.

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

Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, гармонирующие с окраской стен и подвешенные в складку на расстоянии 15 - 20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

На рабочем месте нужно принять следующие меры: Нормальные показатели микроклимата на рабочем месте T = 19-22C, φ=60-65%, подвижность воздуха 0,1-0,2 м/c.

Рабочие места с компьютерами должны размещаться таким образом, чтобы расстояние от экрана одного видеомонитора до тыла другого была не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов – не менее 1,2 м.

Экран видеомонитора должен находиться на расстоянии 600 - 700 мм, но не ближе 500. Высота рабочей поверхности стола должна регулироваться в пределах 680-800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм.

Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, глубиной на уровне колен – не менее 450 мм и на уровне вытянутых ног – не менее 650 мм.

Рабочий стул (кресло) должен быть подъемно-поворотным и регулируемым по высоте и углам наклона сиденья и спинки, а также – расстоянию спинки от переднего края сиденья.

Рабочее место должно быть оборудовано подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм и по углу наклона опорной поверхности подставки до 20 градусов; поверхность подставки должна быть рифленой и иметь по переднему краю бортик высотой 10 мм. Рабочее место с персональным компьютером должно быть оснащено легко перемещаемым пюпитром для документов.

Площадь на одно рабочее место с ПЭВМ для взрослых пользователей должна составлять не менее 6,0 кв. м., а объем не менее 20,0 куб. м. Для внутренней отделки интерьера помещений с мониторами и ПЭВМ должны использоваться диффузно - отражающиеся материалы с коэффициентом отражения для потолка - 0,7 - 0,8; для стен - 0,5 - 0,6; для пола - 0,3 - 0,5.

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

Вывод:

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

  1.  
    Вывод

В рамках данной работы были рассмотрены методы DDoS-атак. Были проанализированы основные подходы к защите от атак DDoS в целом и от атак типа «HTTP-flood» в частности, сделан обзор существующих коммерческий решений и решений с открытым исходным кодом.

В качестве практической части была реализована система защиты от распределенных атак на веб-сервер, отвечающая всем поставленным требованиям. На основании теоретических исследований были разработаны оптимальные формулы подсчета вероятностей отнесения атрибутов запросов к одному из двух классов, которые применяются в «наивном» алгоритме Байеса для классификации запросов.

Стоит отметить, что на рынке свободно распространяемого программного обеспечения нет аналогов разработанной системе. Существующие решения классифицируют запросы, основываясь на одном критерии «благонадежности» запроса, а система классификации запросов к веб-серверу, разработанная в данной работе, анализирует запрос сразу по следующим атрибутам:

  •  IP-адреса инициатора,  
  •  количество запросов с одного IP-адреса,  
  •  страна, из которой идет запрос,
  •  метод запроса,
  •  запрашиваемая страница,
  •  страница входа на сайт,
  •  тип браузера,
  •  тип операционной системы.
  1.  
    Список используемой литературы
  2.  DoS-атака: https://ru.wikipedia.org/wiki/DoS-атака
  3.  Технический отчет: Угрозы DDoS – риски, устранение и лучшие практические приемы:

https://www.cisco.com/web/RU/netsol/ns480/networking_solutions_sub_solution_home.html

  1.  Смит П. Оптимизация и защита Linux сервера своими руками. Наука и Техника. Санкт-Петербург, 2006. C. 78-133.
  2.  Вентцель Е.С. Теория вероятности. Издательство «Наука», Москва, 1964. 56 с.
  3.  Ржавин Д. Защита от DDoS-атак — актуальная бизнес-услуга для операторов связи: http://www.pcweek.ru/themes/detail.php?ID=120056
  4.  Зобнин Е. Устоять любой ценой. Методы борьбы с DoS/DDoS-атаками:

http://www.xakep.ru/magazine/xa/129/124/1.asp

  1.  Фоменко З. Классификация DoS-атак: http://www.xakep.ru/magazine/xs/021/012/1.asp
  2.  Шишкин С. Что такое DDOS и как с этим бороться:

 http://netfraud.ru/publication/ttk/5

  1.  Ados - система защиты вебсервера от DDoS-атак:
  2.   http://www.ddosu.net/addos-description
  3.  Защита сервера от DDoS с помощью модуля GeoIP для Apache2: http://www.io-hosts.ru/dikw/311209.php
  4.  Защита от легкой flood и ddos атаки по HTTP-протоколу используя mod_dosevasive: http://www.mironovs.com/os/unix-os/zashhita-ot-legkoj-flood-i-ddos-ataki-po-http-protokolu-ispolzuya-mod_dosevasive.html
  5.  Атаки конкурентов, способные нанести вред вашему сайту: Классический DDOS веб-сервера:

http://www.manageserver.ru/2010/02/20/атаки-конкурентов-способные-нанести-3/

  1.  Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables: http://habrahabr.ru/blogs/infosecurity/84172/
  2.  Бочканов С., Быстрицкий В. ALGLIB//Байесовский классификатор:
  3.         http://alglib.sources.ru/dataanalysis/bayes.php
  4.  Введение в nginx, часть 1: http://greenmice.info/ru/node/115
  5.  Персональный сайт Игоря Сысоева: http://sysoev.ru/
  6.  Торчинский Ф. Практическое пособие администратора UNIX. 2-е издание. Издательство «Символ-Плюс», 2005.
  7.  ГОСТ 12.1.005-99. Вредные вещества. Классификация и требования безопасности.
  8.  ГОСТ 12.1.030-01. Электробезопасность. Защитное заземление.  Зануление.
  9.  ГН 2.2.5.1313, 1314-03. ПДК загрязняющих веществ в воздухе рабочей зоны.
  10.  Долин П.А. Справочник по технике безопасности. М. 1992.
  11.  В.Е. Виглин, Отчистка воздуха и вентиляция на предприятиях РЭП. М. МИЭМ. 1987.
  12.  Юдин Е.Я. и др. Охрана труда в машиностроении. М. 1993.
  13.  Трудовой кодекс РФ (ФЗ №197, 30.12.2001).
  14.  ГОСТ 12.0.003-99. Опасные и вредные производственные факторы.
  15.  ГОСТ 12.1.030-01. Электробезопасность. Защитное заземление. Зануление.
  16.  ГОСТ 12.1.045-01. Электростатические поля. Допустимые условия на рабочих местах.
  17.  ГОСТ Р 50948, 49-96. Общие эргономические требования и требования безопасности и ее параметры для ЭВМ.
  18.  СанПиН №1340-03. Гигиенические требования к персональным ЭВМ и организация работы. Санитарно-гигиеничекие правила и нормы.
  19.  Перова Ю.Ф., Гетовский Ю.В. Электромагнитная безопасность в офисе и дома. М. 1998.


 

А также другие работы, которые могут Вас заинтересовать

81882. Законы организации и динамика их развития 73.5 KB
  Закон композиции отражает необходимость согласования целей организации: они должны быть направлены на поддержание основной цели более общего характера. Для обеспечения однонаправленности целей организации можно использовать систему деревьев целей.
81883. Организация как система управления 75 KB
  Организация в менеджменте - это объединение людей, совместно реализующих некоторую программу или достигающих определенной цели и действующих на основе определенных процедур и правил. В общем смысле под организацией имеют в виду способы упорядочения и регулирования действий отдельных индивидов и социальных групп.
81885. Внешняя среда организации 41.32 KB
  Подвижность среды это скорость с которой происходят изменения в окружении организации. Среда прямого воздействия включает факторы которые непосредственно влияют на операции организации и испытывают на себе прямое влияние операций организации. Зависимость между организацией и сетью поставщиков обеспечивающих ввод указанных ресурсов один из наиболее ярких примеров прямого воздействия среды на операции и успешность деятельности организации.
81886. Понятие и классификация структур управления 34.87 KB
  В рамках структуры управления протекает весь управленческий процесс в котором участвуют менеджеры всех уровней категорий и профессиональной специализации. Структура управления – простая совокупность способов посредством которых процесс труда сначала разделяется на отдельные рабочие задачи а затем достигается координация действий по решению задачи. Типы организационных структур: Иерархический тип – структура которая характеризуется высокой степенью разделения труда иерархией управления многочисленными нормами и правилами поведения.
81887. Основные элементы структуры управления 39.32 KB
  Под структурой управления организацией понимается упорядоченная совокупность взаимосвязанных элементов находящихся между собой в устойчивых отношениях обеспечивающих их развитие и функционирование как единого целого. Элементами структуры управления являются. Структура управления характеризуется наличием связей между её элементами.
81888. Иерархические структуры управления 38.72 KB
  Соблюдение этого принципа должно обеспечивать единство управления. Такая организационная структура образуется в результате построения аппарата управления из взаимоподчинённых органов в виде иерархической лестницы т. Функциональная организационная структура основана на создании подразделений для выполнения определённых функций на всех уровнях управления.
81889. Принципы «рациональной бюрократии» Макса Вебера как основа иерархических структур управления 38.18 KB
  Бюрократия рассматривалась им как некий идеальный образ наиболее эффективный инструмент управления социальными структурами и отдельными структурными единицами. Бюрократию как рациональную машину управления характеризуют: жесткая ответственность за каждый участок работы: координация во имя достижения организационных целей; оптимальное действие безличных правил; четкая иерархическая зависимость. Однако позже Вебер стал различать бюрократию в позитивном смысле западная рациональная система управления и в негативном смысле восточная...
81890. Достоинства и недостатки линейной структуры управления 36.39 KB
  Другими словами все функции управления и подчинения сосредотачиваются у руководителя создается вертикальная линия управления и прямой путь воздействия на подчиненных Преимущества линейной структуры управления: Создает реальные условия для единоначалия обеспечивает единство распоряжения в системе управления ориентирует руководителей в основном на решение оперативных задач. Простота управления один канал связи. Недостатки линейной структуры управления: Высокие требования к руководителю который должен быть подготовлен всесторонне.