Взлом: боты сканируют сайты (02.05.2018). Печать
2018 - Май
02.05.2018 13:20
Save & Share
Оказывается, автоматические боты сканируют сайты по всему миру в поисках уязвимостей - для последующего инфицирования, взлома и прочих прелестей от злодеев с техническим складом ума.

Симптоматика: даже если вы только что создали домен (и посетители о нем не знают) - в логах тут же начинают появляться строки вида:
- "script '/home/XXX/bad-good.ru/www/images/stories/xx.php.xxxjpg' not found or unable to stat";
- "script '/home/XXX/bad-good.ru/www/includes/logo_img.php.suspected' not found or unable to stat, referer: http://site.ru";
- "AH01276: Cannot serve directory /home/XXX/bad-good.ru/www/attach/docs/: No matching DirectoryIndex (index.html,index.htm,index.php,index.php3,index.phtml,index.cgi,index.pl,index.shtml,default.htm,default.html) found, and server-generated directory index forbidden by Options directive";
- "File does not exist: /home/XXX/bad-good.ru/www/index.shtml";
- "File does not exist: /home/XXX/bad-good.ru/www/wp-content".

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

И данное сканирование обнаружится в любом error_log любого сайта, независимо от провайдера. Мировой уровень имеет как сам факт сканирования, так и обширность государств сканирования (используют прокси?).

Защита со стороны провайдера, возможно, должна заключаться в использовании нестандартных портов HTTPS, SSH (провайдер отказал в этом). Защита со стороны пользователя:
- привязка FTP сайта к одному IP-адресу или их диапазону;
- настройка .ftpaccess, .htaccess;
- прочие, даже старые, способы.

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

Файлы-исключения - вида "apple-touch-icon.png". Оказывается, подобные файлы в корне сайта есть иконки для устройств яблочников. Даже здесь в Apple умудрились все через жопу сделать, а не брать стандартную иконку сайта. В итоге пришлось:
- создавать новую иконку, т.к. старой в BMP уже давно нет, и качество 64x64 не подходит для новых создаваемых. Итого - 8 новых иконок с разными размерами;
- добавлять код в <head>, чтобы иконки заработали.

<link rel="apple-touch-icon" href="/apple-touch-icon-60.png">
<link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180.png">

(добавлено 03.05.2018) И их precomposed-версии.
Обновлено ( 03.05.2018 19:05 )