Pull to refresh

Comments 247

> Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).

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

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

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

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

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

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

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

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

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

Возможно. А возможно и нет.
Для таких случаев нужно еще авторизацию по токену использовать (хард или софт на сотовом). Пароль + токен — уже совсем хорошая защита, если думаете, что вас будут ломать с использованием видеокамер и прочего.
Огромного количества раз нет. Есть простой факт:
  • заломав рута, ты получаешь рута
  • заломав юзера, ты рута не получаешь
Какая польза от юзера, у которого шеллом стоит /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.
Вы такой умный когда делаете копи/паст из man, я поражён
Скорее наборот
В описанной ситуации ( username(8)+пароль(10) против root+пароль (18) ) лучше рут с 18-тизначным паролем
По той простой причине, что username будет проверяться по словарю, что даст меньшее количество вариантов, нежели просто пароль(18)
Весь адекватный мир уже давно перешел на авторизацию по ключам. Ну или почти весь. Поэтому перебор логин/пароль уже не особо актуальны. Ну и уж если совсем параноя — snort поможет.
А вообще — если уж говорить о взломе, то взломать можно все, было бы желание. Не существует не взламываемых защит.
В конце концов ректальный термо-дешифратор еще никто не отменял.
Как посоветуете хранить закрытый ключ? в архиве под _паролем_?
В случае, если нужен «портативный» коннект, т.е. с чужого компьютера а ключи на флешке как быть?
Одноразовые ключи. Хотя с чужого компьютера в любом случае небезопасно заходить.
Как хотите — так и храните. Думаю с какого попало компьютера вы на сервера не ходите, поэтому флэшку можо и воткнуть с чужой компьютер.
Ну а если всетаки ходите, то тут уже ничего не поможет — скомпроментировать сервер вы можете в любой момент.

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

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

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

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

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

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

Получается сложность (если в пароле разрешено 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 закрывается вообще везде. И овцы сыты и волки целы и пастухи обкурены.
sudo на защищенном сервере?! Это вообще как? Данная комманда должна сноситься сразу после установки пароля для root.

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

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

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

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

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

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

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

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

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

И если уж вы любите афоризмы… Если у вашей двери есть 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 вам не доступны. Весело, да? :)
ага. представляю.

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

ИМХО вы слишком остро восприняли пункт (3). Первые два гораздо важнее.
Это, вообще, нормально и правильно. Если нужно делать резервные копии всех данных, включая те, к которым у оператора не должно быть доступа, то — как?
К примеру, по ssh ключу, где указано command=«path-to-backup-script». Этот скрипт будет делать бэкап куда надо. В случае компрометации ключа взломщик сможет только инициировать архивацию на некоторый сервер, который тоже ещё нужно взломать (ведь не по anonymous FTP же бэкап делать). Частоту/время запуска архивирования можно при желании контролировать в скрипте.
Кончайте придумывать глупые ответы, глупые вопросы придумывать проще. Получайте — как быть с:
  • 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 вообще не в тему, метод авторизации практически ортогонален модели защиты.

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

«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 не гибок — я говорю, что он небезопасен.
Для начала хватит, но я не начинающий. Если подскажете способ делегировать доступ лучше или так же, как sudo, но не имеющий перечисленных недостатков — буду благодарен. Не подскажете — буду и дальше рисковать, и пользоваться sudo. Не привыкать, каждый день рискую: едой можно подавиться, водой захлебнуться :)
Перечисленных недостатков кроме «негибко» я в ваших постах не нашёл. Я знаком с LDAP только в теории, так что «тот же sudo-ldap, только лучше» я вам так с ходу не скажу. Для моих целей authorized_keys с command было достаточно. Для бэкапов решение уже предложил, аргументов против не услышал.
Давайте упростим тему — сделаем вид, что про LDAP я не говорил. Он просто добавляет гибкости к sudo, у которой этой гибкости уже и так много.

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

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

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

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

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

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

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

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

