Правила файервола для Apache за шлюзом (Разрешить только ответы клиентам сервера)

[yamah]

Добрый день.

Есть шлюз на дистрибутиве, будем считать, CentOS 6.6.
Есть внутренний сервер с Apache с публичным сайтом.
До сервера с Apache проброшены порты. C самого с Apche разрешены любые соединения типа FORWARD. Для других устройств в сети действуют различные ограничения.
Пока все работает нормально.

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

). - это скрипт, которым формируются правила IPTABLES на основе конфигурационных файлов.

[Bizdelnick]

Универсальная защита любой CMS — запретить перезапись её файлов юзеру, от которого работает веб-сервер. Если, конечно, она не совсем кривая. и от этого не пострадает её функционал.
А скрипт не смотрел, извините — лень качать и разархивировать. Положите на pastebin или прямо в сообщении покажите, если он умеренно длинный.

[МАН69К]

запретить любые соединения, кроме ответов на запросы клиентов

Т. е. нужно запретить новые исходящие соединения, кроме ответов на уже установленные?
Тогда что-то вроде:

Код: Выделить всё

iptables -A OUTPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

И, разумеется, после перечисления всех разрешённых исходящих - запрет всем остальным.

Универсальная защита любой CMS — запретить перезапись её файлов юзеру, от которого работает веб-сервер.

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

[Bizdelnick]

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

