@Wendor25 июл 2014 в 06:28

Начинайте думать

4 мин

34K

Веб-разработка *

+34

Комментарии 96

@nikolayvaganov 25 июл 2014 в 06:59

С праздником!!! =)

<zanuda_mode>
Чтобы запустить fpm пулы от рута, недостаточно просто указать user/group root в конфиге пула ( который, между прочим, принято держать не в общем php-fpm.conf а отдельным конфигом в pool.d ), а нужно еще в инит скрипте в список DAEMON_ARGS добавить "-R", ибо стандартно пул под рутом у вас запуститься не должен.
</zanuda_mode>

@Wendor 25 июл 2014 в 07:08

Ну это если говорить про debian/ubuntu.

@milar 25 июл 2014 в 07:07

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

По первому пункту, ionice, на мой взгляд, не лучшее решение. Для больших дисковых операций лучше использовать pv, одна из самых вкусных возможностей которой с ключом "-L" — позволяет ограничить скорость чтения с диска. В случае ionice жесткий диск все равно будет использоваться под завязку. Просто с немного измененной очередью и моментная задача прочесть более-менее большой объем все таки затормозится пока не будет окончена текущая фаза работы. А с pv мы можем выделить пул скорости.

График, на котором ограничены ресурсы при создании архива на сотни гигабайт

В копилку полезностей — используйте fail2ban. Простая возможность ограничить брутфорс паролей к вашему серверу.

@nikolayvaganov 25 июл 2014 в 07:13

При первом заходе на свой сервер отключаю парольную авторизацию ( PermitRootLogin without-password ), генерирую сертификат и далее уже никогда не вспоминаю про брутфорс.

@milar 25 июл 2014 в 07:48

Сертификаты — замечательно! Безопасность можно увеличивать практически бесконечно -). Поэтому инструменты обеспечения безопасности выбираются из специфики условий использования и соотношением уровня паранои к продуктивности работы с ней. Дабы ваш ответ не был из ряда «а я лучше», а мой бесполезным для других читателей ответом — приведу эту ссылочку на частный случай настройки авторизации по ключу к Ubuntu серверу с Windows машины.

@kashey 28 июл 2014 в 07:21

Есть мнение что сертификат менее безопасен чем пароль — его «увести» легко.
А вот сертификат с(под) паролем — вот это дело полезное.

@nikolayvaganov 28 июл 2014 в 07:45

Если на компьютере пользователя вирус — не спасет ни пароль ни сертификат. А против брутфорса сертификат — это выход, подобрать его в разы сложнее, чем пароль.

@dsx 25 июл 2014 в 12:24

В копилку полезностей — НЕ используйте fail2ban. Он не знает про IPv6 и умеет замечательно DoS'ить сервер, пока борется с брутфорсом.

@evg_krsk 25 июл 2014 в 14:04

Какие есть живые альтернативы?

@RicoX 25 июл 2014 в 14:10

psad+snort+таблицы фаирвола.

@evg_krsk 25 июл 2014 в 15:48

Совсем из другой оперы.

Из аналогов знаю mf2b, но выглядит он пока сыровато.

@RicoX 25 июл 2014 в 16:54

Опера одна и та-же, цель не допустить вторжения на свои сервера, а что мы делаем лог парсим или попытки этого самого вторжения сути не меняет, ваш f2b, при знании что он установлен, замечательно валится генерацией спуфленых пакетов от имени вышестоящего сервера либо просто забиваем весь его лог попытками соединения с кучи разных IP.

@dsx 25 июл 2014 в 14:32

Для SSH — sshguard.

@evg_krsk 25 июл 2014 в 15:45

Кроме ssh много чего бывает. Нужно универсальное.

@dsx 25 июл 2014 в 15:53

Не бывает универсального. Точнее, есть — fail2ban — и оно плохо работает именно тогда, когда нужно, чтобы работало хорошо. Проблема глубже лежит к сожалению.

@evg_krsk 25 июл 2014 в 15:56

Это не отменяет наличие задач, которые им как-то да решаются. Я не защищаю, сам ищу вменяемую альтернативу :-)

@dsx 25 июл 2014 в 17:58

Есть обходные пути с запуском анализа логов и блокированием после достижения определённого лимита неудачных попыток аутентификации. Но это требует от приложений сообщать о таких событиях с минимальными накладными расходами, что не всегда возможно. Насколько я знаю, вменяемых альтернатив нет. Да и на мой взгляд если писать универсальное средство, то всё в итоге упирается в парсинг логов, что, мягко говоря, процесс небыстрый. Вот если бы был какой-то общепринятый стандарт сигнализации для приложений, но это была бы совсем другая вселенная.