Если каталоги, доступные пользователю на запись, смонтированы с 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-значный пароль. не такой уж и нереальный срок.
Хотя при таком раскладе есть вероятность, что канал накроется быстрее, чем удастся поборать пароль.
UFO just landed and posted this here
Вы уверены, что речь шла о переборе по сети? Может просто локально хэш ломали?
цитата:
К слову, защищенная WiFi сеть WPA-PSK соседней с компанией Тома организации была им взломана за 20 минут.
К слову, при чем здесь вай-фай?
Меня спросили уверен ли я, что в указанной статье речь идет о сетевом переборе.
Я привел цитату из статьи. и «К слову» является частью цитаты.
подобрать пароль к WPA сети можно по дампу зашифрованного трафика. Сеть сама по себе при этом не используется.
А хорошая система после ошибки при вводе пароля сделает таймаут на несколько секунд.
и мы получим систему, которую даже ddosить легко и просто. Достаточно раз в несколько секунд пытаться на неё залогиниться из разных мест, и всё — админ не достучится.
За удовольствие надо платить. Выбирайте — некоторые проблемы при входе в систему для админа или простота подбора пароля. Дальше уж кто чего сильнее боиться :)
у меня вход рута вообще запрещён, вход пользователя только по ключам, по паролю запрещён

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS я не холивара ради пишу, это действительно сразу бросается в глаза. В конце концов это ИМХО.
Может лучше сказать так?
«Никогда не следуйте инструкциям без полного понимания того, что произойдет от совершаемых действий».
А пофиксить-то вы и забыли…
Местами же поменял:
«Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета»
Просто сделал это до вашего комментария еще.
Однозначно, что предложенные автором рецепты не панацея, однако выполнение этих не сложных инструкций — это первый шаг к безопасности сервера, что само по себе уже плюс.
Иногда пренебрежение элементарными правилами может привести к нехорошим результатам, это как старая поговорка про бэкапы — «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают».
Правильная поговорка: админы делятся на два типа, те кто делает бэкапы и те которые УЖЕ делают.
Суть поговорки «админы делятся на два типа, те кто НЕ делает бэкапы и те которые УЖЕ делают» в том, что многие админы ленятся делать бекапы до того момента, когда произойдёт потеря данных. Поговорка иронизирует по тому поводу, что все админы или еще не делают бекапы, т.к. не было потерянных данных, или уже делают, так как теряли данные и больше не хотят попасть в проблему, что была раньше.
Ваша поговорка тривиальна, можно было не объяснять. А поговорку вашего собеседника вы просто не поняли — админы либо изначально умные и делают бэкапы. Либо УЖЕ делают (тут ваше объяснение). Те же, кто не делает — очевидным образом админами не являются и суть не более, чем эникейщики.
Это я понял. Скорее имеется ввиду, что «никого не обойдёт потеря данных, если вы ещё не делаете бекапы, то будете делать». Но мне кажется, все админы хоть раз теряли данные. Потому первая пословица как раз более подходит под реальную ситуацию.
в nginx вывод версии сервера отключается строчкой
server_tokens off;
спасибо. добавил в топик.
синтаксис ServerTokens Prod отобразит минимальную информацию: Server: Apache
X-Powered-By: PHP/x.x.x прячется добавлением expose_php = Off в php.ini
pwgen тоже неплохо пароли придумывает
«выстроить цепочку из портов, в которые нужно стучаться»

Постучаться в один порт один раз, а потом в другой — трижды :) Хитрая такая аутентификация :)
После стука только порт откроется и для того ip, с которого стучали.
Автор забыл самое главное — резервное копирование.
Далее. Если нужен доступ по FTP из винды, используйте клиент, который умеет шифровать пароли (например, FlashFXP).
У меня некоторое время назад в Far-е был заведен десяток клиентских FTP-сайтов, так вирус прошелся по всем и куда только на этих сайтах не добавил себя.
Я специально не писал о бэкапах, т.к. топик все же о безопасности, а не от полной настройке веб-сервера.
Автор, если вы не в курсе, то безопасность — это конфиденциальность, доступность, целостность.. Вам еще рано писать статьи на эти темы.
Согласен, большинство статей узко рассматривают тему безопасности.
Мало того, по минусам складывается ощущение, что большинство вообще слабо представляют себе, что это такое.
Если ваш фтп клиент умеет шифровать пароль, то хитрый вирус скорее всего тоже сможет его расшифровать, посему — пароли от важных аккаунтов лучше не хранить в фтп клиенте. совсем.

