Web-сервер глазами хакера [Михаил Евгеньевич Флёнов] (pdf) читать онлайн

Санкт-Петербург
«БХВ-Петербург»
2021

УДК 004.451
ББК 32.973.26-018.2
Ф71

Фленов М. Е.
Ф71

Web-сервер глазами хакера. — 3-е изд., перераб. и доп. — СПб.:
БХВ-Петербург, 2021. — 256 с.: ил. — (Глазами хакера)
ISBN 978-5-9775-6795-4
Рассмотрена система безопасности web-серверов и типичные ошибки, совершаемые web-разработчиками при написании сценариев на языках PHP, ASP и Perl.
Приведены примеры взлома реальных web-сайтов, имеющих уязвимости, в том
числе и популярных. В теории и на практике рассмотрены распространенные хакерские атаки: DoS, Include, SQL-инъекции, межсайтовый скриптинг, обход аутентификации и др. Представлены основные приемы защиты от атак и рекомендации
по написанию безопасного программного кода, настройка и способы обхода каптчи.
В третьем издании рассмотрены новые примеры реальных ошибок, приведены
описания наиболее актуальных хакерских атак и методов защиты от них.
Для web-разработчиков и системных администраторов

УДК 004.451
ББК 32.973.26-018.2

Группа подготовки издания:
Руководитель проекта
Зав. редакцией
Редактор
Компьютерная верстка
Дизайн серии
Оформление обложки

Павел Шалин
Людмила Гауль
Наталья Смирнова
Натальи Смирновой
Марины Дамбиевой
Карины Соловьевой

"БХВ-Петербург", 191036, Санкт-Петербург, Гончарная ул., 20.

ISBN 978-5-9775-6795-4

© ООО "БХВ", 2021
© Оформление. ООО "БХВ-Петербург", 2021

Оглавление

Введение............................................................................................................................ 7
Обо мне............................................................................................................................................ 8
Требования ...................................................................................................................................... 9
Что не вошло в книгу...................................................................................................................... 9
Интернет ........................................................................................................................................ 10
Благодарности ............................................................................................................................... 10

Глава 1. Основы безопасности ................................................................................... 11
1.1. Социальная инженерия.......................................................................................................... 11
1.2. Природа взлома...................................................................................................................... 15
1.3. Исследование ......................................................................................................................... 17
1.3.1. Определение типа операционной системы.............................................................. 20
1.3.2. Определение имен работающих служб.................................................................... 21
1.3.3. Используемые фреймворки....................................................................................... 24
1.3.4. Использование эксплоитов ....................................................................................... 28
1.3.5. Автоматизация ........................................................................................................... 29
1.4. Взлом web-сайтов .................................................................................................................. 32
1.4.1. Анализатор web-уязвимостей ................................................................................... 34
1.4.2. Взлом с помощью поисковой системы .................................................................... 37
1.5. Подбор паролей...................................................................................................................... 40
1.6. Троянские программы ........................................................................................................... 44
1.7. Denial of Service (DoS)........................................................................................................... 44
1.7.1. Distributed Denial of Service (DDoS) ......................................................................... 47
1.7.2. Защита от распределенной атаки.............................................................................. 48
1.8. Меры безопасности................................................................................................................ 49
1.8.1. Защита web-сервера ................................................................................................... 50
1.8.2. Модули безопасности Apache................................................................................... 51
1.9. Права доступа......................................................................................................................... 53
1.9.1. Права сценариев web-сервера................................................................................... 53
1.9.2. Права системных сценариев ..................................................................................... 54
1.9.3. Права доступа к СУБД .............................................................................................. 55
1.10. Не все так безнадежно ......................................................................................................... 57

4

Оглавление

1.11. Ошибки есть, их не может не есть...................................................................................... 59
1.11.1. Самостоятельно написанные программы .............................................................. 59
1.11.2. Готовые решения ..................................................................................................... 60
1.11.3. Программы, написанные под заказ ........................................................................ 62
1.11.4. Золотая середина...................................................................................................... 62
1.12. Сложность защиты............................................................................................................... 62

Глава 2. Простые методы взлома .............................................................................. 63
2.1. Накрутка голосования ........................................................................................................... 63
2.1.1. Вариант накрутки № 1............................................................................................... 64
2.1.2. Вариант накрутки № 2............................................................................................... 65
2.1.3. Вариант накрутки № 3............................................................................................... 66
2.1.4. Защита от накрутки.................................................................................................... 67
2.2. Флуд ........................................................................................................................................ 69
2.3. CAPTCHA............................................................................................................................... 71
2.3.1. Внутренний мир каптчи ............................................................................................ 72
2.3.2. Примеры некорректных каптчей.............................................................................. 73
2.3.3. Пример хорошей каптчи ........................................................................................... 75
2.4. Хрупкое печенье .................................................................................................................... 77

Глава 3. Взлом PHP-сценариев .................................................................................. 79
3.1. Неверное обращение к файлам ............................................................................................. 80
3.1.1. Пример реальной ошибки ......................................................................................... 80
3.1.2. Проблема include ....................................................................................................... 85
3.1.3. Инъекция кода............................................................................................................ 89
3.2. Ничего лишнего ..................................................................................................................... 91
3.2.1. Лишние сценарии на рабочем сервере..................................................................... 91
3.2.2. Дополнительные программы .................................................................................... 92
3.2.3. Резервные копии или старые файлы ........................................................................ 92
3.3. Автоматическая регистрация переменных .......................................................................... 94
3.3.1. Метод GET.................................................................................................................. 96
3.3.2. Метод POST................................................................................................................ 99
3.3.3. Уязвимость ............................................................................................................... 102
3.3.4. Другие методы ......................................................................................................... 103
3.3.5. Инициализация переменных ................................................................................... 105
3.4. Принцип модульности ......................................................................................................... 111
3.4.1. Конфигурационные файлы...................................................................................... 112
3.4.2. Промежуточные модули.......................................................................................... 114
3.4.3. Скрытые функции .................................................................................................... 118
3.5. Проверка корректности параметров................................................................................... 118
3.6. Проблема регулярных выражений ..................................................................................... 121
3.7. Регулярные выражения Perl ................................................................................................ 121
3.8. Опасность переменных окружения .................................................................................... 124
3.9. Выполнение в iframe............................................................................................................ 125
3.9.1. Воровство кликов .................................................................................................... 126
3.9.2. Cross Frame Scripting................................................................................................ 126
3.9.3. Защита от фреймов .................................................................................................. 127

Оглавление

5

Глава 4. Работа с системными командами ............................................................ 129
4.1. Вызов системных команд.................................................................................................... 129
4.2. Защита от выполнения произвольных команд .................................................................. 133
4.3. Загрузка файлов ................................................................................................................... 135
4.3.1. Проверка корректности файлов изображений....................................................... 139
4.3.2. Проверка корректности текстовых файлов ........................................................... 142
4.3.3. Сохранение файлов в базе данных ......................................................................... 142
4.3.4. Обращение к файловой системе ............................................................................. 143
4.3.5. Угроза безопасности................................................................................................ 146
4.4. Функция eval ........................................................................................................................ 146

Глава 5. SQL-инъекция (PHP + MySQL)................................................................ 148
5.1. Поиск..................................................................................................................................... 149
5.2. Ошибка ................................................................................................................................. 152
5.2.1. Сбор информации .................................................................................................... 156
5.2.2. Использование уязвимости ..................................................................................... 162
5.2.3. Доступ к файловой системе .................................................................................... 163
5.2.4. Поиск уязвимости .................................................................................................... 164
5.2.5. Процент опасности .................................................................................................. 165
5.2.6. Возможные проблемы ............................................................................................. 167
5.2.7. От теории к практике............................................................................................... 169
5.3. Настройка защиты от SQL-инъекции................................................................................. 172
5.4. Защита СУБД ....................................................................................................................... 176
5.5. Защита от инъекции в C# .................................................................................................... 179

Глава 6. SQL-инъекция .NET + MS SQL Server.................................................... 180
6.1. Особенности MS SQL Server............................................................................................... 180
6.1.1. Опасные процедуры MS SQL Server ...................................................................... 181
6.1.2. Распределение прав доступа ................................................................................... 184
6.1.3. Опасные SQL-запросы ............................................................................................ 186
6.1.4. Рекомендации по безопасности MS SQL Server.................................................... 187
6.2. Защита от инъекции в .NET ................................................................................................ 189

Глава 7. CSRF, или XSRF-уязвимость.................................................................... 191
7.1. Примеры межсайтовой атаки.............................................................................................. 191
7.2. Плохая защита от межсайтовой уязвимости...................................................................... 193
7.3. Хорошая защита................................................................................................................... 194
7.4. Сross-origin — делим ресурсы ............................................................................................ 198

Глава 8. DoS-атака на web-сайт ............................................................................... 200
8.1. Поиск медленных страниц .................................................................................................. 200
8.2. Оптимизация работы с СУБД ............................................................................................. 201
8.2.1. Оптимизация SQL-запросов.................................................................................... 202
8.2.2. Оптимизация базы данных...................................................................................... 208
8.2.3. Выборка необходимых данных .............................................................................. 211
8.2.4. Резюме ...................................................................................................................... 213

6

Оглавление

8.3. Оптимизация кода................................................................................................................ 213
8.3.1. Кеширование вывода............................................................................................... 213
8.3.2. Кеширование web-страниц...................................................................................... 214
8.3.3. Программные решения............................................................................................ 216
8.3.4. Медленный код ........................................................................................................ 218
8.3.5. Асинхронный код .................................................................................................... 219
8.4. Блокировки ........................................................................................................................... 220
8.5. Другие ресурсы .................................................................................................................... 220
8.6. Оптимизация в C# ................................................................................................................ 222

Глава 9. Авторизация................................................................................................. 225
9.1. Аутентификация на web-сервере ........................................................................................ 225
9.2. Аутентификации на основе cookie...................................................................................... 227
9.3. Советы по хранению паролей ............................................................................................. 232
9.4. Соль на рану ......................................................................................................................... 233
9.5. Фиксация сеанса или сессии ............................................................................................... 234
9.6. Закрытые сессии .................................................................................................................. 236
9.7. Сессии публичных сайтов ................................................................................................... 236

Глава 10. XSS ............................................................................................................... 238
10.1. Основы XSS........................................................................................................................ 238
10.2. Перехватываем данные...................................................................................................... 240
10.3. Мощь языка JavaScript....................................................................................................... 242
10.4. Защита от XSS.................................................................................................................... 244

Заключение .................................................................................................................. 250
Предметный указатель .............................................................................................. 252

Введение

Предыдущее издание 2009 года начиналось словами: "Интернет захватывает все
новые и новые области". Прошло уже более 10 лет, и можно смело сказать, что интернет захватил все. У меня дома свет включается голосом через "умную" колонку,
и даже контролировать включение лампочки я могу удаленно. Если же я не помню,
выключил ли свет перед уходом, то смогу это легко проверить с помощью телефона через интернет. Дверь в дом также открывается с телефона, и настройки сделаны
так, чтобы дверь открывалась автоматически, когда я подхожу к дому. Через интернет также можно управлять температурой в доме, включая системы климатконтроля. Все эти возможности автоматизированного управления домом посредством интернета объединены в понятие "умный дом" (от англ. smart home).
В 2000-х годах я писал о том, что не готов представить управление через интернет
даже безобидными бытовыми приборами, но уже через пять лет рискнул начав автоматизацию и продолжаю это делать по сей день.
Что изменилось, и почему я поменял свое отношение к интернету? Дело в том, что
ИТ-мир изменился, отношение людей к безопасности изменилось. Да, мир еще не
идеален и, возможно, никогда таким не станет, уязвимости в программном обеспечении существовали и будут существовать, но за счет более серьезного отношения
к безопасности хочется доверять и жить в современном мире с полноценной автоматизацией.
Крупные бренды серьезно относятся к безопасности, и поэтому я просто выбираю
известных и проверенных производителей, которые вкладывают деньги не только в
разработку, но и в тестирование.
Действительно ли хакеры так страшны? Может быть, страх навеян журналистами, которые пишут на тему интернет-взломов и любят приукрасить, преувеличивая возможности хакеров? Да, действия хакеров содержат угрозу, но более опасны программисты
и администраторы, не уделяющие проблемам безопасности достаточно внимания.
Ошибаются все, я и сам не без греха. Но иногда встречается откровенный непрофессионализм, когда нет даже простейших попыток обеспечить web-серверу достойную защиту. Чаще всего этим грешат люди, не имеющие достаточных навыков
работы с компьютером, которые только недавно подключились к интернету и решили создать свой web-сайт.
Но непрофессионализм или невнимательность составляют не такую уж и большую
долю в нашем мире. Если бы сайты так легко было взломать, то они бы не существовали. В интернете много сайтов, которые оперируют не только безобидной информацией, но и деньгами в виде электронной наличности.

8

Введение

Я никогда не был хакером, но всегда интересовался безопасностью, потому что работаю со стороны защитных барьеров. А чтобы защититься от интернет-атак, нужно понимать, откуда может прийти опасность и чем она может грозить.
Зачем мы будем рассматривать взлом, да еще и на практике? С одной стороны, этот
материал можно воспринимать как инструкции по взлому, но с другой стороны, вы
не сможете защититься, если не будете знать, откуда может прийти угроза и в чем
она будет выражаться. Допустим, что вы полководец и хотите защитить свою территорию от вторжения. Вы можете выкопать вокруг своих земель ров, заминировать дороги и растянуть колючую проволоку, но все эти действия будут бессмысленными, если враг готовит воздушный удар или авиацию с бомбами. Поэтому
сначала следует выяснить, как может действовать неприятель, а потом уже искать
достойный ответ. Именно так мы и поступим: будем рассматривать возможную угрозу, а потом искать защиту от нее.
Несмотря на то, что я описываю взлом и знаю, как взламываются сайты, я еще ни
разу в жизни ничего не взламывал ради личной выгоды или корыстных цел. То, что
я делал, даже нельзя называть взломом. Да, я находил уязвимости на сайте и обнаруживал двери проникновения на web-сайты, но я никогда не брал чужой информации и всегда сообщал о найденных уязвимостях владельцам сайтов.
Что подразумевается под взломом web-сервера? Это взлом web-сайта или службы,
которая обрабатывает web-страницы? Мы будем рассматривать проблему комплексно, включая защиту аппаратной части и операционной системы (ОС), а также
web-сервера, баз данных и самих сценариев, которые выполняются на web-сервере.
Аппаратную часть и ОС мы будем рассматривать поверхностно, по мере того как
нам понадобится та или иная информация. Просто я не думаю, что стоит лишний
раз говорить о том, как защищать BIOS компьютера или загрузчик: этот вопрос уж
слишком отдален от тематики книги.

