Надёжный и безопасный Linux (наш ответ Чемберлену)

После прочтения на Хабре недавних статей, посвящённых теме безопасности линукс систем, у меня возникло желание поделиться своей точкой зрения на этот вопрос.
Статья в целом рассчитана на начинающих администраторов, поэтому в ней изложены очевидные для хорошего специалиста вещи. Ценные дополнения и замечания приветствуются.
Копи-пейст выдержки из конфиг файлов я почти не буду приводить по трём причинам:
  1. Это приведёт с излишнему разрастанию статьи
  2. Маны и гугл никто не отменял
  3. Пункт 2 очень полезен для развития специалиста


Итак, как повысить безопасность и надёжность сервера (да и рабочей станции) на базе линукс?



Эту задачу я разделю на 3 части:
  1. (Про)активное обеспечение безопасности — ужесточение настроек системы и демонов. Сюда же относится настройка файрвола.
  2. Пассивное обеспечение безопасности и надёжности — мониторинг системы.
  3. Бэкапы

Ужесточение настроек системы

  1. Отключить неиспользуемые сервисы/демоны. Внимательно просмотреть список процессов (например по команде ps -ef | less ) и определить те из них, которые вам не нужны. Убедиться в том, что они не нужны самой системе. Отключить.
  2. Если это возможно, то изменить стандартные порты и интерфейсы на которых слушают оставшиеся сервисы и настроить дополнительные ограничения по безопасности средствами самих сервисов (т.е путем редактирования их конфигурационных файлов / добавления ключей к параметрам запуска).
    Проиллюстрирую на примере sshd. Здесь необходимо сделать следующее — изменить стандартный порт с 22-го на любой свободный, например на 6622. Запретить доступ под логином root. Жёстко задать список разрешённых для доступа имён пользователя. Разрешить sshd прослушивать только определённый адрес. Как вариант разрешить доступ только по ключу, но мне это не очень нравится
    UPD Ключи единогласно признаны отличным способом доступа к серверу, поэтому используйте их (но не отключайте окончательно парольный вход).
  3. Все сервисы, которые используются только системным администратором либо ограниченным кругом лиц должны быть доступными только через vpn либо ssh соединения.
  4. Везде, где это возможно перейти на использование шифрованного соединения (pop3->pops3, http->https итд)
  5. Iptables
    Настройка файрвола очень интересная тема, которой нужно посвятить отдельную статью.
    Основные принципы таковы:
    Файрвол должен работать по принципу белого списка, т.е всё что не разрешено явно, является запрещённым.
    Этого можно достичь двумя способами:
    Способ №1
    Установка политики файрвола по умолчанию командами iptables -P INPUT DROP, iptables -P OUTPUT DROP и iptables -P FORWARD DROP. После выполнения этих команд весь входящий, исходящий и транзитный трафик, для которого не создано разрешающих правил будет заблокирован, поэтому выполнять их следует с осторожностью.
    Перед тем, как хоть что-то делать с iptables настоятельно рекомендую изучить отличное руководство от Oskar Andreasson
    При его прочтении обратите внимание на цель (действие) LOG, которое позволяет записывать в лог различные данные по попадающим в систему пакетам. Это очень сильно помогает при первоначальном написании файрвола. Могу посоветовать примерно такой порядок настройки файрвола:
    a) Написать все нужные правила
    б) В конец каждой цепочки добавить правило логирования (оно будет отлавливать все пакеты, которые вы не учли в предыдущих правилах и записывать информацию о них в сислог)
    в) Включить файрвол
    г) Находить неучтённые вами соединения в сислоге и добавлять правила для них в файрвол.
    Пункт (г) повторять до исчезновения записей в сислоге.
    Понятно, что не следует бездумно добавлять всё, что появляется в сислоге т.к там будут видны и результаты попыток несанкционированного доступа.
    Отмечу, что политику по умолчанию DROP нужно включать лишь после успешного завершения пункта (г) — это гарантирует, что существующие сервисы продолжат свою работу во время отладки файрвола.
    Также отмечу один не совсем явный для начинающих момент:
    Вот выдержка из того, что должен содержать шаблон стандартного файрвола.
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    Эти правила разрешают входящие и исходящие пакеты, которые принадлежат уже установленным сессиям.
    Работает это конечно только для stateful протоколов, в частности для протокола tcp.
    Если не использовать эти правила, то для каждого приложения придётся писать по 2 правила — одно для цепочки INPUT, а второе для OUTPUT.
    Если же их использовать, то можно ограничиться лишь одним, тем которое позволит установить изначальное соединение.

    Способ №2
    В конце каждой цепочки прописать правило, отправляющее все пакеты в REJECT.
    Т.е в стандартном случае нужно добавить три правила — iptables -A INPUT -j REJECT, iptables -A OUTPUT -j REJECT и iptables -A FORWARD -j REJECT.
    В результате добавления этих правил, все пакеты которые явно не разрешены предыдущими правилами будут отвергнуты с сообщением port-unreachable.
    Всё остальное нужно делать точно так же, как и в способе №1, включая добавление правил с --state RELATED,ESTABLISHED.

    Способ №2 является наиболее верным идеологически и я советую использовать именно его, но выбор остаётся за вами.
  6. SELinux
    Очень интересная и перспективная вещь. Ограничивает права процессов по доступу куда-либо. Каждое действие, которое разрешено делать процессу должно быть прописано в политике, сопоставленной с ним.
    Существует ещё одна аналогичная система — Apparmor (насколько я знаю она используется в ubuntu linux).
    Честно говоря с обеими системами я ещё не работал вплотную (поэтому рекомендаций особых дать не могу), частично использовал SELinux в одном проекте, но ввиду цейтнота по времени, в котором я тогда находился, пришлось временно эту задачу отложить. В скором времени однозначно вернусь к настройке SELinux т.к он мне весьма понравился.

