Базовые рекомендации для повышения безопасности *nix веб-сервера

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


Шаг нулевой. Отставить тупое следование инструкциям.

Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета (книжек и вообще любых источников) и особенно форумным советам (вы же еще не забыли знаменитый однострок на perl'e?). Даже если вы настраиваете веб-сервер по супер крутой статье от самих разработчиков apache и компилируете ядро по инструкции Линуса Торвальдса, помните, что людям свойственно ошибаться и никто не застрахован от опечаток и ошибок в инструкциях, которые могут привести к фатальным последствиям. Поэтому если вы что-то в инструкции не понимаете, то сначала следует разобраться, а потом делать.
Собственно без соблюдения этого пункта, вообще в IT лучше не соваться.

Шаг первый. Настройка удаленного доступа (ssh).

  • Перевешиваем ssh на нестандартный порт. От злоумышленника, решившего во чтобы то не стало взломать ваш сервер, это не спасет, однако мы избавимся от кучи ломящихся ботов и в логах найти нужную строчку будет гораздо проще, если вдруг что.
    Для параноиков можно реализовать port knocking (это когда мы порт с ssh по умолчанию закрыт и открывается только после того, как мы постучимся в определенный другой). Для совсем безнадежных параноиков можно выстроить цепочку из портов, в которые нужно стучаться.
  • Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
  • Явно задаем список пользователей, которым разрешено логиниться на сервер.
  • Ставим фильтр, который банит ipшники после, скажем, пяти неудачных попыток залогиниться (fail2ban, например).
  • (опционально, т.к. не всегда является возможным) Запрещаем логин по паролю и разрешаем ходить только по открытым ключам.


Шаг второй. Собственно сам веб-сервер.

В качестве веб-серверов преимущественно используется apache, либо apache+nginx, реже просто nginx, еще реже различные lighttpd, cherokee и прочее. Поэтому шаг относится в большей части все относится именно к apache и nginx.
  • Не пренебрегать open_basedir (многие просто его отключают, т.к. не могут с ним справиться: видят, что возникает ошибка из-за open_basedir и просто тут же его вырубают)
  • Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.
  • Скрыть версию используемого ПО. В apache это ServerSignature и ServerTokens, в nginx — server_tokens off; (upd от alxsad).
  • В php.ini так же есть возможность урезать отображаемую информацию
  • upd от edhell: так же отключаем опасные функции в php.ini (exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc).


Шаг третий. Обновление ПО.

Своевременное обновление ПО на сервере — один из важнейших моментов. Лучше к тому же и подписаться на рассылку безопасности, дабы своевременно получать информацию об уязвимостях. Причем данный пункт относится не только к установленной unix-системе, но так же и исползуемым cms.

Шаг четвертый. Права.

Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они, права 777, крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров. На php-шном хостинге вполне достаточно 644 для файлов и 755 для директорий. И раздел, где лежат файлы сайтов вообще лучше монтировать с noexec.
hint:find /path/to/dir -type f -exec chmod 644 {} \;
Да и вообще неплохо бы четко понимать, нужны ли выставляемые права файлу или нет.

Шаг пятый. Мониторинг.

Необходимо настроить систему мониторинга с оповещением о нестандартном поведении (имеется в виду превышение установленных норм). Идеально подходит munin (легкий в настройке, удобно расширять функционал и графики красивые).
upd от gunya: csf + lfd — автоматически обнаруживает брутфорс, при флуде тоже помогает.

Шаг шестой и последний. Закрываем все неиспользуемые порты для внешнего доступа с помощью iptables.

Как правило, достаточно оставить открытыми порты для ssh + 80 и 443 для веб-сервера + порт для мониторинга. Собтсвенно все.
FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.
upd. от farcaller: Если пользователю не нужен shell, то его следует отключать, при предоставлении доступа для копирования файлов по ssh.

Ну и конечно же не стоит забывать, что пароли 123456 и qwerty использовать не стоит. Есть отличная утилитка для придумывания неплохих паролей:
$ apg -t -q -n 2
dickluer (dick-luer)
JicNeut3 (Jic-Neut-THREE)
$ apg -t -q -m 12 -a 1 -n 2
@%p-a^b`kI>R
dKYeK{7)E`Es


Все это не является в полной мере исчерпывающей информацией по вопросу безопасности, но даже при соблюдении лишь этих пунктов, подобраться к вам будет значительно сложнее.
Метки:
Поделиться публикацией
Комментарии 248
  • +6
    > Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).

    во FreeBSD запрещен.

    > Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.

    первым делом нужно отключить .htaccess

    • +10
      > первым делом нужно отключить .htaccess
      И переписывать все rewrite, на которых построена большая часть тех же чпу?
      • +2
        Ну, если сервер свой, то можно все просто закинуть в VirtualHost.
        • 0
          Батенька знает толк в извращениях.
          Allowoveride спасет мир (с) В. Брежнева
          • +1
            Если хотите, используйте .htaccess, минусы уже везде расписаны.
        • 0
          Автор было не очень точен в выражении мысли. Имелось ввиду запрещение доступа к скрытым (начинающимся с точки) файлам. Хотя по умолчанию в Apache доступ к .ht* и так перекрыт. Но у многих, кто использует nginx как frontend, из-за неправильной конфигурации возможен доступ к любым статическим файлам.
        • +4
          В чём смысл отключения .htaccess'а?
          • +3
            При обработке запроса от пользователя апач смотрит на наличие правил в htaccess в каждой папке до корня. Скорость генерации страницы сервером заметно снижается, если убрать htaccess
            • +4
              Как это коррелирует с темой топика?
              • +1
                Вообще-то повышается. Но к теме это имеет мало отношения.
                • +1
                  Скорость повышается, конечно. Время сокращается :)
          • +9
            Утомили. Ну чем вам хождение рутом не нравится? При запрете логина с паролем или нормальным паролем вида «Cak_Ubr4Flg ghirgOlyet0» и сертификатом для daily use, чем это опасно?

            Не просто «на всякий случай», а чем именно?
            • +1
              Таким образом мы увеличиваем число преград на пути взломщика: ему становится неизвестно имя пользователя, которому разрешено логиниться в систему. А чем меньше у взломщика информации, тем меньше вероятность взлома.
              • +9
                А теперь вопрос:

                чем отличается для взломщика username(8)+пароль(10) от root+пароль (18)? Если вы допишите username к паролю рута, что осложнится для злоумышленника? Количество операций перебора такое же.
                • –3
                  На самом деле отличается… при переборе пары логин\пароль, при условии что логин не известен, кол-во вариантов для подбора увеличивается в огромное кол-во раз!

                  Я не хочу сказать что юзать root'a — плохо, сам юзаю так =), просто ответил на вопрос =)
                  • +14
                    В какое «огромное количество раз»? Я вас ещё раз спрашиваю, чем отличается перебор username(x)+password(y) от перебора password(x+y)? Если вы оставите в стороне «криптографию на пальцах» и просто посчитаете, количество вариантов, то увидите, что оно строго одинаковое. Более того, на username обычно а) накладываются более жёсткие ограничения по набору символов б) он обычно осмысленный, то есть он криптографически хуже, чем дополнительные случайные символы в пароль в размере username'а.

                    Вот потому я и говорю, что нет никакого смысла в запрете root'а, есть смысл в незапоминаемо-длинных паролях и сертификатах.
                    • +1
                      Может лучше просто отслеживать попытки брутфорса? Тогда и пароля длинной в 10 символов будет достаточно…
                      • 0
                        а это уже зависит от того сколько у вас серверов, пользователей и есть ли адекватная служба мониторинга
                      • 0
                        Позвольте сморозить глупость, сударь. Дело в том, что иногда системные администраторы настолько беспечны, что могут под камерой наблюдения ввести пароль или на машине с кейлогером. Если будет целая лютая каша из символов, то отысКать в нём пару логин-пароль будет сложнее.

                        И совсем уж бестолковые администраторы могут записывать пароли на бумажки, которые кто-нибудь сможет улицезреть и нещадно воспользоваться. На распознавание пары «root:Ny#azN__)GluKk03ss!@» уйдёт меньше времени, чем на то же самое с малопонятной строкой вместо имени.

                        Возможно. А возможно и нет.
                        • 0
                          Для таких случаев нужно еще авторизацию по токену использовать (хард или софт на сотовом). Пароль + токен — уже совсем хорошая защита, если думаете, что вас будут ломать с использованием видеокамер и прочего.
                        • –1
                          Огромного количества раз нет. Есть простой факт:
                          • заломав рута, ты получаешь рута
                          • заломав юзера, ты рута не получаешь
                          Какая польза от юзера, у которого шеллом стоит /bin/false?

                          Для рута нужно отключать вход по паролю, но оставлять вход по ключу, если это необходимо.
                          Зачем нужен вход по ключу, и почему он предпочтительнее, можно прочитать в man authorized_keys, /AUTHORIZED_KEYS FILE FORMAT. Например, вот такая вкусность:
                          from="pattern-list"
                                Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in
                                the comma-separated list of patterns.  See PATTERNS in ssh_config(5) for more information on patterns.
                          
                          • 0
                            Вы такой умный когда делаете копи/паст из man, я поражён
                            • 0
                              Остерегайтесь, это заразно.
                        • +6
                          Скорее наборот
                          В описанной ситуации ( username(8)+пароль(10) против root+пароль (18) ) лучше рут с 18-тизначным паролем
                          По той простой причине, что username будет проверяться по словарю, что даст меньшее количество вариантов, нежели просто пароль(18)
                          • +3
                            Весь адекватный мир уже давно перешел на авторизацию по ключам. Ну или почти весь. Поэтому перебор логин/пароль уже не особо актуальны. Ну и уж если совсем параноя — snort поможет.
                            А вообще — если уж говорить о взломе, то взломать можно все, было бы желание. Не существует не взламываемых защит.
                            В конце концов ректальный термо-дешифратор еще никто не отменял.
                            • –1
                              Как посоветуете хранить закрытый ключ? в архиве под _паролем_?
                              В случае, если нужен «портативный» коннект, т.е. с чужого компьютера а ключи на флешке как быть?
                              • 0
                                Одноразовые ключи. Хотя с чужого компьютера в любом случае небезопасно заходить.
                                • +1
                                  Как хотите — так и храните. Думаю с какого попало компьютера вы на сервера не ходите, поэтому флэшку можо и воткнуть с чужой компьютер.
                                  Ну а если всетаки ходите, то тут уже ничего не поможет — скомпроментировать сервер вы можете в любой момент.

                                  В конце концов вас могут поймать, привязать к стулу и сказать «Заходи», приставив дуло танка к голове. Тут уже никакие пароли и безопасности не помогут.
                                  • 0
                                    ну почему, вот я например настроил хренение ключа в etoken-е. Даже если кейлоггером перехватят пароль на токен — ничего страшного — токен-то я с собой унесу.
                                    Правда недобно — надо ставить дрова на токен и вводить доп. пароль.
                                    • 0
                                      Отлично! Только это никак не умаляет возможность привязывания Вас к стулу вместе с вашим токеном.

                                      Вообще трэд начался с вопроса о хождении по серверам под рутом. Плохо это или хорошо — дело личное. По мне так для начала нужно определиться с моделью угроз, а уже на основании этой модели рисовать схему защиты, а попадет туда рут, Администратор, sudo/su — это уже частности.

                                      Да, я согласен, что нужно обеспечивать какой-то адекватный базовый уровень безопасности, но если меня захотят сломать — меня сломают, и ничто меня не спасет — ти токены, ни ключи, ни мегабайтные пароли. В конце концов охотятся не за доступом, а за информацией. Которую и без паролей можно взять, если конечно на томах шифрование не включено (а включено далеко не у всех, я бы сказал даже, что у единиц, в сравнении с количеством серверов на планете).
                                      Поэтому я воспринимаю данный топ, как некий базис для начинающих, этакие простые истинны, на которые стоит обратить внимание.
                                      • 0
                                        Вообще говоря, первый же совет топика рекомендует не следовать бездумно всему, что пишут. В том числе и остальным советам топика =)
                                  • +2
                                    www.opennet.ru/man.shtml?topic=ssh-keygen&category=1&russian=0

                                    Угадайте второй вопрос команды ssh-keygen без доп. опций.

                                    Архив — можно, но не полезно: ключи маленькие.
                                    • 0
                                      Закрытый ключ, кстати говоря, в файле шифруется с кодовой фразой. Так что архив с паролем бесполезен совершенно, ибо он уже есть.
                                • +4
                                  Как вариант отключение логина по ssh от рута все же дает гемор взломщику, а именно вот какой:
                                  взломав акк. обычного юзера он имеет доступ к ограниченному кол-ву файлов и команд, поэтому он конечно может нагадить пользователю, которого взломал, но не всему серваку вцелом, а чтобы получить доступ к su (чтобы нагадить на сервере вцелом) ему все равно придется взламывать пароль от рута, но уже от лица взломанного им пользователя, тобишь все равно взломщику дополнительный гемор.

                                  но соглашусь, 18символьный пароль от рута тоже вещь :)
                                  • +1
                                    А дальше у нас замечательная команда sudo, которая позволяет делать очень много.

                                    Кстати, комбинация 9 символов root'а и 9 символов username'а хуже, чем 18 символов root'а, так как 9+9 ломается по-очереди, а 18 нужно брутить целиком.
                                    • +2
                                      как это — по-очереди?
                                      при логине в *nix нет разницы в сообщениях об ошибке логина при неправильном логине или пароле

                                      тут фокус в другом — можно «случайно» узнать содержимое /etc/passwd и оттуда получить всех пользователей
                                      • 0
                                        Объясняю, почему «по-очереди». Сначала вы перебираете 9 паролей пользователя и получаете подтверждение об успешном логине, а потом (уже точно зная, что это правильный пароль, спокойно подбираете пароль root'а).

                                        Получается сложность (если в пароле разрешено A символов) A9+A9, что в триллионы раз меньше A18 при сколь-либо приличном A.

                                        Есть ещё проблема пользователя, но пользователь может получить who, last и т.д., не говоря уже про /etc/passwd, так что ему придётся сделать A9+A9+A9 переборов, что опять же, много меньше даже A10, не говоря уже про A11 паролей.
                                        • 0
                                          А откуда вы знаете логин пользователя?
                                          • 0
                                            cat /etc/passwd, who, last.

                                            Ваш капитан
                                            • –1
                                              О мой капитан, я преклоняюсь перед вашей мудростью, но вы ведь должны знать имя пользователя до того, как залогинетесь от этого пользователя? Это же не root который везде root.
                                              • –1
                                                См выше — перебор имени пользователя проще, чем такого же количества символов, дописанных к паролю рута.
                                                • +5
                                                  Разве? Когда идет одновременный перебор имени и пароля, то А будут умножаться, а не складываться, ведь там идет не по очереди перебор, а одновременно.
                                                  Ведь если вы наберет правильный логин, но неправильный пароль, то ответ будет тот же, что и при неправильном логине и правильном пароле.
                                                • 0
                                                  поменять имя root'a на другое — тоже не велика задача :)
                                                  И, кстати, все виндовые инструкции таки одним из пунктов советуют переименовывать Administrator-a. А вот юниксовые root-a переименовывать не советуют, ибо есть куча кривого софта, который ориентируется не на UID, а на имя. Что само по себе очень хреново. Но тоже решается.
                                                  Создается юзер типа 'superadmin' с UID=0, а root закрывается вообще везде. И овцы сыты и волки целы и пастухи обкурены.
                                        • 0
                                          sudo на защищенном сервере?! Это вообще как? Данная комманда должна сноситься сразу после установки пароля для root.

                                          P.S. Доступ по ssh для root все же лучше закрывать по двум причинам:
                                          1. Если пароль сложный (а он должен быть сложным), то вломщику придется ломать голову еще и над эскалацией привилегий (а т.к. компиляторов на сервере по идее быть не должно и все доступные на запись пользователю папки должны быть смонтированы с noexec, просто так запустить сплойт или локальный переборщик будет проблематично). Плюс, как уже говорилось, root — это заранее известный взломщику логин. Если имена пользователей не словарные, то уже поиск логинов будет нетривиальной задачей.
                                          2. Из-за того, что для перехода к root все будут вынужнены использовать su, получаем дополнительные подробности в логах: не просто факт захода рутом, а кто именно им заходил.
                                          • 0
                                            Ну и чтобы взломщикам вообще жизнь малиной не казалась, настраиваем syslog на зеркалирование логов на отдельный, недоступный для простых смертных, сервер, на котором вообще закрываем все, что только можно, и ставим совсем драконовские пароли.
                                            • +1
                                              И чем вам sudo не угодил?
                                              • +5
                                                Данная комманда должна сноситься сразу после установки пароля для root.
                                                Откройте для себя /etc/sudoers. sudo очень полезен, если надо кому-то дать возможность выполнить от рута конкретный скрипт.
                                                • –3
                                                  Или sudo passwd выполнить… Можете меня переубеждать, но я уверен, что у пользователя не должно быть прав рута, даже временных. Кроме того, сервер нужно настраивать так, чтобы у пользователя и потребностей в этом особых не возникало. Если же такое вдруг потребовалось, то пользователь должен обратиться к админу, который, после ревизии скрипта, либо выполнит его сам, либо, поместив в недоступную для записи пользователями директорию, пропишет его в crontab.

                                                  P.S. Если вам кажется все это слишком муторным или сложным, спешу напомнить одно мудрое высказывание на тему: «Безопасность — это процесс, а не продукт (результат)».
                                                  • +3
                                                    Судя по всему, вы никогда в компаниях где больше одного админа, не работали, и пользователям права на, скажем, выключение их же собственных машин не выдавали.
                                                    • 0
                                                      Расскажите, пожалуйста, про проблемы >1 админов.
                                                      • +1
                                                        А что непонятного-то? Скажем, вы нанимаете младшего администратора себе в помощь, будете сообщать ему сходу рутовый пароль? А потом разгребать последствия его неосторожного движения над кнопками, или менять рутовые пароли на всех серверах?
                                                    • +3
                                                      Расскажите мне пожалуйста, как пользователь сможет выполнить sudo password, если в /etc/sudoers этому пользователю не будет разрешен passwd?
                                                      • +3
                                                        >Или sudo passwd выполнить…

                                                        Нет, вы всё-таки откройте для себя /etc/sudoers.

                                                        Hint: не обязательно давать пользователю права на выполнение всех программ от рута, можно перечислить конкретные.
                                                    • +7
                                                      > Данная комманда должна сноситься сразу после установки пароля для root.

                                                      кхм. а не могли бы вы пояснить причины столь безаппеляционного заявления?!
                                                      • –3
                                                        Уменьшение кол-ва доступных пользователю команд, с установленным setuid bit. Кроме того, нет /etc/sudoers, нет стремления получить к нему какой-либо доступ у злоумышленника.

                                                        Кроме того, в некоторых системах, после использования sudo, повторный вызов команды в течение некоторого времени не затребует пароль рута (создается временный файл, указывающий на то, что недавно был успешно выполнен подъем привилегий). Это конечно можно отключить, но если забыть это сделать, то можно себе представить какая это потенциальная дыра.
                                                        • +1
                                                          простите, а какое отношение sudo имеет к количеству установленных программ с suid/sgid?!

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

                                                          а если забыть ключи от дома его могут обворовать. ну и так далее.

                                                          в общем как-то я не понял почему вам не нравится sudo.
                                                          • 0
                                                            Вы уже передергиваете. Кроме того, что удаление sudo, которое по-сути не нужно, если данные на сервере организованы правильно, уменьшает кол-во доступных для злоумышленника средств, для поднятия привилегий, это еще и уменьшает кол-во вещей, о которых «можно забыть».

                                                            И если уж вы любите афоризмы… Если у вашей двери есть n замков, каждый из которых по одтельности может полностью открыть дверь, шанс, что вы потеряете один из ключей увеличивается соответственно. А если вы еще и даете дубликаты ключей другим людям, шанс, что кто-то их них потеряет ключ, становится еще больше.
                                                            • +1
                                                              1) Как было верно замечено, чем меньше suid, а тем более suid root программ, тем лучше. Аргументы — к примеру, вот:

                                                              lists.openwall.net/full-disclosure/2010/10/18/7
                                                              lists.openwall.net/full-disclosure/2010/10/22/15

                                                              В идеале их вообще быть не должно.

                                                              2) su/sudo плохи тем, что позволяют переходить от менее привилегированного аккаунта к более привилегированному. Если этот аккаунт будет скомпрометирован, то будет скомпрометирован и рут — как минимум появляется возможность подбора пароля, как максимум получение пароля путём перехвата (поддельная pts).

                                                              3) Представьте себе, что у вас уже _есть_ пароль рута, но вам некуда его вводить — ни su, ни sudo, ни ssh вам не доступны. Весело, да? :)
                                                              • +1
                                                                ага. представляю.

                                                                только мы вроде бы говорили о веб-сервере. а туда обычно доступ только по ssh бывает. и как тогда работать админу? ;)
                                                                • 0
                                                                  По ключу конечно же.
                                                                  • 0
                                                                    а доступ root тоже по ключу делать?
                                                                    • 0
                                                                      А какие проблемы? Вы думаете разрешение удалённого логина для рута менее безопасно чем su/sudo? Про проблемы su/sudo я написал выше.

                                                                      ИМХО вы слишком остро восприняли пункт (3). Первые два гораздо важнее.
                                                        • –1
                                                          Это, вообще, нормально и правильно. Если нужно делать резервные копии всех данных, включая те, к которым у оператора не должно быть доступа, то — как?
                                                          • +1
                                                            К примеру, по ssh ключу, где указано command=«path-to-backup-script». Этот скрипт будет делать бэкап куда надо. В случае компрометации ключа взломщик сможет только инициировать архивацию на некоторый сервер, который тоже ещё нужно взломать (ведь не по anonymous FTP же бэкап делать). Частоту/время запуска архивирования можно при желании контролировать в скрипте.
                                                            • –1
                                                              Кончайте придумывать глупые ответы, глупые вопросы придумывать проще. Получайте — как быть с:
                                                              • tcpdump -i ath0
                                                                tcpdump: ath0: You don't have permission to capture on that device
                                                                (socket: Operation not permitted)
                                                                
                                                              • ping -i 0.01 localhost
                                                                PING localhost (127.0.0.1) 56(84) bytes of data.
                                                                ping: cannot flood; minimal interval, allowed for user, is 200ms
                                                                
                                                              Все требуют рутового доступа, но могут использоваться «админами на час» для диагностики сети, например.
                                                              А как быть, если названия копируемых файлов меняются, и вписать их в скрипт нельзя?

                                                              Если админов много, но с головой — один, то ему при помощи sudo будет удобно делегировать доступ. Особенно, если безголовые часто меняются. sudo — наше всио, если правильно приготовить.
                                                              Есть ещё sudo-ldap всякие — тоже неспроста, наверно…
                                                              • +1
                                                                Это шутка, да?) Вы спросили про довольно распространённый случай бэкапов, я конкретно на него ответил. Невозможно сделать просто «безопасную систему», с ней ещё нужно вести себя соотв. образом. Ответа «на отвали» вы вряд ли найдёте.

                                                                Про названия файлов — если они меняются, и нет простого способа их задать или ограничить заранее, то, видимо, wrapper вокруг tar (или чем вы там архивируете) и ssh key with command=«path-to-script». C компрометацией ключа взломщик получит возможность прочитать любой файл в системе. Если заранее позаботиться о black list'е, то можно исключить приватные ssh ключи, pgp ключи в /home/*/, и всякие критичные /etc/shadow.

                                                                Советую поискать разницу между sudo и ssh key command="...". Основное имхо — habrahabr.ru/blogs/sysadm/112908/#comment_3621721

                                                                LDAP вообще не в тему, метод авторизации практически ортогонален модели защиты.

                                                                В стране макак нужно либо думать как с ними бороться, либо менять глобус :)
                                                                • +1
                                                                  segoon, это не только Вам лично, а в целом о дикуссии — вместо обмена позитивным опытом началось ругание sudo/suid и других механизмов управления доступом, которые плохи тем, что ругающие их просто «ниасилили».

                                                                  «command=» — спусковой крючок для выполнения команд. Годный, но не гибкий механизм.

                                                                  sudo — способ делегирования доступа. Мне и моим коллегам это позволяет выборочно повышать привилегии сотрудникам, которые не должны иметь неограниченного (рутового) доступа. Тоже годный, но более сложный/гибкий.

                                                                  sudo-ldap — тоже тема, но не про авторизацию. Не pam-ldap, и не nss-ldap.
                                                                  • –1
                                                                    www.ubuntu.com/usn/usn-1046-1
                                                                    www.ubuntu.com/usn/usn-983-1
                                                                    www.ubuntu.com/usn/usn-956-1
                                                                    www.ubuntu.com/usn/usn-928-1
                                                                    www.ubuntu.com/usn/usn-905-1
                                                                    www.ubuntu.com/usn/usn-722-1
                                                                    Для начала хватит?

                                                                    Сдаётся, что command="" вы просто мало использовали. Заметте, я не говорю, что sudo не гибок — я говорю, что он небезопасен.
                                                                    • +1
                                                                      Для начала хватит, но я не начинающий. Если подскажете способ делегировать доступ лучше или так же, как sudo, но не имеющий перечисленных недостатков — буду благодарен. Не подскажете — буду и дальше рисковать, и пользоваться sudo. Не привыкать, каждый день рискую: едой можно подавиться, водой захлебнуться :)
                                                                      • 0
                                                                        Перечисленных недостатков кроме «негибко» я в ваших постах не нашёл. Я знаком с LDAP только в теории, так что «тот же sudo-ldap, только лучше» я вам так с ходу не скажу. Для моих целей authorized_keys с command было достаточно. Для бэкапов решение уже предложил, аргументов против не услышал.
                                                                        • 0
                                                                          Давайте упростим тему — сделаем вид, что про LDAP я не говорил. Он просто добавляет гибкости к sudo, у которой этой гибкости уже и так много.

                                                                          Для моих целей гибкости authorized_keys оказалось недостаточно, и этого аргумента мне достаточно. Про бэкапы — первый вопрос из трёх заданных, и только для него был получен ответ. А, как я уже говорил, у меня в запасе есть ещё много вопросов, ответом на которые является «sudo», а не «authorized_keys». И не такие уж эти вопросы глупые — все возникли по ходу жизни, а не «от балды».
                                                                          • 0
                                                                            Для tcpdump и ping ответ практически такой же, догадайтесь сами. Хотя зачем предоставлять возможность флудить недоадмину, для меня остаётся загадкой.

                                                                            Последний раз спрашиваю — в чём заключается гибкость sudo, которой невозможно добиться с пом. ssh keys? Именно приниципиальной разницы, ибо это всё-таки разные вещи.
                                                                            • +1
                                                                              Флудить нужно для оценки качества линии связи. Операция выполняется после ремонтно-восстановительных работ самым низкооплачиваемым персоналом, часто — с антисоциальными наклонностями. Стандартными пингами выявлять потери менее 1% не очень удобно.

                                                                              На вопрос «в чём именно принципиальная разница всё-таки разных вещей» я ответить затрудняюсь. Извините.
                                                              • 0
                                                                например, Zabbix-агент крутится под непривелигерованным пользователем. Когда ему нужно бывает (бывает такое) выполнить специфическую команду, он делает её через sudo, и больше ничего сделать не может

                                                                ssh тут опаснее — например, приватный ключ пришлось бы хранить в открытом виде (чтобы агент мог его использовать)
                                                                • 0
                                                                  Приватный ключ имеет права 0600. В чём опасность?
                                                                  • 0
                                                                    через sudo всё равно безопаснее. Никакого ключа вообще нет.

                                                                    Кроме того, для работы с sudo не нужен ssh вообще — это повышает надёжность
                                                                    • 0
                                                                      habrahabr.ru/blogs/sysadm/112908/?reply_to=3624500#comment_3621721 и коментарий ниже со списком уязвимостей за прошлый год в одном дистрибутиве, если теория вас не впечатляет. Забавно, что некоторые отказываются от sudo в пользу ssh по соображениям безопасности, вы же наоборот, но по тем же причинам :)
                                                                      • 0
                                                                        Всё-таки я подчеркну: безопасности и надёжности. Мониторинг должен делать своё дело, вне зависимости от того, брутфорсят ли сервер и может ли кто-то подключиться по SSH или нет. Даже если ssh-сервер упал. Мониторинг должен быть настолько автономен, насколько это технически возможно.
                                                            • 0
                                                              Это вообще правильно. Наоборот, su на защищённом сервере — «это как?».

                                                              И в sudoers мы разным пользователям даём разные возможности в зависимости от степени доверия и т. д. Мог бы он ещё в зависимости от сложности пароля давать разные возможности…

                                                          • +3
                                                            а чтобы получить доступ к su (чтобы нагадить на сервере вцелом) ему все равно придется взламывать пароль от рута, но уже от лица взломанного им пользователя

                                                            не забывайте про локальные уязвимости ядра — редко на серверах стоят свежие ядра, а на старых получить повышение привилегий довольно несложно, если повезет.
                                                            более того, чаще всего рутовый аккаунт — не предмет для взлома: например, рассылать спам можно и без него.
                                                            • 0
                                                              >… например, рассылать спам можно и без него...

                                                              Если каталоги, доступные пользователю на запись, смонтированы с noexec, а на сервере не стоит собственного настроенного мылера, то рассылать спам без рута будет проблематично.
                                                              • +3
                                                                Каким образом noexec помешает запустить скрипт а-ля php/python/perl из командной строки? noexec всего лишь запрещает установку +x бита, не больше.
                                                                • +1
                                                                  Не говоря уж о штатном telnet, с помощью которого можно также можно отправить почту хоть куда ;)
                                                                  • +1
                                                                    noexec больше направлен не на защите от скриптов, а на защиту от бинарников, коих немало используется для повышения привилегий.
                                                                    • 0
                                                                      Ошибаетесь, chmod разрешён, а запрещён execve(2) и некоторые фишки в программах типа /usr/lib/ld.so /path-to-mount-noexec/binary (в новых версиях лоадера).
                                                              • +5
                                                                Вы серьёзно думаете, что кому-то в здравом уме придёт в голову брутить пароли? Максимум — словарь. Прогнал словарик — убедился, что ничего не получилось, и дальше попытки входа через парадную дверь прекращаются.

                                                                Разумный довод в пользу запрета входа рутом заключается в том, что это поможет потом по логам определить, кто из администраторов ходил на сервер и что-то сломал.
                                                                • 0
                                                                  Да, в ситуации с несколькими админами — это первый аргумент в пользу «нет руту», который я слышу.
                                                                  • 0
                                                                    Если сильно нужен именно этот сервер, а не очередной хост для спама etc, то брутят
                                                                    • +1
                                                                      Пароль в 6 буков, 10 запросов в секунду. Умножаем. Получаем 357 суток. Пароль в 8 буков, 1000 запросов в секунду — 2000 лет.
                                                                      • –2
                                                                        Помнится, не так давно был тут топик, где скорость перебора была на несколько порядков выше. и если поделить ваши 2000 лет на 40000 (в статье же 400к/сек), то получится всего лишь 18.25 дней на 8-значный пароль. не такой уж и нереальный срок.
                                                                        Хотя при таком раскладе есть вероятность, что канал накроется быстрее, чем удастся поборать пароль.
                                                                        • +8
                                                                          Это какая система отзывается на попытку логина со скоростью 400к в секунду?
                                                                          • +3
                                                                            Вы уверены, что речь шла о переборе по сети? Может просто локально хэш ломали?
                                                                            • –1
                                                                              цитата:
                                                                              К слову, защищенная WiFi сеть WPA-PSK соседней с компанией Тома организации была им взломана за 20 минут.
                                                                              • +1
                                                                                К слову, при чем здесь вай-фай?
                                                                                • –2
                                                                                  Меня спросили уверен ли я, что в указанной статье речь идет о сетевом переборе.
                                                                                  Я привел цитату из статьи. и «К слову» является частью цитаты.
                                                                                  • 0
                                                                                    подобрать пароль к WPA сети можно по дампу зашифрованного трафика. Сеть сама по себе при этом не используется.
                                                                          • 0
                                                                            А хорошая система после ошибки при вводе пароля сделает таймаут на несколько секунд.
                                                                            • 0
                                                                              и мы получим систему, которую даже ddosить легко и просто. Достаточно раз в несколько секунд пытаться на неё залогиниться из разных мест, и всё — админ не достучится.
                                                                              • 0
                                                                                За удовольствие надо платить. Выбирайте — некоторые проблемы при входе в систему для админа или простота подбора пароля. Дальше уж кто чего сильнее боиться :)
                                                                                • 0
                                                                                  у меня вход рута вообще запрещён, вход пользователя только по ключам, по паролю запрещён

                                                                                  пусть брутфорсят, ей-богу, а я всегда смогу «достучаться»
                                                                        • 0
                                                                          Да, я так думаю :) Словари бывают разных размеров, к тому же словарь — это то, от чего можно отталкиваться, добавляя к слову в разных местах произвольные символы, пермутировать его, менять регистр и пр. Если пароль можно будет подобрать через пару месяцев — замечательно (для взломщика)! Мало кто так часто меняет пароли.
                                                                      • +3
                                                                        Таким образом мы увеличиваем количество преград самому себе, и не более того.
                                                                        Да, в большинстве серверных дистрибутивов хождение под рутом выключено. Но это сделано как защита от администраторов-идиотов, ставящих пароль рута 1234 «на время установки».
                                                                        • +1
                                                                          Не будем тыкать пальцами, но… сам такой администратор :) Потому руту разрешаю ходить только по сертификату.

                                                                          А вообще, IMHO, спор сродни: «что лучше — мыть руки перед обедом или пользоваться вилкой?»))) Кому как удобнее.
                                                                          • 0
                                                                            Рутовые права нужны в неделю раза два. Можно и через su привилегии поднять. Пальцы не отвалятся.
                                                                            Если не можете понять зачем в умных книжках вам настойчиво рекомендуют не работать под рутом без острой на то необходимости… ну просто примите на веру. Понимание приходит с возрастом… правда к каждому в разное время =).
                                                                            • –3
                                                                              Вы, молодой человек, сначала молоко с губ сотрите) Я вам не про книжки, а про реальную эксплуатацию говорю.
                                                                              А суть в том, что на серверах не работают. На них заходят раз в N месяцев обновить софт, ну может еще что-то доставить. Всё, остальное время нормально настроенным сервером управляет автопилот. Обычных «пользователей» там вообще нет, есть рут и есть псевдоюзеры для учета ресурсов и разделения прав. Ну, у хостеров еще иногда может зайти админ клиента и что-то поковырять под своими урезанными правами, но на выделенных серверах никому кроме рута логин в систему вообще не разрешен. Просто некому и нечего разрешать.
                                                                              И тем не менее, многие настойчиво рекомендуют таки завести дополнительного пользователя и авторизовываться в два шага. При этом не приводя ни одного примера — зачем оно надо.
                                                                            • +2
                                                                              «Ой, я не в том окошке нажала» — сказала одна девушка перед тем, как её уволили за то, что она обнулила лицевые счета всех абонентов… А ведь девушке говорили — «Никогда, слышишь — НИКОГДА не оставляй открытой консольку базы данных, которую ты администрируешь».
                                                                              • 0
                                                                                Да-а, мой коронный номер — shutdown -h now не в то окошко. Потом звонки в датацентр и час ожидания, пока они кнопку ткнут.
                                                                            • 0
                                                                              ОК, юзер 'superadmin' с UID=0 удовлетворяет задаче? И не надо лишних телодвижений админу (зайти под лимитированным юзеров, а потом сделать su/sudo) и прячет админский юзернейм от шаловливых взломщиков.
                                                                            • –1
                                                                              По возможности следует избегать работать из под root-а. Если вам постоянно нужны рутовые права, то это говорит скорее о вашей некомпетентности, даже если аккаунт у вас с сертификатом и зубодробительным паролем.
                                                                              Для большинства операций не требуется рутовых прав. Поэтому логиниться под ним не надо. И поэтому поднятие прав через su не назойливая хрень (вроде UAC в винде), а такой же инструмент, который без необходимости трогать не надо. После некоторых неосторожных действий результат может быть оооочень плачевным.

                                                                              З.Ы. Дабы никого не оскорблять скажу только одну фразу: «Тут вам не виндовс».
                                                                              • 0
                                                                                Извините, у меня под управлением десяток серверов, а операций я совершаю ровно три: апдейт пакета, правка конфига, рестарт сервиса.
                                                                                Для каких из них не нужны права рута?
                                                                                • 0
                                                                                  Большинство _каких_ операций? На моём ноуте? да.

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

                                                                                  Хотя да, есть некоторые сервера (вроде хранилища git-репозитория) — да, я там пользователь и хожу под пользовательским аккаунтом.
                                                                              • +1
                                                                                >Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они крайне редко нужны)
                                                                                Так никогда или крайне редко?
                                                                                • +4
                                                                                  На файлы cms'ок — не выставляйте никогда. Вообще — выставляйте крайне редко.
                                                                                  Что в этом предложении вам не понятно?
                                                                                  • +1
                                                                                    достаточно папки группы «content» перевесить на пользователя www-data (речь идёт о пользователе, от которого запущен веб-сервер)
                                                                                  • +1
                                                                                    незнаю как с другими, а для линуксов МОРЕ документации существует именно в виде HOWTO —
                                                                                    пошаговых инструкций часто без особых объяснений.
                                                                                    • +2
                                                                                      Все нормальные howto (а не посты «как сделать high-avability кластер из Ubuntu Lynx для начинающих») дают более чем теоретического обоснования тому, что делает(ся).
                                                                                      • 0
                                                                                        Ну это же не значит, что следуя им, нужно отключать мозг, правда?
                                                                                        А вдруг там rm -rf /* случайно промелькнет, тоже скопипастите и в консоль? (:
                                                                                        • +1
                                                                                          это не отменяет возможности узнать а как работает то что предлагает автор HOWTO.
                                                                                        • +3
                                                                                          > Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
                                                                                          В большинстве адекватных линуксов стоит PermitRooLogin = no, либо как вариант — не указано, что равносильно.

                                                                                          >(fail2ban, например)
                                                                                          может быть ресурсозатратно, проще написать 2 строки в iptables
                                                                                          • +3
                                                                                            Какие 2 строки?
                                                                                            • 0
                                                                                              Например ограничить кол-во подключений к ssh
                                                                                              • 0
                                                                                                fail2ban банит не только после неудачных попыток в ssh, но и фтп, и даже в апаче и exim.
                                                                                                iptables все это умеет?
                                                                                                • +1
                                                                                                  iptables умеет ограничивать кол-во соединений в секунду/минуту/… и устанавливать допустимый burst. Например — с одного IP не более 10 соединений в первую минуту, не более 1 в следующие сутки. Брутфорсерам это почему-то не нравится, а мне работать не мешает.

                                                                                                  В сислог записать таких брутфорсеров с правильным префиксом, iptables тоже умеют.
                                                                                                  • 0
                                                                                                    Один момент: надо быть очень аккуратным при задании действий обнаружения DoS/bruteforce'а — ведь злоумышленник может этим воспользоваться и от ip жертвы начать лихорадочно коннектиться к серверу. Если правила на уровне «более 100 TCP SYN в секунду — IP в бан на минуту/час», то легко обрезать доступ к серверу для честных клиентов.
                                                                                                    • 0
                                                                                                      Спорно. Если честный и злоумышленник брутфорсят с одного IP, то должен быть кто-то ответственный за использование этого IP.

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

                                                                                                      Могут быть ситуации с сознательным искажением src IP, но где профит?
                                                                                                      • 0
                                                                                                        Я же сказал — атака на клиентов.
                                                                                                        • –1
                                                                                                          А я спросил — а профит? Если ваш сервер атакуют, чтобы лишить клиентов, значит:
                                                                                                          • они у вас есть
                                                                                                          • их у вас много
                                                                                                          • поэтому вам завидуют

                                                                                                          В этой ситуации нужно:
                                                                                                          • гордиться собой и важничать
                                                                                                          • подумать об отделении услуг от безопасности — погрузить сервер в DMZ, безопасность которой обеспечивается уже не подручными средствами
                                                                                                          Второе предложение уже за рамками статьи, а первое — неэффективно.
                                                                                                          • +1
                                                                                                            Значит у нас с вами разное отношение к клиентам, если вы атаки против них вы за уязвимость не считаете.
                                                                                                            • 0
                                                                                                              Есть такая штука — SLA. Что там клиент подпишет и оплатит — то будем выполнять.
                                                                                          • +3
                                                                                            С сгенерированными паролями нужно быть аккуратно, символ может или отобразить переменную или быть проглочен консолью, помню историю, когда при установке пароля в нём оказалась переменная с PID текущего процесса.
                                                                                            • +2
                                                                                              Еще есть очень удобная штука — csf + lfd — автоматически обнаруживает брутфорс, при флуде тоже помогает.
                                                                                              • +4
                                                                                                > Как правило, достаточно оставить открытыми порты для ssh + 80 и 443 для веб-сервера + порт для мониторинга. Собтсвенно все.

                                                                                                А может достаточно не открывать остальные порты? А если фильтровать – так еще неплохо бы резать по типичным для nmap'а флагам на TCP.

                                                                                                > FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.

                                                                                                S/FTP вполне ок. Про scp надо не забыть зарезать юзеру возможность заходить непосредственно на шелл (если она ему не нужна).
                                                                                                • 0
                                                                                                  > А может достаточно не открывать остальные порты?
                                                                                                  Ну их же слушают другие приложения. Тот же mysql на 3306. Нужно запретить доступ к нем извне.
                                                                                                  > S/FTP вполне ок.
                                                                                                  У меня он как-то не прижился.
                                                                                                  • +2
                                                                                                    Нужно запретить мускулу слушать по TCP/IP. Если никак – пусть слушает на 127.0.0.1.

                                                                                                    S/FTP отлично прижился у кучи моих клиентов, когда я его поставил форсированно, и объяснил что без «enable secure connection» и аналогов FTP теперь не работает.
                                                                                                  • 0
                                                                                                    Защита от дурака, а то мало ли где вместо localhost стоит *
                                                                                                    • 0
                                                                                                      Защиту от дурака надо делать не на файрволле, а еще в netstat -tnlpu, нет?
                                                                                                      • 0
                                                                                                        Надо, но это не повод не иметь еще один уровень безопасности, особенно если ты не супер профи в администрировании серверов
                                                                                                    • 0
                                                                                                      TCP для DNS? FTP?
                                                                                                      • 0
                                                                                                        угу, и для еще ~4900 зарегистрированных протоколов. Зачем утрировать? Я точно помню что методов обнаружения открытых TCP портов в nmap несколько, и их можно порезать на iptables. А вот с UDP не помню – потому про UDP ни слова не написано.
                                                                                                    • –3
                                                                                                      > Никогда! не следуйте инструкциям с интернета
                                                                                                      А ваша статья не в интернете? Чем она лучше остальных? :)
                                                                                                      • +9
                                                                                                        Вот к чему приводит вырывание цитаты из текста. Полная мысль звучит так:
                                                                                                        Никогда не следуйте инструкциям с интернета без полного понимания того, что произойдет от совершаемых действий.
                                                                                                        • –5
                                                                                                          Согласен, но ведь вы сделали акцент на «Никогда! не следуйте инструкциям с интернета», дальше в предложении много уточнений и поэтому от взгляда ускользает продолжение.

                                                                                                          PS я не холивара ради пишу, это действительно сразу бросается в глаза. В конце концов это ИМХО.
                                                                                                          • 0
                                                                                                            Может лучше сказать так?
                                                                                                            «Никогда не следуйте инструкциям без полного понимания того, что произойдет от совершаемых действий».
                                                                                                            • +1
                                                                                                              пофиксил.
                                                                                                              • 0
                                                                                                                А пофиксить-то вы и забыли…
                                                                                                                • 0
                                                                                                                  Местами же поменял:
                                                                                                                  «Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета»
                                                                                                                  Просто сделал это до вашего комментария еще.
                                                                                                        • +3
                                                                                                          Однозначно, что предложенные автором рецепты не панацея, однако выполнение этих не сложных инструкций — это первый шаг к безопасности сервера, что само по себе уже плюс.
                                                                                                          Иногда пренебрежение элементарными правилами может привести к нехорошим результатам, это как старая поговорка про бэкапы — «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают».
                                                                                                          • –3
                                                                                                            Правильная поговорка: админы делятся на два типа, те кто делает бэкапы и те которые УЖЕ делают.
                                                                                                            • +1
                                                                                                              Это как раз ошибочная
                                                                                                              • +5
                                                                                                                Суть поговорки «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают» в том, что многие админы ленятся делать бекапы до того момента, когда произойдёт потеря данных. Поговорка иронизирует по тому поводу, что все админы или еще не делают бекапы, т.к. не было потерянных данных, или уже делают, так как теряли данные и больше не хотят попасть в проблему, что была раньше.
                                                                                                                • 0
                                                                                                                  Ваша поговорка тривиальна, можно было не объяснять. А поговорку вашего собеседника вы просто не поняли — админы либо изначально умные и делают бэкапы. Либо УЖЕ делают (тут ваше объяснение). Те же, кто не делает — очевидным образом админами не являются и суть не более, чем эникейщики.