Назад | Перейти на главную страницу

Блокировка моего сервера Ubuntu с помощью UFW

Я использую Ubuntu 12.04 на инстансе Amazon EC2 и новичок в области системного администратора. Я работаю над собственным небольшим проектом, и я уже начинаю становиться мишенью для ботов (по крайней мере, я надеюсь, что это боты).

Я использую PHP и в своих журналах ошибок заметил w00tw00t romanian anti-sec и /w00tw00t.at.blackhats.romanian.anti-sec:. Я googledd и нашел несколько результатов, таких как этот и этот оба утверждают, что это, скорее всего, всего лишь несколько ботов. Они искали варианты PHPMyAdmin, PMA, MyAdmin. Насколько я могу судить, они ничего не нашли, а получили только 404 ошибки. Что касается PHPMyAdmin, я использую псевдоним, и у меня есть доступ, ограниченный парой IP-адресов.

В настоящее время я использую UFW и у меня есть эти правила

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       MY.IP.ADDRESS1
22                         ALLOW       MY.IP.ADDRESS2
22                         ALLOW       MY.IP.ADDRESS3
80                         ALLOW       Anywhere (v6)
443                        ALLOW       Anywhere (v6)

Все руководства, которые я видел по UFW, просто говорят, как его настроить, а не предложения по самой конфигурации. В основном я использую SFTP и SSH (с парой ключей) для работы на моем сервере. Есть ли какие-то обязательные правила, которые мне не хватает?

Я не понимаю, как вы могли бы использовать UFW, чтобы избежать подобных атак.

Если все, кроме 80/443, запрещено в публичном доступе, и вы указали только несколько конкретных IP-адресов для доступа по ssh, то проблема заключается в вашем приложении, а не в конфигурации сети.

В этом случае даже не трогайте правила брандмауэра.

Вам нужно защитить себя от:

  • Слабые пароли
  • Очевидные ссылки "Страница администратора", т.е. website.com/admin, website.com/phpmyadmin
  • Пароли, встроенные в ваш код
  • SQL-инъекции и другие различные уязвимости веб-кода / базы данных.

Чтобы повысить безопасность вашего сервера, вы можете заставить Apache запускаться chroot'ed, чтобы он был отделен от основной системы виртуальным слоем.

Вы также можете реализовать FIM (управление целостностью файлов), чтобы файлы, которые не должны изменяться, не изменялись (пример: конфигурация apache / php)

или вы можете написать сценарий для регистрации всех команд, выполняемых root / apache, и периодически отправлять его по электронной почте.

На подобные вещи стоит обратить внимание после настройки брандмауэра (что вы уже сделали).

Всевидящий w00tw00t Трафик в ваших журналах означает именно то, что вы видите: вас проверяет какой-то скрипт. Я бы не стал придавать этому большое значение, но если вы действительно обеспокоены, то используйте iptables & ufw действительно не поможет.

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

В репозитории Ubuntu есть пакет для ModSecurity, но его основной набор правил (CRS) устарел. Так что я бы рекомендую скачать это здесь.

Что приводит нас в кроличью нору: ModSecurity не так просто настроить для новичков. Я делал это много раз, но даже когда он запущен, есть проблемы, о которых нужно знать. Например, поскольку ModSecurity работает эвристически и отслеживает веб-трафик, иногда ожидаемое поведение на вашем веб-сервере будет заблокировано из-за «ложного срабатывания».

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

Если вы используете какое-либо стандартное программное обеспечение, такое как WordPress или Joomla !, мой лучший совет - сделать это: просто поместите пароли веб-авторизации Apache в URL-адреса / пути администрирования для вашей CMS. Серьезно, это одна из лучших мер безопасности. Сценарии, проверяющие сайты, обычно ищут недостатки в кодировании сценариев (PHP, Perl, Ruby и т. Д.), Но, установив пароль веб-авторизации Apacce, вы в значительной степени заблокировали значительную часть имеющихся сценариев. Отрицательным моментом этого подхода является то, что теперь вы должны помнить свой пароль для CMS, а также пароль Apache, но это тривиальное неудобство по сравнению с компрометацией вашей системы.

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

Еще одна вещь, которую вы можете сделать, чтобы защитить себя от распространенных атак, - это настроить VPN и ограничить доступ к административным службам (SSH, панели управления и т. Д.) IP-адресами в этой VPN. Используйте свой брандмауэр, чтобы убедиться, что такой трафик действительно исходит из VPN и не подделан (например, отбросьте трафик, привязанный к интерфейсу VPN из WAN).

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

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