Обо мне
На всякий случай немного обо мне и о том, почему я решился создать эту книгу.
Я всегда интересовался безопасностью. В 1990-е годы начинал как один из внештатных авторов журнала "Хакер", для которого написал множество статей, и стоял у истоков создания рубрики "Кодинг".
В 2009 году переехал в Канаду, где начал работать в консалтинговой компании,
которая выполняла работы для Sony USA. После ухода из этой компании я еще три
года работал на Sony и выполнял для них работы по контракту. Я разрабатывал и
сопровождал такие сайты, как:


www.sonyreward.com — сейчас этот сайт переехал на новый адрес
https://www.rewards.sony.com;



www.wheeloffortune.com — сайт для телепрограммы, которая является оригинальной версией "Поля чудес".

Введение

9

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

Требования
Какие знания понадобятся для чтения этой книги? Да практически никаких, я постараюсь рассказывать все максимально просто, чтобы информация была доступна
всем.
Для работы с примерами в этой книге я бы рекомендовал Linux или macOS, но если
вы предпочитаете Windows, то его тоже можно использовать, особых проблем нет.
Благо в Windows появилась возможность запустить подсистему Linux. Запустите
Windows Store (в русской редакции Windows это может называться "Магазин приложений Windows"), далее находим Ubuntu и устанавливаем его. Таким образом вы
получите доступ к полноценной командной строке Linux прямо в Windows.
Я пишу эти строки в Windows 10, а все Linux команды буду выполнять как раз с
помощью подсистемы WSL (Windows Subsystem for Linux или подистема Windows
для Linux) и конкретно Ubuntu. Когда я буду говорить, что какую-то команду нужно выполнить из командной строки Linux, то ее можно выполнять из терминала
Linux или macOS или из терминала Ubuntu в Windows.

Что не вошло в книгу
Что не будет рассмотрено в данной книге подробно, так это социальная инженерия.
Эту тему мы затронем лишь поверхностно, хотя именно данный метод позволяет
осуществить взлом достаточно быстро и эффективно. Тут можно писать отдельную
книгу, и если вас интересует более подробная информация, то советую обратиться к
гуру социальной инженерии Кевину Митнику и его книге "Искусство обмана: контролирование человеческого фактора в безопасности".
Немного отвлекусь и скажу, что когда Кевин Митник отбывал наказание в местах
не столь отдаленных, то большинство считало его величайшим хакером всех времен и народов, потому что он получил большой срок. Помню, как в интернете легко было встретить лозунги типа "Free Kevin Mitnick" ("Освободите Кевина Митника"). Но стоило человеку выйти на свободу, как его тут же начали считать чуть ли
не ламером и зазнайкой, потому что он начал писать книги и специализироваться
на консалтинге в сфере безопасности.

10

Введение

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

Интернет
Из интернет-ресурсов я могу порекомендовать:


www.flenov.info — блог очень умного парня. Сам себя не похвалишь, так никто
не похвалит;



www.securitylab.ru — отличный сайт по безопасности, где можно почитать
много интересных статей и пообщаться на форуме с очень опытными людьми в
сфере безопасности;

www.xakep.ru — сайт знаменитого журнала "Хакер", в котором работал и ваш
покорный слуга.
Сайтов по безопасности в рунете очень много, но для начала этого будет достаточно. Не буду выделять какие-то как лучшие, а порекомендую читать разные сайты,
чтобы увидеть различные точки зрения.


Благодарности
В каждой своей книге я благодарю тех, кто помогает мне в работе. Не устану благодарить своих родных и близких (жену, детей, родителей), которые ежедневно окружают меня и терпят мои исчезновения в виртуальной реальности. Я вас всех
люблю и рад, что вы у меня есть.
Отдельная и особая благодарность издательству "БХВ-Петербург" и всем его сотрудникам, которые помогали мне в создании этой книги.
Хочу поблагодарить всех моих читателей и Вас, за то, что купили эту книгу,
а не скачали из интернета нелегальную копию, и надеюсь, что эта работа Вам понравится. Мы постарались сделать все необходимое, чтобы книга была интересной
и полезной и никто не пожалел бы о потраченных на нее денег.
Если возникнут вопросы или пожелания по улучшению данной книги, то вы всегда
можете связаться со мной через сайт www.flenov.info.

ГЛАВ А

1

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

1.1. Социальная инженерия
Социальная инженерия — это очень мощное оружие, которое может срабатывать
даже там, где программы на сервере написаны идеально, потому что она использует самое слабое звено — человека. Наверное, каждая уязвимость связана с человеческим фактором, ведь серверные программы, в которых мы будем искать уязвимости, написаны человеком и именно он делает ошибку, которая приводит к взлому.
В данном случае социальная инженерия ищет слабое место (можно сказать, уязвимость, если проводить аналогию с программами) в человеке.
С помощью социальной инженерии происходило большинство наиболее громких
взломов и создавались самые известные вирусы. В моей молодости много шума
наделал вирус "Анны Курниковой", когда пользователям приходило письмо с
вложением и предложением посмотреть фотографию обнаженной Анны. Это тоже социальная инженерия, которая играет на слабостях человека. Любопытство
мужчин, которые запускали прикрепленный файл и таким образом заражали свой
компьютер, помогло распространению этого вируса. А ведь на тот момент мужская половина была бóльшей частью пользователей интернета. В данном случае
использовалась слабость (можно снова назвать уязвимостью) человека — любопытство и похоть.

12

Глава 1

Социальная инженерия основана на психологии человека и использует его слабые
стороны. С ее помощью хакеры заставляют жертву делать то, что им нужно: заражают компьютеры, получают пароли. Сколько раз я слышал про украденные номера кредитных карт с помощью простых почтовых сообщений. Пользователь получает письмо с просьбой сообщить свой пароль, потому что база данных банка порушилась из-за погодных условий, проказ хакера или неисправности оборудования.
Ничего не подозревающие пользователи всегда сообщают данные, потому что боятся потерять информацию.
Да, в последнее время доверчивость у пользователей интернета уменьшается благодаря СМИ. Теперь уже все сложнее найти человека, который откроет свой пароль
в ответ на поддельное письмо от службы поддержки. Сейчас наоборот, пользователи боятся использовать некоторые защищенные и очень полезные сервисы. Но и
хакеры не дремлют и ищут все новые и новые методы, все более изощренные способы обмануть людей.
Есть и такие хакеры, которые редко придумывают что-либо новое, а используют
старые и проверенные способы. И, несмотря на это, всегда находятся те, кто попадаются на удочку. Я пользуюсь интернетом уже очень долгое время и ежедневно
получаю десятки писем с просьбой запустить файл для обновления защиты или для
того, чтобы увидеть что-то интересное. А ведь достаточно часто отправители —
пользователи зараженных компьютеров. Значит, кто-то открывает такие вложения.
Я никогда не открываю вложения, и это одна из причин, почему мне не нужны антивирусы уже лет 15.
Несмотря на широкое использование защитных программных комплексов и антивирусных программ, количество вирусов не уменьшается, а если и уменьшается, то не
сильно. Каждый день в интернете появляются новые пользователи, которые еще
ничего не знают о мерах предосторожности. Именно они чаще всего попадаются на
различные уловки.
Итак, давайте рассмотрим некоторые способы, которыми пользуются хакеры. Это
поможет вам распознавать их и отделять попытки психологического воздействия от
простого общения с людьми. Помните, что социальная инженерия максимально
сильна в интернете, когда вы не можете воочию оценить намерения своего собеседника.
Классика — взлом через смену пароля. Жертве приходит письмо с просьбой обновить свои реквизиты на web-странице банка, и при этом ссылка из письма указывает совершенно на другой web-сайт, где введенные пользователем данные попадают
в руки хакеру.
Мне регулярно приходят письма, в которых используется очень старый и давно забытый способ социальной инженерии. Письмо имеет примерно следующее содержание: "Здравствуйте. Я администратор компании ХХХХХ. Наша база была подвержена атаке со стороны хакера, и мы боимся, что некоторые данные были изменены. Просьба просмотреть следующую информацию, и если что-то неверно, то
сообщите мне, я восстановлю данные в базе".

Основы безопасности

13

После этого может идти перечисление данных обо мне, которые легко получить
через социальные сети.
У меня есть сайты, поэтому мои данные легко находят в интернете с помощью сервиса whois. На любом web-сайте регистрации доменов есть такая служба, позволяющая определять имя владельца домена. Хакер может воспользоваться этим и
указать в письме всю найденную информацию. Помимо этого, он может указать
еще два параметра: имя пользователя и пароль. Конечно же, эти данные хакер, скорее всего, не знает, поэтому здесь будут неверные значения. Кое-кто из пользователей при получении таких писем теряется и, волнуясь за свой web-сайт, открывает
ссылку из письма, которая ведет на зловредный сайт, и там через какую-либо форму
сообщает хакеру уже правильные параметры доступа.
Данный метод использует хороший психологический прием: сначала приводится
достоверная информация, и только в параметрах доступа заложена ошибка. Таким
образом завоевывается расположение и доверие жертвы, и если пользователь незнаком с таким принципом социальной инженерии, то вероятность получить пароль
достаточно высока. Это подтверждает не только множество знаменитых взломов в
80-х годах прошлого столетия, но и то, что этот метод существует и работает даже
в наши дни.
Сейчас количество взломов этим методом сократилось, однако это может быть
лишь затишьем перед бурей. Пользователи могут расслабиться, и атака снова станет популярной. Ведь все новое — это хорошо забытое старое. Если немного модифицировать подход, чтобы пользователи сразу не заметили подвоха, то атака
может стать очень эффективной.
Задача хакера — войти в доверие к защищающейся стороне и узнать пароли доступа. Для этого используются психологические приемы воздействия на личность. Человеку свойственны любопытство, доверчивость и чувство страха. Любое из этих
чувств может стать причиной утери информации.
Благодаря излишнему любопытству мы верим призывам открыть прикрепленный к
письму файл и самостоятельно запускаем на своем компьютере вирусы. В силу нашей доверчивости хакерам удается узнать секретную информацию. Но самые сильные эмоции вызывает страх. Именно на страхе и боязни потери паролей основана
большая часть атак, с помощью которых пользователя вынуждают сказать необходимые сведения.
Еще две слабости, которые очень часто приводят к положительному результату, —
жадность и алчность. Деньги портят людей, а хакеры умеют этим пользоваться.
Наилучший результат достигается тогда, когда хакер использует сразу несколько
слабостей: например, страх и любопытство одновременно.
У нас на работе есть отдел, который занимается безопасностью. Они регулярно
рассылают письма с напоминанием, что нельзя открывать ссылки из писем, источник которых нам неизвестен. Несмотря на то, что многие прекрасно знают о проблемах безопасности, подобные напоминания помогают держать нас в тонусе.

14

Глава 1

Крупные и громкие взломы происходят циклично. Пара-тройка крупных взломов,
после чего может быть тишина в течение продолжительного времени. За время затишья народ расслабляется и больше подвержен атакам. Чтобы этого не произошло, и рассылаются подобные письма.
Как бы ни говорили о том, что социальная инженерия через электронные письма —
опасная вещь и она регулярно становится причиной проблем, эффективность этих
рассказов все же далека от идеала. Реальность показывает, что люди часто игнорируют предупреждения в надежде, что их это не коснется.
Но что может быть лучше реальных примеров? Поэтому у нас на работе как-то рассылали письмо, которое копировало популярную атаку хакеров и содержало ссылку на фейковый сайт. Говорят, что в результате достаточно большое количество
сотрудников кликнуло по ссылке.
Хакеры пользуются социальной инженерией незаметно, но эффективно. Вы даже
не почувствуете подвоха, когда у вас попросят пароль или секретную информацию,
и послушно все отдадите. Чтобы не попасться на крючок, вы должны иметь представление о том, какие методы социальной инженерии могут использоваться для
достижения необходимой цели. С основными методами можно познакомиться в
книге самого знаменитого хакера — Кевина Митника "Искусство обмана: контролирование человеческого фактора в безопасности".
Социальная инженерия работает до сих пор, и очень много взломов по сей день совершается старым добрым методом — через почту заражается компьютер одного
из сотрудников компании. Получив контроль над одним из компьютеров, заражается какое-то программное обеспечение в сети и идет дальнейшее продвижение.
Пока что идет расследование недавнего взлома SolarWinds, но, похоже, именно так
он и произошел. Хакеры подбросили зловредный код в одно из приложений, которое используется в компании, что привело в дальнейшем к очень серьезным последствиям.
Хотя я и сказал, что не буду в данной книге уделять большого внимания социальной инженерии, давайте все же рассмотрим несколько рекомендаций, как защищаться от фейковых писем:
всегда проверяйте адрес отправителя. Очень часто почтовые программы прячут
e-mail и показывают только имя отправителя. Если хакер отправит письмо от
имени info-microsoft.com, то почтовая программа может
отобразить только info-microsoft.com, а реальный адрес будет спрятан. При
клике на имя программа все же покажет спрятанный e-mail и если это что-то типа an1930123@mail.ru, то письмо явно не от Microsoft. Вообще нужно обращать
внимание на каждую мелочь в адресе. Солидные компании не рассылают письма
от имени e-mail адресов, которые не вызывают доверия;
 ссылки внутри письма также могут указывать на то, реальное перед нами письмо или нет. Если навести на ссылку мышкой, то должна появиться подсказка,
которая точно будет указывать реальную ссылку, на которую мы попадем при
клике. Если она вызывает доверие и реально указывает на сайт, о котором го

Основы безопасности

15

ворится в письме, то можно кликнуть. Если письмо от Microsoft со ссылкой
m1cr0soft.com, то, конечно, же это фейк;


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