Мониторинг

Взломы и аварии, как известно лучше предотвращать, чем устранять их последствия.
В этой связи очень актуальна грамотно настроенная система мониторинга, которая при первых признаках проблемы сразу подаст сигнал администратору.
  1. Nagios
    Существует несколько крупных систем мониторинга (nagios, zabbix, cacti, munin).
    Я пробовал их все и в итоге остановился на Nagios. Очень удобная и гибкая в настройке система.
    Огромное количество плагинов для мониторинга, а если подходящего плагина нет, можно написать свой на любом удобном вам языке (я например использую для этого bash и python).
    Как минимум необходимо настроить мониторинг загрузки процессора, памяти, свапа, свободного места на диске, load average. Очень желательно мониторить доступность критичных сервисов (например apache, mysql, nginx, tomcat итд).
  2. MRTG/RRD
    Динамику изменения различных показателей удобно просматривать на графиках, генерируемых с помощью MRTG.
    MRTG позволяет просмотреть в удобном виде зависимость различных системных параметров от времени.
    Например можно посмотреть то, как изменяются загрузка процессора и памяти в зависимости от времени суток. Рисовать графики можно практически для любых показателей — от температуры процессора, до количества запросов к базе данных. MRTG это инстумент, крайне полезный для анализа состояния системы.
    У MRTG есть несколько ограничений и недостатков, которые можно обойти воспользовавшись утилитой RRD от того же автора.
  3. Smartd + smartmontools
    Позволяет мониторить состояние жёстких дисков и выявлять подозрительные показания на самом раннем этапе. Можно интегрировать в Nagios.
    Например отличное от нуля значение переменной Reallocated_Sector_Ct указывает на то, что на диске появились бэд секторы, причём появились уже давно т.к smart узнаёт о наличии бэдов только после того, как переполняется заводская remap таблица (тут могу немного ошибаться, теорию по этому поводу давно не обновлял, возможно у современных жёстких дисков бэды сразу видны через smart).
    Можно и нужно настроить smartd так, чтобы все подозрительные показания сразу же высылались по электронной почте администратору.
  4. Анализаторы логов
    Ясно, что вручную мониторить логи системы на предмет ошибок занятие неблагодарное.
    Для этой цели уже давно существует много анализаторов логов.
    Советую поставить сразу несколько систем и выбрать ту, что понравится больше.
    Начать можно с logwatch.
  5. Remote syslog
    Как вы думаете, какова первая цель злоумышленника, проникшего в какую-либо систему?
    Цель — скрыть своё присутствие.
    Для этого он обязательно удалит все упоминания о своих действиях из логов системы (а также попробует подменить некоторые системные утилиты, но об этом ниже).
    Для того, чтобы защититься от негативных последствия удаления логов необходимо организовать их запись на удалённый сервер. Желательно, чтобы ssh доступ на этот сервер был невозможен (самому можно заходить через IP KVM) либо сильно затруднён, иначе ничего не помешает взломщику удалить хранящуюся там немодифицированную копию логов. На самом лог сервере удобнее всего хранить логи в какой-либо СУБД.
  6. HIDS и NIDS
    HIDS мониторит состояние системы (логи, целостность системных утилит итд) и при подозрении на нарушение безопасности информирует об этом администратора. Она поможет в случае, если злоумышленник из предыдущего пункта подменит какую либо системную утилиту с целью скрыть своё присутствие либо обеспечить себе вход в систему. Например можно подменить утилиты ps, who, w, last с тем, чтобы администратор не мог видеть кто залогинен в системе в настоящий момент. Заменить утилиты iptables и sshd с тем, чтобы они позволяли злоумышленнику свободно входить в систему.
    HIDS конечно не сможет помешать таким действиям, но вполне сможет уведомить о них администратора.
    Одним из примеров HIDS является OSSEC.

    NIDS Если HIDS мониторит внутреннее состояние системы, то NIDS анализирует подозрительную сетевую активность (сканирование портов, попытки подбора паролей, различные атаки против сервисов системы итд). Наиболее известной NIDS является Snort.