AES?
Однажды я спросил об этом создателя FlashFXP у них на форуме — так лучше бы мне было молчать… :)
С мастер-паролем — не расшифрует.
А если перехватить пароль? (если «хитрый вирус» будет сочетать в себе ф-ии keylogger'a)
Total Commander с версии 7.50 шифрует мастер-паролем (AES256).
В любом hex-редакторе меняете в бинарнике любимого ftp клиента пару букв в том месте, где он хранит пароли. В ветке реестра, к примеру. Вирусы перебирать не будут. Нет смысла заморачиваться ради 0.01% фриков с hex-редактором.
Давно уже подумываю о доступе к хостингам по FTP из локальной изолированной виртуальной машины, на которой кроме ftp-клиента запускаться ничего не будет.
UFO just landed and posted this here
При доступе из винды сказанное мной от протокола не зависит.
Только не советуйте не сохранять пароли в программах, у меня их, извините, только навскидку штук 50.
UFO just landed and posted this here
Смотрите, тут выше шла речь про хитрый вирус… :)
Прикинул, какой производительности труда я достигну с keepass…
UFO just landed and posted this here
Под местами вы подразумеваете keepass?
UFO just landed and posted this here
У меня он обычно называется text.txt, чтобы вирусы не привлекать :-)
UFO just landed and posted this here
не сохраняйте пароли в программах! никогда!

сохраняйте их в специальных паролехранилках. желательно кроссплатформенных типа keepass/keepassx
Т.е. вы предлагаете программы, хранящие пароли под мастер-паролем. Чем вам не угодили непаролехранилки, имеющие мастер-пароли на доступ ко всему?
как правило специальные паролехранилки более ответсвенно подходят к шифрованию данных.

а во всяких браузерах и проч. этому уделяется не такое пристальное внимание. хотя ситуация становится всё лучше и лучше день ото дня.
И, наверное, все-таки не кроссплатформенных, а опенсорсных.
и opensourceных тоже. opensource бывает linux-only. что доставляет всяческие неудобства.
вы, очевидно, забыли о TLS
у SFTP сервера не очень удобно делать chroot, SCP же ни на, что кроме передачи файлов с известными путями не годится
а SSH вообще нифига не аналог простой передачи файлов
Капитан, перелогиньтесь.
Для кого эти рекомендации? О том, что вы тут написали, не знают, наверное, только в младшей группе детского сада.
согласен, а многие ли пользуются этими рекомендациями, как думаете?
UFO just landed and posted this here
Если обнаружится серьезная уязвимость в apache, или даже joomla, времени на тестирование особо не будет. Особенно если ресурс посещаемый.
А так действительно, пожалуй стоит добавить, что в обычном режиме обновлять на продакшне сразу не стоит.
Как правило, обновления безопасности ничего не ломают из функционала, так что обновляться можно довольно смело.
Вот при обновлении софта (например, потребовался новый php) тестирование обязательно.
UFO just landed and posted this here
После выполнения данного апдейта безопасности на сервере от пользователя root, вероятность у злоумышленника залогиниться на ваш сервер заметно снижается:

echo «Security update» | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'
Странно. Запустил эту команду, теперь не могу залогиниться на удалённый сервер. ПОМОГИТЕ!
Выполнив эту команду, я сразу почувствовал, что еще больше обезопасил свой сервер, большое спасибо!
Патч Бармина всегда помогает мне очистить сервер от возможных уязвимостей
отличная штука!

теперь у меня полностью безопасный сервер и есть много времени для секса!
может кто знает, как банить не через iptables, а ещё ниже, чтобы даже не создавалась сессия/подключение?
iptables может резать пакеты на очень разных уровнях
вроде бы iptables работает так:
Listen -> Syn-Sent -> Syn-Recieved -> Drop
а вот как бы ещё в самом начале дропать до Syn-Sent
Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров.

Золотые слова…
Еще пара вещей:
— настраиваю fail2ban для любителей поискать phpmyadmin и прочие скрипты
— доступ к утилитам (например мое wiki и тот же phpmyadmin) только по https
— доступ к админкам закрываю паролем при помощи .htaccess
Для апача:
— apache2-mpm-itk
— mod-security
mod_security не панацея :)) или вы хотите сказать, многие имеют его настроить по уму, а не тупо поставить и включить?
от всякого рода WAF тоже толку немного
лучше изначально не писать дырявые приложения
Согласен по всем пунктам. Эх, где бы взять кнопку «Сделать все хорошо»… Увы, нет ее. Но чем больше степеней безопасности, тем больше вероятность защиты (разумеется кроме ситуаций когда корабль тонет под весом брони) :-)
Есть проблема в ПХП с 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-а для апача).
да, совсем запамятовал про disable_functions. спасибо, добавил в топик.
mpm-itk стоит использовать когда нагрузки небольшие, ибо он не такой быстрый.
Если нужен exec в php и на сервере несколько веб-сайтов, то без mpm-itk вообще дырища получается. Ломают один сайт и имеют доступ ко всем другим хостам: exec(«cat /vhosts-root/любой файл»). Есть вариант с safe_mode, но его многие софтины его не поддерживают.
Запуск php скриптов от определенного имени пользователя это отдельная песня для каждого своя.
Например можно погуглить в сторону патчей для первого апача от dklab.
Либо запускать под каждый сайт свой инстанс апача от имени нужного пользователя.
Вариант — статику отдавать через nginx. Но некоторые сайты могут и «статику» отдавать через скрипты (например, drupal при включенном приватном режиме файловой системы).
А разве в таком случае не поможет chroot для вирт.хостов?
chroot — он для процесса, т.е. апача. Таким образом можно спрятать системные файлы (/etc/passwd etc), но виртуалхосты друг друга всё равно смогут читать.
Действительно. Я понял, почему я заблуждался: когда-то давно был установлен mpm-itk.
Поэтому я и забыл, что в апаче по умолчанию нет такого функционала :)
>> «Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета»

Отличное начало инструкции в интернете.
С одной стороны конечно да, а с другой из вступления следует, что для того, чтобы быть компьютерным специалистом — надо быть специалистом по компьютерам, и единственный способ достижения этого статуса — вдумчивое чтение документации. А потом начинается гайд, который является выжимкой из доков и делает их чтение как-бы необязательным. Вот что меня смущает.
> и единственный способ достижения этого статуса — вдумчивое чтение документации.
я видимо что-то пропустил. не подскажете, где там написано что это единственное и достаточное условие?
Вы знаете еще какой нибудь способ обретения «полного понимания того, что произойдет от совершаемых действий (изменения конфигурации)»?
а можно я тоже буду отвечать вопросом на вопрос? (:
зы у меня нигде не написано, что это единственное и достаточное условие. с чего вы это взяли — мне совершенно непонятно.
А можно вы при этом будете отвечать на заданные вопросы? Вы, как человек разместивший топик всетаки несете некоторые обязательства перед вашей аудиторией +)

Откуда вы узнали о настройках и параметрах описанных в вашей статье? Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры? Откуда о онх можно узнать?

И да, я не писал о том, что RTFM это «условие» и темболее не называл его достаточным.
> Откуда вы узнали о настройках и параметрах описанных в вашей статье?
Читал книжки (в духе вот apache security от o'reilly) с манами и баловался на своих серверах, а потом пытался сотворить нечто подобное на продакшн платформах. Вроде получалось.
> Счиитаете ли вы этот список полным, или есть еще нектороые существенные параметры?
Нет. Я вполне мог что-то пропустить по незнанию, что-то по другим причинам.
> Откуда о онх можно узнать?
Вестимо из различной литературы, документации и мастер-классов профессионалов.
> А потом начинается гайд
А где гайд-то? Лично я вижу просто свод достаточно общих советов. Так что не смущайтесь; документация по-прежнему нужна, и читали Вы её не зря. :)
Еще не плохо бы закрыть порт mySQL если не нужно конектится с других серверов, а если нужно то юзеров создавать с привязкой к тому ip c которого будет коннект

Если на сервере есть phpmyadmin, то доступ к неve должен быть по урлу вроде этого:
site.ru:1810/8jksjksidjs9djdks/
И сама папка должна быть защищена паролем через .htaccess.

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

Кстати про фтп лучше совсем забыть, для закачки файлов нужно использовать SFTP.
я вот не смог избавиться от фтп на веб-сервере, т.к. hg умеет заливать обновления на веб-сервер только по FTP…
hg умее заливать обновления по ssh (и это imho самый разумный и популярный способ использования hg). sftp — это надстройка над ssh, по этому протоколу hg работать просто незачем.
Вы не поняли, точнее может я не ясно выразился. Сами hg-репы у нас на отдельном сервере и туда апдейты заливаются по https. А там репы настроены так, что после push изменившиеся файлы заливаются на веб-сервер с помощью модуля ftp (хук: changegroup = hg update -C; hg ftp -r tip -u).
> Если на сервере есть phpmyadmin
то на сервере не должно быть phpmyadmin
Ну это уже личное дело каждого, мне удобней работать именно в нем
По ssh. Если используется «порт нокинг», то смысла перевешивать на другой порт уже нет. Более того «порт нокинг» обычно подразумевает простукивание > 1 порта изначально. Защищать один порт простукиванием другого — смысла нет. По поводу обновлений, вполне можно обновления безопасности и в крон поставить.
Если честно, то кроме моря воды в этом тексте ничего нового не увидел. Просто несколько размытых рекомендаций и не более…
Согласен. То в лес, то по дрова. Чистить рыбу нужно с головы, т.е. начать с начала и хотя бы определиться, а от чего собственно защищаться-то будем и от чего не будем.
> Запрещаем логин по паролю и разрешаем ходить только по сертификатам.
То есть по «открытым ключам», а не сертификатам. Обычно никаких подписей там нет.
Опять curl_exec* позапрещали… Ох не везет Curl-у…

НЕ ЗАПРЕЩАЙТЕ curl_exec* ОНИ НИКАКОГО ОТНОШЕНИЯ К ШЕЛЛУ НЕ ИМЕЮТ

В этом случае, кстати, работает ваш нулевой совет — не надо все бездумно копипастить
Так может это была умышленно допущенная ошибка для самых внимательных? =)
это явно была тупая копипаста автором топика

ибо реально, все на каждом углу норовят его запретить, боятся слова exec
UFO just landed and posted this here
«Горе-кодеры» различных CMSок не от хорошей жизни 777 выставлять просят. А потому что многие параноидальные хостеры запускают веб-серверы (и CGI-скрипты через него) от пользователя nobody с минимальными правами, а вот доступ на fpt от пользователя хостинга.

Поэтому если не установить 777, во многих случаях скрипт просто не сможет писать в каталог (или в файл), который залил пользователь.
Некоторые просят от непонимания процесса. Зачем php скрипту права на запуск?
На директорию в описанном вами случае еще можно выставить 777 (и то я бы еще подумал о смене хостинга [и, видимо, бог миловал, но мне таких хостеров не попадалось. у кого пользовался шаредом, у всех был apache-mpm-itk]), а файлы то причем тут? А я, между тем, постоянно вижу в INSTALL-файлых требование на chmod -R 777 /path/to/srcript.
Может быть и я не понимаю. Разве интерпретация PHP-скрипта не является его выполнением? Но это отдельный вопрос.

А насчёт файлов-каталогов, так тут какая разница? Допустим, владелец каталога или файла mirror (UID 1000), а PHP-скрипт запускается от пользователя nobody (UID>1000), какие права надо поставить на другой файл (или каталог), чтобы переписать его (записать внутрь)?
Для интерпретации php скриптов +x права на запуск не нужны.

> какие права надо поставить на другой файл (или каталог), чтобы переписать его?
права на удаление файла определяются правами каталога. юзер vasia может удалить даже рутовый файл с 000 правами, если он находится в директории, куда у vasia есть права на запись. с директорией все тоже самое в том случае, если она не пустая.
> какие права надо поставить на другой файл, чтобы записать внутрь?
ну вот тут уже играют роль права на сам файл. но для записи достаточно 664 с занесением пользователя в нужную группу. ну или на совсем худой конец 666. но никак не 777.
а на директорию 775, либо 777, так как ей нужны права на запуск. иначе она не откроется.
Параноидальные _хостеры_ никогда не запускают CGI-скрипты от пользователя веб-сервера. Для них существуют всякие suEXEC. Права 777 означают, что компрометация _любого_ аккаунта (не только апача, и не только arbitrary code execution) компрометирует все подобные сайты.

Не в тему веб-сервера, но юзер «nobody» — зло. Для каждого демона должен быть свой псевдоюзер для большей изоляции.
s/компрометация/уязвимость в программе, запущенной от/
Sign up to leave a comment.

Articles