Это даже не решение, это просто нормальная практика (см. википедия://принцип минимальных привилегий), следование которой сводит к минимуму последствия возможного взлома (причём не только в случае CMS). А временные файлы и загрузки должны лежать в отдельном каталоге (в который запись, разумеется, должна быть разрешена) и ни при какой погоде не запускаться на исполнение; в идеале этот каталог должен быть вообще за пределами DocumentRoot. Увы, многие PHP-кодеры этого не понимают, из-за чего я и добавил оговорку про степень кривизны CMS.

[МАН69К]

в идеале этот каталог должен быть вообще за пределами DocumentRoot

Ну это случай отдельный. Многие CMS пишут прямо в каталог внутри себя.

Принцип минимальных привилегий как мне кажется, вы в данном случае трактуете неверно. Он годится для того, что бы каждый веб-сервер работал от отдельного пользователя. Что бы разные сайты работали от разных пользователей. Но ограждать сайт сам от себя на уровне прав доступа - это не самая лучшая тактика защиты.
Если менять права через chmod - любой вредоносный код сможет через тот же chmod их выставить обратно. Запретить сайту выполнять системные ф-ции? А есть гарантия, что не сломается что-то в самой CMS?
Через chattr i, что сможет только root? А как предполагается обновлять CMS и её дополнения? Это же предпологается рано или поздно делать? Ставить новую тему?

Этот совет - он сродни совету отключать JS для повышения уровня анонимности в Сети. Был раньше такой совет популярен, да и сейчас иногда его встречаю. Сделать-то это, конечно, можно, но неудобств при этом будет столько - что лучше искать другие решения проблемы.

[Bizdelnick]

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

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

Если менять права через chmod - любой вредоносный код сможет через тот же chmod их выставить обратно.

Файл вообще не должен принадлежать пользователю, от имени которого запущен веб-сервер.

А как предполагается обновлять CMS и её дополнения?

Ну во всяком случае не через её собственный веб-интерфейс. Позвольте не перечислять >9000 способов это сделать.

Ставить новую тему?

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

[МАН69К]

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

[Bizdelnick]

Какое отношение имеет то, от какого пользователя запущен веб-сервер, к правам на файлы CMS?

Такое, что сделать chmod на чужие файлы нельзя (если ты не root, конечно).

Скрипты CMS в любом случае будут запускаться не от того пользователя, от которого запущен веб-сервер, а от имени владельца файлов.

Садитесь, двойка.

[yamah]

Универсальная защита любой CMS — запретить перезапись её файлов юзеру, от которого работает веб-сервер. Если, конечно, она не совсем кривая. и от этого не пострадает её функционал.
А скрипт не смотрел, извините — лень качать и разархивировать. Положите на pastebin или прямо в сообщении покажите, если он умеренно длинный.

Боюсь, что CMS будет писать в свою же дирректорию временные файлы для проверки лицензионного ключа и работы модулей.
К тому же, судя по инфор о безопасности данной CMS, есть подозрения, что через дыры могут начать спамить или совершать атаки на другие узлы сети.

Код: Выделить всё

iptables -A OUTPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

И, разумеется, после перечисления всех разрешённых исходящих - запрет всем остальным.

Спасибо за подсказку. Но мне нужно защититься на уровне шлюза, на котором проброшены порты до вебсервера.
Мне, видимо, нужно будет смотреть в сторону INPUT и FORWARD на шлюзе по источнику с внутренним IP-сервера?
Естественно, дополнительная защита на самом сервере на повредит.

[Bizdelnick]

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

Каким образом? Ломают CMS обычно через HTTP-запросы, которые можно фильтровать разве что через прокси, но не через файрвол, а с поломанной системы можно немало нагадить уже внутри локалки, и настройки шлюза тут ничем не помогут.

[МАН69К]

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

А в Вашей CMS есть функция отправки писем? При регистрации пользователей, к примеру или других событиях? Или подключения к внешним ресурсам? На уровне iptables вы не защититесь от исходящих запросов, которые могут быть как нормальными, так и нет. В случае с той же почтой, к примеру - iptables вас от спама не защитит, если вам нужно так же и нормальные письма отсылать (хотя можно нормальные письма отправлять через smtp, а не через mail(), если CMS такое позволит - лучше будет). Поэтому я вам всё же рекомендую посмотреть в сторону mod_security - модуль Apache, который позволит сравнивать POST запросы с заданным набором правил и блокировать те, которые характерны для всякой не хорошей деятельности.

[yamah]

Каким образом? Ломают CMS обычно через HTTP-запросы, которые можно фильтровать разве что через прокси, но не через файрвол, а с поломанной системы можно немало нагадить уже внутри локалки, и настройки шлюза тут ничем не помогут.

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

А в Вашей CMS есть функция отправки писем? При регистрации пользователей, к примеру или других событиях? Или подключения к внешним ресурсам? На уровне iptables вы не защититесь от исходящих запросов, которые могут быть как нормальными, так и нет. В случае с той же почтой, к примеру - iptables вас от спама не защитит, если вам нужно так же и нормальные письма отсылать (хотя можно нормальные письма отправлять через smtp, а не через mail(), если CMS такое позволит - лучше будет). Поэтому я вам всё же рекомендую посмотреть в сторону mod_security - модуль Apache, который позволит сравнивать POST запросы с заданным набором правил и блокировать те, которые характерны для всякой не хорошей деятельности.

Отправку спама можно пресечь на том самом разрешенном почтовом сервере.
Нужно еще пресечь возможность загрузки файлов самим сервером. Только метод POST через форму.

[nerve]

если eth0 - это внутренний интерфейс на шлюзе, то возможно

Код: Выделить всё

iptables -A INPUT -i eth0 -s apache_ip -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
iptables -A INPUT -i eth0 -s apache_ip -p tcp -m tcp ! --tcp-flags SYN SYN -m state --state NEW -j DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

то есть дропать соединения, инициированные апачем, а ответные пакеты на входящие соединения - пропускать.
но это надо проверять на практике.

[yamah]

если eth0 - это внутренний интерфейс на шлюзе, то возможно

Код: Выделить всё

iptables -A INPUT -i eth0 -s apache_ip -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
iptables -A INPUT -i eth0 -s apache_ip -p tcp -m tcp ! --tcp-flags SYN SYN -m state --state NEW -j DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

то есть дропать соединения, инициированные апачем, а ответные пакеты на входящие соединения - пропускать.
но это надо проверять на практике.

Спасибо.

[nerve]

проверили?