Комментарии 60
> апачевский юзер не должен иметь прав на изменение и удаление апачевских логов
А что ещё не должно быть?
А что ещё не должно быть?
Конфа должна быть нечитаема. Приватные ключи.
я бы еще document root закрыл бы от греха подальше.
питание сервера отключить не забудьте, зачем свет мотает?
сервер в бетон, в запертую комнату с вооруженными охранниками, and even then I have my doubts.
Спасибо
Эта фича называется hardening. И еще, Апачевский юзер не должен иметь прав на ЧТЕНИЕ логов, а так же не быть разделенной учеткой, вроде nobody. Всем добра 8)
Может кто-нибудь напишет статью об основных проверках безопасности Linux?
Например рутовый пароль не должен быть «qwerty»
Ну, например, у нас на всех серверах рутовый пароль примерно подобный. И что в этом плохого?
Единственный случай, когда человеку нужно его вводить — если он либо имеет физический доступ к серверу в ДЦ, либо имеет доступ к менеджменту сервера через IPMI (что по сути примерно то же самое). Если есть физический доступ или менеджмент-доступ — то уже делать что-то с сервером и защищать его от злостных хакеров, которые банально могут снять жесткие диски и унести (или снять копию по сети через IPMI) — бессмысленно. Рутовый пароль не защищает ни от чего: атакующий человек проникает в ДЦ, вынимает диски, копирует что нужно, вставляет на место, уходит.
Единственный случай, когда человеку нужно его вводить — если он либо имеет физический доступ к серверу в ДЦ, либо имеет доступ к менеджменту сервера через IPMI (что по сути примерно то же самое). Если есть физический доступ или менеджмент-доступ — то уже делать что-то с сервером и защищать его от злостных хакеров, которые банально могут снять жесткие диски и унести (или снять копию по сети через IPMI) — бессмысленно. Рутовый пароль не защищает ни от чего: атакующий человек проникает в ДЦ, вынимает диски, копирует что нужно, вставляет на место, уходит.
А если человек получит ограниченный шелл и сделает su? У нас рут вообще отключен везде.
su настраивается так, что доступен только по руту (очевидно, без пароля) для, наоборот, снижения привилегий. Никаких причин, кроме legacy, для использования модели «один пароль root на всех» — нет.
Для повышения привилегий используется sudo, который, в зависимости от ситуации, или не просит пароль, а смотрит лишь на права пользователя, либо просить ввести пароль вызывающего его ограниченного пользователя.
Для повышения привилегий используется sudo, который, в зависимости от ситуации, или не просит пароль, а смотрит лишь на права пользователя, либо просить ввести пароль вызывающего его ограниченного пользователя.
sudo su?
Доступ к IPMI != физический. Первый потенциально проще получить.
Доступ к IPMI != физический. Первый потенциально проще получить.
И что
Я не говорю, что доступ к IPMI == физическому. Я говорю, что получение или того, или другого дает практически абсолютный контроль над машиной — и абсолютно не важно, есть ли пароль от рута, есть ли вообще рут, есть ли вообще возможность залогиниться на машину или даже банально включена ли она и т.д.
sudo su? Можно и sudo -i сделать, результат почти такой же. Только sudo сможет сделать только тот, у кого есть на то права, а не любой, кто подсмотрел / подобрал / утащил некий общий пароль (особенно если этот общий пароль известен более, чем 1 человеку).Я не говорю, что доступ к IPMI == физическому. Я говорю, что получение или того, или другого дает практически абсолютный контроль над машиной — и абсолютно не важно, есть ли пароль от рута, есть ли вообще рут, есть ли вообще возможность залогиниться на машину или даже банально включена ли она и т.д.
Насчет рутового пароля:
В тех конторах, где за безопасностью реально следят, причем следят суровые дядьки безопасники, рутовый пароль: a) сложный, генерируемый рандомно b) задается и меняется начальником it-отдела в присутсвии безопасника, админ пароль не знает, он при этом находится в другой комнате c) запечатывается в конверт и лежит у начальника службы безопасности в сейфе d) юзера в том числе админы ходят по ssh ключам e) конверт с паролем достается только в случае экстренной необходимости физического доступа f) после случаев «экстренной необходимости» пароли меняются.
Насчет IPMI:
IPMI тоже не должен быть «дыркой». Т.е. как минимум пароль на IPMI не должен совпадать с рутовым. Да и вообще, по максимуму возможность «менеджмента сервера» надо закрыть извне.
Насчет физического доступа:
1) Если нет физической безопасности, то нет никакой. Именно поэтому, многие серьезные конторы предпочитают держать сервера у себя, а не в «облаках». Политика безопасности.
2) Позвольте поинтересоваться, это что у вас за ДЦ такой, по которому «злостные хакеры» могут шастать безконтрольно туда-сюда и вынимать отовсюду жесткие диски ;)
3) Если уровень секретности информации таков, что стоит реальная задача обезопасить информацию даже на случай физического «выдирания диска», то к вашим услугам криптование. Естественно, достигаетеся это ценой значительного снижения производительности, соотвественно, практикуется реже.
А еще есть:
1) Мониторинг состояния серверов. С сервером не должно происходить ничего такого важного, о чем бы никто не знал (старт/рестарт/недоступность/вход в консоль под рутом — если вам об таких делах не приходит сразу смска — у меня для вас плохие новости).
2) Отправка логов на другой сервер. Проникнув на сервер, злоумышленик в первую очередь постарается «замести все следы», сделав так как будто ничего не было. Если логи дублированы на другом независомом сервере, сделать это будет проблематично.
3)… да еще тысячи всяких простых и сложных мер, одно перечисление которых потянуло бы на толстую книжку…
В тех конторах, где за безопасностью реально следят, причем следят суровые дядьки безопасники, рутовый пароль: a) сложный, генерируемый рандомно b) задается и меняется начальником it-отдела в присутсвии безопасника, админ пароль не знает, он при этом находится в другой комнате c) запечатывается в конверт и лежит у начальника службы безопасности в сейфе d) юзера в том числе админы ходят по ssh ключам e) конверт с паролем достается только в случае экстренной необходимости физического доступа f) после случаев «экстренной необходимости» пароли меняются.
Насчет IPMI:
IPMI тоже не должен быть «дыркой». Т.е. как минимум пароль на IPMI не должен совпадать с рутовым. Да и вообще, по максимуму возможность «менеджмента сервера» надо закрыть извне.
Насчет физического доступа:
1) Если нет физической безопасности, то нет никакой. Именно поэтому, многие серьезные конторы предпочитают держать сервера у себя, а не в «облаках». Политика безопасности.
2) Позвольте поинтересоваться, это что у вас за ДЦ такой, по которому «злостные хакеры» могут шастать безконтрольно туда-сюда и вынимать отовсюду жесткие диски ;)
3) Если уровень секретности информации таков, что стоит реальная задача обезопасить информацию даже на случай физического «выдирания диска», то к вашим услугам криптование. Естественно, достигаетеся это ценой значительного снижения производительности, соотвественно, практикуется реже.
А еще есть:
1) Мониторинг состояния серверов. С сервером не должно происходить ничего такого важного, о чем бы никто не знал (старт/рестарт/недоступность/вход в консоль под рутом — если вам об таких делах не приходит сразу смска — у меня для вас плохие новости).
2) Отправка логов на другой сервер. Проникнув на сервер, злоумышленик в первую очередь постарается «замести все следы», сделав так как будто ничего не было. Если логи дублированы на другом независомом сервере, сделать это будет проблематично.
3)… да еще тысячи всяких простых и сложных мер, одно перечисление которых потянуло бы на толстую книжку…
ммм. Библиографию не посоветуете? :)
Со всем практически согласен, только с поправкой на то, что так было лет 10-15 назад. Сейчас «где за безопасность реально следят» ни один безопасник не допустит наличия в production учетной записи с неограниченными привилегиями вообще. Либо sudo, либо какие-то более fine-grained модели безопасности.
Вообще, работа безопасника начинается не с банального «я знаю N практик правильной безопасности и буду их применять прямо сейчас и прямо тут», а с анализа и моделирования системы угроз / векторов атак, их ранжирования, определения векторов противодействия для каждой из атак и т.д.
Насчет «ДЦ, по которому злостные хакеры могут шастать бесконтрольно» — это, как вы можете догадаться, не «ДЦ такой», а именно простейшее моделирование вектора атаки. Да, в норме, разумеется, не может. Но если сможет — то пароль рута, пароль «на BIOS» или любые подобные банальные штуки не помогают фактически совсем никак.
Про криптографию — да, но:
1) это либо заметно медленно, либо заметно дорого,
2) это безусловно
3) даже корректно сделанная криптография — не панацея; снифферы PCI-шин, снифферы SATA/SAS — железки доступные и стоят не то, чтобы очень дорого; на каком-то DefCon'е показывали даже совсем бюджетный сниффинг чего угодно через осциллограф за 200$ + ноутбук + софт для декодирования сигналов шин
Если вы до сих пор пользуетесь смсками — у меня для вас плохие новости. Этой чудесной технологии на днях исполнилось 20 лет, если считать от даты посылки первой в мире sms, и 30 лет, если считать от даты написания первых драфтов. И, да, я обычно предпочитаю спать ночью, а внезапно умершие ночью сервера предпочитаю, чтобы обслуживали ночные дежурные.
Вообще, работа безопасника начинается не с банального «я знаю N практик правильной безопасности и буду их применять прямо сейчас и прямо тут», а с анализа и моделирования системы угроз / векторов атак, их ранжирования, определения векторов противодействия для каждой из атак и т.д.
Насчет «ДЦ, по которому злостные хакеры могут шастать бесконтрольно» — это, как вы можете догадаться, не «ДЦ такой», а именно простейшее моделирование вектора атаки. Да, в норме, разумеется, не может. Но если сможет — то пароль рута, пароль «на BIOS» или любые подобные банальные штуки не помогают фактически совсем никак.
Про криптографию — да, но:
1) это либо заметно медленно, либо заметно дорого,
2) это безусловно
3) даже корректно сделанная криптография — не панацея; снифферы PCI-шин, снифферы SATA/SAS — железки доступные и стоят не то, чтобы очень дорого; на каком-то DefCon'е показывали даже совсем бюджетный сниффинг чего угодно через осциллограф за 200$ + ноутбук + софт для декодирования сигналов шин
если вам об таких делах не приходит сразу смска — у меня для вас плохие новости
Если вы до сих пор пользуетесь смсками — у меня для вас плохие новости. Этой чудесной технологии на днях исполнилось 20 лет, если считать от даты посылки первой в мире sms, и 30 лет, если считать от даты написания первых драфтов. И, да, я обычно предпочитаю спать ночью, а внезапно умершие ночью сервера предпочитаю, чтобы обслуживали ночные дежурные.
Яростно плюсую. А то VPS-ки дешёвые стали, у всех появился маленький тестовый сервачок, а вот в ботнет попаст не хочется :)
Во FreeBSD (проверял под 9.0-RELEASE) апачевский юзер не httpd, а www:
[root ~]# su -m httpd -c /usr/local/bin/bash
su: unknown login: httpd
[root ~]# su -m www -c /usr/local/bin/bash
[www ~]$
А для CentOS может как-то по-другому надо?
Пользователя www-data нет в системе, есть пользователь apache:
su -l apache
This account is currently not available.
Пользователя www-data нет в системе, есть пользователь apache:
su -l apache
This account is currently not available.
Там у Вас, скорее всего, шелл nologin.
по-моему, в CentOS есть понятие системных аккаунтов и залогинится под ними невозможно
Попробуйте вот это:
Eсли шелл стоит
su -l apache -s /bin/bash
Eсли шелл стоит
/bin/nologin или /bin/false это ничего не меняет, т.к. процесс все равно работает под этим юзером. И атака будет идти не через ssh, а через дыру в программе.
О боже! А если у меня nginx и кастомный пользователь, то что мне делать? 8-0
Товарищи, кто выше писал про другие системы и юзеров, ну конечно же разные в разных осях юзеры — это ежу в танке очевидно.
И посмотреть их 5 секундов.
ps: Btw, всех с Новым Годом! :)
Товарищи, кто выше писал про другие системы и юзеров, ну конечно же разные в разных осях юзеры — это ежу в танке очевидно.
И посмотреть их 5 секундов.
ps: Btw, всех с Новым Годом! :)
В Freebsd лучше /bin/csh использовать или /bin/sh
bash не ставится по умолчанию и чаще всего идет в комплекте какого-нибудь пингвиньего монстра.
bash не ставится по умолчанию и чаще всего идет в комплекте какого-нибудь пингвиньего монстра.
Сами используйте эти отродья. У нас bash разворачивается по умолчанию везеде. Как плюс можно использовать нормальный синтаксис типа
[[ ]] или (( )) в скриптах.А что не так с csh?
В среде с Linux и FreeBSD серверами? Только одно: стандарт на оболочку. Зачем сущости плодить и забивать голову?
Ну tcsh вполне себе хороший стандарт.
Можно его и на лине ставить тоже.
Можно его и на лине ставить тоже.
Вопрос предпочтений, да.
99% скриптов на bash, только freebsd на sh, а так все инит и не только скрипты в линуксе на bash, зачем изучать другое обычному админу не знаю
Вообще-то лет 5 последних идет массовая тенденция как раз _отказа_ от bash в мейнстримных дистрибутивах (Debian, Ubuntu, RH, SuSE) в пользу dash/ash, которые есть как раз sh. Процесс далеко не всегда простой и быстрый, но, например, в Debian/Ubuntu добились, что /bin/sh уже года 2-3 как указывает не на /bin/bash, а на /bin/dash, и в системных скриптах стандартной поставки нет вызовов #!/bin/bash.
sh практически всегда куда проще bash — в том числе и в изучении (меньше сложных синтаксических конструкций, меньше стимулов делать на sh какие-то алгоритмически-сложные штуки, которые проще и понятнее реализовать на скриптовых языках), а еще радикально производительнее, как правило.
sh практически всегда куда проще bash — в том числе и в изучении (меньше сложных синтаксических конструкций, меньше стимулов делать на sh какие-то алгоритмически-сложные штуки, которые проще и понятнее реализовать на скриптовых языках), а еще радикально производительнее, как правило.
Здесь недавно упоминали дистрибутив который тоже немножко поможет в тестировании.
У меня есть машины со старым find'ом (GNU find version 4.1.20), там нет ключа '-wholename'.
Использую такой набор ключей:
find / -type d \( -perm -g+w -or -perm -u+w \) -user www -exec ls -adl {} \;
В find версии 4.3.0 или больше есть ключ '-writable'.
Посмотреть список файлов, куда текущий пользователь имеет права записи: find . -writable
И куда не имеет: find . ! -writable
Использую такой набор ключей:
find / -type d \( -perm -g+w -or -perm -u+w \) -user www -exec ls -adl {} \;
В find версии 4.3.0 или больше есть ключ '-writable'.
Посмотреть список файлов, куда текущий пользователь имеет права записи: find . -writable
И куда не имеет: find . ! -writable
т.е. если у меня у того же апача стоит /sbin/nologin — я могу спать спокойно?
Нет. Сам апач то может писать в директории, ему плевать на оболочку.
Делаете
Делаете
su www-data -c bash, и вперед проверять.Сорри, промазал.
habrahabr.ru/post/164245/#comment_5651729
habrahabr.ru/post/164245/#comment_5651729
korp # su apache -c bash
This account is currently not available.
This account is currently not available.
Сама возможность выполнения "# su -l www-data", т.е. логина под www-data — уже некий изъян в безопасности.
Я думаю не особенный, если только сдуру вход по ssh ему не разрешить. Вот если опишите по пунктам почему конкретно изъян, поверю :-p
Тут такое дело, в безопасности часто пляшут с бубном не понимая причин, нужно всегда понимать конкретно потенциальную проблему.
Тут такое дело, в безопасности часто пляшут с бубном не понимая причин, нужно всегда понимать конкретно потенциальную проблему.
Такой же не особенный, как и «права на изменение и удаление апачевских логов». Просто есть такое правило, что права надо давать по минимуму, т.е. если юзеру не надо логиниться, то и давать ему такую возможность не надо. Ведь разрешать в sshd логиниться то не надо — по умолчанию дефолтным конфигом в большинстве дистрибутивов оно разрешено всем обычным юзерам с валидным шеллом. Если я через дыру в Апатче получу возможность выполнять код от апатчевского юзера, то возможность интерактивного шелла по ssh мне очень облегчит жизнь.
Жеванный крот, никогда не думал что такую банальщину и такие «советы» будут писать на хабре. Это же основы администрирования.
P.S. Можете минусовать и сливать, но от этого моё мнение не изменится.
P.S. Можете минусовать и сливать, но от этого моё мнение не изменится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая проверка безопасности на ваших серверах