Пример:

access-list number deny icmp any any redirect

access-list number deny ip 127.0.0.0 0.255.255.255 any

access-list number deny ip 224.0.0.0 31.255.255.255 any

access-list number deny ip host 0.0.0.0 any

Практически во всех операционных системах межсетевых экранов существует возможность принудительно перевести межсетевой экран в режим проверки адреса источника каждого пакета. Это будет работать только в случае, если маршрутизация симметричная. Если сеть будет построена так, что путь трафика от хоста А до хоста В будет проходить другим путем, чем трафик от B до A, проверка всегда будет давать неверный результат, и связь между хостами будет невозможна. Данная проверка известна как reverse path forwarding (RPF).

Для атаки типа «smurf» обычно используется IP directed broadcasts.

«IP directed broadcast» - это пакет, который посылается на адрес broadcast, то есть широковещательный адрес подсети, к которой посылающая система напрямую не подключена. «Directed broadcast» маршрутизируется через сеть как обыкновенный пакет, пока не достигнет подсети назначения.

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

При атаке типа «smurf» атакующий посылает пакеты «ICMP echo requests», используя сфальсифицированный адрес источника, и все хосты подсети отвечают на подмененный адрес источника.

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

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

2.1.4 Методика защиты от DoS и DDoS атак

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

Одним из мероприятий по противодействию атакам такого характера является ограничение допустимого предела или rate limit. Лучший способ немедленной помощи, доступный большинству компаний, должно быть «ограничение допустимого предела» злонамеренного типа трафика. Ограничение допустимого предела накладывает ограничение на пропускную способность, которую определенный тип трафика может потреблять в данный момент времени. Это может быть достигнуто путем удаления полученных пакетов, когда превышен некоторый порог.

Например, компания Cisco предлагает способ, который позволяет ограничить ICMP пакеты, используемые в нападении:

interface xy

rate-limit output access-group 2020 3000000 512000 786000 conform-action

transmit exceed-action drop

access-list 2020 permit icmp any any echo-reply

Этот пример поднимает интересную проблему, которая была отмечена ранее. Например, ограничение SYN flood, направленное на вычислительную систему, отклонит и легитимный и нелегитимный трафик, так как все законные подключения требуют начального установления связи. Это комплексная проблема, не имеющая однозначного решения. Нельзя защитится от таких типов DoS нападений, не жертвуя частью легитимного трафика.

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

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

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

Более того, сам факт предотвращения DDoS нападения, в некоторый момент, не может зависеть от выстраивания механизма защиты.

2.2 Защиты от угроз воздействия на структуру веб-сайта, находящегося на веб сервере, реализованном на базе вычислительной системы

2.2.1 Методика защиты от SQL - инъекций

Самое главное -- не вставлять чистую переменную прямо в SQL запрос. Лучше всего пропустить её через специальный обработчик.

В случае с MySQL и PHP есть 2 варианта. Первый чуть более старый (так сказать «допотопный»), а второй современный и объектно ориентированный. Выбор метода зависит от того, как именно вы передаёте данные в MySQL. Если используете уже устаревшую функцию mysql_query -- то подойдет первый способ, если же современный и надежный PHP класс PDO -- вторую.

Рассмотрим первый способ защита от sql инъекций PHP через mysql_query.

Если вы всё-ещё используете старые функции mysql_connect, mysql_select_db и mysql_query, то на помощь в защите от sql инъекций подойдет функция: mysql_real_escape_string.

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

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

Рассмотрим на нашем примере:

$search=$_GET['query'];

$search=mysql_real_escape_string($search);

$query="SELECT * FROM table WHERE field = ".$search;

В итоге всё пройдет нормально. В запросе MySQL будет следующий код:

SELECT * FROM table WHERE field = '1;DROP TABLE table;'

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

Второй способ: защита от sql инъекций PHP и PDO

PDO -- это встроенный класс PHP, который обеспечивает современную связь с БД, объектно-ориентированный подход и встроенную защиту от инъекций.

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

Рассмотрим на примере:

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute(array('column' => $unsafeValue)).

Полагаем, что, в данном случае, из кода и так всё понятно, но следует пободробнее рассмотреть данную ситуацию.

Сначала мы создаём запрос к БД (пока это только объект на PHP) -- $preparedStatement.

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

Затем мы выполняем запрос, передавая массив параметров для подстановки в запрос с функцией execute. При этом все переменные, передаваемые в запрос с функцией execute автоматически защищаются от SQL инъекций.

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

2.2.2 Методика защиты от PHP - инъекций

Отметим, что сегодня существует несколько способов защиты от такой атаки:

Все данные приведены ниже в таблице 2.

Таблица 2 - Способы защиты от PHP-инъекций

Способы защиты от PHP-инъекций
Посторонние символы в $module	Допустимое значение в $module	Значение через «if»	Использование «switch»

1) Проверять, не содержит ли переменная $module посторонние символы:

<? ...

$module = $_GET['module'];

if (strpbrk($module, '.?/:')) die('Blocked');

include $module. '.php'; ...

?>

2) Проверять, что $module присвоено одно из допустимых значений:

<?

...

$module = $_GET['module'];

$arr = array('main', 'about', 'links', 'forum');

if (!in_array($module,$arr)) $module = $arr[0];

include $module . '.php';

...

?>

Этот способ является более эффективным, красивым и аккуратным.

3) Прописать каждое значение через if:

<?

...

$module = $_GET['module'];

if ($module == 'main') include 'main.php';

if ($module == 'about') include 'about.php';

if ($module == 'links') include 'links.php';

if ($module == 'forum') include 'forum.php';

...

?>

4) Использовать оператор switch:

<?

...

$module = $_GET['module'];

switch($module){

case 'main': include 'main.php'; break;

case 'about': include 'about.php'; break;

case 'links': include 'links.php'; break;

case 'forum': include 'forum.php'; break;

default: include 'main.php';

}

...

?>

Это решение аналогично решению с if, но имеет более компактную запись.

PHP предоставляет также возможность отключения использования удаленных файлов, это реализуется путём изменения значения опции allow_url_fopen на Off в файле конфигурации сервера php.ini.



2.3 Выводы по второй главе

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

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

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

- использование системы защиты от спуфинга, которая реализуется, в том числе, при помощи использования листов контроля доступа;

- метод адресной фильтрации, который позволяет противодействовать DDoS-атакам;

- методы защиты от sql инъекций PHP и PDO.

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



3. Методы противодействия межсайтовому выполнению сценариев

3.1 Классификация XSS атак

Безусловно, классификация XSS атак является довольно сложным и до конца не изученным вопросом.

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

Для наглядности стоит привести простой пример. Предположим, что изначально код веб-сайта содержит критическую уязвимость, которая, несмотря на то, что не позволяет выходить за рамки самих тегов, все-таки дает возможность выйти за рамки атрибута src тега <a> в тексте блока новостей на главной странице.

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

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

Получается, что в каком-то смысле XSS атаки являются одновременно активными и пассивными, что и обуславливает необходимость их классификации по таким критериям как:

- способ воздействия;

- вектор воздействия.

Вместе с тем, данная классификация требует отдельного пояснения.

Во-первых, XSS это межсайтовый скриптинг, что образовано от английского выражения «Cross site script» и если речь идет об активном скриптинге, то каких-либо дополнительных действий от пользователя не требуется, поскольку атака активируется сама по себе. Однако, если речь идет о пассивном скриптинге, то пользователь, зачастую не зная о наличии вредоносного вируса, активирует атаку посредством каких-либо действий.

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

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

Так, существует «классический скриптинг» (XSS), который является наиболее распространенной моделью атак, поскольку сервер, в данном случае, обладает неконстантной уязвимостью, а если серверные скрипты недостаточно тщательно фильтруют переданные им параметры, то само тело XSS-вектора попадет в результирующий HTML, CSS либо javascript-код, а уже оттуда, непосредственно, в браузер пользователя.

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

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

