Как взламывают сайты —

Что нужно сделать для защиты своего сайта

• Грамотно выбирать хостера. Если не хватает компетенции выбрать хостинговую площадку по техническим параметрам самостоятельно, совет — довериться одному из хостеров, входящих в десятку лучших по РФ или СНГ. Например, воспользоваться этой информацией или посмотреть рейтинг хостинговых компаний по числу клиентских доменов. Ведущие хостинг-провайдеры заботятся о безопасности своих клиентов и активно инвестируют в повышение безопасности своих серверов.
• Нужно всегда помнить про безопасное размещение сайтов на хостинге. Если есть возможность, взять отдельный аккаунт для каждого сайта или разместить на аккаунте минимальное число сайтов, так как это будет более безопасно. Об этом нужно думать в момент размещения сайта на хостинге или при выборе хостинга, так как некоторые хостеры уже имеют встроенный механизм изоляции сайтов внутри виртуальной площадки. Если сайты не изолированы друг от друга (то есть скриптами одного сайта можно вносить изменения в файлы другого) — то велик риск взлома всего аккаунта.
• Необходимо ограничить подключение по FTP и SSH с помощью дополнительного пароля, например, приходящего по SMS, или предоставить доступ с определенных IP-адресов.
• Регулярно менять пароли. Чем чаще вы меняете пароли, тем меньше у злоумышленника шансов воспользоваться перехваченными или украденными.
• Для работы в открытых wi-fi сетях использовать VPN, чтобы избежать перехвата конфиденциальной информации программами-анализаторами трафика — снифферами.

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

Почему взламывают даже защищённые cms на безопасном хостинге

.htaccess

Ну и конеч­но же, нель­зя не ска­зать о том, что вла­дель­цы сай­тов зачас­тую оставля­ют дос­тупны­ми на чте­ние некото­рые дирек­тории. В том же WordPress чаще все­го мож­но попасть в эти слу­жеб­ные пап­ки:

• /wp-content/;
• /wp-content/plugins/;
• /wp-content/themes/;
• /wp-content/uploads/files/;
• /images/.

Оче­вид­но, что делать там пос­торон­ним совер­шенно нечего, пос­коль­ку в таких пап­ках может хра­нить­ся кри­тич­ная информа­ция, в том чис­ле доволь­но‑таки кон­фиден­циаль­ная.

Зап­ретить дос­туп к слу­жеб­ным пап­кам мож­но, опять же уста­новив соот­ветс­тву­ющий шаб­лон, или самым прос­тым спо­собом — помес­тить в кор­не каж­дой дирек­тории пус­той файл index.html (либо добавить в .htaccess сай­та строч­ку Options All -Indexes).

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

. Поиск слабых настроек сервера

Итак, из веб-сайтов мы уже вытрясли всё, что только можно, — исходный код, базы данных, пароли пользователей.

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

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

Скачиваем её:

. Брут-форс SSH и FTP

На сервере были найдены два пользователя с правами администратора, root и ещё один, имя которого привести не могу.

Анализ исходного кода веб-интерфейсов для просмотра сохранённых с камер фотографий дал ещё один пароль — тоже из шести цифр. Я обратил внимание, что владельцем папок веб-сервера, где расположены фотографии, является не Apache (не www-data), а разные пользователи.

Оказалось, что для них предусмотрены учётные данные FTP, а также для под ними можно входить по SSH, причём в обоих случаях подходит пароль администратора, который подходит и для root MySQL, и для сервиса на сайте. К сожалению, у этих пользователей нет прав на выполнение команд с sudo.

Но, что самое печальное, что этот самый пароль администратора не подходит к пользователю системы Linux, также не подходит к учётной записи root. Если честно, я сначала даже удивился — ко всему подходит, а к этому не подходит… Видимо, пароли для этих пользователей придумывали на аутсорсе…

Будем исходить из того, что пароль всё-таки из шести цифр. Тогда сгенерируем его с помощью maskprocessor:

maskprocessor ?d?d?d?d?d?d > dig.pass

Для брутфорса я предпочитаю patator.