@ValdikSS 28 июл 2014 в 07:28

Он не только для ssh, а еще для кучи всего. Не вводите evg_krsk в заблуждение.

@evg_krsk 28 июл 2014 в 08:11

Спасибо, посмотрю. Никому нельзя верить :-)

@borisko 27 июл 2014 в 07:19

csf+lfd

@evg_krsk 27 июл 2014 в 08:46

Спасибо, выглядит интересно.

@J_o_k_e_R 25 июл 2014 в 18:42

Можно, пожалуйста, поподробнее про DoS? Так как для IPv6 я его почти в порядке изучения питона доработал взяв за основу информацию из их wiki.

@dsx 26 июл 2014 в 14:16

Логи пишутся с ужасающей скоростью, демон начинает загребать и без того малодоступные ресурсы под себя, чтобы всё это распарсить, и в итоге помогает уложить сервер. Сразу скажу, я такое видел один раз только, но осадочек остался.

@J_o_k_e_R 26 июл 2014 в 14:21

Ну не надо парсить логи, которые могут писаться с ужасающей скоростью. А те котороые парсить настраивать только то, что нужно для fail2ban'а.

@dsx 26 июл 2014 в 23:28

Свежая идея. Но что же делать, если это уже был отдельный лог только с ошибками Авторизации именно для fail2ban? Ещё более как-то его настроить? Кстати, тоже пробовали. Писать только каждую десятую неудачную попытку, например. Помогло по началу, но «с той стороны» тоже не идиоты сидели.

@Nikobraz 25 июл 2014 в 07:34

Со всем согласен, кроме установки пакетов. Почему и сорцов ставить софт хуже? Лниуксы не админил, только Фряху.

@nikolayvaganov 25 июл 2014 в 07:51

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

@milar 25 июл 2014 в 07:54

Нет ничего плохого в установке пакетов из исходников. Однако, вопрос как именно их ставить. Стандартно через make install — не лучшее решение. Особенно после ситуации, когда пакет оказывается потом ненужным. Все установленое «рассасывается» по системе непонятно куда. Поэтому есть решение получше — собрать свой пакет из исходников, который затем устанавить. Пример статьи как это делается на примере Ubuntu.

@iznakurnozh 25 июл 2014 в 08:45

Потому что не у всех пакетов есть нормальное правило для make uninstall.
[facepalm]Я буду обновлять комментарии прежде чем писать свой[/ facepalm]

@heathen 25 июл 2014 в 11:43

На FreeBSD из сырцов — только через ports. Потому что иначе управлять всем этим вручную скомпилированным зоопарком со всеми зависимостями и т.п. становится нереально через какое-то время. Ну, и гораздо проще ведь сделать
cd /usr/ports/<chapter>/<tool_name> ; make install clean
И получить через какое-то время установленный по всем правилам софт со всеми зависимостями, фряшными стартовыми скриптами и т.п.

@northbear 27 июл 2014 в 07:26

На Linux, если вы не на слаке (хотя там тоже появился пакетный менеджер говорят), подавляющее большинство работает с пакетами. Если же админ на Linux ставит приложение из сырцов, то он как правило знает что делает…
Должно соблюдаться простое правило: Из сырцов собираем пакет и его уже устанавливаем… Ставить на прямую минуя штатный пакетный менеджер — это гарантированная попаболь в будущем…
Для FreeBSD c некоторых пор придерживаемся того же правила…
Более того, мы делаем локальные репозитории пакетов ставим им самый большой приоритет. Если в локальных репозиториях пересобранных пакетов нет, то ищем в публичных…

НЛО прилетело и опубликовало эту надпись здесь

@milar 25 июл 2014 в 07:56

Например, небольшой смысл в том, что брутфорсеры «любят» подбирать пароли именно к «root» имени. Есть меньшая вероятность подбора пароля к пользователю «superuservasya».

@skobkin 25 июл 2014 в 08:45

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

НЛО прилетело и опубликовало эту надпись здесь

@qw1 26 июл 2014 в 06:16

Заходить строго своим юзером нужно для порядка. Заходишь на сервер — представься, пожалуйста.
Другая причина — менять пароль рута бывает страшно на продакшене (что может внезапно отвалиться, никто не знает). Поэтому пароль не меняют. Увольняется админ Вася — блокируем учётку vasya. И пароль рута менять не надо, и нет головной боли, что кто-то может зайти, используя информацию от уволившегося сотрудника.