1.2. Природа взлома
Универсального способа взлома интернета (а точнее, web-сайтов) не существует.
Если бы такое средство существовало, интернет бы уже охватили анархия и беспредел, а все сайты были бы взломаны. Вместо этого каждый раз приходится искать свое решение, которое откроет необходимую дверь для определенного сайта.
Да, есть атаки, которые могут уничтожить любую защиту: DDoS (Distributed Denial
of Service, распределенная атака на отказ в обслуживании) или подбор паролей, но
затраты на проведение этих атак могут оказаться слишком большими, хотя они не
требуют много ума и доступны для реализации даже новичку. За взлом сервера с
помощью перебора паролей или за DDoS-атаку хакеры никогда не будут признаны
общественностью как профессионалы, поэтому к подобным методам прибегают
только в крайних случаях и в основном начинающие взломщики.
Почему количество атак с каждым годом только увеличивается? Я не говорю сейчас о свершившихся или удачных атаках, я говорю о попытках. Раньше вся информация об уязвимостях хранилась на закрытых BBS (Bulletin Board System, электронная доска объявлений) и была доступна только избранным. К этой категории
относились и хакеры, совершавшие безнаказанные атаки, потому что уровень их
знаний и опытности был достаточно высок. Проникнуть на такую BBS непосвященному или новичку было очень сложно, а чаще всего просто невозможно. Информация об уязвимостях и программы для реализации атак были доступны ограниченному количеству людей.
С одной стороны, информация становится более доступной, с другой стороны —
люди становятся более образованными с точки зрения компьютерной грамотности.
Когда только появились машины, то управление ими было доступно только избранным, но с распространением машин все больше людей могут ими управлять.
Сейчас уже не только профессиональные гонщики соревнуются в скорости, по
улицам может гонять кто угодно, хотя это и грозит штрафами.
То же самое и с ИТ. Если раньше только программистам был доступен взлом компьютеров и web-сайтов, то в наше время это может делать практически кто угодно.

16

Глава 1

С помощью специального софта и за счет возросшей образованности все больше
людей пользуются взломом для совершения не очень законных действий.
Мир меняется. Компьютеры становятся более доступными и сейчас уже есть практически в каждой семье.
В настоящее время сведения об уязвимостях стали практически общедоступными.
Существует множество сайтов, где можно не только получить подробные инструкции по взлому, но и найти программу, которая вообще без специализированных
знаний по нажатию кнопки, будет производить атаку. В некоторых случаях достаточно только указать адрес web-сайта, который вы хотите взломать, нажать на "волшебную" кнопку, и компьютер сделает все необходимое сам, без вашего вмешательства, при этом вы абсолютно не будете знать и понимать, как это произошло.
Да, далеко не вся информация попадает в публичный доступ (паблик) сразу после
обнаружения. Хакеры могут использовать найденные уязвимости только в определенных кругах и какое-то время держать информацию доступной только для избранной категории. Особенно это касается группировок, которые взламывают профессионально. Но со временем и эта информация становится публичной.
С одной стороны, информация действительно должна быть открытой. Администраторы, зная методы взлома, могут построить соответствующую защиту. Другое дело,
что далеко не каждый следит за тенденциями в сфере безопасности, и далеко не все
администраторы отрабатывают свою зарплату, строя безопасные сети.
С другой стороны, если закрыть web-сайты, на которых содержится информация об
уязвимостях, то количество атак резко сократится. Большинство взломов совершается именно непрофессионалами, которые нашли где-то программу для совершения
злодеяний и выполнили ее.
Лично я разрываюсь между двух огней и не могу проголосовать за открытость или
закрытость информации. С одной стороны, информация должна быть открыта, а
администраторы и программисты должны быть внимательнее и быстрее реагировать на найденные ошибки, а с другой — ее лучше закрыть, чтобы у злоумышленников не было соблазна использовать готовые программы.
Наверное, я все же проголосую за открытость, но при этом правоохранительные
органы должны лучше реагировать на действия вандалов, а администраторы должны лучше контролировать безопасность. Каждое общество требует разумного
управления. Это не значит, что за каждым щелчком нужно следить, это значит, что
взломы должны наказываться по определенным законам. Мы должны вести себя
цивилизованно, иначе, как раковая опухоль уничтожает живой организм, мы уничтожим сами себя.
Безусловно, интересно наблюдать за тем, как две команды хакеров воюют между собой, взламывая web-сайты друг друга, но все должно иметь свой предел. Каков этот
предел, я судить не могу. Никто не может вынести решение, каким быть интернету,
потому что на данный момент он свободен и в каждой стране подчиняется своим законам. Но интернет — это единое общество, а закон должен быть для всех единым.
Пока не будет закона, его соблюдения и контроля, анархия будет продолжаться.

Основы безопасности

17

1.3. Исследование
Допустим, что у вас на примете есть сервер или компьютер, который нужно взломать или протестировать на защищенность от взлома. С чего нужно начинать? Что
сделать в первую очередь?
Четкой последовательности действий нет. Взлом — это творческий процесс, а значит, и подходить к нему надо с этой точки зрения. Нет определенных правил, и
нельзя все подвести под один шаблон.
Самое первое, с чего начинается взлом или тест ОС на уязвимость, — сканирование портов. Для чего? А для того, чтобы узнать, какие службы (в Linux это демоны) установлены в системе. Каждый открытый порт — это программа, установленная на сервере, к которой можно подключиться и выполнить определенные
действия. Например, на 21-м порту работает служба FTP. Если вы сможете к ней
подключиться, то вам станет доступной возможность скачивания и загрузки файлов. Но это только если вы будете обладать соответствующими правами на удаленном сервере.
Сначала следует просканировать первые 1024 порта. Среди них очень много стандартных служб типа FTP, HTTP, Telnet и т. д. Открытый порт — это дверь с замочком для входа на сервер. Чем больше таких дверей, тем больше вероятность, что
какой-то засов не выдержит натиска и откроется, поэтому на сервере должно быть
запущено только то, что необходимо.
Будет лучше, если вы установите на сервер только те программы, которые реально
будут использоваться. Все остальное лучше не запускать, запрещать, а лучше вообще не устанавливать, чтобы хакер не смог самостоятельно их запустить и использовать.
У хорошего администратора открыты только самые необходимые порты. Например, если это web-сервер, не предоставляющий доступ к электронной почте, то нет
смысла держать почтовые службы. Должен быть открыт только 80-й порт, на котором как раз и работает web-сервер. Все остальные порты должны быть не просто
закрыты сетевым экраном, а лучше, если соответствующие службы совсем не будут
установлены.
Распространенная ошибка: установлю на всякий случай все, просто не буду запускать или прикрою сетевым экраном. Это очень серьезная ошибка, которую я часто
вижу у программистов. Им лень тонко настраивать нужные сервисы, им лень смотреть что именно нужно, а что нет. Хочется просто чтобы все работало и скорей
приступить к программированию.
Если хакер проникнет на вашу систему, то он запустит остановленную службу или
приоткроет сетевой экран, чтобы воспользоваться уже запущенной. Я об этом говорю уже очень давно, и то, что Microsoft движется вэтом направлении, свидетельствует о том, что я верно мыслю. Понимаю, что это не я подсказал сотрудникам
Microsoft, что не нужно устанавливать лишнее, но это говорит о том, что задумываюсь об этом не только я. Сначала IIS (Internet Information Server) стал устанав-

18

Глава 1

ливаться на компьютеры в минимальной конфигурации. Теперь и MS Windows
Server устанавливается в минимальной конфигурации, а вы можете добавлять потом только нужные вам роли и только нужные вам программы.
Хороший сканер портов определяет не только номер открытого порта работающего
на удаленной системе сервиса, но и показывает название работающей на нем службы. Жаль, но очень часто показывают не настоящее название, а только имя возможного сервера. Так, для 80-го порта будет показано "http". Если сканер не показывает
имен служб, то в ОС Windows их можно посмотреть в файлах protocol и services из
каталога C:\WINDOWS\system32\drivers\etc. Просто откройте их в Блокноте или любой другой программе просмотра текстовых файлов. В результате вы увидите чтото похожее на следующий список:
echo
echo
discard
discard
systat
systat
daytime
daytime
qotd
qotd

7/tcp
7/udp
9/tcp
9/udp
11/tcp
11/tcp
13/tcp
13/udp
17/tcp
17/udp

sink null
sink null
users
users

quote
quote

#Active users
#Active users

#Quote of the day
#Quote of the day

Файл имеет следующую структуру:


/

[псевдонимы...]