Я хотел запустить подбор пароля прямо с самого сервера. Python там оказался установленным, но не оказалось paramiko, поэтому я получил ошибку:

Загрузка бэкдора

В начале я хотел воспользоваться самым простым вариантом — c99unlimited.php. Это шелл в фиде файлового менеджера и в нём удобно бродить по каталогам и скачивать файлы. Но у меня он не заработал — выдал ошибку 500. Видимо, у сервера с ним какая-то несовместимость.

Это абсолютно не проблема, разнообразных шеллов в Webshells очень много — можно долго сидеть и выбирать тот, который понравится, но я решил воспользоваться ещё более любимым Weevely. У меня к этому инструменту ещё более чувства )))) Хотя у него интерфейс командной строки — так мне нравится даже больше.

Создаём новый бэкдор (да, пароль просто цифра 1):

weevely generate 1 test.php

Заливаем его на сервер.

И подключаемся к нему:

Осматриваемся на сервере из бэкдора

Примечание: для лучшего понимания происходоящего, рекомендуется к знакомству цикл статей «Азы работы в командной строке Linux (часть 1)».

После подключения, Weevely показал, что я нахожусь в папке /var/www/XX1/tmp.

Можно дополнительно в этом убедиться:

pwd
/var/www/XX1/tmp

Посмотрим, какие у меня права на эту папку:

ls -dl .

Вывод:

drwxrwxrwx 2 XX1 root 4096 Apr 21 14:16 .

Из этой информации следует, что владельцем папки является пользователей XX1. Но права на запись есть вообще у всех.

Кстати, а кто там я?

whoami

Вывод:

www-data

Я работаю от пользователя www-data.

Анализ добытых паролей

База данных раскрыла много интересной информации. Но самая интересная — это список пользователей с паролями.

У нас есть имена пользователей и пароли (а также email’ы и другая типичная для профилей информация). Пароль администратора для входа на сервис точно такой же, как и пароль пользователя root от MySQL. Напомню, если вы запутались: пароль от MySQL мы нашли в исходном коде файлов сайта, а пароль админа сервиса (сайта) мы нашли в базе данных. Хотя они оказались одинаковыми 

Это важно — пользователь имеет тенденцию использовать одинаковые пароли — это отдельная уязвимость, между прочим.