Впрочем, если у сервера один админ, запрет входа рутом это лишнее.

@max_mara 25 июл 2014 в 08:19

О первых трех случаях хочется сказать, что эти программисты дебилы.

@Wendor 25 июл 2014 в 08:45

Не дебилы, просто у них нет достаточного опыта.

@max_mara 25 июл 2014 в 18:45

Eще в далеком 2008 году, когда еще и не было намека на border-radius и css3, а я верстал простенькие сайты и ходил в 9 класс, я уже знал, что не стоит складировать изображения пачками в папках, и кешировать все трудоемкие операции если не хотите получить джумлу. Об этом даже Фленов помоему писал, которого так не любили на винграде. А сейчас что? У нас парнишка в Днепропетровске прошел курс в академии Шаг и плати ему теперь по 800 долларов за элементарный форм билдер на jQuery Mobile.

@webkumo 25 июл 2014 в 09:20

Скорее студенты…

@blind_oracle 25 июл 2014 в 12:50

О, и имя им легион. Часто сталкиваюсь с таким говнокодом, причем обычно это продукт «известных» и «уважаемых» веб-студий и им подобных.

@luckyredhot 25 июл 2014 в 15:12

Да ладно, обычное дело, если аутсорс)

@northbear 27 июл 2014 в 07:32

Просто каждый должен заниматься своим делом…

@ivs13 25 июл 2014 в 09:16

Случай 3.
При запуске скрипта создался файл.
Скрипт по каким-то причинам не откработал до конца и лок-файл не удалился.
Больше скрипт не запускается, т.к. лок-файл существует.
Приплыли?

@maxru 25 июл 2014 в 09:41

Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

Лок-файлы не умное решение.

@dsx 25 июл 2014 в 12:30

С лок-файлами уже всё давно придумано за нас. flock (man 1 flock) достаточно умный. Грепать по списку процессов — вот где не умное решение. Вместе с неидемпотентными скриптами такой подход может произвести совершенно феерические спецэффекты.

@muzzle 28 июл 2014 в 04:59

Дополню про греп имени процесса.
Был у нас замечательный скриптик бэкапа/рестора файрбердовских баз, здоровенный, умный.
И отслеживал он свою запущенность именно грепая свое имя в списке процессов.
И однажды, на свежеустановленной системе, он работать перестал, потому что при грепе в вывод стал попадать и сам греп.
Т.е. с точки зрения скрипта он был запущен всегда.
После этого переехали на генерацию/проверку pid файлов, а потом уже и на лок файлы.

(PS: а про pgrep никто тогда не вспомнил)

@muzzle 25 июл 2014 в 10:44

Лок файл в скрипте открывается на эксклюзивную запись, если скрипт умер — ядро блокировку само снимет.
Если залочить на эксклюзивную запись удалось — значит работаем, не удалось — кто то другой работает, отваливаемся.

@Wendor 25 июл 2014 в 15:51

Register_shutdown_function выполняет функцию после того как скрипт отработал, даже если выполнение прервалось по ошибке или даже die. А на случай ребута, хорошо бы класть этот локфайл в tmpfs (хорошо нынче в linux он практически везде есть). Возможно конечно есть тут подводные камни и есть вероятность, что схема отработает коряво, но я пока такого ни разу не встретил за свои годы.

@alexkbs 26 июл 2014 в 03:09

Можно и без tmpfs:

flock($GLOBALS[__FILE__] = fopen($_SERVER['PHP_SELF'], "r"), LOCK_EX | LOCK_NB) or exit(-1);

В этом случае для работы блокировки больше ничего не нужно делать.

@webkumo 25 июл 2014 в 09:19

WhiteList для доступа на сервер? Серьёзно? А если провайдер вам IP поменяет, что делать будете? А если ещё и предупредит (как это всегда делается) только на сайте и вы об этом узнаете постфактум, когда сервер скажет «обломинго»?

@dsx 25 июл 2014 в 12:33

Port knock. Jump server. Сменить провайдера. На выбор.

@webkumo 25 июл 2014 в 13:25

Ну Port knock — годное решение. Jump server не защищён в полной мере от этой проблемы (хотя уже на порядок лучше, согласен). При смене провайдера IP поменяется сразу (покажите мне того провайдера, который вообще никогда не поменяет IP, если он был жёстко прописан в договоре/доп. соглашении?)

