Зачем защищать небольшой сайт? “У меня маленький сайт-блог, зачем мне его защищать и от кого?”
Немного печальной статистики.
Скажем так, сейчас в 50% на Вашем сайте пасутся боты, а не живые люди. Вот классический пример работы ботнета – с разных IP (зараженные ПК пользователей) идет подбор пароля к логину Administrator – аккуратно, с интервалом в 5-10 минут.
Успехов тебе, железяка :) Всё, что видит ботнет со своей стороны – после однократного ввода логина/пароля форма входа исчезает…
Как видно на картинке выше – атака перебором идет с разных IP (разные заражённые ПК), которые через небольшой интервал времени меняются. Т.е. необходимо запоминать (с помощью плагина) IP, которые повторяются – и плавно увеличивать им время блокировки – 1 час, 2 часа, 4 часа, 8 часов, 16 часов, 32 часа и так далее. Со временем у ботнета начнется выпадение из “работы” наиболее активных IP (для атак на Ваш сайт) – для них время блокировки сильно возрастет.
После серьезной атаки только наличие актуальной копии позволит восстановить рабочий сайт. При заражении сайта практически невозможно его отремонтировать на 100%. В движке порядка 4000 файлов, все их вычистить от вирусов очень сложно. Где-то что-то останется, какие-то функции после очистки сломаются. А наличие бэкапа позволит восстановить сайт на 100%. Это вообще полезное мероприятие – периодически делать полные бэкапы.
подбор скриптов PHP в адресной строке браузера – ошибка “404”. Попытки проверить установленные плагины, правильность ограничения доступа к самим файлам CMS на сервере и пр. 1000 попыток в сутки с разных IP
попытки запускать скрипты ядра сайта или плагинов с разными параметрами – это же просто файлы php – разработчики должны принимать специальные меры (что бы например плагины WordPress можно было запустить только изнутри)
попытки чтения файла wp-config.php, там логин/пароль к базе MySql хранится в открытом виде
SQL инъекция, выполнение несанкционированных запросов
CSRF (англ.Сross Site Request Forgery — «межсайтовая подделка запроса», также известна как XSRF
XSS — выполнение произвольного JS кода/скрипта в страницу. XSS — Cross Site Scripting (первая буква в аббревиатуре «X» чтобы не было путаницы с CSS (стилями)
RFI/LFI — Remote/Local file inclusion. Использование удаленных («извне»)/локальных файлов в своих целях
поля формы обратной связи
200 писем в день, их них 50 с рекламой, остальные 50 – с пустым полем “сообщение”, там были спецсимволы для взлом
ввод кода исполняемого скрипта в поле сообщения
загружаемый файл на Ваш сервер
загрузка исполняемого скрипта (например, вместо картинки), проверки расширения файла путем сравнения строк недостаточно – нужно также проверять MIME тип файла
использование уязвимостей ядра WordPress и плагинов
DDoS-атака на Ваш сайт
В отличии от вышеперечисленных атак (где были хакеры-взломщики) – здесь хакеры-хулиганы. Их задача – “положить” Ваш сайт. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании»
С большого количества IP (работает ботнет) поступают вполне корректные запросы к Вашему сайту. Просто их очень много, много этих запросов. Т.к. ресурсы хостинга конечные (процессор, память) – через некоторое время сайт перестает отвечать на запросы пользователей.
Как говорил О. Бендер – “с развитием печатного дела на Западе….” отличить ботов от визитов обычных людей практически невозможно:
со служебными заголовками всё в порядке (IP, User-agent)
у ботов есть поведенческий фактор (пролистывание страниц, нажатие на кнопки)
вариант защиты с куками тоже особо не работает (это когда при первом посещении с IP присваивается кука, а при повторном – проверяется её наличие) – это же ботнет, IP-адрес может и не повториться в ближайшее время
заходы на главную страницу или на другие, вполне нормальные страницы (никаких страниц логгирования или системных файлов)
Но есть одна метрика, которые боты не знают. Обычно полноценная DDoS-защита реализуется на уровне хостера:
есть обычная статистика посещений Вашего сайта, например 1000 визитов в день (итого 30 000 в мес нормально для коммерческого сайта)
из этой 1000 = 700 IP России, 100 IP Украины, 100 IP Белоруссии и остальные 100 – разные страны
даже если Вы даете рекламу и посещаемость сайта возрастает в 5-10 раз = статистика по странам изменится несильно
а вот при DDoS-атаке (допустим тоже в 10 раз) на уровне визитов 10 000 в день – появятся массово IP США, Китая, Бразилии и так далее
хостер это “видит” (точнее робот на входе анализирует) = и начинает массово блокировать запросы с этих IP, что бы они не доходили до сайта
Подпишитесь в VKontakte - нажмите кнопку
Подпишитесь в Telegram - нажмите кнопку
Наша группа ODNOKLASSNIKI
Вы можете сохранить ссылку на эту страницу себе на компьютер в виде htm файла
CMS WordPress является достаточно популярной платформой для ведения блогов и создания сайтов. Это же автоматически подразумевает большое количество желающих использовать Ваш сайт для своих целей:
перехват и перепродажа трафика (т.е. пользователь пришел на Ваш сайт и редиректом ушел на целевой сайт хакера)
размещение рекламных ссылок
создание бота на Вашем сервере/сайте (будет использоваться как минимум для подбора паролей на чужих сайтах)
отправка спама (да, у WordPress есть свой почтовый сервер)
добавление к Вашему сайту рекламных страниц (достаточно дописать в базу MySql)
Самое обидное - что сайт живет после взлома не более 6 мес. Поисковые роботы находят всё это... (Читать полностью...)
Нехороших хакеров можно и нужно банить по IP - т.е. не пускаем пакеты с отдельных IP в обработку.
Но есть ряд проблем:
часть IP (с которых идет атака) принадлежат не хакерам, а вполне обычным пользователям, которые наловили вирусов на свой ПК (и теперь он работает на другого хозяина)
с учетом ежедневной смены IP провайдером у большей части обычных пользователей - через сутки конкретный IP станет не опасным
есть упрямые хакеры, которые работают с постоянного IP
еще есть "умники", которые пытаются запустить разные php-скрипты в адресной строке браузера (в основном получают, конечно, код 404)
есть принципиально разные блокировки IP
на уровне CMS WordPress
на уровне... (Читать полностью...)
80% всех атак ботов на WordPress идут на вход в административную панель. Наша задача - такие IP отправить в бан.
Используем плагин WP fail2ban.
Плагин делает важную вещь — он выводит в лог /var/log/auth.log (это один из системных логов Linux) каждую попытку авторизации на сайте (настройками можно изменить). Т.е. не создается дополнительный лог-файл - а идет запись в один общий системный лог Linux. Это удобно, если у Вас несколько сайтов на VPS, всё ошибки входа по всем сайтам будут записываться в один общий файл.
И не нужно дополнительно под каждый сайт настраивать WP fail2ban:)
ВАЖНО: можно вообще "спрятать" админку от злых ботов
Меняем адрес административной панели... (Читать полностью...)
Включаем двухфакторную аутентификацию WordPress - т.е. логин + пароль для входа + еще дополнительный код/пароль.
Защита паролем сервера Апач
Общая структура папки Вашего сайта на WordPress (на сервере хостинга) следующая
Сайт сайт запускается файлом index.php в корневой папке.
Административная панель запускается файлом index.php в папке wp-admin
Существует два варианта входа в систему управления сайтом:
через браузер в административную панель
вход или site.ru/wp-admin (тут расположена сама панель управления) или site.ru/wp-login.php (проверка логина/пароля)
через мобильное приложение (Android / iOS), см. ниже - указываем логин/пароль и сайт (уже без "хвостика"... (Читать полностью...)
Используем web-сервер Apache для блокировки доступа извне
ВАЖНО: всё нижеперечисленное будет работать, если Вы конечно, используете сервер Apache.
Если Вы используете связку NginX и PHP-FPM (сервера Apache тут нет!)
все эти инструкции работать не будут! Сервер Apache не участвует в обработке запросов!
Закроем файл wp-login.php
Мы можем спрятать вход в административную панель. И ввод логина/пароля не будет уже использовать напрямую файл wp-login.php.
Но сам файл wp-login.php конечно продолжает существовать и работать, просто теперь WordPress при его запросе показывает ошибку 404. Но как мы помним, ботнетов много - и они по прежнему будут загружать Ваш сервер PHP на обработку... (Читать полностью...)
База данных на сервере хостинга - основное место, где хранятся "детальки" (текстовые данные в основном) от Вашего сайта. Если туда что-либо записать лишнего - то движок WordPress это и покажет = и это уже будет не Ваш сайт :(
Зачем нужна вообще какая-то база для сайта? Читаем статью
База MySql
Прямая атака на базу MySql
По умолчанию, при установке WordPress создает в базе таблицы с префиксом wp_. Злоумышленники об этом знают. Необходимо либо при установке выбрать другой префикс вида mysite_ (WordPress спросит при установке, не более 6-ти латинских букв), либо поменять его у готового сайта.
Зачем это нужно? Ну вот пример - мы при установке указали другой префикс вида xxx_... (Читать полностью...)
Как защитить свой блог (картинки и текст) от копирования?
В общем случае - никак :(
Всё, что Вы видите в своем браузере - оно уже есть на Вашем компьютере. Но можно сильно усложнить сам процесс копирования для любителей copy-paste.
Итак, основные направления:
запрет выделения текста мышью и дальнейшее copy-paste
запрет хотлингов (т.е. показывать картинки с Вашего сайта на другом домене)
защита картинок через "водяной знак" (он же Watermark)
запрет парсинга страницы сайта с другого домена
Запрет выделения текста мышью (запрет копирования)
Казалось бы самый простой вариант - заблокировать правую кнопку мыши. Но это не есть хорошо. Часть посетителей... (Читать полностью...)
Потеряли пароль от админики WordPress? Что делать?
Не всё так плохо :)
Используем средство восстановления пароля WordPress
При входе
Вводим свой email
Получаем на свою почту служебную ссылку, заходим, меняем пароль. Всё стандартно.
Используем нашу базу MySql для смены пароля
Да, в ней хранится информация о пользователях, их паролях и прочая полезная информация.
Для прямого подключения к базе используем phpMyAdmin (параметры входа у Вас должны быть от Вашего хостера).
Вот база данных и таблица wp_users
Хакеры, не мучайтесь, все критичные данные замазаны, Administrator - это ник, а не логин :)
Пароль пользователя в базе хранится в зашифрованном виде.
Делаем Sql-запрос... (Читать полностью...)
При отображении записи WordPress выводит автора поста.
Как отключить вывод автора поста/записи?
Если ничего не делать - то любой желающий сможет увидеть логин входа в систему и ему останется только подбирать пароль.
И да - WordPress в стандартной установке еще и подтверждает правильность логина.
И вот тут нас поджидает проблема. Вывод автора поста делает не сам движок WP - это зависит от применяемой темы. В каких-то темах автор выводится, в каких-то темах автор не выводится, в каких-то настраивается.
Есть специальный плагин - но он работает не на всех темах (именно по этой причине, что в разных темах сделано иногда по разному).
Итак, что мы можем сделать.
Плагин Show/Hide... (Читать полностью...)
Посмотрим статистику.
Для начала устанавливаем плагин Activity Log (логгирование действий пользователей), активируем
И видим следующие картину
Кто все эти люди и откуда они знают мой логин?
Это не люди мучают клавиатуру с ручным подбором паролей, это боты (зараженные компьютеры). Точнее даже не компьютеры, а устройства типа микроволновки и холодильника. Сейчас везде производители ставят процессоры и выход в интернет, на таких устройствах практически нет никакой защиты, их взламывают и они вливаются в ряды ботов.
Еще есть «банды умных лампочек» – smart-лампы с управлением со смартафона через Wi-Fi. Тоже хорошо взламываются и начинают работать на чужих дядей.
WordPress достаточно... (Читать полностью...)
Будем переводить сайт на защищенный протокол HTTPS
ВАЖНО: Это именно зашифрованная передача данных от сервера до конечного посетителя, а не показатель безопасности сайта!
Сайт может быть взломан, сайт сам по себе может быть сделан мошенниками и прочее - и при этом сайт будет работать по защищенному протоколу https и иметь "зеленый замочек". Поэтому сейчас зеленый цвет замочка остался только в Opera, остальные браузеры показывают его серым цветом.
Переводим на HTTPS
Читаем основную статью
Как включить HTTPS на сайте?
Для работы HTTPS нам нужно несколько базовых вещей:
нужно получить сертификат SSL (браузер как-то должен проверить валидность ключа для... (Читать полностью...)
Лучшая безопасность для сайта - это делать backup сайта.
И регулярно.
Даже если враги всё сломали (а там почти 3000 файлов PHP в движке) - всё удаляем из папки WWW на сервере (именно ВСЁ - включая файлы движка WordPress) и восстанавливаем из бэкапа как было.
Что такое архивация сайтов?
Backup сайта это копирование баз данных, файлов сайта, почты, FTP-аккаунтов и множества других "деталек" на Вашем хостинге.
Сайт у нас состоит собственно из нескольких частей:
набор файлов (файлы PHP движка и картинки)
база данных MySQL, в которой хранится текстовая часть сайта, меню и все взаимосвязи между модулями
Не обязательно, кстати, именно PHP - для разработки сайта может быть... (Читать полностью...)