[#]

Но не забывайте, что это только описание стандарта, который легко нарушить. Администратор без проблем может запустить web-сервер не на 80-м порту,
а на 21-м, и сканер портов напишет нам, что это FTP-сервер.
Остановитесь и посмотрите сейчас файл services. Здесь описаны наиболее распространенные на данный момент службы и порты, на которых они работают. Если вы
еще не знакомы с этими номерами, то следует хотя бы что-то из этого оставить в
памяти, чтобы знать потом, что искать на атакуемой системе. Я рекомендую обратить внимание и запомнить, что на портах 1433 и 1434 протоколов TCP и UDP работает Microsoft SQL Server и Microsoft SQL Monitor. На порту 1512 работают
WINS (Microsoft Windows Internet Name Service, служба имен интернета для сетей
Windows), которая далеко не без изъяна. Я весь файл приводить не буду, потому
что он большой, а вы и без меня сможете в любой момент его посмотреть.
Но существуют программы, которые не доверяют стандарту и проверяют полученную информацию самостоятельно. Как это определить? Есть несколько способов:
 по строке приветствия, которая возвращается при подключении к порту. Большая часть служб при подключении возвращает сообщение, которое содержит
название и версию службы. Позже мы еще будем говорить о том, что это сообщение может быть подделано;


по ответу на подключение или по ответу на команду. Например, подключившись к 80-му порту, можно попробовать отправить серверу HTTP-команду, и

Основы безопасности

19

если сервер ответит корректно, то перед нами именно web-сервер. Если мы увидим ошибку, то нас пытаются обмануть;
службы в ответ на подключения присылают разные пакеты. У некоторых пакетов есть достаточно уникальные метки, по которым мы можем с большой вероятностью сказать, что перед нами определенный сервис.
После того как мы определили состояние первых 1024 портов, можно начинать
сканировать порты свыше этого. Здесь стандартные службы встречаются редко.
Зачем же тогда сканировать? А вдруг кто-то до вас уже побывал на этом месте и
оставил открытую дверку или установил на сервер троянскую программу. Большинство троянских программ держит открытыми порты свыше 1024, поэтому если
вы администратор и нашли открытый порт в этом диапазоне, необходимо сразу насторожиться. Ну а если вы взломщик, то нужно узнать имя троянской программы и
найти для нее клиентскую часть, чтобы воспользоваться ею для управления чужой
машиной.
Среди служб, использующих порты выше 1024, встречаются и некоторые коммерческие, например СУБД (система управления базами данных). Дело в том, что номера из первой тысячи уже давно распределены и использовать какой-то из этого
диапазона достаточно проблематично, поэтому современные службы эксплуатируют весь диапазон номеров до 65 535.
Нередко можно увидеть даже web-службы, которые работают на порту 8080. По
умолчанию используется 80-й порт, но когда по каким-то причинам его не получается задействовать, это число удваивают до 8080.
Первые 1024 порта в ОС Linux обладают еще одним очень важным свойством: запустить службу, работающую на таком порту, может только пользователь с правами администратора (для UNIX-систем это пользователь с правами root). Таким образом система гарантирует, что службы, работающие на портах ниже 1024, запущены администратором. Они являются наиболее критичными с точки зрения
безопасности сервера, поэтому рядовые пользователи не должны иметь права их
запускать.
Если после сканирования вы нашли программу, через которую можно получить полный доступ к серверу, то на этом взлом может закончиться. Жаль, что такое происходит очень и очень редко, и чаще всего нужно затратить намного больше усилий.
Хорошо было во времена появления троянской программы Back Orifice, когда один
хакер заражал компьютер пользователя, а другой без проблем мог воспользоваться
уже готовым взломом. В настоящее время по интернету гуляет слишком большое
количество троянских программ, которые используют разные порты и чаще всего
даже позволяют настраивать номер порта, на котором они будут работать. А если
серверная часть программы защищена паролем, то воспользоваться чужим трудом
будет проблематично.


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

20

Глава 1

1.3.1. Определение типа операционной системы
Сканирование — это всего лишь начальный этап, который дает немного информации для размышления. Ведь мы рассматриваем безопасность web-серверов, а значит, нас больше всего интересует 80-й порт. Тогда зачем нам нужно сканировать
остальные? Это поможет узнать, какая ОС установлена на сервере. Ведь если на сервере работает MS SQL Server, то там, скорее всего, стоит Windows.
Желательно иметь сведения о версии, но это удается выяснить не всегда, да
и на первых порах изучения системы можно обойтись без конкретизации. Главное — иметь четкое представление об используемой платформе: Windows, Linux,
BSD, Mac OS или др. От этого зависит очень многое:


какие программы могут быть установлены на сервере;



какие команды можно выполнять;



где находится информация о пользователях и их паролях;



где может быть установлена ОС (в какой папке или в каком разделе);



какие существуют уязвимости для данной ОС.

Как определяется тип ОС? Для этого есть несколько способов. Помимо работающих на удаленной системе сервисах, о типе системы мы можем судить:


по реализации протокола TCP/IP. Это низкоуровневый метод, который работает на уровне пакетов, передаваемых от клиента к серверу. В различных ОС поразному организован стек протоколов. В основном этот вывод расплывчатый:
Windows или Linux. Точную версию таким образом узнать невозможно, потому
что в Windows 8 и 10 реализация протокола практически не менялась. В таком
случае будет сложно определить разницу. Даже если программа определила, что
на сервере установлен Linux, то какой именно дистрибутив, сказать будет сложно. И поэтому такая информация — это только часть необходимых данных для
взлома;



по ответам служб. Допустим, что на сервере жертвы есть анонимный доступ
по FTP. Вам нужно всего лишь присоединиться к нему и посмотреть сообщение при входе в систему. По умолчанию в качестве приглашения используется
надпись типа: "Добро пожаловать на сервер FreeBSD4.0, версия FTP-клиента
Х.ХХХ". Если вы такое увидели, то еще рано радоваться, так как неизвестно,
правда это или нет. Хороший администратор изменяет строку приветствия,
чтобы не упрощать взломщику жизнь. Могут не просто изменить, но и вводить
в заблуждение, когда на Windows-сервере появится приглашение, например
Linux. В этом случае злоумышленник безуспешно потратит очень много времени в попытках взломать Windows, стараясь использовать ошибки Linux. Поэтому не очень доверяйте надписям и старайтесь их перепроверить другими
способами;

Основы безопасности

21

по социальной инженерии. Если вычислить адрес администратора или какогото работника компании, то можно отправить ему на почту пресс-релиз о якобы
найденной уязвимости в ОС и сделать ссылку на описание уязвимости для разных версий. Дальше просто смотрим, если кто-то кликнул по одной из ссылок и
по какой именно.
Чтобы вас не обманули, обязательно обращайте внимание на используемые на сервере службы. Например, в Linux, скорее всего, не будут работать web-страницы,
созданные по технологии ASP. Такие вещи подделывают редко, хотя это и возможно — достаточно использовать расширение asp для хранения PHP-сценариев и перенаправлять их интерпретатору PHP. Таким образом хакер увидит, что на сервере
работают файлы ASP, но реально это будут PHP-сценарии.


1.3.2. Определение имен работающих служб
Определение типа ОС — это только начальный этап. После этого переходим к определению имен служб, которые работают на сервере. Если открыт 80-й порт, то
необходимо узнать, какой установлен web-сервер: Apache или IIS. От используемой
службы и ее версии зависит, как ее можно взламывать. Например, некоторые версии определенных служб могут содержать одну ошибку, а другие версии — другую
ошибку. А бывают даже случаи, когда ошибок вообще нет. Хотя нет, таких случаев
практически не бывает. Ошибки, скорее всего, есть, просто их еще никто не нашел,
и нужно поискать или подождать, когда найдут другие.
Иногда хакеры определяют версию ОС или установленных служб по наличию
ошибок. Например, если web-сервер IIS версии 5.0 содержал определенную ошибку
при получении слишком большого пакета, то можно попытаться отправить такой
пакет, и если в ответ мы получим ошибку, то перед нами именно IIS 5.0. Вроде бы
все хорошо и метод определения достаточно точный, но не совсем. Дело в том, что
наличие ошибки может зависеть и от конфигурации ОС или самой службы. Известная вам ошибка может проявляться только при определенных условиях, и если
ошибка не проявилась, то, возможно, не соблюдены необходимые условия (см.
разд. 1.3.4).
Защищающая сторона должна дать противнику как можно меньше информации,
чтобы у него было меньше возможности взломать сервер. Да, прятать нужно не
только название ОС, но и названия служб. Например, если подделать Apache под
IIS, то хакер будет пытаться взломать не тот web-сервер, используя не те программы, что усложнит его задачу.
Задача хакера — четко определить, что же он взламывает. Без этого производить в
дальнейшем какие-либо действия будет сложно, потому что он даже не будет знать,
какие команды ему доступны после вторжения на чужую территорию, где искать
системные файлы и пароли, а также какие исполняемые файлы нужно загружать на
сервер.
В случае с web-серверами должен работать как минимум web-сервер, который чаще
всего откликается на портах 80, 443 или 8080. Чтобы проверить, нужно сначала уз-

22

Глава 1

нать реальный IP-адрес сайта, с которому мы можем подключиться. Самый простой
способ узнать IP — выполнить ping с флагом -f:
ping -f flenov.ru

В результате вы должны увидеть что-то типа:
flenov.ru [162.241.30.65] with 32 bytes of data:
Reply from 162.241.30.65: bytes=32 time=164ms TTL=48

Для некоторых настроек ping может не работать. В таких случаях можно выполнить команду nslookup c параметром class=A и указанием домена:
nslookup class=A flenov.ru
Server: UnKnown
Address: 162.241.30.65

Итак, мы нашли IP-адрес 162.241.30.65. Почему именно IPv4 адрес? В принципе
можно работать и с 6-й версией, просто из личного опыта могу сказать, что про 4-ю
версию проще найти информацию в Google. Сейчас почти все сайты имеют адрес
4-й и 6-й версии, и хотя нам уже давно обещали переход на 6-ю, это произойдет
еще не скоро, они оба будут сосуществовать вместе.
Теперь надо узнать чуть больше информации про этот адрес. Вбиваем в Google этот
адрес или воспользуемся следующей ссылкой: https://ipgeolocation.io/browse/ip/
162.241.30.65. В результате вы должны увидеть что-то похожее на рис 1.1.

Рис. 1.1. Информация о IP flenov.ru

Основы безопасности

23

Похоже, мой сайт находится на bluehost.com в Северной Америке. Как владелец
сайта могу подтвердить, что это действительно так.
Теперь попробуем чуть более интересный сайт. Давайте найдем IP-адрес для достаточно популярного в США сайта Wheel Of Fortune:
ping -f wheeloffortune.com

Результат:
Pinging wheeloffortune.com [2.17.164.116] with 32 bytes of data:
Reply from 2.17.164.116: bytes=32 time=371ms TTL=53

Снова можно использовать Google или уже знакомый сайт ipgeolocation.io
https://ipgeolocation.io/browse/ip/2.17.164.116 (рис 1.2).

Рис. 1.2. Информация об IP для Wheel Of Fortune

Интересно, что этот сайт показывает на то, что IP находится в Европе, а точнее в
Швеции. А ведь сайт направлен на американского пользователя, а не европейского.
Возможно, это ошибка, и еще стоит проверить и подтвердить эту информацию.
Но обратите внимание на домен akamaitechnologies.com. Это очень крупная компания из США, которая предоставляет различные защитные сервисы, включая защиту от DDoS (Distributed Denial of Service — распределенный отказ обслуживания). Сайт, скорее всего, находится на других серверах, возможно в Azure, AWS
или другой компании (я знаю где, но пока не скажу).

24

Глава 1

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

Рис. 1.3. Работа Akamai + Prolexic

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

1.3.3. Используемые фреймворки
Труд программистов не из самых дешевых, поэтому его очень часто пытаются оптимизировать за счет использования каких-то готовых библиотек или фреймворков,
которые кто-то уже написал, а мы теперь можем использовать этот труд, чтобы
создание сайтов было проще и быстрее.
И в таких библиотеках и фреймворках тоже могут быть уязвимости, которые могут
привести к взлому, поэтому неплохо было бы попробовать выяснить, что именно
использовали программисты при создании сайта.
Здесь можно уже не только поговорить о теории, но и погрузиться в практику.
Возьмем для примера www.wheeloffortune.com и загрузим его в Chrome. Но прежде чем загружать сайт, нажмите ++, чтобы открыть утилиты разработчика, или в главном меню программы выберите More Tools | Developer Tools.
Появится окно с несколькими вкладками. Перейдите на вкладку Network и теперь
загрузите сайт (рис.1.4).
В окне утилит разработчиков начнут появляться строки с именами файлов, которые
браузер загружает для того, чтобы отобразить сайт. Найдите самый первый файл
https://www.wheeloffortune.co/ и кликните на нем. Слева должна появиться (если

Основы безопасности

25

еще не было) панель с информацией о запросе, который был отправлен на сервер, и
информацией о том, что вернулось с сервера.

Рис. 1.4. Web-сайт www.wheeloffortune.com

Информация о запросе разделена на три основных раздела (рис 1.5).


General — здесь мы можем узнать, по какому URL был загружен файл. Для основного файла этот URL будет совпадать с тем, что мы видим в браузере, но все
последующие будут отличаться, и таким образом мы можем узнать, где именно
находятся различные картинки и другие файлы ресурсов.
Помимо этого, здесь будет метод запроса (чаще всего GET или POST), реальный
IP-адрес сервера. В данном случае IP-адрес 2.17.164.116. Там еще вы можете
увидеть двоеточие и цифры 443, но это порт, который соответствует зашифрованному HTTPS-трафику.



Response Headers — не знаю почему, но вторым идет раздел информации о том,
что мы получили от сервера. Здесь мы можем прочитать то, что по умолчанию
скрыто от глаз — различные параметры, которые сервер указал в ответ на наш
запрос.



Request Header — какую техническую информацию браузер отправил на сервер
для получения результата. Логичнее именно этот раздел поместить на второе
место, но уж так работает браузер.

26

Глава 1

Рис. 1.5. Информация о запросе для загрузки файла

Чаще всего интересная информация скрыта в Response Headers. Одним из популярных параметров, который может что-то сказать, является server. Здесь можно
увидеть, какой web-сервер вернул результат, и в данном случае это nginx. Это один
из трех популярных серверов, остальные два — IIS и apache.
Сервер nginx говорит о том, что, скорее всего, на сервере работает ОС Linux.
Давайте перейдем на вкладку Preview и посмотрим, что можно здесь увидеть. Нам
сразу же бросаются в глаза две строки:
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({"drupalLanguage":"en","drupalCountry":"US",
"siteName":"Wheel of Fortune

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


Здесь нам четко говорят, что использовалось в разработке — Drupal 8, и есть даже
ссылка, где можно узнать о нем (рис 1.6).
Обычно программисты стараются не указывать подобное, а тут компания-разработчик дала нам очень много полезной информации:


мы знаем web-сервер: с большой вероятностью это nginx, — и это не поддельное, а реальное название;

Основы безопасности

27



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



скорее всего, сайт написан на PHP, потому что Drupal написан на этом языке.

Рис. 1.6. Информация о фреймворке

Если зайти на официальный сайт https://www.drupal.org, то там можно узнать, что
сейчас уже доступна 9-я версия. Причем на момент написания этих строк 9-я версия была доступна уже полгода.
Говорит ли это о каких-то проблемах? Пока нет, я просто показываю на одном
примере, как происходит исследование сайтов со стороны.
Далеко не все компании открыто указывают так много подробной информации о
недрах сайта, что он использует и как работает. Как я уже сказал в начале книги, я
когда-то работал над wheeloffortune.com, тогда он был написан на C#, и с тех пор
его полностью переписали. Когда я начинал писать эту книгу, именно факт моей
бывшей связи с этим сайтом привел к тому, что я взглянул на него в утилитах разработчика и удивился, что так много всего сообщается всего в одном-единственном
запросе.
Не ждите от меня каких-то инсайдов, я буду рассказывать только публичную информацию, которая доступна абсолютно всем. У меня слишком большое уважение
к этой компании.

28

Глава 1

1.3.4. Использование эксплоитов
Итак, теперь вы в курсе, какая на сервере установлена ОС, какие порты открыты и
какие именно службы работают на этих портах. Раз мы говорим о web-серверах, то
как минимум должен быть открыт 80-й порт и/или 443.
Не ленитесь записывать все собранные данные. Помните, что даже компьютеры
иногда сбоят, а человеческий мозг делает это регулярно. Самое интересное, что
чаще всего забывается наиболее необходимое. Ну а если вы взломаете сервер, то
записи смогут послужить доказательством содеянного в суде. Возможно, это сможет дисциплинировать вас и не позволит пойти дальше исследования. Я все записываю, потому что дальше исследования не иду. Как поступать в случае желания
нарушить закон, я советовать не могу. Не могу и не хочу (есть такая песня).
Если вы выяснили ОС и даже используемые фреймворки, то этой информации уже
достаточно для простейшего взлома с помощью ошибок в ОС и службах, установленных на сервере. Просто посещайте регулярно www.securityfocus.com, а российскому пользователю могу посоветовать web-сайт www.securitylab.ru. Здесь можно
найти информацию о новых уязвимостях. Уже давно известно, что на большей части серверов (по разным источникам, от 70 до 90%) ошибки не устраняются или
устраняются, но с большими задержками (обычно после взлома). Поэтому проверяйте все найденные ошибки на жертве, — возможно, что-то и сработает.
Когда я использовал на своем web-сайте распространенные форумы типа phpBB, то
благодаря www.securitylab.ru оперативно узнавал об уязвимостях и чаще всего успевал устранять найденные в ИТ-мире ошибки. Но лет 10 назад я отказался от распространенных решений, стал все писать для своих сайтов сам и как-то перестал заглядывать на этот сайт дальше главной страницы, где читаю новости. Раньше на сайте достаточно часто обсуждали уязвимости и их эксплуатацию, но сейчас даже возможности
комментарии оставить нет.
Сейчас уже существуют более стандартные методы доступа к известным уязвимостям
через базы данных CVE (Common Vulnerabilities and Exposures). Одну из таких баз
данных можно найти на сайте cve.mitre.org. Все уязвимости получают уникальный
номер в формате CVE-YYYY-NNNN, где YYYY это год фиксации уязвимости и
NNNN уникальный номер в этом году. Это значит, что если вы хотите найти самую
первую зафиксированную уязвимость для не самого удачного 2020 года, то искать
нужно CVE-2020-0001.
На сайте cve.mitre.org есть раздел Search CVE List, где можно искать по известным
уязвимостям, указав уникальный код. Попробуйте найти информацию об уязвимости
CVE-2020-0001. Это баг в ОС Андроид. На сайте дается достаточно поверхностная
информация о баге, и если вам нужны более подробные данные о проблеме и программы-эксплоиты, которые автоматически эксплуатируют эту уязвимость, то эту информацию нужно уже искать в других источниках.
Я отказался от открытых форумов типа phpBB, потому что они часто становились
жертвами скрипт-кидди (людей, использующих для взлома чужие программы, —
чаще всего это молодые ребята, которые только хотят стать хакерами), от которых

Основы безопасности

29

часто слышатся высказывания типа: "Научите меня использовать эту уязвимость".
А ведь если научат, то он пойдет крушить все web-сайты подряд — надо же где-то
попробовать полученные знания. Именно такие люди представляют наибольшую
опасность.
Ошибки в программах проявляются достаточно часто, но если защита сервера, который вы решили взломать, в данный момент близка к совершенству (минимум
служб, и установлены все последние обновления), то придется ждать появления
новых ошибок и эксплоитов к установленным на сервере службам. Как только увидите что-нибудь интересное, сразу скачайте эксплоит (или напишите свой) и воспользуйтесь им, пока администратор не успел закрыть уязвимость. Хороший администратор закрывает ошибки быстро, сразу после их появления, а если есть возможность, то автоматизирует этот процесс.
Мы не будем рассматривать реальные примеры ошибок серверов и сервисов, потому что такие ошибки латаются очень быстро, и к моменту появления книги на полках магазинов эта информация станет не просто устаревшей, а подобной каменному веку, поэтому не имеет смысла тратить время на рассмотрение подобного класса
ошибок. В данном случае нужна только актуальная информация, и ее можно получить в интернете.
Со стороны защиты наша задача — отслеживать последние новости и обновлять ОС,
программное обеспечение, фреймворки и любые скрипты на своих серверах как
можно быстрее. Очень часто только обновление является единственным и уж точно
наилучшим способом защититься.
А если обновления от разработчика еще нет? Тут все зависит от ситуации; возможно, стоит временно отключить сервис; возможно, поможет сетевой экран. Трудно
дать какие-то рекомендации, когда может произойти практически все, что угодно.

1.3.5. Автоматизация
Практически каждый день специалисты по безопасности находят в разных системах недочеты, дыры или даже пробоины в системе безопасности. Все эти материалы выкладываются в отчетах BugTraq (бюллетень безопасности). Все новое, действительно, можно найти там, но ведь есть целый ворох старых уязвимостей, которые
существовали и, возможно, еще не закрыты. Как же поступить с ними? Неужели
придется качать все эксплоиты и проверять каждый на работоспособность? Ну, конечно же, нет. Для этого используются программные сканеры безопасности.
Сканеры безопасности, как и антивирусы, защищают хорошо, но только от старых
уязвимостей. Любой новый метод взлома не будет обнаружен, пока вы не обновите
программу.
В случае с web-уязвимостями сканнеры помогают достаточно неплохо, даже бесплатные и с открытым исходным кодом. По различным метрикам программы могут
найти признаки реальных уязвимостей.

30

Глава 1

Почему же тогда даже после лучшего и самого полного сканирования нельзя быть
уверенным, что уязвимостей нет? Помимо ошибок надо принимать во внимание
еще и фактор конфигурации. На каждом сервере могут быть свои настройки, и при
определенных условиях легко обнаруживаемая вручную уязвимость может остаться незаметной для автоматического сканирования. На сканер надейся, а сам не
плошай. Так что продолжайте тестировать систему на известные вам ошибки самостоятельно вручную.
Каждый сканер безопасности использует свои способы и приемы поиска уязвимостей, и если один из них ничего не нашел, то другой может отыскать. Специалисты по безопасности любят приводить пример с квартирой. Допустим, что вы
пришли к другу и позвонили в дверь, но никто не открыл. Это не значит, что дома
никого нет, просто хозяин мог не услышать звонок, или он не работал. Но если
позвонить по телефону, который лежит в этот момент возле хозяина, то он возьмет трубку. Может быть и обратная ситуация, когда вы названиваете по телефону, но его не слышно, а на звонок в дверь домочадцы отреагируют.
Точно так же происходит и при автоматическом сканировании: один сканер может
позвонить по телефону, а другой — постучит в дверь. Они оба хороши, но в конкретных случаях при разных конфигурациях сканируемой машины могут быть получены различные результаты.
Существуют три метода автоматического определения уязвимости: сканирование,
зондирование и имитация. В первом случае сканер собирает информацию о сервере, проверяет порты, чтобы узнать, какие на нем установлены службы, и на основе
их выдает отчет о потенциальных ошибках. Например, сканер может проверить
сервер и увидеть на 21-м порту работающий FTP-сервер. По строке приглашения
(если она не была изменена), выдаваемой при попытке подключения, можно определить его версию, которая сравнивается с базой данных. И если в базе есть уязвимость для данного FTP-сервера, то пользователю выдается соответствующее сообщение.
Сканирование — далеко не самый точный процесс, потому что автоматическое определение легко обмануть, да и уязвимости может не быть. Некоторые погрешности в службах проявляются только при определенных настройках, т. е. при установленных вами параметрах ошибка не обнаружится.
При зондировании сканер не обследует порты, а проверяет программы на наличие в
них уязвимого кода. Этот процесс похож на работу антивируса, который просматривает все программы на наличие соответствующего кода. Ситуации похожие, но
искомые объекты разные. Метод хорош, но одна и та же ошибка может встречаться
в нескольких программах. И если код в них разный, то сканер ее не обнаружит.
Во время имитации сканер безопасности моделирует атаки из своей базы данных.
Например, в FTP-сервере может возникнуть переполнение буфера при реализации
определенной команды. Сканер не будет выявлять версию сервера, а попробует
выполнить инструкцию. Конечно же, это приведет к зависанию, но вы точно будете знать о наличии или отсутствии ошибки на нем.

Основы безопасности

31

Имитация — самый долгий, но надежный способ, потому что если таким образом
удалось взломать какую-либо службу, то и у хакера это получится. При установке
нового FTP-сервера, который еще не известен сканерам безопасности, он будет опробован на уже известные ошибки других серверов. Очень часто программисты
разных фирм допускают одни и те же ошибки. При использовании сканирования
анализатор может без проблем найти уязвимость.
Когда проверяете систему, обязательно отключайте сетевые экраны. Если доступ
заблокирован, то сканер безопасности не сможет протестировать нужную службу.
В этом случае он сообщит, что ошибок нет, но реально они могут быть. Конечно
же, это не критичные ошибки, потому что они закрыты сетевым экраном, но если
хакер найдет потайной ход и обойдет сетевой экран, то уязвимость станет опасной.
Некоторые считают, что наиболее эффективно удаленное сканирование, когда атака имитируется по сети, ведь хакер тоже будет находиться на удаленной машине.
Дистанционное сканирование тоже имеет важное значение. При нем производится
попытка прорваться в сеть. Такой анализ может указать на стойкость защиты от
нападения извне. Но по статистике большинство взломов происходит изнутри, когда зарегистрированный пользователь поднимает свои права и тем самым получает
доступ к запрещенной информации.
Хакер тоже может иметь какую-нибудь учетную запись с минимальным статусом и
воспользоваться уязвимостями для повышения прав доступа. Хакер может иметь
доступ к внутренней сети, если ему удалось заразить компьютер одного из сотрудников компании, что случается не так уж и редко. Поэтому сканирование должно
происходить и дистанционно — для обнаружения потайных дверей, и локально —
для выявления ошибок в конфигурации, с помощью которых можно изменить привилегии.
В случае с web-серверами данное утверждение тоже имеет место. Дело в том, что
сценарии сайта выполняются в системе с правами web-сервера, которые должны
быть минимальными, и в большинстве систем они являются таковыми по умолчанию. Найдя уязвимость в сценарии, хакер получает возможность выполнять в системе сценарии с этими правами, и следующая его задача — поднять свои права,
чтобы увидеть защищенные данные.
Автоматические сканеры безопасности проверяют не только уязвимости ОС и ее
служб, но и сложность пароля, и имена учетных записей. В их анализаторах есть
база наиболее часто используемых имен и паролей, и программа перебором проверяет их. Если удалось проникнуть в систему, то выдается сообщение о слишком
простом пароле. Обязательно замените его, потому что хакер может использовать
тот же метод и легко узнает параметры учетной записи.
Сканеры безопасности могут использовать как хакеры, так и администраторы. Но
задачи у них разные. Одним нужно автоматическое выявление ошибок для последующего применения, а вторые используют его с целью поиска уязвимости с последующим устранением ошибки, причем желательно это сделать раньше, чем найдет и будет использовать ее хакер.

32

Глава 1

Ошибки, которые вы можете найти и которые могут привести к взлому, можно разделить на следующие категории:


ошибки в коде программ. Такие ошибки исправляются простым обновлением
программ;



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



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



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

Не все автоматические анализаторы разделяют ошибки по типам, но понимать источник ошибки желательно.

1.4. Взлом web-сайтов
Чем этот раздел отличается от предыдущего? В разд. 1.3 мы говорили о тестировании ОС и сервисов, которые работают на сервере — web-сервер (apache, nginx, iis),
возможно FTP-сервер и что еще стоит на сервере, где расположен ваш сайт или тот
сайт, который вы тестируете.
При взломе web-сайтов есть свои особенности. Если на нем выполняются PHP, Perl,
Python или другие сценарии, то предварительные исследования, которые мы описывали ранее, можно даже опустить. Иногда можно обойтись и без сканирования
портов, а вот ОС определить желательно, ведь когда вы получите возможность выполнять команды, то должны знать, какие именно команды может выполнять система.
Для начала нужно просканировать web-сервер на наличие уязвимых CGIсценариев. Да, именно просканировать, потому что есть программы, которые автоматизируют этот процесс. Вы не поверите, но опять же по исследованиям различных компаний, в интернете работает большое количество "дырявых" сценариев.
Это связано с тем, что при разработке web-сайтов в них изначально вносятся ошибки. Нет, не специально. Начинающие программисты очень редко проверяют входящие параметры в надежде, что пользователь не будет изменять код web-страницы

Основы безопасности

33

или URL, где web-серверу передаются необходимые данные для выполнения какихлибо действий. Это стало возможным потому, что программисты понадеялись на
добросовестность посетителей. А зря. Посетители очень часто не добросовестные.
Как и в случае с тестированием серверов и их сервисов (о чем мы говорили в разд. 1.3),
для web-сайтов есть как сканеры безопасности, так и защитные системы, которые
работают как сетевые экраны и защищают код сайтов от злоумышленников.
У web-приложений тоже бывают своеобразные экраны, которые могут фильтровать
трафик, который идет от пользователя к серверу. Одним из популярных решений в
данной сфере является Application Security Manager (менеджер защиты приложений
ASM) фирмы F5 Networks (https://ru.wikipedia.org/wiki/F5_Networks). Его работа
схожа с сетевым экраном, потому что он анализирует проходящий трафик на наличие трафика, который похож на атаку хакера, и блокирует его.
Мне довелось поработать с ASM этой компании в течение 5 лет, и он показал хорошие результаты, хотя и были проблемы с ложным срабатыванием защитных
фильтров. Сейчас же нас волнует вопрос автоматического тестирования.
Защитные фильтры для web-сайтов могут блокировать нормальное тестирование
web-сайта, и сканер просто не увидит уязвимость, которая в реальности может существовать. Хорошо это или плохо?
Если сканер не увидит уязвимость, то и хакер, скорее всего, тоже, если будет использовать этот же инструмент. А если он будет искать уязвимость руками? История показывает, что далеко не все фильтры идеальны — им свойственно ошибаться
или подводить.
Не стоит прятать уязвимость с помощью фильтров и надеяться, что она останется
невидимой. Уж лучше найти и исправить все проблемы заранее.
У меня менеджер защиты приложений всегда был включен для серверов, которые
обслуживали пользователей (production servers). Но тестирование сайтов проходило
в обход этой защиты, чтобы сканеры имели полный доступ и прямой доступ к сайту. Как же это реализовать?
Все очень просто: сканеры безопасности тестировали реальные рабочие сервера раз
в неделю в периоды, когда трафик пользователей был низким. Помимо этого, был
специально выделенный сервер, на котором находился такой же код сайта, как и у
рабочих серверов, просто база данных не содержала реальные данные и этот webсервер был защищен сетевым экраном так, что к нему могли подключиться только
из внутренней сети с компьютеров, с которых происходило тестирование безопасности.
Таким образом у тестирующих сайт компьютеров был прямой доступ к такому же
коду, как и на рабочих серверах, и он мог найти даже те уязвимости, которые скрыты за менеджером защиты приложений.
Дайте сканеру безопасности все необходимые права и доступ к сканируемой системе.

34

Глава 1

1.4.1. Анализатор web-уязвимостей
Итак, ваша первостепенная задача — запастись парочкой хороших сканеров webуязвимостей. Какой лучше? Ответ однозначный — все. Даже самый простой сканер
с минимальными возможностями может найти брешь, о которой неизвестно другому.
На заре интернета очень часто можно было встретить сканеры с базами данных уязвимостей, но поддержка такой базы данных в наше время — очень дорогое удовольствие, потому что различных сценариев в интернете очень много, а уязвимостей еще больше (в одном сценарии иногда находят по 10 и более ошибок). Все это
отслеживать очень дорого, а платить пользователи за подобную программу не хотят. Хакеры вообще мало за что хотят платить, а администраторам и владельцам
сайтов такая база просто не нужна. Их интересуют ошибки только сценариев, установленных у них, и только актуальные ошибки, а не устаревшие.
Из-за этого в мире тестирования web-уязвимостей более популярны программыимитаторы, которые имитируют ошибку. На мой взгляд, это наиболее эффективный
в данной сфере способ, потому что позволяет искать ошибки не по базе, а на абсолютно любом сайте.
Программы для тестирования безопасности приходят и уходят, кто-то создает сначала бесплатную версию, но как только она становится популярной, ее делают платной.
Такое происходит достаточно часто. Но все же есть еще бесплатные утилиты, с помощью которых можно производить точечное тестирование определенных уязвимостей.
Я как-то давно работал над собственной программой для тестирования уязвимостей
CyD Network Utilities - Security tools под Windows, которую все еще можно скачать с
моего сайта www.cydsoft.com, но если честно, я ее уже давно не поддерживаю, последнее обновление было лет 8 назад, и даже не знаю, запустится программа сейчас
под Windows 10 или нет.
Проблема простых и бесплатных автоматических тестов, с которыми я работал: их
функционал ограничен и они не всегда видят проблему. Очень часто программы тестируют только данные, которые передаются в строке URL, но это не единственное
место, на которое может повлиять пользователь, есть еще и плюшки cookie, в которых также могут быть уязвимости. Есть еще и формы, которые отправляют данные
на сервер, и при этом они могут быть защищены от автоматической отправки данных
на сервер, и тогда программные средства фактически становятся бесполезными.
Одной из таких защит является каптча (CAPTCHA) — это тест, когда нужно ввести в
специальное поле цифры и буквы с картинки или сделать что-то в определенной последовательности. Такая защита делается специально, чтобы защищать сайт от спамеров и автоматических систем.
Опять же, чтобы программное средство проверило ваш код на ошибки, нужно дать
ему эту возможность и отключать защиту, когда запросы идут от определенной программы.

Основы безопасности

35

Можно отключать защиту, если запросы приходят с определенного IP-адреса, на котором установлено приложение проверки безопасности. Это, наверное, самый надежный способ. Я видел, когда защиту отменяли, если запрос приходит на домен
test.site.com. В принципе, это будет работать, потому что по умолчанию пользователи
загружают сайты по адресу www.site.com или просто site.com, а для test.site.com
может даже не существовать DNS-записи.
Но хакер может изменить свой hosts-файл и добавить в него запись:
162.241.30.65

test.flenov.info

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

sqlmap
Одна из популярных программ с открытым исходным кодом, которая существует
уже долгие годы, sqlmap (http://sqlmap.org/). Она простая, делает одну задачу, но
делает ее очень хорошо — ищет уязвимость SQL Injection.
Следующие команды выполняем в командной строке Linux:
cd ~
git clone https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
cd sqlmap-dev

Программа sqlmap написана на Python, и чтобы ее установить, нужно скачать скрипты из git-репозитория. Это открытый проект, в котором может участвовать кто угодно.
В первой команде мы переходим в свою домашнюю папку, второй командой копируем файлы с git-сервера в папку sqlmap-dev и третьей командой переходим в папку
sqlmap-dev, чтобы из нее запускать уже программу.
Формат команды для запуска:
python3 sqlmap.py --batch --banner

-u "url"

после ключа -u в двойных кавычках идет адрес к странице, которую вы хотите протестировать. Адрес должен быть с каким-то параметром в адресе. Когда мы будем
подробно рассматривать природу уязвимости, вы поймете, почему именно так. Уязвимости чаще всего живут в тех местах, где данные передаются серверу.
Возьмем мой сайт — www.flenov.info. На нем есть страница поиска, которая позволяет искать на сайте по какому-то тексту. URL страницы выглядит как:
https://www.flenov.info/search/index?search=

После вопросительного знака в URL могут идти параметры, которые пользователь
передает серверу. В данном случае имя параметра search, и если сервер неверно использует полученные данные при обращении к нему, то это приводит к уязвимости.
python3 sqlmap.py --batch --banner
-u "https://www.flenov.info/search/index?search="

36

Глава 1

Программа начнет тестировать этот адрес и будет пытаться найти уязвимость SQL
Injection. В конце тестов программа покажет самое важное для нас:
all tested parameters do not appear to be injectable.

Грубо говоря, это можно перевести так: "Все протестированные параметры, похоже,
не имеют инъекции". Для меня это хорошо, потому что мой сайт неуязвим к подобной ошибке, по крайней мере программа sqlmap ничего не нашла, но, может, она не
так хорошо искала или не смогла определить проблему?

XSStrike
Эта программа также написана на Python, и поэтому проще будет работать с ней из
командной строки Linux. Но прежде чем устанавливать ее, убедись, что установлен
pip, который позволяет устанавливать дополнительные модули для python-программ.
Устанавливаем программу и для этого скачиваем исходники:
cd ~/
git clone https://github.com/s0md3v/XSStrike.git xss-strike
cd xss-strike

Здесь я снова перехожу в домашнюю папку, запускаю скачивание с githubисходников программы в папку xss-strike и перехожу в эту папку.
Теперь запускаем тест с помощью
python3 xsstrike.py
-u https://www.flenov.info/search/index?search=

Если произошла ошибку, то для Ubuntu версий Linux нужно выполнить следующие
две команды:
sudo apt update
sudo apt install python3-pip

Если у вас macOS, то можно выполнить следующие двекоманды:
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py

Теперь повторите попытку запустить тест.
XSStrike — достаточно продвинутый тестер, который неплохо проверяет параметры,
но у него очень много ложных срабатываний.
Я показал две программы просто для примера. Подобные утилиты тестирования приходят и уходят. Те, о которых я писал 10 лет назад, уже ушли, и не удивлюсь, что и
эти исчезнут. Даже если это произойдет, для простых тестов их будет достаточно.
Я не пытался показать или научить вас пользоваться всеми возможными и нужными
для тестов утилитами. Я сам не фанат их использования. Да, они позволяют дать какое-то быстрое представление, но самое интересное кроется в ручном тестировании.

Основы безопасности

37

1.4.2. Взлом с помощью поисковой системы
Функции поисковых систем уже давно развились до такой степени, что позволяют
находить не только разрешенную информацию, но и запрещенную. Жаль, что
большинство пользователей не освоили все функции поисковых систем (меньше
возникало бы вопросов в стиле "где найти"), а вот взломщики изучили все функции
и используют их в своих целях. Да, такую мощь злоумышленники просто не могли
обойти стороной.
Один из самых простых способов взлома — найти с помощью поисковой системы
закрытую web-страницу. Некоторые web-сайты имеют засекреченные области, к
которым доступ осуществляется по паролю. Сюда же относятся платные ресурсы,
где защита основана на проверке пароля при входе, а не на защите каждой webстраницы и использовании SSL. В таких случаях Google проиндексирует запрещенные web-страницы, и их можно будет просмотреть, правильно составив поисковый запрос. Для этого всего лишь надо четко знать, какая информация хранится в
файле, и как можно точнее составить строку запроса.

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

или
Годовой отчет filetype:xls

И вы найдете все документы в формате Word или Excel, содержащие слова "Годовой отчет". Возможно, документов будет слишком много, поэтому запрос придется
ограничить сильнее, но кто ищет, тот всегда найдет.

Поиск уязвимых web-сайтов
Допустим, вы узнали, что в какой-либо системе управления web-сайтом появилась
уязвимость. Что это за система? Существует множество платных и бесплатных готовых программ, написанных на PHP, Perl, Python и других языках и позволяющих
создать web-сайт без особых усилий. Такие системы могут включать в себя готовые
реализации форумов, гостевых книг, лент новостей и т. д. Например, WordPress —

38

Глава 1

система управления контентом. Эта система очень сильно распространена в интернете, и на ее базе построено достаточно большое количество сайтов.
Если в каком-нибудь популярном фреймворке или каком-то популярном приложении найдена критическая уязвимость, то все web-сайты в интернете, использующие
этот код, подвергаются опасности. Очень часто у небольших сайтов нет даже администраторов или специалистов по безопасности, которые бы отслеживали новости
и обновляли сценарии, поэтому остается только найти нужный web-сайт и воспользоваться готовым решением для осуществления взлома.
Как найти web-сайты или форумы, которые содержат уязвимость? Очень просто.
Чаще всего сценарий жертвы можно определить по URL. Например, когда вы просматриваете на web-сайте www.sitename.ru раздел форума, использующего в качестве движка Invision Power Board, то строка адреса содержит http://www.sitename.ru/
index.php?showforum=4. Текст "index.php?showforum=" будет встречаться на любом
web-сайте, использующем для форума Invision Power Board. Чтобы найти webсайты, содержащие в URL данный текст, нужно выполнить в поисковой системе
Google следующий запрос:
inurl:index.php?showforum

Могут быть и другие программы, которые используют этот текст. Чтобы отбросить
их, нужно еще добавить поиск какого-нибудь фрагмента из web-страниц. Например, по умолчанию внизу каждой web-страницы форума есть подпись: "Powered by
Invision Power Board(U)". Конечно же, администратор волен изменить подпись, но
в большинстве случаев ее не трогают. Именно такой текст можно добавить в строку
поиска, и тогда результатом будут только web-страницы нужного нам форума. Попробуйте выполнить следующий запрос:
Powered by Invision Power Board(U)
inurl:index.php?showforum

Вы увидите более 150 тысяч web-сайтов, реализованных на этом движке. Теперь,
если появится уязвимость в Invision Power Board, то вы легко найдете жертву. Далеко не все администраторы успеют ликвидировать ошибки, а некоторые вообще
не будут их исправлять, потому что web-сайты могут быть уже давно позабыты и
позаброшены.
Попробуйте задать в поиске inurl:admin/index.php, и вы найдете столько интересного, что аж дух захватывает. Такие ссылки очень часто используются для управления чем-либо на web-сайте. Опытные администраторы защищают их паролями, и,
конечно, большинство из этих ссылок будет недоступно, но открытые могут позволить уничтожить web-сайт полностью.

Управление поисковым роботом
Чтобы защититься от ненужной индексации, можно управлять поисковым роботом.
Как поисковые системы находят какие-то документы? Специальная программакраулер "бегает" по интернету по ссылкам со страницы на страницу и индексирует

Основы безопасности

39

все, что находит. Если вы по ошибке выложите где-то ссылку на важные данные,
которые не должны быть публичными, то поисковая система проиндексирует документ, и найти его с помощью поискового запроса станет намного проще.
Чтобы обезопасить важные данные от случайной ссылки и индексации, можно
управлять краулером с помощью файла с именем robots.txt. Это просто текстовый
файл, который нужно создать в корне сайта. В нем прописываются права страницы
или каталоги, которые можно или, наоборот, нельзя индексировать. Если вам нечего
скрывать и можно индексировать весь сайт, то файл должен содержать две строки:
User-agent: *
Allow: /

В первой строке указан параметр User-agent, после которого можно указать поисковую систему, к которой относятся последующие правила. Если правила касаются
всех, то нужно указать звездочку (*). Например, следующее содержимое файла запретит индексацию сайта Яндексом:
User-agent: Yandex
Disallow: /

Не вижу смысла запрещать что-то индексировать одной поисковой системе
и разрешить другим, лучше прописывать разрешения сразу всем.
Во второй строке в первом случае указана команда Allow (разрешение), а во втором — Disallow (запрещение). После этих операторов нужно указать каталог, к которому вы хотите разрешить индексацию или запретить. Разрешать не имеет смысла, потому что по умолчанию поисковые системы индексируют все сайты, которые
находят, если явно не запрещено.
За командами разрешения или запрета после двоеточия указывается путь в URL без
доменного имени, разрешение к которому вы указываете. Это значит, что если
нужно запретить индексацию корня сайта, то достаточно указать слеш /. Если нужно запретить индексацию администраторской панели или доступ к папке приватных
документов, то нужно указать их разрешения, каждое в отдельной строке:
User-agent: *
Disallow: /admin
Disallow: /private-docs

Управляя поисковой системой, можно наступить на небольшие грабли, потому что
файл robots.txt никак не защищается сервером. Он открыт для всеобщего доступа, а не
только поисковым системам. Это значит, что кто угодно сможет обратиться к этому
файлу и увидеть, что запретил к индексации владелец сайта. Нужно просто написать в
URL браузера адрес http://www.flenov.info/robots.txt (конечно же, тут flenov.info
нужно заменить на имя домена, который вы хотите просмотреть), и вы увидите содержимое файла со всеми его разрешениями.
А зачем хакеру нужен файл robots.txt? Если запрещено индексировать папку
/myadmin, то хакер может предположить, что по адресу http://www.flenov.info/
myadmin (этот адрес не существует, это только пример, поэтому можете не пы-

40

Глава 1

таться сейчас найти по нему что-то интересное) находится администраторская панель сайта. Вполне возможно, что хакер окажется прав, и если по этому адресу
страница не защищена паролем, то хакер сможет получить к важным функциям
управления сайтом.
Получается, что файл robots.txt может как защитить вас от хакера, так и наоборот —
помочь злоумышленнику проникнуть на сайт, поэтому не стоит надеяться только
на этот файл.
Вы должны учитывать следующие факты относительно использования поисковых
систем в защите и поиске уязвимостей:
файл robots.txt запрещает только индексирование содержимого какой-то папки
на web-сервере, но не запрещает к ней доступ. Все папки с важными сценариями
и сценариями администрирования должны быть защищены паролями. Это намного важнее и надежнее. Защищенные паролем папки поисковый краулер не
сможет проиндексировать, потому что он не является хакером и индексирует
только открытые сценарии;
 если папка содержит файлы документов, то имеет смысл запрещать их индексирование, если имена файлов непредсказуемы. Если взломщик знает имя файла
или может его предугадать, то файлы будут скачаны с сервера и без поисковой
системы;
 раз поисковая система смогла найти файл с важными данными, то значит, где-то
есть открытая ссылка на файл, которую нашел поисковый краулер и может найти хакер, поэтому robots.txt не является спасением.


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

1.5. Подбор паролей
Там, где не удалось взломать сервер с помощью умения и знаний, всегда можно
воспользоваться чисто русским методом "серпа и молота". Это не значит, что серп
нужно приставлять к горлу администратора, а молотком стучать по голове. Но тут
есть ассоциация с английским выражением brute force — грубая сила.
Давайте снова обратимся к статистике. Очень много исследований пришло к одному и тому же выводу, что большинство начинающих пользователей компьютера
выбирает в качестве пароля имена своих любимых собачек, кошечек, даты рождения или номера телефонов. Так как у кошечек и собак не бывает имен типа
kl43hYP51HBbs4#&g3, а чаще можно встретить Мурзиков, Шариков и Тузиков, то
такие имена подбираются очень быстро. Хорошо подобранный словарь может сломать практически любую систему, так как всегда найдутся неопытные пользователи с простыми паролями в виде имен. Самое страшное, если у этих "чайников" будут достаточно большие права.

Основы безопасности

41

Создать словарь, в котором будет слово kl43hYP51HBbs4#&g3, нереально, потому
что никто даже представить себе такого не сможет. Вы видели фильм "Хакеры" с
Анджелиной Джоли? В нем говорилось о том, что администраторы любят использовать четыре пароля. Нет, их, конечно, не четыре, но на заре интернета разнообразие паролей, действительно, было небольшим — не более ста. Ведь тогда не очень
заботились о безопасности, никто не думал о хакерах. После выхода фильма
"Звёздный путь" (англ. Star Trek — "Стартрек") многие любители этого фильма выбирали в качестве пароля какие-то имена или названия оттуда.
Да что там далеко ходить — для тех систем и сайтов, которые важны для меня, я использую сложные пароли, сгенерированные методом случайного стука по клавиатуре. Для различных форумов, пароли к которым я не хочу запоминать, я использую три варианта паролей или разрешаю браузеру выбрать пароль за меня, благо в
Safari есть возможность сгенерировать сложный пароль и запомнить его в системе.
Стоит ли доверять паролям, которые генерируют браузеры? Я слышал такое мнение, что им доверять нельзя, но при этом люди доверяют специальным менеджерам
паролей. А ведь и те и другие работают примерно одинаково. Браузер Safari под
macOS хранит пароли в специальном хранилище, и Apple за последние годы доказала, что относится к безопасности серьезно.
Я доверяю Apple, Microsoft и их менеджерам паролей и вам рекомендую. Это намного лучше, чем пароли на бумажке, в текстовых редакторах или записных
книжках.
В качестве яркого примера давайте вспомним знаменитейшего "червя Морриса",
который проникал в систему, взламывая ее по словарю. Собственный лексикон
червя был достаточно маленький и состоял менее чем из ста слов. Помимо этого,
при переборе использовались термины из словаря, установленного в системе. Там
их было тоже не так уж много. И вот благодаря такому примитивному алгоритму
червь смог поразить громаднейшее число компьютеров и серверов. Это был один
из самых массовых взломов. Да, случай давний, но средний профессионализм пользователей не растет, так как среди них много начинающих.
Метод подбора очень часто используется для взлома почтовых ящиков, FTP и других служб, в которых протокол представляет собой простые текстовые команды и
где нет шифрования передаваемого по сети пароля. Взламывать шифры перебором — слишком утомительное занятие, особенно если для получения одного зашифрованного текста необходимо много процессорного времени. Да, шифрованные пароли тоже можно взламывать, просто затраты тут будут выше.
Подбор — это достаточно долгий процесс, но если выбран действительно длинный
и сложный пароль, то даже лучший словарь не выручит хакера. Но и в этом случае
не стоит расслабляться. Хакер может воспользоваться полным подбором по всем
символам. Это отнимет в несколько раз больше времени, но, в конце концов, даст
положительный результат. Чтобы этого не произошло, нужно установить какуюнибудь систему обнаружения атак. Хороший сетевой экран без проблем выявит попытки подбора и просигнализирует об этом. Убедитесь, что ваш сетевой экран содержит подобную функцию.

42

Глава 1

Функция определения попытки взлома перебором очень проста в реализации. Нужно только отследить слишком большое количество неудачных попыток авторизации на один и тот же порт (сервис) с одного и того же адреса. Хакеры часто идут на
хитрости и взламывают с нескольких адресов параллельно, но чтобы определить
это, не нужен слишком высокий искусственный интеллект, количество неудачных
попыток все равно остается весьма большим.
Достаточно популярный способ защиты от перебора — блокировка аккаунта на 30
минут после трех неудачных попыток, и не имеет значения, с какого IP-адреса происходит попытка авторизации. При такой защите полный перебор отдельного аккаунта может стать практически бесконечным.
При полном переборе сложного пароля понадобится слишком много времени, что
может оказаться несопоставимым с полученным результатом. За время подбора
также может измениться пароль, если пользователь меняет его каждые пару месяцев. Получается, что защититься от перебора можно и регулярной сменой пароля,
например каждый месяц. В некоторых системах можно даже устанавливать определенные политики, которые смогут принудить пользователя менять пароль. Если в
вашей ОС есть такая возможность, то обязательно используйте ее, чтобы не забывать регулярно менять пароль.
Прежде чем приступать к подбору, нужно хорошо подобрать словари имен и паролей. Очень важно знать, какую систему вы взламываете. Именно для этого мы определяли версию ОС. Например, если это серверный вариант Windows, то желательно, чтобы среди имен учетных записей был "Администратор". Ну а если это
UNIX-подобная система, то обязательно должен присутствовать "root", а все имена
типа "Администратор" нужно убрать, потому что в UNIX таких учетных записей не
создают. Конечно, бывают случаи, когда специалист по безопасности хочет представить свой сервер как Windows, а на самом деле это Linux, но такое бывает редко,
потому что в клане Linux всячески ненавидят все, что связано с Microsoft, и данный
случай можно опробовать отдельно вручную.
Наличие заведомо известного имени упрощает подбор, так как остается только
найти пароль. Поэтому, чтобы усложнить злоумышленнику задачу, необходимо
изменить имена учетных записей. Если же вы используете сложный пароль, то имя
можно сделать попроще, потому что его лучше всего держать в голове. Идеальный
вариант — усложнить и пароль, и имя.
Неплохо было бы включить в словарь любые имена и пароли, используемые по
умолчанию для разных служб. Очень часто администраторы забывают или просто
ленятся поменять пароли на службы, которые запущены, но не используются. Например, я сталкивался с настройкой MS SQL Server 7.0, в которой включена встроенная учетная запись sa, и при этом абсолютно без пароля. Наверное, поэтому
Microsoft собирается убрать это имя уже в следующей версии своей СУБД, а MS
SQL Server 2000 на каждом шагу предупреждает о необходимости использования

Основы безопасности

43

пароля. При установке популярной базы данных MySQL нам даже не предлагают
поменять пароль пользователя root и его нередко забывают поменять.
В последнее время очень хорошо зарекомендовали себя переборы по уже существующим словарям, составленным на основе взломанных ранее сайтов. Хакеры
взламывали и воровали базы данных имен и паролей для множества сайтов, как небольших, так и крупных. Пользователи любят использовать один и тот же пароль
на разных сайтах и если один из этих сайтов был взломан, то хакеры смогут взломать аккаунты этого же пользователя и на других сайтах. Достаточно просто взять
базу данных имен и паролей с одного из взломанных ранее сайтов и прогнать по
всем сайтам подряд.
Формы на вход на сайт очень редко защищают каптчей, поэтому автоматический
прогон не является серьезной проблемой для взломщика.
Есть два способа защититься от подобных вещей:
1. Использовать уникальные пароли на каждом из сайтов. Это правило отлично ра-

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

просить пользователя ответить на какой-либо вопрос безопасности. Очень часто
утекают в сеть именно имена и пароли, а не ответы на вопросы безопасности,
поэтому есть вероятность, что при прогоне словаря имен и паролей у хакера не
будет ответов именно на тот вопрос безопасности, который вы задали.
Если вас раздражают дополнительные вопросы, то я хотел бы посоветовать вам все
же смириться с этим. Помните, что это все делается для вашей же пользы и безопасности.
Итак, дополнительные вопросы действительно могут повысить безопасность, но
это все же не идеальный вариант. Дело в том, что вопросы часто достаточно специфичные, типа город вашего рождения, девичья фамилия мамы, имя лучшего друга, кличка животного и т. д. Если на двух сайтах вас просят имя, пароль и кличку
животного и по какой-то причине имя и пароль совпадают на сайтах у одного и того же пользователя, то кличка животного уж точно будет совпадать.
Однако более эффективным решением считается отправка e-mail с уникальным кодом, отправка SMS с уникальным кодом или использование специального мобильного приложения, и я бы поставил их именно в таком порядке.
Все три метода великолепно защищают от автоматического сканирования, но отметим, что при необходимости вводить какое-то число, которое отправляют вам по
e-mail, sms или с помощью приложения — сканирование становится невозможным.
Первые два варианта не всегда эффективны против направленной атаки на конкретного пользователя, но третья достаточно эффективна даже для защиты от случаев, когда вы стали целью и именно вас пытаются взломать.

44

Глава 1

1.6. Троянские программы
Использование троянских программ — очень глупый (перебор паролей еще глупее,
а троянские программы сидят на хвосте) и ненадежный в отношении администраторов сетей или web-сайтов способ взлома. Хотя среди администраторов встречаются непрофессионалы, но на такие шутки уже мало кто попадается. Однако кроме
них есть еще множество простых пользователей с большими привилегиями и доверчивой душой. Вот именно им и надо устанавливать троянские программы.
Троянская программа состоит из двух частей: клиентской и серверной. Серверную
часть нужно подбросить на компьютер жертвы и заставить жертву запустить файл.
Чаще всего троянская программа прописывается в автозагрузку и стартует вместе с
ОС, и при этом незаметна в системе. После этого вы подключаетесь к серверной
части с помощью клиента и выполняете заложенные в программу действия: например, перезагрузка компьютера, воровство паролей и т. д.
Как забрасывать троянскую программу? Самый распространенный способ — социальная инженерия и ящик электронной почты. Просто даете исполняемому файлу
серверной части какое-нибудь привлекательное имя и отправляете сообщение
жертве. В тексте письма должны быть мягкие, но заманчивые призывы запустить
прикрепленный файл. Если пользователь запустит серверную часть, то вы сможете
выполнять те действия, которые заложены в функционал троянской программы.
Но если троянская программа запущена на компьютере пользователя, это еще не
говорит о том, что компьютер может быть взломан. Прошли те времена, когда ОС
разрешала программам устанавливать совершенно любые сетевые подключения.
Сейчас все системы содержат сетевые экраны, которые защищают пользователей и
могут спасти их от троянских программ.
Но сколько ни пишут об опасности троянских программ, даже в крупных корпорациях хорошо осведомленные люди все равно могут пострадать от них. Ходят слухи, что именно благодаря таким программам из недр Microsoft когда-то ушли исходные коды MS Windows.

1.7. Denial of Service (DoS)
Еще одна атака, которую используют хакеры не только против компьютеров и серверов, но и против web-сайтов, — это DoS (Denial of Service, отказ в обслуживании). Заключается она в том, чтобы заставить сервер не отвечать на запросы пользователей. Как это можно сделать? Очень часто такого результата добиваются с
помощью зацикливания работы. Например, если сервер не проверяет корректность
входящих пакетов, то хакер может сделать такой запрос, который будет обрабатываться вечно, а на работу с остальными соединениями не хватит процессорного
времени, тогда клиенты получат отказ от обслуживания.
Еще один способ заставить сервер не отвечать на запросы — найти такую функцию, которая выполняется дольше всего и съедает больше всего ресурсов процес-

Основы безопасности

45

сора. Запустив на выполнение эту функцию много раз, сервер угрюмо погружается
в тяжелую работу, и ресурсов не хватает на выполнение даже простых запросов.
Если сайт написан на C# и .NET платформу, то плохой код может не освобождать
соединения с базами данных в случае ошибок. Если хакер найдет страницу, которая
в определенный момент генерирует ошибку и начнет загружать ее без остановки,
то не закрытые с базой данных соединения могут привести к тому, что база перестанет отвечать на новые запросы, а web-сервер без возможности подключиться к
базе данных начнет зависать.
Самые распространенные методы основаны на загрузке ресурсов сервера, но это не
единственная стратегия. Атаку DoS можно произвести и через ошибку в серверном
программном обеспечении. Этот способ требует знания уязвимости на сервере.
Рассмотрим, как происходит отказ от обслуживания через переполнение буфера
(чаще всего используемая ошибка). Допустим, что вы должны передать на сервер
строку "HELLO". Для этого в серверной части выделяется память для хранения 5
символов. Структура программы может выглядеть примерно следующим образом:
Код программы
Буфер для хранения 5 символов
Код программы

Предположим, пользователь отправит не пять, а сто символов. Если при приеме
информации программа не проверит размер блока, то при записи данных в буфер
они выйдут за его пределы и запишутся поверх исполняемого кода программы. Это
значит, что программа будет испорчена и не сможет выполнять каких-либо действий, и, скорее всего, произойдет зависание. В результате сервер не будет отвечать на
запросы клиента, т. е. совершится классическая DoS-атака через переполнение буфера.
Таким образом, компьютер не взломали, и информация осталась нетронутой, но
сервер перестал быть доступным по сети.
Такие атаки встречаются не так часто в наше время, потому что большинство webсайтов пишутся на языках, в которых нет прямого доступа к памяти. Системы
управления памятью Java или .NET не позволяют выходить за пределы массивов.
Через переполнение буфера хакер может взломать систему при определенных обстоятельствах, но этот вопрос мы сейчас не рассматриваем. Сейчас разговор идет
об отказе от обслуживания.
Для перегрузки ресурсов атакуемой машины вообще не надо ничего знать, потому
что это война, в которой побеждает тот, кто сильнее. Ресурсы компьютера могут
быть ограничены. Например, web-сервер для связи с клиентами может организовывать только определенное количество виртуальных каналов. Если их создать больше, то web-сервер становится недоступным. Для совершения такой атаки достаточно написать программу на любом языке программирования, бесконечно открывающую соединения. Рано или поздно предел может быть превышен, и сервер не
сможет работать с клиентами.

46

Глава 1

Чтобы защититься от подобных атак сервера не держат открытыми соединения,
если пользователь пассивен, но что, если сделаем вид, что наш канал очень медленный? Есть такая атака, как Slow Http, и ее можно реализовывать как с точки зрения загрузки данных на сервер, так и с точки зрения скачивания данных с сервера.
Если на сервере есть возможность закачивать файлы, то нужно инициировать запрос на закачку максимально допустимого файла и начать отправлять на сервер
данные очень медленно. Так как данные передаются, сервер не будет закрывать
соединение, и инициализация большого количество медленных запросов на загрузку данных на сервер может привести к отказу в обслуживании.
То же самое можно сделать и на скачивание. Нужно найти самый большой файл
(изображение или просто какой-то большой файл) и инициализировать скачивание,
но после получении каждого нового пакета делать задержку, прежде чем отправлять подтверждение, что пакет получен.
От обеих этих атак можно защититься, если настроить сервер так, чтобы он закрывал медленные соединения и не пытался доставить данные клиентам, которые испытывают серьезные проблемы с соединением. Да, в наше время можно наказать
такой настройкой и легитимных пользователей, которые пытаются обратиться к
сайту с мобильного телефона в зоне плохого примера, где проблема со связью. Но
лучше такие пользователи повторят попытку позже, чем все пользователи пострадают от атаки хакеров.
Если нет программных ограничений на ресурсы, то сервер будет обрабатывать
столько подключений, сколько сможет. В таком случае атака может производиться
на канал связи или на сервер. Выбор цели зависит от того, что слабее. Например,
если на канале в 100 Мбит/c стоит компьютер с процессором 100 МГц, то намного
проще вывести из строя компьютер, чем перегрузить данными канал связи. Ну а
если это достаточно мощный сервер, который может выполнять миллионы запросов в секунду, но находится на канале в 64 Кбит/с, то легче загрузить канал.
Как происходит загрузка канала? Допустим, что вы находитесь в чате и кто-то вам
нагрубил. Вы узнаете его IP-адрес, и выясняется, что обидчик работает на простом
модемном соединении со скоростью 56 Кбит/с. Даже если у вас такое же соединение, можно без проблем перегрузить канал обидчику. Для этого направляем на его
IP-адрес бесконечное количество ping-запросов с большим размером пакета. Компьютер жертвы должен будет отвечать на них. Если пакетов много, то мощности
канала хватит только на то, чтобы принимать и отвечать на ping-запросы, и обидчик уже не сможет нормально работать в интернете. Если у вас канал такой же, то и
ваше соединение будет занято исключительно приемом-отсылкой больших пакетов. Это того стоит? Если да, то можете приступать.
В случае атаки на сервер и его процессор наш канал может быть намного слабее,
главное — правильно определить слабое звено. Допустим, что сервер предоставляет услугу скачивания и хранения файлов. Чтобы перегрузить канал такого сервера,
нужно запросить одновременное скачивание нескольких очень больших файлов.
Скорость связи резко упадет, и сервер может даже перестать отвечать на запросы
остальных клиентов, при этом загрузка процессора сервера может быть далека от

Основы безопасности

47

максимальной. Если неправильно определить слабое звено и нарастить мощность
сервера, то производительность не увеличится, потому что требуется расширение
канала связи.
Для загрузки процессора тоже не требуется слишком большой канал. Нужно только
подобрать запрос, который будет выполняться очень долго. Допустим, что вы решили произвести атаку на сервер, позволяющий переводить на другой язык указанные web-страницы любого web-сайта. Находим web-страницу с большим количеством текста, например книгу или документацию RFC (Request for Comments, рабочее
предложение), и посылаем множество запросов на ее перевод. Мало того, что объем большой и для скачивания серверу нужно использовать свой канал, так еще и
перевод — достаточно трудоемкий процесс. Достаточно в течение 1 секунды отправить 100 запросов на перевод громадной книги, чтобы сервер перегрузился. А
если используется блокировка многократного перевода одного и того же, то нужно
подыскать несколько больших книг.
В данном случае атака отказа от обслуживания отражается достаточно просто. Серверное программное обеспечение должно контролировать и ограничивать количество запросов с одного IP-адреса и объем, запрашиваемых за раз данных. Но это все
теоретически, и такие проверки оградят только от начинающих хакеров.
Самое сложное — защититься от перегрузки канала. Дело в том, что когда на наш
сервер идет большое количество пакетов, то отфильтровать их без получения невозможно. Защититься можно только расширением канала до такой степени, чтобы
его невозможно было заполнить.

1.7.1. Distributed Denial of Service (DDoS)
С помощью DoS-атаки достаточно сложно вывести из обслуживания такие webсайты, как www.microsoft.com или www.yahoo.com, потому что для их работы используются достаточно широкие каналы и сверхмощные серверы. Но, как показывает практика, хакеры находят выходы из любых ситуаций. Для получения такой
мощности используется DDoS. В этом случае атаку производит не один компьютер,
а множество, и каждый из них пытается засыпать сервер мусором. Если сложить
все маленькие каналы пользователей, которые засыпают сервер, то в сумме они могут превысить возможности крупного сервера, и тот перестанет отвечать.
Мало кто из пользователей добровольно отдаст мощность своего компьютера для
проведения распределенной атаки на крупные серверы. Чтобы решить эту проблему, хакеры писали раньше вирусы, которые без разрешения занимались атакой.
Так, вирус Mydoom C искал компьютеры, зараженные вирусами Mydoom версий A
и B, и использовал их для атаки на серверы корпорации Microsoft. Благо этот вирус
не смог захватить достаточного количества машин, и мощности не хватило для
проведения полноценного налета. Администрация Microsoft утверждала, что серверы работали в штатном режиме, но некоторые все же смогли заметить замедление в
работе и задержки в получении ответов на запросы. Все же на сеть Microsoft легла
какая-то часть излишнего трафика.

48

Глава 1

Сейчас Microsoft обладает такими мощностями, что трудно себе представить успешную атаку на их сервера или сетевые возможности. Эта компания не только
обеспечила себя вычислительными ресурсами, но и продает их другим в виде облачных Azure-сервисов.
От распределенной атаки защититься очень сложно, потому что множество реально
работающих компьютеров шлют свои запросы на один сервер. В этом случае трудно
определить, что это идут ложные запросы с целью вывести систему из рабочего
состояния. Поэтому здесь эффективное решение предложить очень сложно.
Меня как-то попросили разобраться, почему один сайт очень сильно тормозил, —
клиент думал, что это атака хакеров. Я заглянул в аналитику Google и обратил внимание, что большая часть трафика идет на одну страницу, и именно она часто выдает ошибки. Загрузив эту страницу, я увидел, что на ней находится картинка в несколько мегабайт. Причем на сайте она была мелкой, но кто-то из администраторов
загрузил, не глядя, большую картинку, и этого хватило, чтобы сетевой канал не выдержал нагрузки.
В данном случае ошибка администратора или оператора сайта стала причиной замедления, но хакер может использовать примерно такой же подход. Если перед
ним сайт, на который можно загрузить картинку и сервер не проверяет размер и не
сжимает в случае слишком большого разрешения, то можно загрузить картинку и
использовать ее в своих целях.

1.7.2. Защита от распределенной атаки
В разд. 1.3.3 мы исследовали сайт Wheel of fortune и узнали, что он ответил нам с
адреса 2.17.164.116.
Раз мы получили ответ не от хостинговой компании, а с IP-адреса akamaitechnologies,
значит, сейчас используется их сервис по защите и, скорее всего, от атаки отказа от
обслуживания.
Akamai в 2014 году приобрела Prolexic Technologies — еще одного лидера средств
безопасности, который разработал достаточно хорошую систему защиты от различных атак. Их технология работает как сетевой экрана перед реальными серверами сайтов.
Я точно не знаю алгоритмы работы Akamai и Prolexic, но из личного опыта могу
сказать, что у них достаточно интеллектуальные алгоритмы. Если хакер начнет отправлять большое количество запросов с одного или нескольких IP-адресов, то
Akamai начинает автоматически блокировать такие запросы. Алгоритмы распознают зловредный трафик и не дают ему достичь реального web-сервера. Если трафик
идет распределенный, то могут блокироваться целые сети и провайдеры. Из личного опыта видел, как крупный провайдер попадал в черный список, и все его пользователи (даже легитимные) какое-то время не могли загрузить защищаемый алгоритмами Prolexic сайт.

Основы безопасности

49

Akamai — не единственная компания на рынке, которая предоставляет подобный
сервис защиты от DDoS-атак.
Для того чтобы ваша DDoS-атака была успешной, нужно знать реальный IP-адрес,
чтобы можно было направлять трафик на сервера в обход защитных средств, и даже это даст успех только в том случае, если реальные сервера принимают трафик с
любого источника.
Я не знаю нынешние реальные IP-адреса web-серверов Wheel of fortune и не могу
проверить, можно ли к ним добраться напрямую. Надеюсь, что у них стоит сетевой
экран, который принимает трафик только от Akamai, то есть уже проверенный на
отсутствие DDoS-атак.

1.8. Меры безопасности
Проблема безопасности не ограничивается только защитой определенных программ. Можно написать самую безопасную программу, но при этом установить на
сервер ОС с настройками по умолчанию. Всем известно, что настройки по умолчанию далеки от идеала, и благодаря этому web-сервер может быть взломан даже при
отсутствии уязвимых сценариев.
Безопасным должен быть не только каждый участок программы, но и каждый программный пакет, установленный на сервере, сама ОС, конфигурация и все используемое оборудование (в основном это касается сетевых устройств).
Защищать необходимо не только определенные программы, но и ОС, СУБД, сетевое оборудование. Каждая составляющая требует отдельной книги по безопасности. А если учесть, что существует несколько разновидностей ОС и к безопасности
каждой из них нужно подходить со своей стороны, то книг нужно написать еще
больше. Поэтому ограничимся только основными особенностями защиты.
Есть такое выражение, что безопасность — это не продукт, а процесс. Нельзя просто купить какой-то продукт и тут же оказаться в безопасности.
Вместо этого к безопасности нужно относиться как к процессу, бесконечному и
постоянно работающему.
Даже если вы являетесь разработчиком и не связаны с администрированием сервера своей компании или просто web-сайта, я настоятельно рекомендую вам познакомиться с безопасностью ОС, которая используется на вашем сервере. Для Linuxсистем я могу посоветовать прочитать мою книгу "Linux глазами хакера".
Может, вы заметили, что я очень часто ссылаюсь именно на ОС Linux? Дело в
том, что эта ОС преобладает в интернете в качестве серверов. Именно поэтому
мы будем больше внимания уделять этим ОС. Да, в корпоративном секторе можно встретить и множество решений на Windows-платформе, но в целом они уступают по популярности решениям на Linux.
Компания Microsoft делает серьезные шаги для завоевания рынка web-решений, и
в последнее время удается что-то сделать и отвоевать часть рынка, так что все

50

Глава 1

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

1.8.1. Защита web-сервера
Давайте рассмотрим пример защиты MySQL и Apache в операционной системе
Linux. Мы опустим защиту самой ОС, потому что это отдельная и очень большая
тема, да и весь Apache мы трогать не будем, пусть живет. Итак, защита начинается
с установки и предварительного конфигурирования. В случае с MySQL необходимо
выполнить следующие действия:


СУБД устанавливается с настройками по умолчанию, при которых администраторский доступ разрешен пользователю root и нужно убедиться, что у
всех аккаунтов, которым разрешено подключение, есть пароль, который достаточно сложен, чтобы поддаться простому подбору;



необходимо заблокировать анонимный доступ к СУБД. Подключения должны
осуществляться только авторизованными пользователями;



лучше всего запретить удаленное подключение к СУБД. Например, если к MySQL
обращаются только локально расположенные сценарии, то никто не должен иметь
права подключения с удаленной машины (в настройках MySQL есть такая опция).
Если нужен инструмент управления базой данных, то можно использовать мощный и популярный web-пакет phpMyAdmin (https://www.phpmyadmin.net/), который позволяет управлять базой данных из web-браузера. На мой взгляд, использовать командную строку не так уж и сложно, и очень рекомендую использовать ее, потому что phpmyadmin — это код, написанный программистами, который
тоже может содержать ошибки, и его также нужно поддерживать и обновлять.

Если база данных установлена на одном сервере, а код сайта — на другом, то
тут тоже можно указать, что подключаться к базе можно только с сервера, где
находится код сценария. В этом случае прямого подключения со своего компьютера вы не сможете сделать, но можно сначала открыть SSH — командную
строку на сервере и уже из нее работать с базой данных;
 необходимо удалить все базы данных, созданные для тестирования и отладки. По
умолчанию в СУБД могут устанавливать тестовые базы данных. В работающей
системе такого не должно быть.


Учетная запись администратора по умолчанию, о которой мы уже сказали, есть
практически во всех СУБД. В MS SQL Server это учетная запись sa, которая может
быть без пароля, если администратор не установил его во время инсталляции, а в
MySQL это root, также без пароля. Чтобы изменить пароль для MySQL, выполните
команду:
/usr/bin/mysqladmin –uroot password newpass

Основы безопасности

51

1.8.2. Модули безопасности Apache
Для защиты необходимо по максимуму использовать все возможности. Например,
если в качестве web-сервера вы используете Apache в связке с ОС Linux, то могу
посоветовать расширить его возможности с помощью дополнительных модулей,
возможности которых мы кратко рассмотрим.

Модуль mod_sequrity
Несмотря на то, что безопасность в основном зависит от сценариев, которые выполняются на web-сервере, и программистов, которые их пишут, есть возможность
защититься вне зависимости от сценариев и их безопасности. Отличное решение
данной проблемы — бесплатный модуль для Apache под названием mod_security.
Принцип работы модуля схож с сетевым экраном, который встроен в ОС, только в
данном случае он специально разработан для работы с протоколом HTTP. Модуль
анализирует запросы пользователей и выносит свое решение о возможности пропустить запрос к web-серверу или нет на основе правил, которые задает администратор. Правила определяют, что может быть в запросе, а что нет.
В запросах, которые направляет пользователь на сервер, содержится URL,
с которого необходимо взять документ или файл. Что можно задать в правилах модуля, чтобы сервер стал безопаснее? Рассмотрим простейший пример: в запросе не
должно быть никаких обращений к файлу /etc/passwd, задаем соответствующий
фильтр, и если происходит обращение, содержащее URL этого файла, то запрос
отклоняется.
Итак, модуль mod_security можно взять с web-сайта www.modsecurity.org. После
его установки в файле httpd.conf можно будет использовать дополнительные директивы, фильтрации запросов. Рассмотрим наиболее интересные из них:
 SecFilterEngine On —

включить режим фильтрации запросов;

 SecFilterCheckURLEncoding On —

проверять кодировку (URL encoding is valid);

32
126 — разрешается использовать символы
с кодами только из указанного диапазона. Символы, коды которых менее 32, принадлежат служебным символам типа "перевод каретки", "конец строки". Большинство из этих символов невидимы, но для них существуют коды, чтобы можно было обрабатывать нажатия соответствующих клавиш. Но как же тогда хакер
может ввести невидимый символ в URL? Это действительно невозможно, но
вполне реально ввести их код. Например, чтобы указать символ с кодом 13, необходимо указать в URL адресе %13. Символы с кодами менее 32 и более 126 являются недопустимыми для адреса, поэтому вполне логично такие пакеты не
пропускать до web-сервера;

 SecFilterForceByteRange

 SecAuditLog logs/audit_log —

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

52

Глава 1

 SecFilterDefaultAction "deny,log,status:406" —

этот параметр задает действие
по умолчанию. В данном случаеуказан запрет на доступ (deny);

— если фильтр срабатывает,
то пользователя переадресуют на web-сайт www.webkreator.com;

 SecFilter xxx redirect:http://www.webkreator.com

 SecFilter yyy log,exec:/home/apache/report-attack.pl — если фильтр
тывает, то будет выполнен сценарий /home/apache/report-attack.pl;

сраба-

 SecFilter /etc/password —

в запросе пользователя не должно быть обращения к
файлу /etc/passwd. Таким же образом нужно добавить запрет к обращению и к
файлу /etc/shadow;

 SecFilter /bin/ls —

в запросе пользователя не должно быть обращения к программам. В данном случае запрещается команда ls, которая может позволить
хакеру увидеть содержимое каталогов, если в сценарии есть ошибка. Необходимо запретить обращения к таким командам, как cat, rm, cp, ftp и др.;

 SecFilter "\.\./" —

классическая атака, когда в URL указываются символы
точек. Их не должно быть там;

 SecFilter "delete[[:space:]]+from" —

запрет текста delete ... from, что чаще
всего используется в SQL-запросах для удаления данных. Такой текст очень
часто используется в атаках типа SQL-инъекция. Помимо этого рекомендуется
установить следующие фильтры:


SecFilter "insert[[:space:]]+into"

используется в SQL-запросах для добав-

ления данных;


SecFilter "select.+from" используется

в SQL-запросах для чтения данных из

базы;
и SecFilter "