@Komzpa 25 июл 2014 в 14:54

byfly / Белтелеком уже четыре года не менял мне IP.

@luckyredhot 25 июл 2014 в 15:15

Да ладно, что вы паникуете! Всегда есть вариант «кусать локти»))

@Wendor 25 июл 2014 в 15:48

Прочитайте заголовок статьи! Если есть вероятность того, что провайдер сменит IP — думайте. У меня на серверах указано несколько IP, с которых я могу зайти. Если есть опасность потерять IP, впишите туда hostname который заведете на no-ip.

@northbear 27 июл 2014 в 09:02

Не имейте дело с халявщиками. Иначе людей, которые держат отсветственные сервера на халявных аккаунтах, по которым провайдер может сменить ip без соответствующего уведомления, не назовёшь.…
Если провайдер сменит ip без уведомления, вам отсутствие whitelist'а ничем не поможет. Вообще такой фигней теоретически могут страдать разве что хостеры, но там услугу virtual console никто не отменял…

@webkumo 27 июл 2014 в 12:31

Извините, а при чём тут ip сервера? Речь идёт о ip, которым разрешено доступ по ssh. А вот с провайдерами для физ лиц (а в статье не было различия между потенциальным стартапом, который делает один человек и под это дело сервер заказал, и компанией, которая под определённые нужды берёт себе сервер. Вот для компании (даже сравнительно мелкой) можно достаточно легко (в договоре) добиться стабильного выходного ip с нормальным уведомлением в случае если по какой-то причине его придётся менять. А жёстко прописанные в договоре с ФЛ внешние IP я встречал всего пару раз и было это довольно давно (и были они в доп. соглашении).

@northbear 27 июл 2014 в 18:16

Э=э… Про клиентскую сторону я вообще проблем не вижу… Просто прописывать нужно больше, чем один адрес…
Для администрирования откуда-нибудь издалека, где не пойми какой ip, мы используем прокси внутри нашей рабочей сети…

У меня, физлица, дома прописан реальный ip. Как раз именно для таких целей. Мне вообще никакого труда не составило объяснить админам провайдера для чего мне реальный ip…

@webkumo 27 июл 2014 в 20:42

И какие гранатии, что вам этот IP не сменят, какие гарантии, что при смене объявят как-то иначе, чем у себя на сайтики? В общем чтобы не поиметь проблем от нежданчика нужно иметь схему отличную от вайт-листа. Примеры — предложенный порт-кнок, проксирующий vpn,… Одновременно с бонусами защиты от потери мы получаем защиту от прицельного спуфа ip с попыткой продолбиться.

@northbear 28 июл 2014 в 05:18

В этом мире вообще никаких гарантий нет. Гарантии что-то типа «честного слова», которые дают не очень доверяющие друг другу люди…
Поиметь, как вы пишите, «нежданчика» можно при любой схеме обеспечения безопасности. Безопасность — это всегда ограничения, а значит потенциальные проблемы доступа… Точно также провайдер может вдруг «озаботиться» безопасностью и заблокировать «левый», по его мнению, трафик на «левые» порты, и всё вы приехали со своими порт-кноками и vpn'ами…
Вопрос лишь в том, предусматриваете ли вы у себя альтернативные варианты доступа или полагаетесь на какой-то один. Если последнее, то вы сами себе злобный буратино…

@xandr0s 27 июл 2014 в 14:18

А если провайдер вам IP поменяет, что делать будете

зайду со второго IP, два сразу вряд ли поменяют, правда ведь? А если мне нужно попасть срочно из очень необычного места, где нет возможности пробросить свой привычный IP — ребут сервера, после ребута есть несколько минут для доступа всем. Этакий костыль «на всякий случай»

@webkumo 27 июл 2014 в 17:18

Тот ещё костыль… Имхается мне упомянутый первым ответившим мне человеком PortKnock куда более эффективнаня штука, позволяющая несколько увеличить секурность и при этом иметь куда большее удобство.

@maxru 25 июл 2014 в 09:40

Случай 2.
Лучше картинки разбивать по папкам не по датам, а, скажем, по первым нескольким символам хеша и по нескольким уровням, чтобы более равномерно распределить их по папкам.

Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

Странные у вас программисты какие-то, не умные.

@Wendor 25 июл 2014 в 16:17

2. Кому как. Кому-то нужно по этим файлам потом ориентироваться.
3. Реализация может быть любой. Главное, чтобы скрипт не запускался в нескольких экземплярах.

Не опытные.

@Ernillew 25 июл 2014 в 09:47

> В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root

Какая у вас жуткая реальность.
В моей реальности в 100% случаев под рутом не ходят.
Пароли? Забудьте о паролях, откройте для себя чудесный мир ключей!

И, с праздником, коллега!

@Wendor 25 июл 2014 в 16:20

Такова моя статистика. :(
Я открыл для себя ключи давным давно. Просто не всегда есть возможность ими пользоваться. Хотя вы правы, если есть возможность и условия позволяют — ключи тоже отличный вариант.
С праздником! ;-)

@dmitriko 25 июл 2014 в 21:19

Не могу себе представить ситуацию когда нельзя пользоваться ключами.
Что бы это могло быть?

@Ernillew 26 июл 2014 в 00:18

Вот мне тоже стало интересно. Что такое может быть, что нельзя ключи юзать.

@amgorb 25 июл 2014 в 09:57

Знакомые какие все ситуации :). Насчет sudo/su имхо с ключами вход по руту (а если призывают админа, то 100% придется делать что-то от рута) намного удобней.