Бэкапы

  1. Как известно системные администраторы делятся на тех, кто не делает бэкапы, на тех, кто их уже делает и на тех, кто думает, что их делает.
    Это изречение наполнено глубоким смыслом.
    Бэкапы могут понадобиться во многих случаях, например после аппаратных проблем с системой, после её взлома, после некорректных действий администратора или разработчика.
    Можно условно разделить бэкапы на бэкапы файловой системы и бэкапы баз данных.
    Очень желательно иметь отдельный сервер для хранения бэкапов, в идеале ещё и находящийся отдельно от всего остального оборудования. Отдельно значит на расстоянии километров 5, не меньше.

    Для бэкапа написано много разнообразного ПО, но я предпочитаю использовать скрипты, написанные лично мной. Так я получаю полный контроль над процессом.
    Для бэкапа файловой системы проще использовать rsync с подходящими ключами. В большинстве случаев удобнее делать инкрементальный бэкап.
    Для бэкапов баз данных лучше всего использовать утилиты, предоставленные производителями СУБД, но в случае с mysql я немного отошел от этого правила.
    Стандартная утилита для бэкапа — mysqldump не очень хорошо ведёт себя при снятии бэкапа, а именно — она «лочит» таблицы на запись, запрещая писать в них в момент бэкапа (хотя в случае с innodb этого можно было бы вполне избежать, но mysqldump не умеет этого делать). Это очень актуально при использовании больших баз, размером хотя бы 10-20 Гб, где блокировка таблицы может длиться 10-20 минут. Кроме того восстановление больших баз из такого бэкапа занимает многие часы.
    В такой ситуации более разумно использовать систему master->slave.
    На бэкап сервере настраивается mysql slave для той базы, которую необходимо бэкапить. В дальнейшем бэкапы снимаются уже не с основной базы, а с её slave-а. В случае же аварии можно даже сразу не восстанавливать базу, а просто перенаправить все запросы на slave сервер, что позволит сильно сэкономить время. Для снятия бэкапов со slave сервера и для его первичной подготовки удобно использовать утилиту Innobackupex от компании Percona. Она например позволяет сделать бэкап, пригодный для последующего поднятия slave сервера без остановки основной базы (без блокировки её на запись).
    Есть ещё один очень важный момент — необходимо периодически проверять бэкапы на предмет их корректности, иначе вы рискуете в самый неподходящий момент обнаружить пустые или битые архивы.


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

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