В обоих версиях классификации XSS есть общий тип XSS-атак - это так называемый «XSS через DOM». В этой модели уязвимость сайта заключается в том, что не серверный скрипт, а именно клиентский javascript извлекает данные из URL страницы и внедряет их в HTML страницы через объекты Document Object Model (DOM, отсюда и название модели атаки). Уязвимость сайта находится в HTML или javascript-файлах, и как только пользователь открывает ссылку, содержащую XSS-вектор злоумышленника, содержимое страницы изменяется и в нее уже непосредственно на системе клиента внедряется код из тела вектора.

Все данные приведены ниже в таблице 3.

Таблица 3 - Классификация XSS атак.

Классификация XSS атак
Пассивный XSS / Активный XSS	Классический XSS / Персистирующий XSS

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

3.2 Алгоритм проведения XSS атак

Фактически, общий алгоритм проведения XSS-атаки состоит из следующих этапов:

1) Поиск уязвимости.

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

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

Ярким примером подобного варианта является CMS Wordpress или форумы на движке phpBB, fastBB и т.п. Такая же ситуация возникает при нахождении уязвимостей в коде стандартных библиотек фреймфорков. Для отслеживания подобных уязвимостей требуется постоянно поддерживать актуальную стабильную версию (фремфорка или CMS) и следить за возможными выходами патчей и обновлений.

Стоит так же помнить, что уязвимыми являются не только формы, написанные на HTML, но и динамически генерируемые через AJAX, или даже динамическая часть, подгружаемая вместе с CSS. Теоретически, XSS может быть реализован на любом материале, предаваемом сервером на запрос клиента, если сервер использует клиентские данные в качестве фрагментов для своего ответа.

2) Выбор метода передачи информации или воздействия на пользователя через XSS-вектор.

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

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

3) Поиск способа распространения XSS-вектора.

Для этого используются различные приемы, от обычной маскировки вредоносных ссылок и кода под важную информацию для пользователей, до методов, используемых в SMM (Social Media Marketing).

К примеру, на портале YouTube.com есть видео где злоумышленник, внедряет XSS-код публикуя сообщение от лица пользователя и дает название ссылке «Do not click on me!», сразу под этим сообщением размещается другое от имени еще одного пользователя, который говорит, что угодно про содержимое в сообщение выше, например, «Классная статья» (тема, ролик, картинка и т.п.) и уже другие пользователи, видя данные сообщения невольно могут посмотреть содержимое из любопытства. Это и приведет к атаке на их компьютер.

Подобных способов распространения можно придумать довольно много.

4) Эксплуатирование полученных данных.

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

Тем не менее, современные методы XSS-атак являются, зачастую, более опасными и достаточно упомянуть урон от первого XSS-червя, запущенного благодаря уязвимостям в публичном блоге «MySpace» и устроившего на нем полноценную DDoS-атаку.

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

Ниже в таблице 4 представлен алгоритм проведения XSS атак.

Таблица 4 - Алгоритм проведения XSS атак

Алгоритм проведения XSS атак
Поиск уязвимости	Воздействие через XSS-вектор	Способа распространения XSS-вектора	Эксплуатирование полученных данных

Помимо DDoS-атаки, XSS это еще и ущерб имиджу компании-держателя сайта.

Изменение и инъекция текста в html-страницы и рассылка таких XSS-векторов клиентам компании может нанести существенный ущерб.

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

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

3.3 XSS атаки на HTML5

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

Данная версия разметки уже поддерживается в различной степени всеми современными браузерами и уже перешла в стадию рекомендованной для стандартизации W3C.

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

Рассмотрим несколько наиболее популярных векторов атак.

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

Аналогичным способом можно использовать в <button> такие новые атрибуты как onforminput, onformchange. Самое опасное в этом, что можно вызывать события в форме даже за ее пределами.

<form id="formId"></form>

<button form="formId" formaction="javascript:alert('Hack')"> Нажми меня</button>

Для защиты от подобных векторов следует запрещать пользователям передавать в поля ввода теги типа button и submit. И по возможности не присваивать идентификаторы формам.

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

<input onfocus=write('Hack') autofocus>

Так же возможно создание конкурирующего тега с атрибутом autofocus.

<input onblur=write('Hack') autofocus><input autofocus>

Браузер Opera версии старше 10.5 поддерживает атрибут poster с возможностью написания псевдоскрипта. Чтобы он работал корректно, следует допускать только относительные URI, http URI и только правильные MIME-типы для элементов dataURI.

Если уязвимым является тег <body>, то можно примешать к нему атрибут onscroll и назначить выполнение javascript.

< body onscroll = alert('Hack') > Тело страницы <input autofocus>

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

В HTML5 появились новые теги, такие как <audio> и <video>. Они уже поддерживаются браузерами GoogleChrome, Opera, Firefox.

Данные теги открывают уязвимость при использовании внутри них тега <source>. Уязвимость заключается в возможности задать обработчик события onerror.

<video onerror="alert('Hack')"><source></source></video>

Браузер Mozila Firefox имеет встроенную поддержку SVG и MathML. Так же в нем реализована поддержка нового атрибута href, что делает возможным запуск JavaScript'a.

<math href="javascript:alert('Hack')">Нажми на меня</math>

Такие браузеры как Chrome и Opera поддерживают HTML5 атрибут dirname, что делает возможным изменить поток пользовательского ввода в другой входной элемент и тем самым разгласить скрытую информацию, например, пароль.

3.4 Методы защиты от XSS атак

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

Данный метод основан на фильтрации входных данных пришедших от пользователя.

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

Такими символами могут служить знаки <,>, <php, а также специальные атрибуты типа onclick(), autofocus и прочие. После фильтрации данные записываются в БД или в другие места для хранения и безопасного отображения конечному пользователю. Недостатком данного метода является необходимость разрешения определенных значений тегов для некоторых типов полей. А также большая трудоемкость написания правильных регулярных выражений, учитывающих все особенности языка разметки.Так же обычно нет возможности проинформировать администратора о возможной попытке проведения атаки.

Помимо всего прочего, данные проверки достаточно ресурсоемки.

2) Метод преобразования специальных символов.

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

Все приведенные данные могут быть представлены в виде таблицы 5.

Таблица 5 - Классификация XSS атак

Методы защиты от XSS атак
Метод фильтрации пользовательских данных	Метод преобразования спецсимволов

3.5 Примеры реальных XSS атак

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

Это является показателем того, что защите от XSS атак сегодня, нужно уделять огромное внимание.

1) XSS уязвимость на сайте UBER-такси.

Данный пользователь нашёл XSS уязвимость на сайте developer.uber.com

В качестве вознаграждения ему было выплачено 7,500$ компанией uber. На рисунке 13 приведен пример найденной уязвимость на сайте developer.uber.com.

Рисунок 13 - XSS уязвимость на сайте UBER-такси

2) XSS уязвимость в строке поиска на сайте mercantile.wordpress.org

Данный пользователь нашёл XSS уязвимость на сайте mercantile.wordpress.org. В качестве вознаграждения ему было выплачено 275$ компанией Wordpress. На рисунке 14 приведен пример найденной уязвимость на сайте mercantile.wordpress.org.

Рисунок 14 - XSS уязвимость в строке поиска на сайте mercantile.wordpress.org



Выводы по третьей главе

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

- поиск уязвимостей в системе;

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

- поиск оптимальных способов распространения XSS-вектора;

- анализ и использование полученных в результате атаки данных.

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

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



Заключение

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

· Вычислительной техники и её составных частей;

· Телекоммуникационной структуры, которая, собственно, и обслуживает вычислительную технику;

· Специального программного обеспечения или операционных систем, установленных на компьютерном оборудовании);

· Структуры веб-сайтов, которые физически расположены на веб-серверах.

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

- Перехват сетевых данных;

- Атаки методом подмены IP-адреса, или, так называемый, IP-спуфинг;

- Атаки с помощью подбора паролей;

- Атаки методом вызова отказа в обслуживании, или DoS/DDoS атаки.

Затем мы изучили существующие методы противодействия киберугрозам и определили следующие:

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

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

- использование системы защиты от спуфинга, которая реализуется, в том числе, при помощи использования листов контроля доступа;

- метод адресной фильтрации, который позволяет противодействовать DDoS-атакам;

- методы защиты от sql инъекций PHP и PDO.

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

- поиске существующих уязвимостей в системе;

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

- поиске наиболее оптимальных способов для распространения XSS-вектора;

- анализе и использовании полученных в результате атаки данных.

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

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

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

Список использованной литературы

1. Microsoft Windows 2000. Справочник администратора. Серия «IT Professional» (пер. с англ.). У.Р. Станек. - М.: Издательско-торговый дом «Русская Редакция», 2002.

2. Networking Essentials. Э. Титтел, К. Хадсон, Дж.М. Стюарт. Пер. с англ. - СПб.: Издательство «Питер», 1999.

3. Атака на Интернет. И.Д. Медведковский, П.В. Семьянов, Д.Г. Леонов. - 3-е изд., стер. - М.: ДМК, 2000.

4. В. Олифер, Н. Олифер. “Компьютерные сети. Принципы, технологии, протоколы”. Учебник для вузов. Издание 3. Спб, 2014.

5. В. Смирнова, П. Козик. “Технологии современных сетей Ethernet. Методы коммутации и управления потоками данных”, Москва, 2014.

6. Г. М. Афонина, П. В. Безногов, В. В. Гераскин “Большая энциклопедия технологий передачи данных”, 4 том. 2 изд. Научное издательство «Большая Российская энциклопедия», Москва, 2003.

7. Глобальное информационное пространство: новые границы / Я.Н. Засурский // Вестник МГУ. Сер. 10. Журналистика. - 2004. - № 5. - с. 3-17.

8. Дементьев А.Н. Электронные системы безопасности личности и имущества. Ч.2. Охранное телевидение: учебное пособие. - Томск: В-спектр, 2007.

9. Журнал "Системы безопасности" #2, 2012. Статья - Безопасность WEB. Риски и их предотвращение.

10. Журнал "Системы безопасности" #6, 2011. Статья - Настоящее и будущее видеоаналитики Технологии. Вызовы. Решения.

11. Злобин В. «Интеграция! Интергация?», Алгоритм безопасности. - 2004.

12. Каталог "Системы безопасности"-2012 Статья - Веб-серверы, развитие технологий. Бизнес-результаты.

13. Макаров А.С. Теория и практика хакерских атак. М.: Альянс-пресс, 2006. - 219 с.

14. Манойло А.В., Петренко А.И., Фролов Д.Б. Государственная информационная политика в условиях информационно-психологических конфликтов высокой интенсивности и социальной опасности, курс лекций. -- М.: Изд. МИФИ, 2003 - 390 с.

15. Молодежный экстремизм / Под ред. A.A. Козлова. СПб., 2002. - 172 с.

16. Н. Кузьменко. “Компьютерные сети и сетевые технологии”, Москва, 2009.

17. Э. Таненбаум, Д. Уэзеролл, “Computer Networks, 5ed.”, New York, 2009.

18. Атака на Web-сервер [Электронный ресурс]. http://www.e-reading.club/chapter.php/99829/138/Kasperski_-_Tehnika_setevyh_atak.html.

19. Вычислительные сети. Теория и практика [Электронный ресурс]. http://network-journal.mpei.ac.ru/cgi-bin/main.pl?l=ru&n=3&pa=9&ar=1.

20. Как защититься от xss атаки и устранить уязвимости [Электронный ресурс]. http://shublog.ru/php/kak-zashhititsya-ot-xss-ataki-i-ustranit-uyazvimost/.

Размещено на Allbest.ru

...