Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 247
> Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
во FreeBSD запрещен.
> Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.
первым делом нужно отключить .htaccess
во FreeBSD запрещен.
> Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.
первым делом нужно отключить .htaccess
> первым делом нужно отключить .htaccess
И переписывать все rewrite, на которых построена большая часть тех же чпу?
И переписывать все rewrite, на которых построена большая часть тех же чпу?
Ну, если сервер свой, то можно все просто закинуть в VirtualHost.
Автор было не очень точен в выражении мысли. Имелось ввиду запрещение доступа к скрытым (начинающимся с точки) файлам. Хотя по умолчанию в Apache доступ к .ht* и так перекрыт. Но у многих, кто использует nginx как frontend, из-за неправильной конфигурации возможен доступ к любым статическим файлам.
В чём смысл отключения .htaccess'а?
Утомили. Ну чем вам хождение рутом не нравится? При запрете логина с паролем или нормальным паролем вида «Cak_Ubr4Flg ghirgOlyet0» и сертификатом для daily use, чем это опасно?
Не просто «на всякий случай», а чем именно?
Не просто «на всякий случай», а чем именно?
Таким образом мы увеличиваем число преград на пути взломщика: ему становится неизвестно имя пользователя, которому разрешено логиниться в систему. А чем меньше у взломщика информации, тем меньше вероятность взлома.
А теперь вопрос:
чем отличается для взломщика username(8)+пароль(10) от root+пароль (18)? Если вы допишите username к паролю рута, что осложнится для злоумышленника? Количество операций перебора такое же.
чем отличается для взломщика username(8)+пароль(10) от root+пароль (18)? Если вы допишите username к паролю рута, что осложнится для злоумышленника? Количество операций перебора такое же.
На самом деле отличается… при переборе пары логин\пароль, при условии что логин не известен, кол-во вариантов для подбора увеличивается в огромное кол-во раз!
Я не хочу сказать что юзать root'a — плохо, сам юзаю так =), просто ответил на вопрос =)
Я не хочу сказать что юзать root'a — плохо, сам юзаю так =), просто ответил на вопрос =)
В какое «огромное количество раз»? Я вас ещё раз спрашиваю, чем отличается перебор username(x)+password(y) от перебора password(x+y)? Если вы оставите в стороне «криптографию на пальцах» и просто посчитаете, количество вариантов, то увидите, что оно строго одинаковое. Более того, на username обычно а) накладываются более жёсткие ограничения по набору символов б) он обычно осмысленный, то есть он криптографически хуже, чем дополнительные случайные символы в пароль в размере username'а.
Вот потому я и говорю, что нет никакого смысла в запрете root'а, есть смысл в незапоминаемо-длинных паролях и сертификатах.
Вот потому я и говорю, что нет никакого смысла в запрете root'а, есть смысл в незапоминаемо-длинных паролях и сертификатах.
Может лучше просто отслеживать попытки брутфорса? Тогда и пароля длинной в 10 символов будет достаточно…
Позвольте сморозить глупость, сударь. Дело в том, что иногда системные администраторы настолько беспечны, что могут под камерой наблюдения ввести пароль или на машине с кейлогером. Если будет целая лютая каша из символов, то отысКать в нём пару логин-пароль будет сложнее.
И совсем уж бестолковые администраторы могут записывать пароли на бумажки, которые кто-нибудь сможет улицезреть и нещадно воспользоваться. На распознавание пары «root:Ny#azN__)GluKk03ss!@» уйдёт меньше времени, чем на то же самое с малопонятной строкой вместо имени.
Возможно. А возможно и нет.
И совсем уж бестолковые администраторы могут записывать пароли на бумажки, которые кто-нибудь сможет улицезреть и нещадно воспользоваться. На распознавание пары «root:Ny#azN__)GluKk03ss!@» уйдёт меньше времени, чем на то же самое с малопонятной строкой вместо имени.
Возможно. А возможно и нет.
Огромного количества раз нет. Есть простой факт:
Для рута нужно отключать вход по паролю, но оставлять вход по ключу, если это необходимо.
Зачем нужен вход по ключу, и почему он предпочтительнее, можно прочитать в man authorized_keys, /AUTHORIZED_KEYS FILE FORMAT. Например, вот такая вкусность:
- заломав рута, ты получаешь рута
- заломав юзера, ты рута не получаешь
Для рута нужно отключать вход по паролю, но оставлять вход по ключу, если это необходимо.
Зачем нужен вход по ключу, и почему он предпочтительнее, можно прочитать в 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.
Скорее наборот
В описанной ситуации ( username(8)+пароль(10) против root+пароль (18) ) лучше рут с 18-тизначным паролем
По той простой причине, что username будет проверяться по словарю, что даст меньшее количество вариантов, нежели просто пароль(18)
В описанной ситуации ( username(8)+пароль(10) против root+пароль (18) ) лучше рут с 18-тизначным паролем
По той простой причине, что username будет проверяться по словарю, что даст меньшее количество вариантов, нежели просто пароль(18)
Весь адекватный мир уже давно перешел на авторизацию по ключам. Ну или почти весь. Поэтому перебор логин/пароль уже не особо актуальны. Ну и уж если совсем параноя — snort поможет.
А вообще — если уж говорить о взломе, то взломать можно все, было бы желание. Не существует не взламываемых защит.
В конце концов ректальный термо-дешифратор еще никто не отменял.
А вообще — если уж говорить о взломе, то взломать можно все, было бы желание. Не существует не взламываемых защит.
Как посоветуете хранить закрытый ключ? в архиве под _паролем_?
В случае, если нужен «портативный» коннект, т.е. с чужого компьютера а ключи на флешке как быть?
В случае, если нужен «портативный» коннект, т.е. с чужого компьютера а ключи на флешке как быть?
Одноразовые ключи. Хотя с чужого компьютера в любом случае небезопасно заходить.
Как хотите — так и храните. Думаю с какого попало компьютера вы на сервера не ходите, поэтому флэшку можо и воткнуть с чужой компьютер.
Ну а если всетаки ходите, то тут уже ничего не поможет — скомпроментировать сервер вы можете в любой момент.
В конце концов вас могут поймать, привязать к стулу и сказать «Заходи», приставив дуло танка к голове. Тут уже никакие пароли и безопасности не помогут.
Ну а если всетаки ходите, то тут уже ничего не поможет — скомпроментировать сервер вы можете в любой момент.
В конце концов вас могут поймать, привязать к стулу и сказать «Заходи», приставив дуло танка к голове. Тут уже никакие пароли и безопасности не помогут.
ну почему, вот я например настроил хренение ключа в etoken-е. Даже если кейлоггером перехватят пароль на токен — ничего страшного — токен-то я с собой унесу.
Правда недобно — надо ставить дрова на токен и вводить доп. пароль.
Правда недобно — надо ставить дрова на токен и вводить доп. пароль.
Отлично! Только это никак не умаляет возможность привязывания Вас к стулу вместе с вашим токеном.
Вообще трэд начался с вопроса о хождении по серверам под рутом. Плохо это или хорошо — дело личное. По мне так для начала нужно определиться с моделью угроз, а уже на основании этой модели рисовать схему защиты, а попадет туда рут, Администратор, sudo/su — это уже частности.
Да, я согласен, что нужно обеспечивать какой-то адекватный базовый уровень безопасности, но если меня захотят сломать — меня сломают, и ничто меня не спасет — ти токены, ни ключи, ни мегабайтные пароли. В конце концов охотятся не за доступом, а за информацией. Которую и без паролей можно взять, если конечно на томах шифрование не включено (а включено далеко не у всех, я бы сказал даже, что у единиц, в сравнении с количеством серверов на планете).
Поэтому я воспринимаю данный топ, как некий базис для начинающих, этакие простые истинны, на которые стоит обратить внимание.
Вообще трэд начался с вопроса о хождении по серверам под рутом. Плохо это или хорошо — дело личное. По мне так для начала нужно определиться с моделью угроз, а уже на основании этой модели рисовать схему защиты, а попадет туда рут, Администратор, sudo/su — это уже частности.
Да, я согласен, что нужно обеспечивать какой-то адекватный базовый уровень безопасности, но если меня захотят сломать — меня сломают, и ничто меня не спасет — ти токены, ни ключи, ни мегабайтные пароли. В конце концов охотятся не за доступом, а за информацией. Которую и без паролей можно взять, если конечно на томах шифрование не включено (а включено далеко не у всех, я бы сказал даже, что у единиц, в сравнении с количеством серверов на планете).
Поэтому я воспринимаю данный топ, как некий базис для начинающих, этакие простые истинны, на которые стоит обратить внимание.
www.opennet.ru/man.shtml?topic=ssh-keygen&category=1&russian=0
Угадайте второй вопрос команды ssh-keygen без доп. опций.
Архив — можно, но не полезно: ключи маленькие.
Угадайте второй вопрос команды ssh-keygen без доп. опций.
Архив — можно, но не полезно: ключи маленькие.
Закрытый ключ, кстати говоря, в файле шифруется с кодовой фразой. Так что архив с паролем бесполезен совершенно, ибо он уже есть.
Как вариант отключение логина по ssh от рута все же дает гемор взломщику, а именно вот какой:
взломав акк. обычного юзера он имеет доступ к ограниченному кол-ву файлов и команд, поэтому он конечно может нагадить пользователю, которого взломал, но не всему серваку вцелом, а чтобы получить доступ к su (чтобы нагадить на сервере вцелом) ему все равно придется взламывать пароль от рута, но уже от лица взломанного им пользователя, тобишь все равно взломщику дополнительный гемор.
но соглашусь, 18символьный пароль от рута тоже вещь :)
взломав акк. обычного юзера он имеет доступ к ограниченному кол-ву файлов и команд, поэтому он конечно может нагадить пользователю, которого взломал, но не всему серваку вцелом, а чтобы получить доступ к su (чтобы нагадить на сервере вцелом) ему все равно придется взламывать пароль от рута, но уже от лица взломанного им пользователя, тобишь все равно взломщику дополнительный гемор.
но соглашусь, 18символьный пароль от рута тоже вещь :)
А дальше у нас замечательная команда sudo, которая позволяет делать очень много.
Кстати, комбинация 9 символов root'а и 9 символов username'а хуже, чем 18 символов root'а, так как 9+9 ломается по-очереди, а 18 нужно брутить целиком.
Кстати, комбинация 9 символов root'а и 9 символов username'а хуже, чем 18 символов root'а, так как 9+9 ломается по-очереди, а 18 нужно брутить целиком.
как это — по-очереди?
при логине в *nix нет разницы в сообщениях об ошибке логина при неправильном логине или пароле
тут фокус в другом — можно «случайно» узнать содержимое /etc/passwd и оттуда получить всех пользователей
при логине в *nix нет разницы в сообщениях об ошибке логина при неправильном логине или пароле
тут фокус в другом — можно «случайно» узнать содержимое /etc/passwd и оттуда получить всех пользователей
Объясняю, почему «по-очереди». Сначала вы перебираете 9 паролей пользователя и получаете подтверждение об успешном логине, а потом (уже точно зная, что это правильный пароль, спокойно подбираете пароль root'а).
Получается сложность (если в пароле разрешено A символов) A9+A9, что в триллионы раз меньше A18 при сколь-либо приличном A.
Есть ещё проблема пользователя, но пользователь может получить who, last и т.д., не говоря уже про /etc/passwd, так что ему придётся сделать A9+A9+A9 переборов, что опять же, много меньше даже A10, не говоря уже про A11 паролей.
Получается сложность (если в пароле разрешено A символов) A9+A9, что в триллионы раз меньше A18 при сколь-либо приличном A.
Есть ещё проблема пользователя, но пользователь может получить who, last и т.д., не говоря уже про /etc/passwd, так что ему придётся сделать A9+A9+A9 переборов, что опять же, много меньше даже A10, не говоря уже про A11 паролей.
А откуда вы знаете логин пользователя?
cat /etc/passwd, who, last.
Ваш капитан
Ваш капитан
О мой капитан, я преклоняюсь перед вашей мудростью, но вы ведь должны знать имя пользователя до того, как залогинетесь от этого пользователя? Это же не root который везде root.
См выше — перебор имени пользователя проще, чем такого же количества символов, дописанных к паролю рута.
поменять имя root'a на другое — тоже не велика задача :)
И, кстати, все виндовые инструкции таки одним из пунктов советуют переименовывать Administrator-a. А вот юниксовые root-a переименовывать не советуют, ибо есть куча кривого софта, который ориентируется не на UID, а на имя. Что само по себе очень хреново. Но тоже решается.
Создается юзер типа 'superadmin' с UID=0, а root закрывается вообще везде. И овцы сыты и волки целы и пастухи обкурены.
И, кстати, все виндовые инструкции таки одним из пунктов советуют переименовывать Administrator-a. А вот юниксовые root-a переименовывать не советуют, ибо есть куча кривого софта, который ориентируется не на UID, а на имя. Что само по себе очень хреново. Но тоже решается.
Создается юзер типа 'superadmin' с UID=0, а root закрывается вообще везде. И овцы сыты и волки целы и пастухи обкурены.
sudo на защищенном сервере?! Это вообще как? Данная комманда должна сноситься сразу после установки пароля для root.
P.S. Доступ по ssh для root все же лучше закрывать по двум причинам:
1. Если пароль сложный (а он должен быть сложным), то вломщику придется ломать голову еще и над эскалацией привилегий (а т.к. компиляторов на сервере по идее быть не должно и все доступные на запись пользователю папки должны быть смонтированы с noexec, просто так запустить сплойт или локальный переборщик будет проблематично). Плюс, как уже говорилось, root — это заранее известный взломщику логин. Если имена пользователей не словарные, то уже поиск логинов будет нетривиальной задачей.
2. Из-за того, что для перехода к root все будут вынужнены использовать su, получаем дополнительные подробности в логах: не просто факт захода рутом, а кто именно им заходил.
P.S. Доступ по ssh для root все же лучше закрывать по двум причинам:
1. Если пароль сложный (а он должен быть сложным), то вломщику придется ломать голову еще и над эскалацией привилегий (а т.к. компиляторов на сервере по идее быть не должно и все доступные на запись пользователю папки должны быть смонтированы с noexec, просто так запустить сплойт или локальный переборщик будет проблематично). Плюс, как уже говорилось, root — это заранее известный взломщику логин. Если имена пользователей не словарные, то уже поиск логинов будет нетривиальной задачей.
2. Из-за того, что для перехода к root все будут вынужнены использовать su, получаем дополнительные подробности в логах: не просто факт захода рутом, а кто именно им заходил.
Ну и чтобы взломщикам вообще жизнь малиной не казалась, настраиваем syslog на зеркалирование логов на отдельный, недоступный для простых смертных, сервер, на котором вообще закрываем все, что только можно, и ставим совсем драконовские пароли.
И чем вам sudo не угодил?
Данная комманда должна сноситься сразу после установки пароля для root.Откройте для себя /etc/sudoers. sudo очень полезен, если надо кому-то дать возможность выполнить от рута конкретный скрипт.
Или sudo passwd выполнить… Можете меня переубеждать, но я уверен, что у пользователя не должно быть прав рута, даже временных. Кроме того, сервер нужно настраивать так, чтобы у пользователя и потребностей в этом особых не возникало. Если же такое вдруг потребовалось, то пользователь должен обратиться к админу, который, после ревизии скрипта, либо выполнит его сам, либо, поместив в недоступную для записи пользователями директорию, пропишет его в crontab.
P.S. Если вам кажется все это слишком муторным или сложным, спешу напомнить одно мудрое высказывание на тему: «Безопасность — это процесс, а не продукт (результат)».
P.S. Если вам кажется все это слишком муторным или сложным, спешу напомнить одно мудрое высказывание на тему: «Безопасность — это процесс, а не продукт (результат)».
Судя по всему, вы никогда в компаниях где больше одного админа, не работали, и пользователям права на, скажем, выключение их же собственных машин не выдавали.
>Или sudo passwd выполнить…
Нет, вы всё-таки откройте для себя /etc/sudoers.
Hint: не обязательно давать пользователю права на выполнение всех программ от рута, можно перечислить конкретные.
Нет, вы всё-таки откройте для себя /etc/sudoers.
Hint: не обязательно давать пользователю права на выполнение всех программ от рута, можно перечислить конкретные.
> Данная комманда должна сноситься сразу после установки пароля для root.
кхм. а не могли бы вы пояснить причины столь безаппеляционного заявления?!
кхм. а не могли бы вы пояснить причины столь безаппеляционного заявления?!
Уменьшение кол-ва доступных пользователю команд, с установленным setuid bit. Кроме того, нет /etc/sudoers, нет стремления получить к нему какой-либо доступ у злоумышленника.
Кроме того, в некоторых системах, после использования sudo, повторный вызов команды в течение некоторого времени не затребует пароль рута (создается временный файл, указывающий на то, что недавно был успешно выполнен подъем привилегий). Это конечно можно отключить, но если забыть это сделать, то можно себе представить какая это потенциальная дыра.
Кроме того, в некоторых системах, после использования sudo, повторный вызов команды в течение некоторого времени не затребует пароль рута (создается временный файл, указывающий на то, что недавно был успешно выполнен подъем привилегий). Это конечно можно отключить, но если забыть это сделать, то можно себе представить какая это потенциальная дыра.
простите, а какое отношение sudo имеет к количеству установленных программ с suid/sgid?!
а если забыть сделать стойкий пароль рута его тоже можно взломать.
а если забыть ключи от дома его могут обворовать. ну и так далее.
в общем как-то я не понял почему вам не нравится sudo.
а если забыть сделать стойкий пароль рута его тоже можно взломать.
а если забыть ключи от дома его могут обворовать. ну и так далее.
в общем как-то я не понял почему вам не нравится sudo.
Вы уже передергиваете. Кроме того, что удаление sudo, которое по-сути не нужно, если данные на сервере организованы правильно, уменьшает кол-во доступных для злоумышленника средств, для поднятия привилегий, это еще и уменьшает кол-во вещей, о которых «можно забыть».
И если уж вы любите афоризмы… Если у вашей двери есть n замков, каждый из которых по одтельности может полностью открыть дверь, шанс, что вы потеряете один из ключей увеличивается соответственно. А если вы еще и даете дубликаты ключей другим людям, шанс, что кто-то их них потеряет ключ, становится еще больше.
И если уж вы любите афоризмы… Если у вашей двери есть n замков, каждый из которых по одтельности может полностью открыть дверь, шанс, что вы потеряете один из ключей увеличивается соответственно. А если вы еще и даете дубликаты ключей другим людям, шанс, что кто-то их них потеряет ключ, становится еще больше.
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 вам не доступны. Весело, да? :)
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 вам не доступны. Весело, да? :)
Это, вообще, нормально и правильно. Если нужно делать резервные копии всех данных, включая те, к которым у оператора не должно быть доступа, то — как?
К примеру, по ssh ключу, где указано command=«path-to-backup-script». Этот скрипт будет делать бэкап куда надо. В случае компрометации ключа взломщик сможет только инициировать архивацию на некоторый сервер, который тоже ещё нужно взломать (ведь не по anonymous FTP же бэкап делать). Частоту/время запуска архивирования можно при желании контролировать в скрипте.
Кончайте придумывать глупые ответы, глупые вопросы придумывать проще. Получайте — как быть с:
А как быть, если названия копируемых файлов меняются, и вписать их в скрипт нельзя?
Если админов много, но с головой — один, то ему при помощи sudo будет удобно делегировать доступ. Особенно, если безголовые часто меняются. sudo — наше всио, если правильно приготовить.
Есть ещё sudo-ldap всякие — тоже неспроста, наверно…
- 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 всякие — тоже неспроста, наверно…
Это шутка, да?) Вы спросили про довольно распространённый случай бэкапов, я конкретно на него ответил. Невозможно сделать просто «безопасную систему», с ней ещё нужно вести себя соотв. образом. Ответа «на отвали» вы вряд ли найдёте.
Про названия файлов — если они меняются, и нет простого способа их задать или ограничить заранее, то, видимо, 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 вообще не в тему, метод авторизации практически ортогонален модели защиты.
В стране макак нужно либо думать как с ними бороться, либо менять глобус :)
Про названия файлов — если они меняются, и нет простого способа их задать или ограничить заранее, то, видимо, 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 вообще не в тему, метод авторизации практически ортогонален модели защиты.
В стране макак нужно либо думать как с ними бороться, либо менять глобус :)
segoon, это не только Вам лично, а в целом о дикуссии — вместо обмена позитивным опытом началось ругание sudo/suid и других механизмов управления доступом, которые плохи тем, что ругающие их просто «ниасилили».
«command=» — спусковой крючок для выполнения команд. Годный, но не гибкий механизм.
sudo — способ делегирования доступа. Мне и моим коллегам это позволяет выборочно повышать привилегии сотрудникам, которые не должны иметь неограниченного (рутового) доступа. Тоже годный, но более сложный/гибкий.
sudo-ldap — тоже тема, но не про авторизацию. Не pam-ldap, и не nss-ldap.
«command=» — спусковой крючок для выполнения команд. Годный, но не гибкий механизм.
sudo — способ делегирования доступа. Мне и моим коллегам это позволяет выборочно повышать привилегии сотрудникам, которые не должны иметь неограниченного (рутового) доступа. Тоже годный, но более сложный/гибкий.
sudo-ldap — тоже тема, но не про авторизацию. Не pam-ldap, и не nss-ldap.
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 не гибок — я говорю, что он небезопасен.
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 не гибок — я говорю, что он небезопасен.
Для начала хватит, но я не начинающий. Если подскажете способ делегировать доступ лучше или так же, как sudo, но не имеющий перечисленных недостатков — буду благодарен. Не подскажете — буду и дальше рисковать, и пользоваться sudo. Не привыкать, каждый день рискую: едой можно подавиться, водой захлебнуться :)
Перечисленных недостатков кроме «негибко» я в ваших постах не нашёл. Я знаком с LDAP только в теории, так что «тот же sudo-ldap, только лучше» я вам так с ходу не скажу. Для моих целей authorized_keys с command было достаточно. Для бэкапов решение уже предложил, аргументов против не услышал.
Давайте упростим тему — сделаем вид, что про LDAP я не говорил. Он просто добавляет гибкости к sudo, у которой этой гибкости уже и так много.
Для моих целей гибкости authorized_keys оказалось недостаточно, и этого аргумента мне достаточно. Про бэкапы — первый вопрос из трёх заданных, и только для него был получен ответ. А, как я уже говорил, у меня в запасе есть ещё много вопросов, ответом на которые является «sudo», а не «authorized_keys». И не такие уж эти вопросы глупые — все возникли по ходу жизни, а не «от балды».
Для моих целей гибкости authorized_keys оказалось недостаточно, и этого аргумента мне достаточно. Про бэкапы — первый вопрос из трёх заданных, и только для него был получен ответ. А, как я уже говорил, у меня в запасе есть ещё много вопросов, ответом на которые является «sudo», а не «authorized_keys». И не такие уж эти вопросы глупые — все возникли по ходу жизни, а не «от балды».
Для tcpdump и ping ответ практически такой же, догадайтесь сами. Хотя зачем предоставлять возможность флудить недоадмину, для меня остаётся загадкой.
Последний раз спрашиваю — в чём заключается гибкость sudo, которой невозможно добиться с пом. ssh keys? Именно приниципиальной разницы, ибо это всё-таки разные вещи.
Последний раз спрашиваю — в чём заключается гибкость sudo, которой невозможно добиться с пом. ssh keys? Именно приниципиальной разницы, ибо это всё-таки разные вещи.
Флудить нужно для оценки качества линии связи. Операция выполняется после ремонтно-восстановительных работ самым низкооплачиваемым персоналом, часто — с антисоциальными наклонностями. Стандартными пингами выявлять потери менее 1% не очень удобно.
На вопрос «в чём именно принципиальная разница всё-таки разных вещей» я ответить затрудняюсь. Извините.
На вопрос «в чём именно принципиальная разница всё-таки разных вещей» я ответить затрудняюсь. Извините.
например, Zabbix-агент крутится под непривелигерованным пользователем. Когда ему нужно бывает (бывает такое) выполнить специфическую команду, он делает её через sudo, и больше ничего сделать не может
ssh тут опаснее — например, приватный ключ пришлось бы хранить в открытом виде (чтобы агент мог его использовать)
ssh тут опаснее — например, приватный ключ пришлось бы хранить в открытом виде (чтобы агент мог его использовать)
Приватный ключ имеет права 0600. В чём опасность?
через sudo всё равно безопаснее. Никакого ключа вообще нет.
Кроме того, для работы с sudo не нужен ssh вообще — это повышает надёжность
Кроме того, для работы с sudo не нужен ssh вообще — это повышает надёжность
habrahabr.ru/blogs/sysadm/112908/?reply_to=3624500#comment_3621721 и коментарий ниже со списком уязвимостей за прошлый год в одном дистрибутиве, если теория вас не впечатляет. Забавно, что некоторые отказываются от sudo в пользу ssh по соображениям безопасности, вы же наоборот, но по тем же причинам :)
Это вообще правильно. Наоборот, su на защищённом сервере — «это как?».
И в sudoers мы разным пользователям даём разные возможности в зависимости от степени доверия и т. д. Мог бы он ещё в зависимости от сложности пароля давать разные возможности…
И в sudoers мы разным пользователям даём разные возможности в зависимости от степени доверия и т. д. Мог бы он ещё в зависимости от сложности пароля давать разные возможности…
а чтобы получить доступ к su (чтобы нагадить на сервере вцелом) ему все равно придется взламывать пароль от рута, но уже от лица взломанного им пользователя
не забывайте про локальные уязвимости ядра — редко на серверах стоят свежие ядра, а на старых получить повышение привилегий довольно несложно, если повезет.
более того, чаще всего рутовый аккаунт — не предмет для взлома: например, рассылать спам можно и без него.
>… например, рассылать спам можно и без него...
Если каталоги, доступные пользователю на запись, смонтированы с noexec, а на сервере не стоит собственного настроенного мылера, то рассылать спам без рута будет проблематично.
Если каталоги, доступные пользователю на запись, смонтированы с noexec, а на сервере не стоит собственного настроенного мылера, то рассылать спам без рута будет проблематично.
Каким образом noexec помешает запустить скрипт а-ля php/python/perl из командной строки? noexec всего лишь запрещает установку +x бита, не больше.
Не говоря уж о штатном telnet, с помощью которого можно также можно отправить почту хоть куда ;)
noexec больше направлен не на защите от скриптов, а на защиту от бинарников, коих немало используется для повышения привилегий.
Ошибаетесь, chmod разрешён, а запрещён execve(2) и некоторые фишки в программах типа /usr/lib/ld.so /path-to-mount-noexec/binary (в новых версиях лоадера).
Вы серьёзно думаете, что кому-то в здравом уме придёт в голову брутить пароли? Максимум — словарь. Прогнал словарик — убедился, что ничего не получилось, и дальше попытки входа через парадную дверь прекращаются.
Разумный довод в пользу запрета входа рутом заключается в том, что это поможет потом по логам определить, кто из администраторов ходил на сервер и что-то сломал.
Разумный довод в пользу запрета входа рутом заключается в том, что это поможет потом по логам определить, кто из администраторов ходил на сервер и что-то сломал.
Да, в ситуации с несколькими админами — это первый аргумент в пользу «нет руту», который я слышу.
Если сильно нужен именно этот сервер, а не очередной хост для спама etc, то брутят
Пароль в 6 буков, 10 запросов в секунду. Умножаем. Получаем 357 суток. Пароль в 8 буков, 1000 запросов в секунду — 2000 лет.
Помнится, не так давно был тут топик, где скорость перебора была на несколько порядков выше. и если поделить ваши 2000 лет на 40000 (в статье же 400к/сек), то получится всего лишь 18.25 дней на 8-значный пароль. не такой уж и нереальный срок.
Хотя при таком раскладе есть вероятность, что канал накроется быстрее, чем удастся поборать пароль.
Хотя при таком раскладе есть вероятность, что канал накроется быстрее, чем удастся поборать пароль.
А хорошая система после ошибки при вводе пароля сделает таймаут на несколько секунд.
и мы получим систему, которую даже ddosить легко и просто. Достаточно раз в несколько секунд пытаться на неё залогиниться из разных мест, и всё — админ не достучится.
Да, я так думаю :) Словари бывают разных размеров, к тому же словарь — это то, от чего можно отталкиваться, добавляя к слову в разных местах произвольные символы, пермутировать его, менять регистр и пр. Если пароль можно будет подобрать через пару месяцев — замечательно (для взломщика)! Мало кто так часто меняет пароли.
Таким образом мы увеличиваем количество преград самому себе, и не более того.
Да, в большинстве серверных дистрибутивов хождение под рутом выключено. Но это сделано как защита от администраторов-идиотов, ставящих пароль рута 1234 «на время установки».
Да, в большинстве серверных дистрибутивов хождение под рутом выключено. Но это сделано как защита от администраторов-идиотов, ставящих пароль рута 1234 «на время установки».
Не будем тыкать пальцами, но… сам такой администратор :) Потому руту разрешаю ходить только по сертификату.
А вообще, IMHO, спор сродни: «что лучше — мыть руки перед обедом или пользоваться вилкой?»))) Кому как удобнее.
А вообще, IMHO, спор сродни: «что лучше — мыть руки перед обедом или пользоваться вилкой?»))) Кому как удобнее.
Рутовые права нужны в неделю раза два. Можно и через su привилегии поднять. Пальцы не отвалятся.
Если не можете понять зачем в умных книжках вам настойчиво рекомендуют не работать под рутом без острой на то необходимости… ну просто примите на веру. Понимание приходит с возрастом… правда к каждому в разное время =).
Если не можете понять зачем в умных книжках вам настойчиво рекомендуют не работать под рутом без острой на то необходимости… ну просто примите на веру. Понимание приходит с возрастом… правда к каждому в разное время =).
Вы, молодой человек, сначала молоко с губ сотрите) Я вам не про книжки, а про реальную эксплуатацию говорю.
А суть в том, что на серверах не работают. На них заходят раз в N месяцев обновить софт, ну может еще что-то доставить. Всё, остальное время нормально настроенным сервером управляет автопилот. Обычных «пользователей» там вообще нет, есть рут и есть псевдоюзеры для учета ресурсов и разделения прав. Ну, у хостеров еще иногда может зайти админ клиента и что-то поковырять под своими урезанными правами, но на выделенных серверах никому кроме рута логин в систему вообще не разрешен. Просто некому и нечего разрешать.
И тем не менее, многие настойчиво рекомендуют таки завести дополнительного пользователя и авторизовываться в два шага. При этом не приводя ни одного примера — зачем оно надо.
А суть в том, что на серверах не работают. На них заходят раз в N месяцев обновить софт, ну может еще что-то доставить. Всё, остальное время нормально настроенным сервером управляет автопилот. Обычных «пользователей» там вообще нет, есть рут и есть псевдоюзеры для учета ресурсов и разделения прав. Ну, у хостеров еще иногда может зайти админ клиента и что-то поковырять под своими урезанными правами, но на выделенных серверах никому кроме рута логин в систему вообще не разрешен. Просто некому и нечего разрешать.
И тем не менее, многие настойчиво рекомендуют таки завести дополнительного пользователя и авторизовываться в два шага. При этом не приводя ни одного примера — зачем оно надо.
«Ой, я не в том окошке нажала» — сказала одна девушка перед тем, как её уволили за то, что она обнулила лицевые счета всех абонентов… А ведь девушке говорили — «Никогда, слышишь — НИКОГДА не оставляй открытой консольку базы данных, которую ты администрируешь».
ОК, юзер 'superadmin' с UID=0 удовлетворяет задаче? И не надо лишних телодвижений админу (зайти под лимитированным юзеров, а потом сделать su/sudo) и прячет админский юзернейм от шаловливых взломщиков.
По возможности следует избегать работать из под root-а. Если вам постоянно нужны рутовые права, то это говорит скорее о вашей некомпетентности, даже если аккаунт у вас с сертификатом и зубодробительным паролем.
Для большинства операций не требуется рутовых прав. Поэтому логиниться под ним не надо. И поэтому поднятие прав через su не назойливая хрень (вроде UAC в винде), а такой же инструмент, который без необходимости трогать не надо. После некоторых неосторожных действий результат может быть оооочень плачевным.
З.Ы. Дабы никого не оскорблять скажу только одну фразу: «Тут вам не виндовс».
Для большинства операций не требуется рутовых прав. Поэтому логиниться под ним не надо. И поэтому поднятие прав через su не назойливая хрень (вроде UAC в винде), а такой же инструмент, который без необходимости трогать не надо. После некоторых неосторожных действий результат может быть оооочень плачевным.
З.Ы. Дабы никого не оскорблять скажу только одну фразу: «Тут вам не виндовс».
Извините, у меня под управлением десяток серверов, а операций я совершаю ровно три: апдейт пакета, правка конфига, рестарт сервиса.
Для каких из них не нужны права рута?
Для каких из них не нужны права рута?
Большинство _каких_ операций? На моём ноуте? да.
На сервера же я хожу как раз с целью администрирования, так что было бы странным, если бы я туда ходил без прав администрирования.
Хотя да, есть некоторые сервера (вроде хранилища git-репозитория) — да, я там пользователь и хожу под пользовательским аккаунтом.
На сервера же я хожу как раз с целью администрирования, так что было бы странным, если бы я туда ходил без прав администрирования.
Хотя да, есть некоторые сервера (вроде хранилища git-репозитория) — да, я там пользователь и хожу под пользовательским аккаунтом.
>Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они крайне редко нужны)
Так никогда или крайне редко?
Так никогда или крайне редко?
незнаю как с другими, а для линуксов МОРЕ документации существует именно в виде HOWTO —
пошаговых инструкций часто без особых объяснений.
пошаговых инструкций часто без особых объяснений.
Все нормальные howto (а не посты «как сделать high-avability кластер из Ubuntu Lynx для начинающих») дают более чем теоретического обоснования тому, что делает(ся).
Ну это же не значит, что следуя им, нужно отключать мозг, правда?
А вдруг там rm -rf /* случайно промелькнет, тоже скопипастите и в консоль? (:
А вдруг там rm -rf /* случайно промелькнет, тоже скопипастите и в консоль? (:
это не отменяет возможности узнать а как работает то что предлагает автор HOWTO.
> Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
В большинстве адекватных линуксов стоит PermitRooLogin = no, либо как вариант — не указано, что равносильно.
>(fail2ban, например)
может быть ресурсозатратно, проще написать 2 строки в iptables
В большинстве адекватных линуксов стоит PermitRooLogin = no, либо как вариант — не указано, что равносильно.
>(fail2ban, например)
может быть ресурсозатратно, проще написать 2 строки в iptables
Какие 2 строки?
Например ограничить кол-во подключений к ssh
fail2ban банит не только после неудачных попыток в ssh, но и фтп, и даже в апаче и exim.
iptables все это умеет?
iptables все это умеет?
iptables умеет ограничивать кол-во соединений в секунду/минуту/… и устанавливать допустимый burst. Например — с одного IP не более 10 соединений в первую минуту, не более 1 в следующие сутки. Брутфорсерам это почему-то не нравится, а мне работать не мешает.
В сислог записать таких брутфорсеров с правильным префиксом, iptables тоже умеют.
В сислог записать таких брутфорсеров с правильным префиксом, iptables тоже умеют.
Один момент: надо быть очень аккуратным при задании действий обнаружения DoS/bruteforce'а — ведь злоумышленник может этим воспользоваться и от ip жертвы начать лихорадочно коннектиться к серверу. Если правила на уровне «более 100 TCP SYN в секунду — IP в бан на минуту/час», то легко обрезать доступ к серверу для честных клиентов.
Спорно. Если честный и злоумышленник брутфорсят с одного IP, то должен быть кто-то ответственный за использование этого IP.
Если честный — юзер, а злоумышленник — вирус на компе юзера, то виноват всё равно юзер.
Если оба за прячутся за NAT — будут интересные диалоги с тем, кто делает NAT — вероятно, провайдером.
Если как-то хитро злоумышленнику удалось воспользоваться IP честного — виноват честный (хотя он же и пострадал): не обеспечил свою безопасность.
Могут быть ситуации с сознательным искажением src IP, но где профит?
Если честный — юзер, а злоумышленник — вирус на компе юзера, то виноват всё равно юзер.
Если оба за прячутся за NAT — будут интересные диалоги с тем, кто делает NAT — вероятно, провайдером.
Если как-то хитро злоумышленнику удалось воспользоваться IP честного — виноват честный (хотя он же и пострадал): не обеспечил свою безопасность.
Могут быть ситуации с сознательным искажением src IP, но где профит?
Я же сказал — атака на клиентов.
А я спросил — а профит? Если ваш сервер атакуют, чтобы лишить клиентов, значит:
В этой ситуации нужно:
- они у вас есть
- их у вас много
- поэтому вам завидуют
В этой ситуации нужно:
- гордиться собой и важничать
- подумать об отделении услуг от безопасности — погрузить сервер в DMZ, безопасность которой обеспечивается уже не подручными средствами
Значит у нас с вами разное отношение к клиентам, если вы атаки против них вы за уязвимость не считаете.
Есть такая штука — SLA. Что там клиент подпишет и оплатит — то будем выполнять.
С сгенерированными паролями нужно быть аккуратно, символ может или отобразить переменную или быть проглочен консолью, помню историю, когда при установке пароля в нём оказалась переменная с PID текущего процесса.
Еще есть очень удобная штука — csf + lfd — автоматически обнаруживает брутфорс, при флуде тоже помогает.
> Как правило, достаточно оставить открытыми порты для ssh + 80 и 443 для веб-сервера + порт для мониторинга. Собтсвенно все.
А может достаточно не открывать остальные порты? А если фильтровать – так еще неплохо бы резать по типичным для nmap'а флагам на TCP.
> FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.
S/FTP вполне ок. Про scp надо не забыть зарезать юзеру возможность заходить непосредственно на шелл (если она ему не нужна).
А может достаточно не открывать остальные порты? А если фильтровать – так еще неплохо бы резать по типичным для nmap'а флагам на TCP.
> FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.
S/FTP вполне ок. Про scp надо не забыть зарезать юзеру возможность заходить непосредственно на шелл (если она ему не нужна).
> Никогда! не следуйте инструкциям с интернета
А ваша статья не в интернете? Чем она лучше остальных? :)
А ваша статья не в интернете? Чем она лучше остальных? :)
Вот к чему приводит вырывание цитаты из текста. Полная мысль звучит так:
Никогда не следуйте инструкциям с интернета без полного понимания того, что произойдет от совершаемых действий.
Никогда не следуйте инструкциям с интернета без полного понимания того, что произойдет от совершаемых действий.
Согласен, но ведь вы сделали акцент на «Никогда! не следуйте инструкциям с интернета», дальше в предложении много уточнений и поэтому от взгляда ускользает продолжение.
PS я не холивара ради пишу, это действительно сразу бросается в глаза. В конце концов это ИМХО.
PS я не холивара ради пишу, это действительно сразу бросается в глаза. В конце концов это ИМХО.
Может лучше сказать так?
«Никогда не следуйте инструкциям без полного понимания того, что произойдет от совершаемых действий».
«Никогда не следуйте инструкциям без полного понимания того, что произойдет от совершаемых действий».
Однозначно, что предложенные автором рецепты не панацея, однако выполнение этих не сложных инструкций — это первый шаг к безопасности сервера, что само по себе уже плюс.
Иногда пренебрежение элементарными правилами может привести к нехорошим результатам, это как старая поговорка про бэкапы — «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают».
Иногда пренебрежение элементарными правилами может привести к нехорошим результатам, это как старая поговорка про бэкапы — «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают».
Правильная поговорка: админы делятся на два типа, те кто делает бэкапы и те которые УЖЕ делают.
Это как раз ошибочная
Суть поговорки «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают» в том, что многие админы ленятся делать бекапы до того момента, когда произойдёт потеря данных. Поговорка иронизирует по тому поводу, что все админы или еще не делают бекапы, т.к. не было потерянных данных, или уже делают, так как теряли данные и больше не хотят попасть в проблему, что была раньше.
в nginx вывод версии сервера отключается строчкой
server_tokens off;
server_tokens off;
pwgen тоже неплохо пароли придумывает
«выстроить цепочку из портов, в которые нужно стучаться»
Постучаться в один порт один раз, а потом в другой — трижды :) Хитрая такая аутентификация :)
Постучаться в один порт один раз, а потом в другой — трижды :) Хитрая такая аутентификация :)
Автор забыл самое главное — резервное копирование.
Далее. Если нужен доступ по FTP из винды, используйте клиент, который умеет шифровать пароли (например, FlashFXP).
У меня некоторое время назад в Far-е был заведен десяток клиентских FTP-сайтов, так вирус прошелся по всем и куда только на этих сайтах не добавил себя.
Далее. Если нужен доступ по FTP из винды, используйте клиент, который умеет шифровать пароли (например, FlashFXP).
У меня некоторое время назад в Far-е был заведен десяток клиентских FTP-сайтов, так вирус прошелся по всем и куда только на этих сайтах не добавил себя.
Я специально не писал о бэкапах, т.к. топик все же о безопасности, а не от полной настройке веб-сервера.
Если ваш фтп клиент умеет шифровать пароль, то хитрый вирус скорее всего тоже сможет его расшифровать, посему — пароли от важных аккаунтов лучше не хранить в фтп клиенте. совсем.
В любом hex-редакторе меняете в бинарнике любимого ftp клиента пару букв в том месте, где он хранит пароли. В ветке реестра, к примеру. Вирусы перебирать не будут. Нет смысла заморачиваться ради 0.01% фриков с hex-редактором.
Давно уже подумываю о доступе к хостингам по FTP из локальной изолированной виртуальной машины, на которой кроме ftp-клиента запускаться ничего не будет.
При доступе из винды сказанное мной от протокола не зависит.
Только не советуйте не сохранять пароли в программах, у меня их, извините, только навскидку штук 50.
Только не советуйте не сохранять пароли в программах, у меня их, извините, только навскидку штук 50.
не сохраняйте пароли в программах! никогда!
сохраняйте их в специальных паролехранилках. желательно кроссплатформенных типа keepass/keepassx
сохраняйте их в специальных паролехранилках. желательно кроссплатформенных типа keepass/keepassx
вы, очевидно, забыли о TLS
у SFTP сервера не очень удобно делать chroot, SCP же ни на, что кроме передачи файлов с известными путями не годится
а SSH вообще нифига не аналог простой передачи файлов
у SFTP сервера не очень удобно делать chroot, SCP же ни на, что кроме передачи файлов с известными путями не годится
а SSH вообще нифига не аналог простой передачи файлов
Капитан, перелогиньтесь.
Для кого эти рекомендации? О том, что вы тут написали, не знают, наверное, только в младшей группе детского сада.
Для кого эти рекомендации? О том, что вы тут написали, не знают, наверное, только в младшей группе детского сада.
согласен, а многие ли пользуются этими рекомендациями, как думаете?
Если обнаружится серьезная уязвимость в apache, или даже joomla, времени на тестирование особо не будет. Особенно если ресурс посещаемый.
А так действительно, пожалуй стоит добавить, что в обычном режиме обновлять на продакшне сразу не стоит.
А так действительно, пожалуй стоит добавить, что в обычном режиме обновлять на продакшне сразу не стоит.
Как правило, обновления безопасности ничего не ломают из функционала, так что обновляться можно довольно смело.
Вот при обновлении софта (например, потребовался новый php) тестирование обязательно.
Вот при обновлении софта (например, потребовался новый php) тестирование обязательно.
После выполнения данного апдейта безопасности на сервере от пользователя root, вероятность у злоумышленника залогиниться на ваш сервер заметно снижается:
echo «Security update» | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'
echo «Security update» | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'
Странно. Запустил эту команду, теперь не могу залогиниться на удалённый сервер. ПОМОГИТЕ!
Выполнив эту команду, я сразу почувствовал, что еще больше обезопасил свой сервер, большое спасибо!
Патч Бармина всегда помогает мне очистить сервер от возможных уязвимостей
отличная штука!
теперь у меня полностью безопасный сервер и есть много времени для секса!
теперь у меня полностью безопасный сервер и есть много времени для секса!
может кто знает, как банить не через iptables, а ещё ниже, чтобы даже не создавалась сессия/подключение?
Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров.
Золотые слова…
Золотые слова…
Еще пара вещей:
— настраиваю fail2ban для любителей поискать phpmyadmin и прочие скрипты
— доступ к утилитам (например мое wiki и тот же phpmyadmin) только по https
— доступ к админкам закрываю паролем при помощи .htaccess
— настраиваю fail2ban для любителей поискать phpmyadmin и прочие скрипты
— доступ к утилитам (например мое wiki и тот же phpmyadmin) только по https
— доступ к админкам закрываю паролем при помощи .htaccess
Есть проблема в ПХП с exec/system и т.д., на них open_basedir не действует. Если даже нельзя сделать file_get_contents('/etc/passwd') из-за open_basedir, то всё равно можно сделать passthru('cat /etc/passwd'). Или почитать файлы из другого виртуалхоста: passthru('path_to_other_documentroot/sites/default/settings.php'). Поэтому взлом одного сайта может означать взлом и всех остальных.
Решение: отключать все функции типа exec в php.ini. Если избранным сайтам всё-таки нужна какая-то из этих функций, то нужно ставить suhosin (http://www.hardened-php.net/suhosin/).
Еще мы на новый веб-сервер ставили mpm-itk.sesse.net/. Он позволяет выполнять обработку запросов апачем под разными юзерами (в зависимости от каталога). Тогда даже с наличием прав на exec или cgi-шки (они тоже редко, но нужны) нельзя было достучаться до соседних хостов (но можно будет достучатся до /etc/passwd, можно еще добавить chroot-а для апача).
Решение: отключать все функции типа exec в php.ini. Если избранным сайтам всё-таки нужна какая-то из этих функций, то нужно ставить suhosin (http://www.hardened-php.net/suhosin/).
Еще мы на новый веб-сервер ставили mpm-itk.sesse.net/. Он позволяет выполнять обработку запросов апачем под разными юзерами (в зависимости от каталога). Тогда даже с наличием прав на exec или cgi-шки (они тоже редко, но нужны) нельзя было достучаться до соседних хостов (но можно будет достучатся до /etc/passwd, можно еще добавить chroot-а для апача).
да, совсем запамятовал про disable_functions. спасибо, добавил в топик.
mpm-itk стоит использовать когда нагрузки небольшие, ибо он не такой быстрый.
Если нужен exec в php и на сервере несколько веб-сайтов, то без mpm-itk вообще дырища получается. Ломают один сайт и имеют доступ ко всем другим хостам: exec(«cat /vhosts-root/любой файл»). Есть вариант с safe_mode, но его многие софтины его не поддерживают.
Вариант — статику отдавать через nginx. Но некоторые сайты могут и «статику» отдавать через скрипты (например, drupal при включенном приватном режиме файловой системы).
А разве в таком случае не поможет chroot для вирт.хостов?
>> «Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета»
Отличное начало инструкции в интернете.
Отличное начало инструкции в интернете.
Бугагашечки.
С одной стороны конечно да, а с другой из вступления следует, что для того, чтобы быть компьютерным специалистом — надо быть специалистом по компьютерам, и единственный способ достижения этого статуса — вдумчивое чтение документации. А потом начинается гайд, который является выжимкой из доков и делает их чтение как-бы необязательным. Вот что меня смущает.
> и единственный способ достижения этого статуса — вдумчивое чтение документации.
я видимо что-то пропустил. не подскажете, где там написано что это единственное и достаточное условие?
я видимо что-то пропустил. не подскажете, где там написано что это единственное и достаточное условие?
Вы знаете еще какой нибудь способ обретения «полного понимания того, что произойдет от совершаемых действий (изменения конфигурации)»?
а можно я тоже буду отвечать вопросом на вопрос? (:
зы у меня нигде не написано, что это единственное и достаточное условие. с чего вы это взяли — мне совершенно непонятно.
зы у меня нигде не написано, что это единственное и достаточное условие. с чего вы это взяли — мне совершенно непонятно.
А можно вы при этом будете отвечать на заданные вопросы? Вы, как человек разместивший топик всетаки несете некоторые обязательства перед вашей аудиторией +)
Откуда вы узнали о настройках и параметрах описанных в вашей статье? Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры? Откуда о онх можно узнать?
И да, я не писал о том, что RTFM это «условие» и темболее не называл его достаточным.
Откуда вы узнали о настройках и параметрах описанных в вашей статье? Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры? Откуда о онх можно узнать?
И да, я не писал о том, что RTFM это «условие» и темболее не называл его достаточным.
> Откуда вы узнали о настройках и параметрах описанных в вашей статье?
Читал книжки (в духе вот apache security от o'reilly) с манами и баловался на своих серверах, а потом пытался сотворить нечто подобное на продакшн платформах. Вроде получалось.
> Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры?
Нет. Я вполне мог что-то пропустить по незнанию, что-то по другим причинам.
> Откуда о онх можно узнать?
Вестимо из различной литературы, документации и мастер-классов профессионалов.
Читал книжки (в духе вот apache security от o'reilly) с манами и баловался на своих серверах, а потом пытался сотворить нечто подобное на продакшн платформах. Вроде получалось.
> Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры?
Нет. Я вполне мог что-то пропустить по незнанию, что-то по другим причинам.
> Откуда о онх можно узнать?
Вестимо из различной литературы, документации и мастер-классов профессионалов.
> А потом начинается гайд
А где гайд-то? Лично я вижу просто свод достаточно общих советов. Так что не смущайтесь; документация по-прежнему нужна, и читали Вы её не зря. :)
А где гайд-то? Лично я вижу просто свод достаточно общих советов. Так что не смущайтесь; документация по-прежнему нужна, и читали Вы её не зря. :)
Чем вам parse_ini_file не угодил?
Еще не плохо бы закрыть порт mySQL если не нужно конектится с других серверов, а если нужно то юзеров создавать с привязкой к тому ip c которого будет коннект
Если на сервере есть phpmyadmin, то доступ к неve должен быть по урлу вроде этого:
site.ru:1810/8jksjksidjs9djdks/
И сама папка должна быть защищена паролем через .htaccess.
Так же не стоит забывать про элементарное правило, что сервер не должен светить в инет лишними, т.е. если не надо фтп, отключаем его и убираем с автозагрузки и так с другими сервисами.
Кстати про фтп лучше совсем забыть, для закачки файлов нужно использовать SFTP.
Если на сервере есть phpmyadmin, то доступ к неve должен быть по урлу вроде этого:
site.ru:1810/8jksjksidjs9djdks/
И сама папка должна быть защищена паролем через .htaccess.
Так же не стоит забывать про элементарное правило, что сервер не должен светить в инет лишними, т.е. если не надо фтп, отключаем его и убираем с автозагрузки и так с другими сервисами.
Кстати про фтп лучше совсем забыть, для закачки файлов нужно использовать SFTP.
я вот не смог избавиться от фтп на веб-сервере, т.к. hg умеет заливать обновления на веб-сервер только по FTP…
По ssh. Если используется «порт нокинг», то смысла перевешивать на другой порт уже нет. Более того «порт нокинг» обычно подразумевает простукивание > 1 порта изначально. Защищать один порт простукиванием другого — смысла нет. По поводу обновлений, вполне можно обновления безопасности и в крон поставить.
Если честно, то кроме моря воды в этом тексте ничего нового не увидел. Просто несколько размытых рекомендаций и не более…
> Запрещаем логин по паролю и разрешаем ходить только по сертификатам.
То есть по «открытым ключам», а не сертификатам. Обычно никаких подписей там нет.
То есть по «открытым ключам», а не сертификатам. Обычно никаких подписей там нет.
Опять curl_exec* позапрещали… Ох не везет Curl-у…
НЕ ЗАПРЕЩАЙТЕ curl_exec* ОНИ НИКАКОГО ОТНОШЕНИЯ К ШЕЛЛУ НЕ ИМЕЮТ
В этом случае, кстати, работает ваш нулевой совет — не надо все бездумно копипастить
НЕ ЗАПРЕЩАЙТЕ curl_exec* ОНИ НИКАКОГО ОТНОШЕНИЯ К ШЕЛЛУ НЕ ИМЕЮТ
В этом случае, кстати, работает ваш нулевой совет — не надо все бездумно копипастить
«Горе-кодеры» различных CMSок не от хорошей жизни 777 выставлять просят. А потому что многие параноидальные хостеры запускают веб-серверы (и CGI-скрипты через него) от пользователя nobody с минимальными правами, а вот доступ на fpt от пользователя хостинга.
Поэтому если не установить 777, во многих случаях скрипт просто не сможет писать в каталог (или в файл), который залил пользователь.
Поэтому если не установить 777, во многих случаях скрипт просто не сможет писать в каталог (или в файл), который залил пользователь.
Некоторые просят от непонимания процесса. Зачем php скрипту права на запуск?
На директорию в описанном вами случае еще можно выставить 777 (и то я бы еще подумал о смене хостинга [и, видимо, бог миловал, но мне таких хостеров не попадалось. у кого пользовался шаредом, у всех был apache-mpm-itk]), а файлы то причем тут? А я, между тем, постоянно вижу в INSTALL-файлых требование на chmod -R 777 /path/to/srcript.
На директорию в описанном вами случае еще можно выставить 777 (и то я бы еще подумал о смене хостинга [и, видимо, бог миловал, но мне таких хостеров не попадалось. у кого пользовался шаредом, у всех был apache-mpm-itk]), а файлы то причем тут? А я, между тем, постоянно вижу в INSTALL-файлых требование на chmod -R 777 /path/to/srcript.
Может быть и я не понимаю. Разве интерпретация PHP-скрипта не является его выполнением? Но это отдельный вопрос.
А насчёт файлов-каталогов, так тут какая разница? Допустим, владелец каталога или файла mirror (UID 1000), а PHP-скрипт запускается от пользователя nobody (UID>1000), какие права надо поставить на другой файл (или каталог), чтобы переписать его (записать внутрь)?
А насчёт файлов-каталогов, так тут какая разница? Допустим, владелец каталога или файла mirror (UID 1000), а PHP-скрипт запускается от пользователя nobody (UID>1000), какие права надо поставить на другой файл (или каталог), чтобы переписать его (записать внутрь)?
Для интерпретации php скриптов +x права на запуск не нужны.
> какие права надо поставить на другой файл (или каталог), чтобы переписать его?
права на удаление файла определяются правами каталога. юзер vasia может удалить даже рутовый файл с 000 правами, если он находится в директории, куда у vasia есть права на запись. с директорией все тоже самое в том случае, если она не пустая.
> какие права надо поставить на другой файл, чтобы записать внутрь?
ну вот тут уже играют роль права на сам файл. но для записи достаточно 664 с занесением пользователя в нужную группу. ну или на совсем худой конец 666. но никак не 777.
а на директорию 775, либо 777, так как ей нужны права на запуск. иначе она не откроется.
> какие права надо поставить на другой файл (или каталог), чтобы переписать его?
права на удаление файла определяются правами каталога. юзер vasia может удалить даже рутовый файл с 000 правами, если он находится в директории, куда у vasia есть права на запись. с директорией все тоже самое в том случае, если она не пустая.
> какие права надо поставить на другой файл, чтобы записать внутрь?
ну вот тут уже играют роль права на сам файл. но для записи достаточно 664 с занесением пользователя в нужную группу. ну или на совсем худой конец 666. но никак не 777.
а на директорию 775, либо 777, так как ей нужны права на запуск. иначе она не откроется.
Параноидальные _хостеры_ никогда не запускают CGI-скрипты от пользователя веб-сервера. Для них существуют всякие suEXEC. Права 777 означают, что компрометация _любого_ аккаунта (не только апача, и не только arbitrary code execution) компрометирует все подобные сайты.
Не в тему веб-сервера, но юзер «nobody» — зло. Для каждого демона должен быть свой псевдоюзер для большей изоляции.
Не в тему веб-сервера, но юзер «nobody» — зло. Для каждого демона должен быть свой псевдоюзер для большей изоляции.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Базовые рекомендации для повышения безопасности *nix веб-сервера