P.S В статью внесены некоторые правки по результатам обсуждений в комментариях. Спасибо всем высказавшимся.
Поделиться публикацией

Комментарии 59

    +8
    Перенёс сервис на левый порт = нажил себе геморрой в будущем. А лучше не стало. Так что так делать не стоит, кроме особых отдельных случаев.

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

    На примере ssh: простым сканированием портов однозначно определяется — он первым делом после установления клиенту сообщает, что он какой-нибудь «SSH-2.0-OpenSSH_5.6p1-hpn13v10». Так что переноси, не переноси — один фиг, безопасности ни капли не добавится.
    А удобства сильно меньше, вместо ssh system.dns.name приходится ещё указывать порт; а scp так и вообще неудобно — порт указывается в отдельном ключике и то ли -P, то ли -p, не помню.

    А вот ключи — очень удобная фича. Как раз стоит вообще отключить доступ по паролю, а разрешить только ключи. И можно не бояться брутфорсов.
      +8
      Я не предлагаю переносить например nginx с 80-го порта на порт 12345.
      В плане изменения порта речь шла о довольно узком круге сервисов, поэтому я и написал "Если это возможно, то изменить стандартные порты ...".
      Возможно это или нет — решать системному администратору.

      Насчёт sshd:

      1) Я меняю порт на нестандартный по той причине, что огромное количество скриптов сканируют онлайн хосты каждую секунду.
      Получать на почту горы сообщений о том, что была неудачная попытка входа под логином root и паролем toor мне не очень улыбается. Смена порта это не защита от серьёзного злоумышленника, это отсечение простых ботов.

      2) Касательно неудобства использования нестандартного порта для логина по ssh. Я один раз прописываю сервер в /etc/ssh/ssh_config и забываю о нём.
      Запись делается такого рода:
      Host 1.2.3.4
      Port 22122

        +3
        для ssh есть bruteblock и fail2ban
          +2
          Ага, знаю. Да и Snort я думаю умеет реагировать на брутфорсы.
          Я намеренно не стал описывать применение конкретных решений — не хотел сильно увеличивать статью.
            +1
            можно через iptables простым правилом по кол-ву соединений на единицу времени

            iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
            iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP

            hitcount сколько соединений
            seconds в течении какого временного промежутка
            –1
            Я имел ввиду, что смена портов — это высокоспецифичный трюк. А вы, вместо списка тех нескольких сервисов, для которых это имеет смысл, привели в пример ssh, для которого его полезность сомнительна. К тому же, все эти несколько сервисов наверняка правильнее закрыть файерволлом, чем перевешивать на другие порты.

            Этот трюк годится для OpenVPN. А больше я что-то и не могу сходу придумать примеров.
              0
              Файрволом, к сожалению, не всегда возможно, хотя это конечно лучшее решение. Часто у пользователей динамические ip адреса, а прописывать в файрволе /10 диапазоны их провайдеров нет никакого смысла.
              А так, да для этого и нужны комментарии — для исправления и уточнения статьи.
                0
                Прописать /10 или /16 это лучше чем для всего инета доступ открывать.
                  0
                  Для меня почти нет разницы если честно.
                  Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
                    0
                    Я обычно vpn не ставлю, а обучаю юзеров делать port forwarding через ssh, чтобы работать с сервисами внутренней сети. При большом количестве сервисов и т.п. — однозначно vpn, но пока только один случай был, когда ssh не хватило.
                    У меня принцип — меньше служб, выше безопасность. Т.е. там где возможно, как минимум вместо vpn и ftp используется ssh.
                  0
                  я вот недавно зафаерволил SMB/CIFS на одном сервачке на /64 :)
                0
                Порты полезно менять, если наш провайдер по дефолту блочит 22 порт. Это отголоски того самого бага в SSHv1. Плюс у нескольких хостеров встречал, что ssh открывается только для определенных адресов. Я предпочитаю делать это сам, поэтому перевешиваю ssh.
                Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
                  0
                  Еще есть port knocking. На мой взгляд лучше, чем менять порты.
                    0
                    Я бы использовал их вместе. Решения дополняют друг друга.
                    Смена порта, как я уже отвечал, помогает отсеять простых ботов, сканирующих диапазоны ip адресов.
                      0
                      Да, но для этого простому боту нужно правильно постучаться. Какова вероятность того, что он угадает правильную последовательность портов?
                        0
                        Я имел в виду вот что:
                        Смена порта обманет простых ботов.
                        Port knocking для отсечения тех, кто целенаправленно изучает именно наш сервер.
                  0
                  Забыл ответить по ключам.

                  Ключи очень удобная вещь, согласен, сам ими пользуюсь чтобы не вводить каждый раз пароли, но с тем, что они повышают защищённость я бы не согласился.
                  Просто меняется точка уязвимости, до этого это был пароль, теперь стал файл с ключом.
                  Также остаётся открытым вопрос — что делать в случае утери ключа? Как зайти на сервер, чтобы заменить ключ на новый?
                    +4
                    Ключи безопасность однозначно повышают. Сравните: при брутфорсе будут подбирать ~20 символов пароля, по ~4 бита энтропии каждый, или же 1024 или 2048 бит закрытого ключа?
                    Кроме того, пока что я не видел, чтобы по ключам брутфорсили. А по паролям — только так.

                    Файлик не так-то просто стырить. Кроме того, он шифруется с парольной фразой. Т.е. на худой конец, даже если пароль стырили, не сразу расшифруют, и ещё надо понять, от чего он.

                    А про потерю — встречный вопрос: что вы будете делать, если забыли пароль?
                      +1
                      По ключам — согласен.
                      Про забытый пароль 1:1 =)
                      +1
                      смена пароля — физический доступ или IP KVM
                        +8
                        1) для взлома ключа вам нужен будет [файл ключа] + [пароль от него]
                        2) Повышает безопасность необходимостью подбора более длинного ключа в отличии от пароля, защищает от совпадений md5
                        3) Позволяет ввести пароль только один раз
                        4) Позволяет Agent Forwarding для доступа далее — можно лазить через цепочку ssh, при этом ключ будет только у вас на машине.
                        5) Позволяет отключить авторизацию по паролю.

                        Что делать в случае утери ключа? То же самое, что в случае забывания пароля.
                        — примонтировать диск и заменить ~/.ssh/authorized_keys нужным
                        — зайти по паролю через физическую консоль
                        — иметь запасной ключ (можно на одну учетку ведь и несколько ключей повесить)
                        — свой вариант решения проблемы
                          +2
                          Я буду обновлять комментарии перед отправкой
                            +4
                            Да ладно, полезный пост, всё подробно расписано.
                            0
                            У меня на каждом компьютере свой закрытый ключ. Поэтому при потере ключа можно зайти с другого компьютера. Правда, чтобы добавить/убрать ключ мороки больше.
                          0
                          Перенос ssh на другой порт отсеивает в первую очередь ботов. Так же, как и грейлист на smtp отсеивает в первую очередь завирусованные винды. К счастью, тупых ботов намного больше, чем целенаправленных попыток проникновения, поэтому один только перенос уже значительно улучшает ситуацию.
                          Например, я у себя держу ssh на стандартном порту на интерфейсах, смотрящих в локальную сеть и на нестандартном на внешних, смотрящих в интернеты.
                            0
                            IMHO отключение рута (если был) и настройка входа только по ключу — первые действия после установки sshd. Тот, кто это пройдёт, и порты просканировать не поленится.
                            Нестандартный порт для часто используемого хоста стоит в .ssh/config указать, там его и scp подберёт.
                              0
                              Уже обсуждалост в комментах к одному из топиков. Какая разница — пароль юзера 8 символов и 8 символов пароль рута или пароль только на рута, но 16 символов? Это при использовании паролей. При использовании ключей все равно админы любят sudo без паролей делать — толку в таком случае рута закрывать?
                                +1
                                Я sudo без пароля не делаю и другим не советую, об этом случае и написал.
                              0
                              ~/.ssh/config

                                0
                                На тему не стандартного порта SSH. поможет файл конфига в домашнем каталоге.
                                scp,svn, и так далее все будут ходить по определенному порту

                                ~/.ssh/config

                                Host xxx.com
                                Port xx
                                0
                                > Маны и гугл никто не отменял

                                Вот это коварно может быть. Бывало, и не раз на дебиан (и не только):
                                Проблема: %software% не полностью решает задачу X.
                                Правильное решение: apt-get install %software%-чегототам
                                Решение любезно подсунутое гуглом: выкачать, пропатчить и собрать %software%
                                На старой работе админ так с php развлекался.
                                  +1
                                  Конкретно по дебиану много различных копи-пейст ресурсов, на том же www.howtoforge.com/ много примеров на базе дебиан. И большинство из них без компиляции.

                                  Вообще не очень люблю собирать из исходников, прибегаю к этому в самом крайнем случае.
                                  Как минимум потом придется подписываться на security рассылку скомпилированного софта и мониторить наличие в нём уязвимостей (что в стандартном случае делает debian security team).
                                  Плюс теряется связность скомпилированного ПО с остальным системным софтом и можно случайно нарушить его работу, удалив казалось бы ненужный пакет (такого у меня пока не было, но думаю опасность вполне реальная).
                                  Ещё минус — для сборки придется ставить много -dev пакетов, которые в обычной системе совсем не нужны.
                                    +1
                                    Сборка чего не надо — это лишь один частный случай из многих.
                                    Каждый 3-й совет из интернета — записать свои труды в rc.local — тем самым превращая rc.local в хренов autoexec.bat. Например записать туда echo «1» > /proc/sys/net/ipv4/ip_forward, вместо разкомментирования строчки в /etc/sysctl.conf
                                    Можно навалить еще кучу примеров.
                                    Важно знать, что хорошо в слаке — то в генту смерть. Вообщем основная моя мысль такая: искать в интернете не «сделать что-то в Linux», а «сделать что-то в %disributive% %version%»
                                    Впрочем, сам я даже не начинающий админ, просто мимо пробегал. Но на форумах много раз видел, как новичкам любезно подкладывают грабли (из лучших побуждений!)
                                  +1
                                  Странное чувство меня одолевает…
                                  На тот ли Хабр я попал???
                                  Перечитал статью трижды и не знаю, к чему бы придраться ;)

                                  Все, что описано тут, совпадает с моими практическими наработками и привычками.
                                  И «перевешивание» sshd, и авторизация по ключам, и стилистика применения iptables…

                                  Мог бы привести много аргументов в пользу изложенного,
                                  мог бы добавить пару-тройку мелких штрихов, типа подмены строки
                                  «SSH-2.0-OpenSSH_5.6p1-hpn13v10».
                                  Или напомнить про recent и hitcount в iptables, которые хорошо отбивают брутфорсы.

                                  Но и так статья хорошая получилась.
                                  Спасибо.
                                    0
                                    Вам спасибо, за положительный комментарий =)

                                    И спасибо всем тем, кто дополняет статью.
                                    0
                                    Меня очень и очень задолбали люди, которые первым советом при настройке CentOS пишут «Отключите SELinux...» вместо нормальной настройки под их изменения.
                                    При этом найти информации по SELinux очень сложно. Методом проб и ребутов его приходится точить под изменения :)
                                    –1
                                    Мне не нравится статья. В ней, как я понимаю, речь идет о защите серверного Линукса.

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

                                    Во-вторых, что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.

                                    В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? Я не понимаю. Вы видимо тоже.

                                    В-четвертых, изменение порта на котором слушает сервис, не обманет даже популярный nmap — e всех сервисов есть характерные сигнатуры. Разве что это спасет от тупых скриптов, которые брутят пароли на 22 порту у всех машин подряд.

                                    В-пятых, пара строчек про HIDS и NIDS несет нулевую ценность. Никто конечно конфиг выложить не просит, но рассказали бы хоть в общих словах.как их настраивать.

                                    И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.

                                    В общем, статья не содержит никаких конкретных рекомендаций. То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно.
                                      +1
                                      Во-1х, статья идёт об усилении простого сервера, подъём jail/vserver это второй уровень защиты.
                                      Во-2х, для SELinux конфиги обычно не руками пишут, а корректируют автогенерённый в процессе 100% чистого запуска в тест режиме.
                                      В-3их, список разрешенных портов гораздо уже, чем запрещенных, и открыть только нужные дырки обнаружив что что-то не работает (причем еще в процессе настройки!) проще, чем потом обнаружить, что у тебя что-то вскрыли.
                                      В-4ых, изменение порта делается не для обмана, а именно для выхода из-под «масс-хак» атак, что снизит вероятность появления очередного ботнета на сайте из-за дырявого сервиса до момента обновления; а не против «персональной» атаки.
                                      В-5ых, самые умные будут грузить чугуний.
                                        0
                                        Начну отвечать с конца.

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

                                        То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно
                                        Я уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.

                                        что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
                                        Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.

                                        И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
                                        Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
                                        Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.

                                        Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы
                                        Да, вы правы. Про chroot я совсем забыл.
                                        Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
                                        Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.

                                        В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить?
                                        При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
                                        Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
                                        Гораздо проще запретить все пакеты и разрешить лишь нужные.
                                        Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
                                          0
                                          >При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
                                          >Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
                                          >Гораздо проще запретить все пакеты и разрешить лишь нужные.
                                          Про полный запрет инпута опять же упоминалось в комментах прошлой статьи. Для апдейтов будете по ip-адресам апдейт-серверов разрешать или по порту все-таки откроете? Проще сделать разрешение на прием ответов для соединений, которые мы же сами и инициировали.
                                            +1
                                            Конечно --state RELATED,ESTABLISHED подразумевался мной в пункте (a) Написать все нужные правила
                                            Давайте для ясности я всё же укажу это в тексте статьи.
                                            Спасибо за дополнение.
                                            0
                                            > Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.

                                            А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.

                                            > Да, вы правы. Про chroot я совсем забыл.

                                            Ну тогда скорее Xen (что, видимо, дорого в плане нагрузки) или Vserver, так как chroot в Линукс никогда не предназначался для повышения безопасности, а только для смены корневого каталога, о чем в его мануале и написано.

                                            И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете? Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д. По моему, проще ограничиться минимумом служб, чем тратить дополнительно время на настройку и перенастройку фаерволла. Отключить службу выгоднее чем зафаерволлить.

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

                                            А исходящие соединения фаерволлить по моему больше проблем вызывает, чем пользы. Ну может, конечно, я и ошибаюсь.
                                              0
                                              А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
                                              Возни немало, но у нас и цель достойная.
                                              Что касается изменений — само по себе ничего не меняется, всё происходит в результате действий администратора. Просто необходимо взять за правило при любых изменениях на сервере не забывать про соответствующие изменения в его системе безопасности. И всё это документировать.

                                              И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете?

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

                                              Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д.

                                              Необходимо хоть немного представлять себе структуру сети, в которой настраиваешь файрвол, тогда таких сюрпризов будет меньше.
                                              Кроме того я добавил к пункту про iptables дополнение, о котором просто забыл написать сразу — политику DROP надо включать после полной отладки файрвола и исчезновения записей в сислоге.
                                            +1
                                            Что касается SELinux.
                                            man getsebool
                                            getsebool |grep http/ftp и т.п.
                                            setsebool value=on/off
                                            man chcon
                                            Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
                                              +1
                                              Блин. Забыл еще:
                                              ps -Z
                                              ls -Z
                                            0
                                            Полиси iptables по дефолту в DROP не стоит ставить. В прошлом топике обсуждали почему. Лучше оттуда примеры скопируйте, т.е. REJECT с корректным отлупом.
                                              0
                                              Я считаю DROP более безопасным. Незачем давать злоумышленнику лишние данные.
                                                0
                                                Какие интересно лишние данные? В случае с корректным REJECT мы по всем портам — открытым или не открытым даем одинаковый отлуп, т.е. определить есть ли служба сканер не сможет, если он не находится в списке разрешенных хостов. А вот головную боль нормальным юзерам обеспечим, особенно с наличием нестандартных портов. Ошибся портом — и сиди жди тайм-аута.
                                                  +1
                                                  Освежив теорию соглашусь с вами, наиболее идеологически правильный вариант это политика ACCEPT по умолчанию + последнее правило в цепочке -j REJECT
                                                  Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
                                                    0
                                                    Ок.
                                                    Насчет типа ответа уже на так принципиально все. Правило стоит последним в цепочке, значит этот ответ будет отдаваться и по открытым и по закрытым портам — дополнительной информации не сливаем, т.к. ответ всегда один.
                                                      +1
                                                      Добавил результаты нашей беседы в статью.
                                              0
                                              Плюс я бы еще добавил в статью:
                                              Все службы, которые нужны только для администрирования, вешаем на 127.0.0.1 и ходим на них через ssh port-forwarding. Плюс также можно перевесить скрипты для администрирования на вторую копию апача, которая также на localhost слушает и работать с ним аналогично.
                                                0
                                                Ну не знаю, мне кажется это уже излишнее усложнение.
                                                Либо привязка по ip (т.е firewall) либо впн для себя любимого.
                                                Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
                                                  +1
                                                  Согласен, но ssh все же немного безопаснее. Типичный сценарий:
                                                  1. Админ с разрешенного адреса заливает файлы по фтп или пользуется другой службой без шифрования трафика.
                                                  2. Трафик идет по открытой сети. Сосед или комп жены/ребенка ловит вирусню, которая начинает шмалять пакеты в сеть о том, что мак шлюза изменился на мак вирусованного компа. Все — пароль уплыл.
                                                  Либо по дороге стоит машина со снифером.
                                                  3. Хакер с утянутым паролем заходит на общедоступную службу нашего сервака и читает почту админа, или еще как-нибудь пакостит.
                                                  Ну и опять же возможен случай, когда хакер зайдет на сервер с вирусованной машины из доверенной сети.
                                                  Т.е. фаервол в данном случае не панацея. Редхат в половине своих курсов не зря постоянно повторяет — не передавайте в чистом виде данные с логином/паролем по открытым сетям.
                                                  То что я использую, на самом деле логическое продолжение парадигмы об отключении лишних сервисов. Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
                                                    +1
                                                    Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
                                                    Абсолютно согласен, добавлю это в статью.
                                                0
                                                Я бы отметил, что перечисленное в разделах
                                                «Ужесточение настроек системы» (кроме пункта 4) и «Бэкапы» применимо вообще к любой современной ОС, в независимости от ядра, лицензии или вероисповедания.
                                                Раздел «Мониторинг» также прекрасно может быть адаптирован под конкретную ОС, нужно лишь найти функциональный аналог.
                                                  0
                                                  я бы еще добавил прекрасном сервисе CSF
                                                    0
                                                    я бы еще добавил о прекрасном сервисе CSF

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое