Комментарии 96
С праздником!!! =)
<zanuda_mode>
Чтобы запустить fpm пулы от рута, недостаточно просто указать user/group root в конфиге пула ( который, между прочим, принято держать не в общем php-fpm.conf а отдельным конфигом в pool.d ), а нужно еще в инит скрипте в список DAEMON_ARGS добавить "-R", ибо стандартно пул под рутом у вас запуститься не должен.
</zanuda_mode>
<zanuda_mode>
Чтобы запустить fpm пулы от рута, недостаточно просто указать user/group root в конфиге пула ( который, между прочим, принято держать не в общем php-fpm.conf а отдельным конфигом в pool.d ), а нужно еще в инит скрипте в список DAEMON_ARGS добавить "-R", ибо стандартно пул под рутом у вас запуститься не должен.
</zanuda_mode>
Действительно, сумбурно -). Однако, для дня системного администратора подборка случаев получается интересной тематичностью дня (возможно, в комментариях имеет смысл продолжить своими случаями с описаниями более лучшей практики?)
По первому пункту, ionice, на мой взгляд, не лучшее решение. Для больших дисковых операций лучше использовать pv, одна из самых вкусных возможностей которой с ключом "-L" — позволяет ограничить скорость чтения с диска. В случае ionice жесткий диск все равно будет использоваться под завязку. Просто с немного измененной очередью и моментная задача прочесть более-менее большой объем все таки затормозится пока не будет окончена текущая фаза работы. А с pv мы можем выделить пул скорости.
В копилку полезностей — используйте fail2ban. Простая возможность ограничить брутфорс паролей к вашему серверу.
По первому пункту, ionice, на мой взгляд, не лучшее решение. Для больших дисковых операций лучше использовать pv, одна из самых вкусных возможностей которой с ключом "-L" — позволяет ограничить скорость чтения с диска. В случае ionice жесткий диск все равно будет использоваться под завязку. Просто с немного измененной очередью и моментная задача прочесть более-менее большой объем все таки затормозится пока не будет окончена текущая фаза работы. А с pv мы можем выделить пул скорости.
График, на котором ограничены ресурсы при создании архива на сотни гигабайт
В копилку полезностей — используйте fail2ban. Простая возможность ограничить брутфорс паролей к вашему серверу.
При первом заходе на свой сервер отключаю парольную авторизацию ( PermitRootLogin without-password ), генерирую сертификат и далее уже никогда не вспоминаю про брутфорс.
Сертификаты — замечательно! Безопасность можно увеличивать практически бесконечно -). Поэтому инструменты обеспечения безопасности выбираются из специфики условий использования и соотношением уровня паранои к продуктивности работы с ней. Дабы ваш ответ не был из ряда «а я лучше», а мой бесполезным для других читателей ответом — приведу эту ссылочку на частный случай настройки авторизации по ключу к Ubuntu серверу с Windows машины.
Есть мнение что сертификат менее безопасен чем пароль — его «увести» легко.
А вот сертификат с(под) паролем — вот это дело полезное.
А вот сертификат с(под) паролем — вот это дело полезное.
В копилку полезностей — НЕ используйте fail2ban. Он не знает про IPv6 и умеет замечательно DoS'ить сервер, пока борется с брутфорсом.
Какие есть живые альтернативы?
psad+snort+таблицы фаирвола.
Опера одна и та-же, цель не допустить вторжения на свои сервера, а что мы делаем лог парсим или попытки этого самого вторжения сути не меняет, ваш f2b, при знании что он установлен, замечательно валится генерацией спуфленых пакетов от имени вышестоящего сервера либо просто забиваем весь его лог попытками соединения с кучи разных IP.
Для SSH — sshguard.
Кроме ssh много чего бывает. Нужно универсальное.
Не бывает универсального. Точнее, есть — fail2ban — и оно плохо работает именно тогда, когда нужно, чтобы работало хорошо. Проблема глубже лежит к сожалению.
Это не отменяет наличие задач, которые им как-то да решаются. Я не защищаю, сам ищу вменяемую альтернативу :-)
Есть обходные пути с запуском анализа логов и блокированием после достижения определённого лимита неудачных попыток аутентификации. Но это требует от приложений сообщать о таких событиях с минимальными накладными расходами, что не всегда возможно. Насколько я знаю, вменяемых альтернатив нет. Да и на мой взгляд если писать универсальное средство, то всё в итоге упирается в парсинг логов, что, мягко говоря, процесс небыстрый. Вот если бы был какой-то общепринятый стандарт сигнализации для приложений, но это была бы совсем другая вселенная.
Он не только для ssh, а еще для кучи всего. Не вводите evg_krsk в заблуждение.
csf+lfd
Можно, пожалуйста, поподробнее про DoS? Так как для IPv6 я его почти в порядке изучения питона доработал взяв за основу информацию из их wiki.
Логи пишутся с ужасающей скоростью, демон начинает загребать и без того малодоступные ресурсы под себя, чтобы всё это распарсить, и в итоге помогает уложить сервер. Сразу скажу, я такое видел один раз только, но осадочек остался.
Со всем согласен, кроме установки пакетов. Почему и сорцов ставить софт хуже? Лниуксы не админил, только Фряху.
дальнейшая поддержка актуальности пакета, поставленного не из репозиторев под большим вопросом, если таких пакетов больше нуля.
Нет ничего плохого в установке пакетов из исходников. Однако, вопрос как именно их ставить. Стандартно через make install — не лучшее решение. Особенно после ситуации, когда пакет оказывается потом ненужным. Все установленое «рассасывается» по системе непонятно куда. Поэтому есть решение получше — собрать свой пакет из исходников, который затем устанавить. Пример статьи как это делается на примере Ubuntu.
Потому что не у всех пакетов есть нормальное правило для make uninstall.
[facepalm]Я буду обновлять комментарии прежде чем писать свой[/ facepalm]
[facepalm]Я буду обновлять комментарии прежде чем писать свой[/ facepalm]
На FreeBSD из сырцов — только через ports. Потому что иначе управлять всем этим вручную скомпилированным зоопарком со всеми зависимостями и т.п. становится нереально через какое-то время. Ну, и гораздо проще ведь сделать
И получить через какое-то время установленный по всем правилам софт со всеми зависимостями, фряшными стартовыми скриптами и т.п.
cd /usr/ports/<chapter>/<tool_name> ; make install cleanИ получить через какое-то время установленный по всем правилам софт со всеми зависимостями, фряшными стартовыми скриптами и т.п.
На Linux, если вы не на слаке (хотя там тоже появился пакетный менеджер говорят), подавляющее большинство работает с пакетами. Если же админ на Linux ставит приложение из сырцов, то он как правило знает что делает…
Должно соблюдаться простое правило: Из сырцов собираем пакет и его уже устанавливаем… Ставить на прямую минуя штатный пакетный менеджер — это гарантированная попаболь в будущем…
Для FreeBSD c некоторых пор придерживаемся того же правила…
Более того, мы делаем локальные репозитории пакетов ставим им самый большой приоритет. Если в локальных репозиториях пересобранных пакетов нет, то ищем в публичных…
Должно соблюдаться простое правило: Из сырцов собираем пакет и его уже устанавливаем… Ставить на прямую минуя штатный пакетный менеджер — это гарантированная попаболь в будущем…
Для FreeBSD c некоторых пор придерживаемся того же правила…
Более того, мы делаем локальные репозитории пакетов ставим им самый большой приоритет. Если в локальных репозиториях пересобранных пакетов нет, то ищем в публичных…
НЛО прилетело и опубликовало эту надпись здесь
Например, небольшой смысл в том, что брутфорсеры «любят» подбирать пароли именно к «root» имени. Есть меньшая вероятность подбора пароля к пользователю «superuservasya».
Выключить логин от рута и снизить вероятность брутфорса его до нуля. Ну и заходить сразу под рутом не обязательно, если, конечно, задача того не требует.
Заходить строго своим юзером нужно для порядка. Заходишь на сервер — представься, пожалуйста.
Другая причина — менять пароль рута бывает страшно на продакшене (что может внезапно отвалиться, никто не знает). Поэтому пароль не меняют. Увольняется админ Вася — блокируем учётку vasya. И пароль рута менять не надо, и нет головной боли, что кто-то может зайти, используя информацию от уволившегося сотрудника.
Впрочем, если у сервера один админ, запрет входа рутом это лишнее.
Другая причина — менять пароль рута бывает страшно на продакшене (что может внезапно отвалиться, никто не знает). Поэтому пароль не меняют. Увольняется админ Вася — блокируем учётку vasya. И пароль рута менять не надо, и нет головной боли, что кто-то может зайти, используя информацию от уволившегося сотрудника.
Впрочем, если у сервера один админ, запрет входа рутом это лишнее.
О первых трех случаях хочется сказать, что эти программисты дебилы.
Не дебилы, просто у них нет достаточного опыта.
Eще в далеком 2008 году, когда еще и не было намека на border-radius и css3, а я верстал простенькие сайты и ходил в 9 класс, я уже знал, что не стоит складировать изображения пачками в папках, и кешировать все трудоемкие операции если не хотите получить джумлу. Об этом даже Фленов помоему писал, которого так не любили на винграде. А сейчас что? У нас парнишка в Днепропетровске прошел курс в академии Шаг и плати ему теперь по 800 долларов за элементарный форм билдер на jQuery Mobile.
Скорее студенты…
О, и имя им легион. Часто сталкиваюсь с таким говнокодом, причем обычно это продукт «известных» и «уважаемых» веб-студий и им подобных.
Да ладно, обычное дело, если аутсорс)
Просто каждый должен заниматься своим делом…
Случай 3.
При запуске скрипта создался файл.
Скрипт по каким-то причинам не откработал до конца и лок-файл не удалился.
Больше скрипт не запускается, т.к. лок-файл существует.
Приплыли?
При запуске скрипта создался файл.
Скрипт по каким-то причинам не откработал до конца и лок-файл не удалился.
Больше скрипт не запускается, т.к. лок-файл существует.
Приплыли?
Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.
Лок-файлы не умное решение.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.
Лок-файлы не умное решение.
С лок-файлами уже всё давно придумано за нас. flock (man 1 flock) достаточно умный. Грепать по списку процессов — вот где не умное решение. Вместе с неидемпотентными скриптами такой подход может произвести совершенно феерические спецэффекты.
Дополню про греп имени процесса.
Был у нас замечательный скриптик бэкапа/рестора файрбердовских баз, здоровенный, умный.
И отслеживал он свою запущенность именно грепая свое имя в списке процессов.
И однажды, на свежеустановленной системе, он работать перестал, потому что при грепе в вывод стал попадать и сам греп.
Т.е. с точки зрения скрипта он был запущен всегда.
После этого переехали на генерацию/проверку pid файлов, а потом уже и на лок файлы.
(PS: а про pgrep никто тогда не вспомнил)
Был у нас замечательный скриптик бэкапа/рестора файрбердовских баз, здоровенный, умный.
И отслеживал он свою запущенность именно грепая свое имя в списке процессов.
И однажды, на свежеустановленной системе, он работать перестал, потому что при грепе в вывод стал попадать и сам греп.
Т.е. с точки зрения скрипта он был запущен всегда.
После этого переехали на генерацию/проверку pid файлов, а потом уже и на лок файлы.
(PS: а про pgrep никто тогда не вспомнил)
Лок файл в скрипте открывается на эксклюзивную запись, если скрипт умер — ядро блокировку само снимет.
Если залочить на эксклюзивную запись удалось — значит работаем, не удалось — кто то другой работает, отваливаемся.
Если залочить на эксклюзивную запись удалось — значит работаем, не удалось — кто то другой работает, отваливаемся.
Register_shutdown_function выполняет функцию после того как скрипт отработал, даже если выполнение прервалось по ошибке или даже die. А на случай ребута, хорошо бы класть этот локфайл в tmpfs (хорошо нынче в linux он практически везде есть). Возможно конечно есть тут подводные камни и есть вероятность, что схема отработает коряво, но я пока такого ни разу не встретил за свои годы.
WhiteList для доступа на сервер? Серьёзно? А если провайдер вам IP поменяет, что делать будете? А если ещё и предупредит (как это всегда делается) только на сайте и вы об этом узнаете постфактум, когда сервер скажет «обломинго»?
Port knock. Jump server. Сменить провайдера. На выбор.
Да ладно, что вы паникуете! Всегда есть вариант «кусать локти»))
Прочитайте заголовок статьи! Если есть вероятность того, что провайдер сменит IP — думайте. У меня на серверах указано несколько IP, с которых я могу зайти. Если есть опасность потерять IP, впишите туда hostname который заведете на no-ip.
Не имейте дело с халявщиками. Иначе людей, которые держат отсветственные сервера на халявных аккаунтах, по которым провайдер может сменить ip без соответствующего уведомления, не назовёшь.…
Если провайдер сменит ip без уведомления, вам отсутствие whitelist'а ничем не поможет. Вообще такой фигней теоретически могут страдать разве что хостеры, но там услугу virtual console никто не отменял…
Если провайдер сменит ip без уведомления, вам отсутствие whitelist'а ничем не поможет. Вообще такой фигней теоретически могут страдать разве что хостеры, но там услугу virtual console никто не отменял…
Извините, а при чём тут ip сервера? Речь идёт о ip, которым разрешено доступ по ssh. А вот с провайдерами для физ лиц (а в статье не было различия между потенциальным стартапом, который делает один человек и под это дело сервер заказал, и компанией, которая под определённые нужды берёт себе сервер. Вот для компании (даже сравнительно мелкой) можно достаточно легко (в договоре) добиться стабильного выходного ip с нормальным уведомлением в случае если по какой-то причине его придётся менять. А жёстко прописанные в договоре с ФЛ внешние IP я встречал всего пару раз и было это довольно давно (и были они в доп. соглашении).
Э=э… Про клиентскую сторону я вообще проблем не вижу… Просто прописывать нужно больше, чем один адрес…
Для администрирования откуда-нибудь издалека, где не пойми какой ip, мы используем прокси внутри нашей рабочей сети…
У меня, физлица, дома прописан реальный ip. Как раз именно для таких целей. Мне вообще никакого труда не составило объяснить админам провайдера для чего мне реальный ip…
Для администрирования откуда-нибудь издалека, где не пойми какой ip, мы используем прокси внутри нашей рабочей сети…
У меня, физлица, дома прописан реальный ip. Как раз именно для таких целей. Мне вообще никакого труда не составило объяснить админам провайдера для чего мне реальный ip…
И какие гранатии, что вам этот IP не сменят, какие гарантии, что при смене объявят как-то иначе, чем у себя на сайтики? В общем чтобы не поиметь проблем от нежданчика нужно иметь схему отличную от вайт-листа. Примеры — предложенный порт-кнок, проксирующий vpn,… Одновременно с бонусами защиты от потери мы получаем защиту от прицельного спуфа ip с попыткой продолбиться.
В этом мире вообще никаких гарантий нет. Гарантии что-то типа «честного слова», которые дают не очень доверяющие друг другу люди…
Поиметь, как вы пишите, «нежданчика» можно при любой схеме обеспечения безопасности. Безопасность — это всегда ограничения, а значит потенциальные проблемы доступа… Точно также провайдер может вдруг «озаботиться» безопасностью и заблокировать «левый», по его мнению, трафик на «левые» порты, и всё вы приехали со своими порт-кноками и vpn'ами…
Вопрос лишь в том, предусматриваете ли вы у себя альтернативные варианты доступа или полагаетесь на какой-то один. Если последнее, то вы сами себе злобный буратино…
Поиметь, как вы пишите, «нежданчика» можно при любой схеме обеспечения безопасности. Безопасность — это всегда ограничения, а значит потенциальные проблемы доступа… Точно также провайдер может вдруг «озаботиться» безопасностью и заблокировать «левый», по его мнению, трафик на «левые» порты, и всё вы приехали со своими порт-кноками и vpn'ами…
Вопрос лишь в том, предусматриваете ли вы у себя альтернативные варианты доступа или полагаетесь на какой-то один. Если последнее, то вы сами себе злобный буратино…
А если провайдер вам IP поменяет, что делать будете
зайду со второго IP, два сразу вряд ли поменяют, правда ведь? А если мне нужно попасть срочно из очень необычного места, где нет возможности пробросить свой привычный IP — ребут сервера, после ребута есть несколько минут для доступа всем. Этакий костыль «на всякий случай»
Случай 2.
Лучше картинки разбивать по папкам не по датам, а, скажем, по первым нескольким символам хеша и по нескольким уровням, чтобы более равномерно распределить их по папкам.
Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.
Странные у вас программисты какие-то, не умные.
Лучше картинки разбивать по папкам не по датам, а, скажем, по первым нескольким символам хеша и по нескольким уровням, чтобы более равномерно распределить их по папкам.
Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.
Странные у вас программисты какие-то, не умные.
> В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root
Какая у вас жуткая реальность.
В моей реальности в 100% случаев под рутом не ходят.
Пароли? Забудьте о паролях, откройте для себя чудесный мир ключей!
И, с праздником, коллега!
Какая у вас жуткая реальность.
В моей реальности в 100% случаев под рутом не ходят.
Пароли? Забудьте о паролях, откройте для себя чудесный мир ключей!
И, с праздником, коллега!
Знакомые какие все ситуации :). Насчет sudo/su имхо с ключами вход по руту (а если призывают админа, то 100% придется делать что-то от рута) намного удобней.
мои 5 копеек.
Иногда приходят и говорят «а-а-а!!! место на диске закончилось! мы все умрём!». И тут начинается веселье.
1. Лезешь на сервер — места до фига, но некоторые замечательные программисты считают ненужным подтирать за собой сессионные файлы. вот inod'ы и заканчиваются.
2. Лезешь на сервер — места до фига. И айнодов полно. После пыток пользователей выясняется, что вот только что удалили огромный файл, а место всё равно не освободилось. про процессы, использующие эти файлы, можно не помнить.
3. Лезешь на сервер — а места и правда нет (:
Иногда приходят и говорят «а-а-а!!! место на диске закончилось! мы все умрём!». И тут начинается веселье.
1. Лезешь на сервер — места до фига, но некоторые замечательные программисты считают ненужным подтирать за собой сессионные файлы. вот inod'ы и заканчиваются.
2. Лезешь на сервер — места до фига. И айнодов полно. После пыток пользователей выясняется, что вот только что удалили огромный файл, а место всё равно не освободилось. про процессы, использующие эти файлы, можно не помнить.
3. Лезешь на сервер — а места и правда нет (:
Первая проблема, мягко говоря, надумана. Но если такое действительно было, то надо по рукам надавать и программистам, и админу. Первым за разгильдяйство и свинарник, вторым — за использование файловых систем для локалхостов на проде.
А еще, люди забывают ставить логи в ротацию или логируют все подрят. И блин….куда же делось место…
На пункт 2. А как это у вас до фига свободного места, если огромный файл до сих пор на диске, пусть и анлинкнутый? du покажет 0 свободного места, как ему и положено.
НЛО прилетело и опубликовало эту надпись здесь
> SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts
простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.
простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.
НЛО прилетело и опубликовало эту надпись здесь
Кажется, вы не знакомы с тем, как базы хранят данные.
В PostgreSQL, к примеру, поля длиннее 8 кб сначала пытаются скомпрессироваться, чтобы влезть в 8 кб, а потом выносятся во внешние, спрятанные от юзера TOAST-таблицы:
www.postgresql.org/docs/9.3/interactive/storage-toast.html
Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.
После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.
В PostgreSQL, к примеру, поля длиннее 8 кб сначала пытаются скомпрессироваться, чтобы влезть в 8 кб, а потом выносятся во внешние, спрятанные от юзера TOAST-таблицы:
www.postgresql.org/docs/9.3/interactive/storage-toast.html
Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.
После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.
SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts
Забудьте о звездочке, всегда перечисляйте только те поля, которые действительно нужны. База сама выберет, какую стратегию чтения выбрать, плюс сможет задействовать покрывающие индексы.
>hosts.allow
>sshd: 123.231.132.213
>И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.
Замена SSH порта на любой из upper range отлично справляется с брутом. Ограничение по IP все-же сильно влияет на возможности доступа.
>sshd: 123.231.132.213
>И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.
Замена SSH порта на любой из upper range отлично справляется с брутом. Ограничение по IP все-же сильно влияет на возможности доступа.
запретить авторизацию от рута (PermitRootLogin yes) в sshd_config.
Это как раз разрешает её)
Я так подозреваю, что человек скопировал строчку из дефолтного конфига просто, забыл сменить на no :)
У человека, нависавшего данную статью априори не должно быть дефолтных конфигов!
Может, тонкая ирония, или как)
Может, тонкая ирония, или как)
Статья выдает в коллеге новичка, так что думаю, что ошибка при копировании.
Вот эти «90% случаев ходят под рутом» выдают новичка с головой.
Вот эти «90% случаев ходят под рутом» выдают новичка с головой.
Автору 27, сомневаюсь, что он новичок :)
Ошибаетесь. Первый линукс я скачивал в далеком 2002-м по dialup соединению. А плотно работаю с linux серверами с 2006-го. А то, что у меня такая статистика — не говорит о моем опыте ни слова, лишь говорит об опыте моих знакомых.
А я не говорил что строчка запрещает рута, я лишь привел опцию которая в ответе за это. Но давайте исправлю, раз так подумали. :-)
Кейсы 2 — 4 — жесть какая-то, и про работу от рута тоже. Имхо надо не думать призывать этих ребят, а просто держаться от них подальше.
К каждой команде программистов нужно приставлять админа с металлической линейкой, чтоб бил по пальцам.
У них просто в другом режиме работает голова – замечал даже по себе: если начинаешь писать что-то посерьезнее наколеночного скрипта, то мозг, находясь в programmer mode, банально решает другие задачи и может легко допустить косяк, на который в admin mode мгновенно бы среагировал.
У них просто в другом режиме работает голова – замечал даже по себе: если начинаешь писать что-то посерьезнее наколеночного скрипта, то мозг, находясь в programmer mode, банально решает другие задачи и может легко допустить косяк, на который в admin mode мгновенно бы среагировал.
Если в случае 2 у вас есть nginx, его же можно заставить самого и кэшировать миниатюрки. Плюсы — можно ограничить общий объём кэша и автоматически выбрасывать из него старье, которое никто не запрашивает.
В 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 не обойтись, к сожалению.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Начинайте думать