@sledopit 25 июл 2014 в 10:06

мои 5 копеек.

Иногда приходят и говорят «а-а-а!!! место на диске закончилось! мы все умрём!». И тут начинается веселье.

1. Лезешь на сервер — места до фига, но некоторые замечательные программисты считают ненужным подтирать за собой сессионные файлы. вот inod'ы и заканчиваются.
2. Лезешь на сервер — места до фига. И айнодов полно. После пыток пользователей выясняется, что вот только что удалили огромный файл, а место всё равно не освободилось. про процессы, использующие эти файлы, можно не помнить.
3. Лезешь на сервер — а места и правда нет (:

@dsx 25 июл 2014 в 12:36

Первая проблема, мягко говоря, надумана. Но если такое действительно было, то надо по рукам надавать и программистам, и админу. Первым за разгильдяйство и свинарник, вторым — за использование файловых систем для локалхостов на проде.

@Wendor 25 июл 2014 в 16:21

А еще, люди забывают ставить логи в ротацию или логируют все подрят. И блин….куда же делось место…

@aml 25 июл 2014 в 18:16

На пункт 2. А как это у вас до фига свободного места, если огромный файл до сих пор на диске, пусть и анлинкнутый? du покажет 0 свободного места, как ему и положено.

НЛО прилетело и опубликовало эту надпись здесь

@Komzpa 25 июл 2014 в 14:52

> SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts

простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.

НЛО прилетело и опубликовало эту надпись здесь

@Komzpa 25 июл 2014 в 15:38

Кажется, вы не знакомы с тем, как базы хранят данные.

В PostgreSQL, к примеру, поля длиннее 8 кб сначала пытаются скомпрессироваться, чтобы влезть в 8 кб, а потом выносятся во внешние, спрятанные от юзера TOAST-таблицы:
www.postgresql.org/docs/9.3/interactive/storage-toast.html

Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.

После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.

@velvetcat 25 июл 2014 в 15:18

SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts

Забудьте о звездочке, всегда перечисляйте только те поля, которые действительно нужны. База сама выберет, какую стратегию чтения выбрать, плюс сможет задействовать покрывающие индексы.

@Cront 25 июл 2014 в 12:00

>hosts.allow
>sshd: 123.231.132.213
>И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.

Замена SSH порта на любой из upper range отлично справляется с брутом. Ограничение по IP все-же сильно влияет на возможности доступа.

НЛО прилетело и опубликовало эту надпись здесь

@Eklykti 26 июл 2014 в 00:02

> Замена SSH порта на любой из upper range отлично справляется с брутом

За исключением тех случаев, когда брутят конкретно тебя и настоящий порт успешно высканен нмапом.

@luckyredhot 25 июл 2014 в 14:17

запретить авторизацию от рута (PermitRootLogin yes) в sshd_config.

Это как раз разрешает её)

@Ernillew 25 июл 2014 в 14:21

Я так подозреваю, что человек скопировал строчку из дефолтного конфига просто, забыл сменить на no :)

@luckyredhot 25 июл 2014 в 14:23

У человека, нависавшего данную статью априори не должно быть дефолтных конфигов!

Может, тонкая ирония, или как)

@Ernillew 25 июл 2014 в 14:50

Статья выдает в коллеге новичка, так что думаю, что ошибка при копировании.
Вот эти «90% случаев ходят под рутом» выдают новичка с головой.