Но ещё интереснее анализ всех паролей пользователей — почти все они шестизначные числа! Видимо, учётные данные генерировал и выдавал администратор. У администратора склонность создавать однотипные пароли — учтём это. То есть если придётся брут-форсить службы на этом сервисе (а нам придётся

Камеры

Без камер сейчас никуда: в комнате отдыха воруют печеньки, на рабочих местах работники не работают, в туалетах промахиваются мимо писсуара… Эта организация тоже не исключение. Я не просто так в первой части показал, как проверять размер папок и как выборочно архивировать папки веб-сервера.

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

Так вот, если на ускоренном темпе просматривать эти фотографии (получается как видео), то создаётся сюрреалистическое впечатление, что люди в этой организации без конца жрут… День проходит так: восходит солнышко, заходят первые люди и начинают пить кофе, затем начинают есть, затем они уходят и начинают есть другие, затем приходят ещё больше людей и тоже начинают есть, потом эти уходят и приходят другие со своей едой и опять едят, и это повторяется и повторяется пока не наступит закат… Затем следующий день — точно такой, люди едят-едят-едят и вот такого почти на 100 Гигабайт…

Причём веб-интерфейс со слабым паролем для просмотра всего этого «добра» расположен на поддомене сайта, доступного из Глобальной сети.

Wordfence

Мой любимый бесплатный плагин безопасности WordPress со встроенным фаерволом веб-приложений. Плагин сканирует сайт WordPress на наличие вредоносных программ, изменения файлов, SQL-инъекций и т.д. Есть защита от DDoS-атак.

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

Варианты взлома сайтов

Рис.1 — Варианты взлома сайтов

На рисунке (Рис.1) мы сгруппировали практически все возможные варианты взлома, которые делятся на три категории:

Самая многочисленная категория относится ко взлому сайтов через веб. (Рис.2):

Рис.2 — Способы взлома сайтов по частоте использования

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

Однако это далеко не так.

Взлом сайта не через веб

Взлом сайта не через веб-уязвимости представлен довольно большим классом технических «возможностей» для злоумышленников:

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

Работа по wi-fi в общественных местах — отдельная возможность для взлома. Вы никогда не знаете, кто сидит за соседним столом и не «снифферит» (перехватывает) ли этот кто-то трафик, чтобы воспользоваться собранной информацией в недобропорядочных целях.

Взлом сайта по вине подрядчиков или сотрудников

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

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

Здесь правила очень просты: хотите управлять безопасностью своего сайта при работе с подрядчиками — управляйте доступами к веб-ресурсу. Что это значит?

• Предоставляйте доступы подрядчикам на минимальный срок и с минимальными привилегиями. То есть, если фрилансеру нужно поправить какой-то шаблон на сайте, не стоит ему давать root-пароль от сервера. Достаточно дать SFTP или SSH доступ, создать пользователя с минимальными, но достаточными правами и предоставить SFTP-подключение в каталог, где лежит указанный шаблон.
• Возьмите за правило проводить аудит сайта, после того как подрядчик выполнил все работы. Это можно сделать самостоятельно после выполнения работ путем сравнения файлов или с помощью привлеченных сторонних специалистов.
• Для самостоятельной проверки сайтов мы рекомендуем использовать бесплатные сканеры вредоносного кодаAI-BOLIT и веб-сканер ReScan.pro. Они помогут быстро проверить сайты на вирусы и вредоносный код.
• Работайте на договорной основе, сотрудничество на «честном слове» может неприятно разочаровать.
• Инструктаж подрядчиков — необходимая составляющая комплекса мероприятий по безопасной работе с веб-ресурсом. Часто, когда задачу нужно сделать быстро — например, срочно поправить что-то в шаблонах или скриптах — правила безопасности могут игнорироваться, а в результате владелец сайта столкнется с неприятными последствиями. Не забываем, что сотрудника можно обмануть и он добровольно передаст доступы третьим лицам.

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

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

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

Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.

Взлом хостинга .mx: php инклудинг на практике

Два типа плагинов брандмауэра wordpress

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

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

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

Большинство экспертов считают, что защита на уровне DNS наиболее эффективна, так как не только отсеивает опасный трафик, но и снижает нагрузку на сервер сайта.

Забытые учетки

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

Толь­ко вдум­чивое курение логов помог­ло отыс­кать нас­тоящую при­чину. Ею ока­зал­ся «бро­шен­ный» FTP-дос­туп, соз­данный дав­ным‑дав­но кем‑то из уво­лен­ных сот­рудни­ков, знав­ших пароль от панели управле­ния хос­тингом. Видимо, не удов­летво­рив­шись раз­мером выход­ного пособия, ново­испе­чен­ный без­работ­ный решил отом­стить сво­ему быв­шему началь­ству таким вот незамыс­ловатым спо­собом.

О брандмауэре

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

Брандмауэр WordPress реализуется плагинами брандмауэра, часто называемыми брандмауэрами веб-приложений или WAF (Web Application Firewall).

Стоит отметить, что фаервол WP обязательно должен работать в паре с антивирусными плагинами или являться их частью (об этом ниже).

О проблеме взлом аккаунта сайта и хостинга

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

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

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

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

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

Это правило работает, если вы каждый день посещаете свои сайты и проверяете их работоспособность. Если вы сайт посещаете редко, искать нужно все новые файлы появившиеся в корнях сайтов с вашего последнего посещения.

• В-третьих, проверяю все файлы index.php всех взломанных сайтов. Для начала проверяю файлы index.php в корневых каталогах.

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

Продолжаю проверять все остальные файлы index.php в сайтах, а именно:

• В темах (WordPress);
• Административном каталоге;
• Шаблонах административной части (для Joomla);
• И т.д.

В моём случае все файлы index.php на всех сайтах хостинга были заражены и имели одинаковые вставки скриптов.

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

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

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

Поиск причин

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

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

На этом сайте стоит плагин безопасности Wordfence Security, который не сработал и пропустил заражение. Вероятная причина в упрощенных настройках сканера плагина (выборочная проверка) и отсутствия расписания сканирования, а проще говоря, моей беспечности.

После сканирования сайт очищен от вирусов, все остальные сайты жестко проверены плагином Wordfence Security, сайты Joomla аккаунта пролистаны вручную.

Если у вас нет желания листать сайты вручную, то есть неплохой инструмент «Сканер AI-Bolit» ), который проверит сайты за вас.

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

Самый цимес

Кто в наше вре­мя не исполь­зует CMS? Все исполь­зуют CMS! Мно­гие про­вай­деры пред­лага­ют услу­гу быс­тро­го раз­верты­вания наибо­лее популяр­ных движ­ков, вро­де WordPress, Joomla, Drupal, Bitrix, из кон­тей­нера: нажал кноп­ку в панели управле­ния хос­тингом, и готово.

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

Фишинг

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

Из­дав радос­тный боевой клич, ты перехо­дишь по ссыл­ке и толь­ко тут, если повезет, замеча­ешь что‑то нелад­ное. Да, пись­мо выг­лядит безобид­но: оно офор­мле­но в точ­ности так же, как офи­циаль­ные сооб­щения от тво­его хос­тера, текст наб­ран тем же шриф­том, адрес отпра­вите­ля — вер­ный.

И даже в «под­вале» на сво­ем закон­ном мес­те рас­положе­ны ссыл­ки на полити­ку кон­фиден­циаль­нос­ти, пра­вила обра­бот­ки пер­сональ­ных дан­ных и про­чую лабуду, которую ник­то никог­да не чита­ет. Толь­ко вот URL стра­ницы авто­риза­ции в адми­нис­тра­тор­ской панели нем­ного отли­чает­ся от нас­тояще­го, да и SSL-сер­тификат на сай­те вызыва­ет подоз­рения и у тебя, и у анти­виру­са. Ой, а не фишинг ли это?

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

Что­бы получить обра­зец кор­поратив­ного пись­ма, дос­таточ­но зарегис­три­ровать­ся на сай­те про­вай­дера или заказать тес­товый хос­тинг, который мно­гие ком­пании бес­плат­но пред­лага­ют на огра­ничен­ный срок. Даль­ше такое пись­мо мож­но обра­ботать в любом HTML-редак­торе, поменяв содер­жимое.

Нет­рудно най­ти и все исполь­зуемые про­вай­дером диапа­зоны IP-адре­сов: для этой цели соз­дано мно­жес­тво сер­висов, нап­ример xseo.in. Ну а затем мож­но получить спи­сок сай­тов на каж­дом из IP-адре­сов shared-хос­тинга, нап­ример здесь, здесь или тут.

Выводы про взлом аккаунта сайта

Во-первых, всегда имейте под рукой резервные копии своих сайтов и всего аккаунта на хостинге. Относитесь к этому серьёзно, и взлом аккаунта сайта и хостинга вам будет не страшен.

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

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

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

Промежуточный итог

Итак: сервер скомпрометирован через уязвимое веб-приложение.

Уже на данном этапе:

• Получен доступ в файловую систему
• Получен доступ к исходному коду сайта
• Есть возможность редактировать файлы веб-сайтов
• Получен пароль от СУБД, получен доступ к базам данных, есть возможность редактировать базы данных
• Получены пароли пользователей от сервисов
• Анализ паролей выявил в них явную закономерность
• Найдены другие сайты и получен их исходный код

Можно уже сейчас составлять отчёт для владельца-заказчика и завязывать с этой оценкой безопасности.

Краткое содержание отчёта: всё плохо.

Но у этой истории будет ещё и вторая часть. Смотрите продолжение «Как взламывают сайты (часть 2)».

Заключение

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

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

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

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

• понимание работы сервера, умение его настраивать
• понимание ОС Linux, её внутренного устройства
• умение работать в командной строке и знание хотя бы самых ходовых команд (утилит) Linux