SSH Honeypot — просто и со вкусом

Honeypot («Ловушка») (англ. горшочек с мёдом) — ресурс, представляющий собой приманку для злоумышленников. (wikipedia.org)

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

$ nmap google.com

Starting Nmap 6.47 ( http://nmap.org ) at 2050-01-11 00:00 GMT
Nmap scan report for google.com (173.194.71.138)
Host is up (0.010s latency).
Other addresses for google.com (not scanned): 173.194.71.139 173.194.71.113 173.194.71.101 173.194.71.100 173.194.71.102
rDNS record for 173.194.71.138: lb-in-f138.1e100.net
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.92 seconds

Из которого мы видим, что на целевой системе открыты 2 порта (стелс-сканирование и прочее мы пока опустим — не к чему оно сейчас): 80/tcp и 443/tcp и это означает, что там наверняка крутится web-сервер, который работает по http и https.

Теперь подойдем к более интересному моменту.

Довольно часто администраторы используют для доступа к своим серверам SSH. Стандартный порт для SSH — 22/tcp. Если администратор хоть чуть-чуть «шарит», то после установки системы он сразу же перевешивает SSH на не стандартный порт (например 454545), запрещает логин от рута и настраивает авторизацию по сертификату вместо пароля. И оно совершенно правильно — держать SSH на стандартном порту, да без какой-либо дополнительной защиты — потенциально огромная брешь в безопасности.

А что если повесить на этот самый 22 порт ещё один ssh-демон, но при этом все попытки логина по нему сразу отправлять в fail2ban? Обычным нашим пользователям SSH не нужен, мы ходим через порт 454545, значит тот, кто будет ломиться на 22 порт — бот или злоумышленник, которого необходимо забанить по IP на довольно длительное время. Обойти это ограничение можно будет лишь заюзав VPN, прокси или другое средство смены IP, ну или дождаться пока не пройдет время бана которое мы установим.

Данную задачу будем решать в 3 этапа:

  1. Настроим и запустим дополнительный sshd-демон, который будет висеть на 22 порту;
  2. Настроим fail2ban, который будет читать логи на попытку коннекта по ssh на 22 порту;
  3. Поставим всё это дело в автозапуск;

Все манипуляции буду производить на CentOS 7, разница с другими дистрибутивами — минимальна

Подробнее под катом

Тотальная защита WordPress

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

Помогать нам будет уже не только nginx — но и fail2ban вкупе с некоторыми дополнениями и настройками самого WP.

Обозначим проблемы безопасности, которые «по умолчанию» имеют место быть:

  1. WordPress вставляет данные о своей версии в различные места генерируемого контента;
  2. Стандартные настройки его имеют довольно много потенциально слабых мест;
  3. Стандартные настройки доступа к сайту позволяют без особых трудностей собрать потенциальному взломщику довольно много информации;
  4. «Из коробки» отсутствуют какие-либо средства против перебора директорий и паролей.

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

Подробнее под катом