Комментарии 60
> апачевский юзер не должен иметь прав на изменение и удаление апачевских логов
А что ещё не должно быть?
А что ещё не должно быть?
+2
Конфа должна быть нечитаема. Приватные ключи.
+5
я бы еще document root закрыл бы от греха подальше.
+6
питание сервера отключить не забудьте, зачем свет мотает?
+17
сервер в бетон, в запертую комнату с вооруженными охранниками, and even then I have my doubts.
+4
Спасибо
-1
Эта фича называется hardening. И еще, Апачевский юзер не должен иметь прав на ЧТЕНИЕ логов, а так же не быть разделенной учеткой, вроде nobody. Всем добра 8)
0
Может кто-нибудь напишет статью об основных проверках безопасности Linux?
+1
Например рутовый пароль не должен быть «qwerty»
+14
Ну, например, у нас на всех серверах рутовый пароль примерно подобный. И что в этом плохого?
Единственный случай, когда человеку нужно его вводить — если он либо имеет физический доступ к серверу в ДЦ, либо имеет доступ к менеджменту сервера через IPMI (что по сути примерно то же самое). Если есть физический доступ или менеджмент-доступ — то уже делать что-то с сервером и защищать его от злостных хакеров, которые банально могут снять жесткие диски и унести (или снять копию по сети через IPMI) — бессмысленно. Рутовый пароль не защищает ни от чего: атакующий человек проникает в ДЦ, вынимает диски, копирует что нужно, вставляет на место, уходит.
Единственный случай, когда человеку нужно его вводить — если он либо имеет физический доступ к серверу в ДЦ, либо имеет доступ к менеджменту сервера через IPMI (что по сути примерно то же самое). Если есть физический доступ или менеджмент-доступ — то уже делать что-то с сервером и защищать его от злостных хакеров, которые банально могут снять жесткие диски и унести (или снять копию по сети через IPMI) — бессмысленно. Рутовый пароль не защищает ни от чего: атакующий человек проникает в ДЦ, вынимает диски, копирует что нужно, вставляет на место, уходит.
0
А если человек получит ограниченный шелл и сделает su? У нас рут вообще отключен везде.
+1
su настраивается так, что доступен только по руту (очевидно, без пароля) для, наоборот, снижения привилегий. Никаких причин, кроме legacy, для использования модели «один пароль root на всех» — нет.
Для повышения привилегий используется sudo, который, в зависимости от ситуации, или не просит пароль, а смотрит лишь на права пользователя, либо просить ввести пароль вызывающего его ограниченного пользователя.
Для повышения привилегий используется sudo, который, в зависимости от ситуации, или не просит пароль, а смотрит лишь на права пользователя, либо просить ввести пароль вызывающего его ограниченного пользователя.
0
sudo su?
Доступ к IPMI != физический. Первый потенциально проще получить.
Доступ к IPMI != физический. Первый потенциально проще получить.
0
И что
Я не говорю, что доступ к IPMI == физическому. Я говорю, что получение или того, или другого дает практически абсолютный контроль над машиной — и абсолютно не важно, есть ли пароль от рута, есть ли вообще рут, есть ли вообще возможность залогиниться на машину или даже банально включена ли она и т.д.
sudo su
? Можно и sudo -i
сделать, результат почти такой же. Только sudo сможет сделать только тот, у кого есть на то права, а не любой, кто подсмотрел / подобрал / утащил некий общий пароль (особенно если этот общий пароль известен более, чем 1 человеку).Я не говорю, что доступ к IPMI == физическому. Я говорю, что получение или того, или другого дает практически абсолютный контроль над машиной — и абсолютно не важно, есть ли пароль от рута, есть ли вообще рут, есть ли вообще возможность залогиниться на машину или даже банально включена ли она и т.д.
0
Насчет рутового пароля:
В тех конторах, где за безопасностью реально следят, причем следят суровые дядьки безопасники, рутовый пароль: 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)… да еще тысячи всяких простых и сложных мер, одно перечисление которых потянуло бы на толстую книжку…
+1
ммм. Библиографию не посоветуете? :)
0
Со всем практически согласен, только с поправкой на то, что так было лет 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 лет, если считать от даты написания первых драфтов. И, да, я обычно предпочитаю спать ночью, а внезапно умершие ночью сервера предпочитаю, чтобы обслуживали ночные дежурные.
0
Яростно плюсую. А то VPS-ки дешёвые стали, у всех появился маленький тестовый сервачок, а вот в ботнет попаст не хочется :)
+1
Во 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 ~]$
+1
Юзера правильного подставляйте, да. У кого что принято.
0
Как бы да:
top | grep http | head -1
....... www ......................................................
+1
А для 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.
+1
Там у Вас, скорее всего, шелл nologin.
+1
по-моему, в CentOS есть понятие системных аккаунтов и залогинится под ними невозможно
+1
Попробуйте вот это:
Eсли шелл стоит
su -l apache -s /bin/bash
Eсли шелл стоит
/bin/nologin или /bin/false
это ничего не меняет, т.к. процесс все равно работает под этим юзером. И атака будет идти не через ssh, а через дыру в программе.+2
О боже! А если у меня nginx и кастомный пользователь, то что мне делать? 8-0
Товарищи, кто выше писал про другие системы и юзеров, ну конечно же разные в разных осях юзеры — это ежу в танке очевидно.
И посмотреть их 5 секундов.
ps: Btw, всех с Новым Годом! :)
Товарищи, кто выше писал про другие системы и юзеров, ну конечно же разные в разных осях юзеры — это ежу в танке очевидно.
И посмотреть их 5 секундов.
ps: Btw, всех с Новым Годом! :)
+4
В Freebsd лучше /bin/csh использовать или /bin/sh
bash не ставится по умолчанию и чаще всего идет в комплекте какого-нибудь пингвиньего монстра.
bash не ставится по умолчанию и чаще всего идет в комплекте какого-нибудь пингвиньего монстра.
+3
Сами используйте эти отродья. У нас bash разворачивается по умолчанию везеде. Как плюс можно использовать нормальный синтаксис типа
[[ ]]
или (( ))
в скриптах.0
А что не так с csh?
+2
В среде с Linux и FreeBSD серверами? Только одно: стандарт на оболочку. Зачем сущости плодить и забивать голову?
0
Ну tcsh вполне себе хороший стандарт.
Можно его и на лине ставить тоже.
Можно его и на лине ставить тоже.
+2
Вопрос предпочтений, да.
0
99% скриптов на bash, только freebsd на sh, а так все инит и не только скрипты в линуксе на bash, зачем изучать другое обычному админу не знаю
+1
Вообще-то лет 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 какие-то алгоритмически-сложные штуки, которые проще и понятнее реализовать на скриптовых языках), а еще радикально производительнее, как правило.
0
Здесь недавно упоминали дистрибутив который тоже немножко поможет в тестировании.
+1
У меня есть машины со старым 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
+3
т.е. если у меня у того же апача стоит /sbin/nologin — я могу спать спокойно?
0
Нет. Сам апач то может писать в директории, ему плевать на оболочку.
Делаете
Делаете
su www-data -c bash
, и вперед проверять.+1
Сорри, промазал.
habrahabr.ru/post/164245/#comment_5651729
habrahabr.ru/post/164245/#comment_5651729
0
korp # su apache -c bash
This account is currently not available.
This account is currently not available.
0
Сама возможность выполнения "# su -l www-data", т.е. логина под www-data — уже некий изъян в безопасности.
0
Я думаю не особенный, если только сдуру вход по ssh ему не разрешить. Вот если опишите по пунктам почему конкретно изъян, поверю :-p
Тут такое дело, в безопасности часто пляшут с бубном не понимая причин, нужно всегда понимать конкретно потенциальную проблему.
Тут такое дело, в безопасности часто пляшут с бубном не понимая причин, нужно всегда понимать конкретно потенциальную проблему.
0
Такой же не особенный, как и «права на изменение и удаление апачевских логов». Просто есть такое правило, что права надо давать по минимуму, т.е. если юзеру не надо логиниться, то и давать ему такую возможность не надо. Ведь разрешать в sshd логиниться то не надо — по умолчанию дефолтным конфигом в большинстве дистрибутивов оно разрешено всем обычным юзерам с валидным шеллом. Если я через дыру в Апатче получу возможность выполнять код от апатчевского юзера, то возможность интерактивного шелла по ssh мне очень облегчит жизнь.
+1
Жеванный крот, никогда не думал что такую банальщину и такие «советы» будут писать на хабре. Это же основы администрирования.
P.S. Можете минусовать и сливать, но от этого моё мнение не изменится.
P.S. Можете минусовать и сливать, но от этого моё мнение не изменится.
+7
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая проверка безопасности на ваших серверах