@luckyredhot 25 июл 2014 в 14:52

Автору 27, сомневаюсь, что он новичок :)

@Ernillew 25 июл 2014 в 15:05

Всякое бывает :)

@Wendor 25 июл 2014 в 16:31

Ошибаетесь. Первый линукс я скачивал в далеком 2002-м по dialup соединению. А плотно работаю с linux серверами с 2006-го. А то, что у меня такая статистика — не говорит о моем опыте ни слова, лишь говорит об опыте моих знакомых.

@Wendor 25 июл 2014 в 16:25

А я не говорил что строчка запрещает рута, я лишь привел опцию которая в ответе за это. Но давайте исправлю, раз так подумали. :-)

@luckyredhot 25 июл 2014 в 16:30

Именно так оно и читалось)
Спасибо за исправление. И за ionice, кстати!

@velvetcat 25 июл 2014 в 15:11

Кейсы 2 — 4 — жесть какая-то, и про работу от рута тоже. Имхо надо не думать призывать этих ребят, а просто держаться от них подальше.

@Wendor 25 июл 2014 в 16:27

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

@scarab 25 июл 2014 в 17:56

К каждой команде программистов нужно приставлять админа с металлической линейкой, чтоб бил по пальцам.

У них просто в другом режиме работает голова – замечал даже по себе: если начинаешь писать что-то посерьезнее наколеночного скрипта, то мозг, находясь в programmer mode, банально решает другие задачи и может легко допустить косяк, на который в admin mode мгновенно бы среагировал.

@aml 25 июл 2014 в 18:22

Если в случае 2 у вас есть nginx, его же можно заставить самого и кэшировать миниатюрки. Плюсы — можно ограничить общий объём кэша и автоматически выбрасывать из него старье, которое никто не запрашивает.

@J_o_k_e_R 25 июл 2014 в 19:04

В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root и практически сразу, эти сервера начинают брутфорсить. Это не есть правильно.
Что можно сделать? Для начала создать пользователя, под которым потом заходить по ssh. А затем, запретить авторизацию от рута (PermitRootLogin no — запретит авторизацию от рута) в sshd_config.

Настолько же спорное, насколько и популярное мнение (я не использую слово «неверное», так как уж очень оно популярное, а я не люблю себя считать умнее других). Не знаю как у других, но большинство работ на сервере из консоли у меня, как у администратора сервера требуют доступа суперпользователя. Поэтому работаю я под ним, просто приучил себя думать прежде, чем жать enter и аккуратно копипастить в консоль.

Как же обеспечить доступ суперпользователя? Прямой логин, su или sudo. Рассмотрим все три варианта. Я приверженец первого.

Прямой логин Вам не нравится брутфорсом? Антибрутер (sshguard или простенький самописный или что еще) + PermitRootLogin without-password убирают какую-либо вероятность брута. Для особенных параноиков могу предложить поднять openvpn и разрешить логин только из приватной сети или внедрить максимально IPv6 (на клиентах через туннели), а на серверах его много уже где дают, хотя можно и туннели, и вешать SSH на какой-то один специально выделенный IPv6 из выданного Вам диапазона (обычно конечному клиенту выдают диапазон /64).

su мне не нравится тем, что обеспечивает возможность повышения полномочий регулярного пользователя. И завязывает на наличие пароля у рута, который можно брутить локально, сломав какой-нибудь сервис запущенный от регулярного пользователя. Да, я знаю, что обычно возможность использовать su до рута залочена на специальную группу (обычно wheel) через PAM, но зачем вносить такую сложную цепочку в безопасность Вашей системы?! Тогда как у меня на серверах сделано либо passwd -l root, либо просто восклицательный знак вместо пароля у рута в /etc/shadow.

sudo в принципе не серверная вещь имхо. Она широко известна в узких кругах уязвимостью, просуществовавшей в ней на протяжении несколько лет (хоть и неизвестной большую часть этого времени публично). Да, такие уязвимости бывают в ней не часто, но если можно избежать потенциально дырявого ПО, то зачем его использовать? Желающие ссылку, пожалуйста, посмотрите в гугле уязвимости sudo сами.

Примечание: я говорю про ситуацию, когда только один админ (ну или несколько с одинаковым суперпользовательским доступом) имеют доступ на сервер по SSH. Когда их несколько, да еще и доступ суперпользователя дробится на несколько кусков, то без sudo\selinux\rbac не обойтись, к сожалению.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий