Комментарии 100
«Файрвол», «Fail2Ban» — вы уж к одному знаменателю приведите. Или «Файрвол», для вас, уже русское слово, а «Fail2Ban» — ещё нет?
Извечный вопрос: зачем отключать root и сидеть из под пользователя с правом повышения до root, если всё равно используются ключи доступа?
Отключение рута это сомнительная тема применяемая в экзотических кейсах, когда есть несколько равноправных администраторов на один сервер с разными учётками и нужно отслеживать кто что делает.
Отключение рута это сомнительная тема применяемая в экзотических кейсах, когда есть несколько равноправных администраторов на один сервер с разными учётками и нужно отслеживать кто что делает.
Добавление ещё одного администратора не сломает схему администрирования. Удобно, и ничего не стоит. Нужно просто заблокировать root.
Хотя бы чтобы самому случайно не накосячить случайно. С точки зрения безопасности по дефолту получается два фактора: ключ и пароль пользователя для sudo. И даже три, если и ключ зашифрован
Да, постоянно под рутом работать — плохая идея. Но если аутентификация по паролю закрыта и своевременно устанавливаются секюрити-апдейты, то отключение рута имеет смысл, если вы опасаетесь, утечки ключа.
А если ключ утек, то вышеописанные меры — это просто небольшое препятствие.
А если ключ утек, то вышеописанные меры — это просто небольшое препятствие.
Ну не такое уж небольшое, если для sudo пароль нужен и к его вібору серьёзно отнеслись. Вроде как в Linux, например, не было простого способа получить пароль, кроме как серьёзного брутфорса. В Windows был — точно помню пароль делился на две части и каждую можно было брутфорсить отдельно :)
Ну да пароль для sudo, только брутфорсить. Можно еще мониторить историю команд, на предмет случайного ввода пароля в командной строке :) или поискать скрипты, где он указан явно. А если пароль на sudo суперсложный, значит его где-то хранят. Как-бы не рядом с ключом ;-)
сороктысячобезьян не такой уж сверхсложный )
Если намеренно добавить орфографические ошибки, подбор будет куда сложнее, потому что по словарю не ловится. Ну и про apg и другие подобные утилиты не стоит забывать: они дают, как мне кажется, очень неплохие результаты как по сложности, так и по запоминаемости. Впрочем, если приходится администрировать много сервером, то пароли всё равно надо где-то хранить и тогда есть смысл просто подумать о таком месте хранения, утечка из которого будет наименее вероятной.
ключ обязательно должен быть зашифрован и лежать в безопасном хранилище
Тоже всегда напрягала необходимость возиться с правами. Linux — ОС для админов. И у машины должен быть один админ. Если нужно разграничить права доступа — есть Docker, виртуалки, доступ через Веб-интерфейс и подобные технологии. А если доступ к командной строке имеет кто-то, не внушающий доверия, то здесь что-то не то. ИМХО.
Linux — ОС для админовЕсть мнение, что разрабатывали программисты для программистов.
Если нужно разграничить права доступа — есть Docker, виртуалки, доступ через Веб-интерфейс и подобные технологии.Для разграничения прав доступа применяется дискреционная или мандатная система разграничения прав доступа. Виртуализация, контейнеризация это немного про другое.
Для разграничения прав доступа применяется дискреционная или мандатная система разграничения прав доступа. Виртуализация, контейнеризация это немного про другое.
Вот понимания этого мне всегда не хватало. Наверное потому, что всегда самостоятельно возился со своими серверами. И именно поэтому контейнеризация как бальзам на душу, поскольку позволяет многое выбросить из головы и начинать с чистого листа с правами root.
Один админ? Т.е. кто-то всё настроил и нужно дёргать его по любому вопросу, когда надо что-то доконфигурировать?
затем что надо делать всё одинаково везде.
Согласен с Вами. В голову приходит только аудит или если в sudo есть ограничения по командам.
Зачем создавать ключи RSA, если задаем пароль в 40 символов + Fail2Ban с баном на 1-3 часа. Подбор невозможен. Да еще можно определить диапазон адресов, с которых возможен логин.
Смена порта — сканером легко определить список открытых портов. Тогда, какой смысл в этом действии?
В общем как то про безопасность все как то спорно все.
Смена порта — сканером легко определить список открытых портов. Тогда, какой смысл в этом действии?
В общем как то про безопасность все как то спорно все.
"задаем пароль в 40 символов"
А вводить его как? Нужен ssh клиент с менеджером паролей. Тогда как с ключом работать умеют все.
Да, стоит ssh клиент с мастер паролем. Длинный пароль хранится зашифрованным в ssh клиенте. Но ведь и ключ RSA хранится в хранилище. Разница в чем?
Менеджер паролей с настройкой сценариев вполне подойдет.
KeePass тот же: вызывает ssh-клиента по клику в парольнице и заполняет все поля сам. Только предварительно нужно сценарий настроить в конкретной записи.
И вот у меня вопрос: а как безопаснее, хранить ключ на диске или хранить пароль длинный в зашифрованном виде в менеджере паролей?
КМК похитить ключ с диска проще, чем похитить файл парольницы и как то его расшифровать.
Или нет?
На приватный ключ тоже можно поставить пароль.
По сути получается примерно одинаково.
Разница только в том, что публичный ключ он как раз-таки «публичный».
Его можно отдавать кому угодно.
Если стоит задача предоставить удаленный доступ, то администратору сервера нужно только взять ваш публичный ключ и прописать его в authorized_keys нужного пользователя. А современных реалиях это чаще делается автоматически, например при создании виртуальных машин или аренде выделенных серверов.
Гораздо проще скриптом (системой конфигурирования) раскидывать публичный ключ, чем обеспечивать безопасность даже временных паролей.
Более того, невозможно проконтролировать хороший (длинный) ли пароль сделал себе пользователь или нет. Это хорошо, если пароль в 40 символов. Но он может оказаться и 123456. А ключи они уже достаточно длинные.
По сути получается примерно одинаково.
Разница только в том, что публичный ключ он как раз-таки «публичный».
Его можно отдавать кому угодно.
Если стоит задача предоставить удаленный доступ, то администратору сервера нужно только взять ваш публичный ключ и прописать его в authorized_keys нужного пользователя. А современных реалиях это чаще делается автоматически, например при создании виртуальных машин или аренде выделенных серверов.
Гораздо проще скриптом (системой конфигурирования) раскидывать публичный ключ, чем обеспечивать безопасность даже временных паролей.
Более того, невозможно проконтролировать хороший (длинный) ли пароль сделал себе пользователь или нет. Это хорошо, если пароль в 40 символов. Но он может оказаться и 123456. А ключи они уже достаточно длинные.
К тому же KeePass есть плагин, который реализует интерфейс Pageant-а. А с ним под виндой умеет работать уже практически всё. Сам Putty, Far, FileZilla…
безопаснее — yubikey/Nitrokey или trusted platform module
Ну это если вы готовы пароль в 40 символов вводить каждый раз.
А если нет — то ключи удобнее. Как минимум раскидывать публичный ключ по серверам безопаснее при автоматизации, чем управлять паролями.
Смена порта — от тупых ботов, чтобы уменьшить спам в syslog, про безопасность речи не идет.
А если нет — то ключи удобнее. Как минимум раскидывать публичный ключ по серверам безопаснее при автоматизации, чем управлять паролями.
Смена порта — от тупых ботов, чтобы уменьшить спам в syslog, про безопасность речи не идет.
Ну не знаю — пароль задал, в менеджер паролей добавил, в ssh клиент добавил и запомнил (под мастер-паролем) и все работает. Ни чего помнить особо не нужно. Возможно, я сильно ошибаюсь. Буду благодарен за разрушение моей стройной системы безопасности длинных паролей для ssh.
Как вы просите админов других серверов создавать вам аккаунт на их серверах с доступом по ssh? Что делаете, чтобы иметь доступ к одному аккаунту с нескольких девайсов, рабочего и домашнего, например?
Ключ в клиенте сохраняется точно также. Но помимо всего прочего ключ можно безопасно передавать и хранить стандартными способами. А ещё иногда к ssh приходится подключаться не ssh-клиентом, а через тоннель, например в закрытую сеть. Тогда отдельно заходим по ssh на торчащий наружу комп, а потом внутри приватной сети ходим по ключам на локальные сервера.
Просто с ключами — более стандартный и заведомо безопасный подход. С сорокасимвольными паролями — выглядит как велосипед. Пароль задумывался под ручной ввод, и менеджеры паролей — это своеобразный костыль. Ключи задумывались под автоматическое использование из коробки, и их для такой цели использовать правильнее.
Если говорить о безопасности, думаю, самый сильный аргумент против пароля, это то, что злоумышленник может получить и использовать Ваш пароль в дальнейшем, если Вы были невнимательны при MITM-атаке (или при попытке авторизоваться на чужом сервере). В отличие от пароля, в подобных ситуациях злоумышленник не сможет получить Ваш приватный ключ и, например, не сможет выполнить произвольные команды на Вашем сервере.
Ключ нужно создать один раз, менять при компрометации. При логине на ПК делается eval $(ssh-agent -s); ssh-add, вводится один раз пароль от ключа и после этого доступен беспарольный SSH на любой узел, где прописан публичный ключ.
Но я не понимаю, в свою очередь, зачем предлагается fail2ban, если аутентификация по паролю отключается.
Но я не понимаю, в свою очередь, зачем предлагается fail2ban, если аутентификация по паролю отключается.
Сканером да, но много "инструментов" которые сканят заданный список портов. И вот тут измененный порт даст возможность уменьшить вероятность взлома через стандартный порт.
Опять же, если серверов >1, и администраторов >1, то управление этим хозяйством здорово усложняется. А при целенаправленной атаке хакер, не обнаружив ответа на 22 порту, заплачет и убежит ;)
Никто и не говорил про целенаправленную атаку.
Речь шла про масс-скан в котором обычно сканят определенный список портов.
Вот в таком случае перенос дефолтного порта — это неплохая идея.
Речь шла про масс-скан в котором обычно сканят определенный список портов.
Вот в таком случае перенос дефолтного порта — это неплохая идея.
А зачем «пароль в 40 символов + Fail2Ban», если можно просто использовать ключи? Подбор невозможен.
Сам Fail2Ban в настройке то ещё удовольствие, не говоря уже о дополнительной нагрузке на систему.
Сам Fail2Ban в настройке то ещё удовольствие, не говоря уже о дополнительной нагрузке на систему.
Ещё есть всякие белые списки, Port Knocking и прочие VPN'ы для защиты ssh и других критичных мест. Кроме инструкции по созданию ключей для ssh, уж очень банально.
Белые списки — да, безопаснее, но не гибко. Что если будет какая-то проблема с сетевой инфраструктурой в конторе, из которой велось управление серверами?
Port Knocking — это тоже не про безопасность (Security Through Obscurity), как и перенос ssh на нестандартный номер порта, а скорее про уменьшение нагрузки на сеть от атакующих ботов.
Использовать в статье типа «гайд для новичка» редактор vim — это сильно…
Какие ужасные и вредные некоторые советы
Нерутовый юзерНачали хорошо. Но зачем ему давать привилегии sudo? Нужен пример? Пожалуйста: через уязвимости злоумышленник получил возможность удалённого выполнения кода от нашего нерутового пользователя. Хорошо, если он просто начал запускать свой скрипт, хотя хорошего в этом мало. Но он может пойти дальше и устроить локальный брутфорс пароля нерутового пользователя. Если у него получится его раздобыть, то дальше у него полностью развязываются руки.
Ключи вместо паролей SSHДельное предложение. Только лучше использовать более продвинутый вариант с ключом на основе эллиптических кривых
ssh-keygen -t ed25519 -C "<comment>"Fail2BanНе помню, чтобы он особенно помогал при атаках. Да, блокирует адреса при некоторых атаках, только при этом может отнять порядочное количество ресурсов, что его эффективность становится под вопросом. При неумелом использовании может вообще заблокировать систему от любого внешнего трафика и тогда начинается уже отдельное веселье.
Автоматические обновления безопасностиВообще это правильно называется автоматическая установка обновлений. И не всегда эти обновления связаны с безопасностью и не всегда обновления не приносят новых уязвимостей. Некоторые обновления могут приводить к перезапуску того или иного сервиса, а ещё могут вызывать конфликты с другими приложениями. С этим надо быть осторожней.
Смена портов по умолчаниюПомогает от тупых ботов, но есть продвинутые, которые, находя открытый порт, начинают проверять его на те или иные ответы. Поэтому лучше использовать более продвинутые методы защиты.
Какие есть варианты по последнему пункту?
Авторизация по ключам + port knocking, и вы уже отгородились от большинства атак.
Никакие. Зачем трогать порты? Еще бы почитать рекомендацию, по смене портов 80/443 у nginx — чтобы боты не ходили…
Хотите закрыть доступ? Ставьте fail2ban или ограничивайте доступ по IP. Возьмите себе простую VPS для постоянного IP. Поставьте openvpn и используйте.
Хотите закрыть доступ? Ставьте fail2ban или ограничивайте доступ по IP. Возьмите себе простую VPS для постоянного IP. Поставьте openvpn и используйте.
Вариант с VPN может оказаться гораздо опасней, чем без неё, если это первая VPN для человека которому поручили её поднять.
В каком смысле?
Вот (https://github.com/angristan/openvpn-install) автоматизированный скрипт, чтобы поднять openvpn на сервере. Давайте по пунктам, какие опасности могут быть?
Вот (https://github.com/angristan/openvpn-install) автоматизированный скрипт, чтобы поднять openvpn на сервере. Давайте по пунктам, какие опасности могут быть?
автоматизированный скрипт
Универсальное != безопасное. ИМХО.
Что именно не безопасно? Давайте по пунктам.
Скрипт автоматизирует установку пакета, и генерацию конфига — который вы сами также бы сделали (или хуже).
Тогда давайте говорить, что универсальный nginx != безопасно. Надо свойвелосипед веб-сервер писать.
Скрипт автоматизирует установку пакета, и генерацию конфига — который вы сами также бы сделали (или хуже).
Тогда давайте говорить, что универсальный nginx != безопасно. Надо свой
Что именно не безопасно? Давайте по пунктам.1 Совсем не обязательно вести атаку на целевой сервис и заниматься его компроментацией. Можно пойти с другой стороны и устроить DOS стороннего сервиса. Что у OpenVPN защитой от атак на отказ в обслуживании?
2 Не стоит думать, что OpenVPN безгрешен и не содержит уязвимостей.
3 Есть другой неприятный момент. Он не частый, но бывали случаи и люди на нём накалывались: некоторые провайдеры непонятно по какой такой блажи блокируют этот тоннель. Поэтому есть мануалы, как закосить под HTTPS, работая по OpenVPN.
Ещё надо иметь в виду, что некоторые провайдеры последней мили блокируют в своих сетях практически весь трафик UPD (сталкивался неоднократно). В настройках скрипта по умолчанию как раз идёт UDP. Но это не замечание, а просто личный опыт.
Любые могут быть при запуске башскрипта на 1500 строк с рутовыми правами. Если вы можете этот скрипт проверить на безопасность, то вы и, скорее всего, руками можете безопасно openvpn поднять. А если не можете...
Ну ок, тогда весь софт пишите самостоятельно. Ведь почти любая программа требует повышения привилегий при установке.
Или вы полностью просмотрели код linux/nginx/sshd/etc и уверены, что там все безопасно?
Или вы полностью просмотрели код linux/nginx/sshd/etc и уверены, что там все безопасно?
Я доверяю авторам и используемым распространителям такого софта типа Canonical, но вот на творчество french software engineering student я бы критическую для компании инфраструктуру завязывать не стал.
АААааа...! вы вообще о чем?
Что критическое для компании? Я предложил использовать openvpn для доступа по ssh, если нет постоянного IP. А IP VPN прописать в белый список, кто может стучаться к порту.
Где проблема с безопасностью? Или вы думаете, что «french software engineering student» что-то внес в свой openvpn скрипт, что может перехватить зашифрованные данные между вашим ПК и сервером? Даже если на VPN есть вредоносный код, то он максимум что может, это стучать на открытый для этого IP порт и все. логин/пароль/ключ/… надо все равно где-то найти…
«Я доверяю авторам и используемым распространителям такого софта типа Canonical»… Пару лет назад уже было, что зайти под рутом, можно зажав какие-то клавиши… Дыры и вредонос может быть везде. Точно ли пакет собран из тех исходников, что вам показывают — вы не знаете, и никогда не узнаете.
Что критическое для компании? Я предложил использовать openvpn для доступа по ssh, если нет постоянного IP. А IP VPN прописать в белый список, кто может стучаться к порту.
Где проблема с безопасностью? Или вы думаете, что «french software engineering student» что-то внес в свой openvpn скрипт, что может перехватить зашифрованные данные между вашим ПК и сервером? Даже если на VPN есть вредоносный код, то он максимум что может, это стучать на открытый для этого IP порт и все. логин/пароль/ключ/… надо все равно где-то найти…
«Я доверяю авторам и используемым распространителям такого софта типа Canonical»… Пару лет назад уже было, что зайти под рутом, можно зажав какие-то клавиши… Дыры и вредонос может быть везде. Точно ли пакет собран из тех исходников, что вам показывают — вы не знаете, и никогда не узнаете.
Мне кажется, я понял, что имеет ввиду VolCh Не надо с непонятных репов тянуть скрипты без их понимания, а потом еще и использовать для прода. Доверия распространителям софта больше. Что не отметает фактов, что и там не будет все гладко иногда.
Пара вопросов.
Про нерутового юзера не очень понял. sudo без ограничений — согласен, плохо. Вы об этом?
Атака скорее будет на повышение привилегий, чем на локальный брут, который по идее по логам детектится. Ну и если делать с норм политикой пароля, брут будет дооолгий. А если совсем убезопаситься, то можно второй фактор сделать, аля yubikey.
Можно подробнее про автообновление? Я в том плане, что Ваш комментарий скорее про администрирование, чем безопасность. Новые уязвимости в патчах — горькая правда жизни, но всяко лучше оставления известных дыр.
ИМХО, порты нет особого смысла менять, безопасность через незнание.
Про нерутового юзера не очень понял. sudo без ограничений — согласен, плохо. Вы об этом?
Атака скорее будет на повышение привилегий, чем на локальный брут, который по идее по логам детектится. Ну и если делать с норм политикой пароля, брут будет дооолгий. А если совсем убезопаситься, то можно второй фактор сделать, аля yubikey.
Можно подробнее про автообновление? Я в том плане, что Ваш комментарий скорее про администрирование, чем безопасность. Новые уязвимости в патчах — горькая правда жизни, но всяко лучше оставления известных дыр.
ИМХО, порты нет особого смысла менять, безопасность через незнание.
Поясните, пожалуйста, чем плохо sudo без ограничений и без пароля для администратора сервера?
это же очевидно: если учётная запись админа будет скомпроментирована, злоумышленник сразу получит полный доступ ко всему.
в случае же пароля на sudo ему придётся ещё подобрать этот пароль.
использовать или нет — решать вам, на моих серверах в основном sudo без пароля.
Если учетная запись админа скомпрометирована на сервере, то просто отсылаем его пароль на сервер злоумышленника. Даже не пароль, а приватный ключ, так как в нормальной конфигурации, доступ к учетной записи возможен только по ключу. Остается только дикий вариант с открытым терминалом, оставленным в кафе, пока админ пошел отлить.
Если учетная запись админа скомпрометирована на сервере, то просто отсылаем его пароль на сервер злоумышленника.
получить пароль — не такая уж тривиальная задача.
Даже не пароль, а приватный ключ, так как в нормальной конфигурации, доступ к учетной записи возможен только по ключу. Остается только дикий вариант с открытым терминалом, оставленным в кафе, пока админ пошел отлить.
а в чём принципиальная разница между «злоумышленник получил приватный ключ админа» и «злоумышленник сел за незаблокированный ноут админ»?
и там, и там у злоумышленника есть доступ в шелл с правами того админа.
sudo -i запросит пароль, получить который ещё надо суметь.
Если я могу выполнить произвольную команду от имени пользователя, то получить пароль можно очень легко.
Далее, пароль наверняка не qwerty01, а посложнее. Значит, каждый раз пользователь его вводить не будет. sudo будет кэшировать введенный пароль и запрашивать снова только после определенного таймаута. По умолчанию это 5 минут.
Тогда сам пароль и не очень нужен. Просто подождем повышения привилегий и воспользуемся.
Далее, если вы администрируете что-то серьезное, скорее всего, у вас целая инфраструктура имеется, серверов несколько, они бэкапятся, есть эталонный образ, из которого создаются новые сервера. Если вы пользуетесь паролями, то хэш вашего пароля очень много где будет лежать. Кто-то может получить доступ не к целевому серверу, а к какому-нибудь бэкапу, найти там /etc/shadow и начать его брутить на своих ресурсах.
Если же вы никогда не используете пароли, то можете образ своего сервера хоть в интернет выкладывать. Злоумышленники ничего полезного для взлома получить оттуда не смогут.
alias sudo='sudo -A /tmp/askpass'
Далее, пароль наверняка не qwerty01, а посложнее. Значит, каждый раз пользователь его вводить не будет. sudo будет кэшировать введенный пароль и запрашивать снова только после определенного таймаута. По умолчанию это 5 минут.
Тогда сам пароль и не очень нужен. Просто подождем повышения привилегий и воспользуемся.
export PS1="\$(sudo -n whoami 2>/dev/null)$PS1"
Далее, если вы администрируете что-то серьезное, скорее всего, у вас целая инфраструктура имеется, серверов несколько, они бэкапятся, есть эталонный образ, из которого создаются новые сервера. Если вы пользуетесь паролями, то хэш вашего пароля очень много где будет лежать. Кто-то может получить доступ не к целевому серверу, а к какому-нибудь бэкапу, найти там /etc/shadow и начать его брутить на своих ресурсах.
Если же вы никогда не используете пароли, то можете образ своего сервера хоть в интернет выкладывать. Злоумышленники ничего полезного для взлома получить оттуда не смогут.
Пара вопросов.Более чем исчерпывающе ответили тут
От души благодарен за такой развёрнутый и понятный ответ.
Теперь вам расскажу более жуткую страшилку. Привилегированные доступы к системе сильно не нужны. Иногда совсем. Что мы обычно имеем на рабочем сервере? Процесс или несколько целевых процессов работающих в сеансе некого пользователя (не могу подобрать подходящего слова, буду благодарен, если поправите мою мысль более точно). Получая доступ к этому пространству, получаете доступ ко всем переменным, объявленных в нём (команда printenv). А что у нас там? Там обычно параметры подключения к базе данных, хранилищам, сторонним сервисам и многое к чему.
Дальше не хочется фантазировать.
Вообще это правильно называется автоматическая установка обновлений. И не всегда эти обновления связаны с безопасностью
ну вот как раз имеет смысл автоматически устанавливать только обновления связанные с безопасностью. и то не на всех серверах, некоторые этого могут и не пережить. современные пакетные менеджеры это позволют.
ведь эти обновления надо тестировать в рамках общего flow в компании.
Зря про ssh-copy-id не упомянули.
Вместо тысячи слов: github.com/topics/cis-benchmark
Вроде как есть исследования, что смена порта как и смена пользователя практически ничего не дает. Только усложняет работу.
Как и супер-длинный пароль.
А когда работа усложняется, пользователи ее упрощают(пишут пароль на бумажку, к примеру).
Класический пример убунту, где рут заблочен по умолчанию и есть пользователь с теми же по факту правами. Ну он просто называется ubuntu. Ага, ботнеты не вкурсе.
Ключи ок, все остальное — в топку.
Fail2ban надо понимать, как и firewall. На практике нормально работает только whitelist firewall с современными ботами. В эпоху ботнетов с сотнятми тысяч адресов fail2ban только им помогает.
Как и супер-длинный пароль.
А когда работа усложняется, пользователи ее упрощают(пишут пароль на бумажку, к примеру).
Класический пример убунту, где рут заблочен по умолчанию и есть пользователь с теми же по факту правами. Ну он просто называется ubuntu. Ага, ботнеты не вкурсе.
Ключи ок, все остальное — в топку.
Fail2ban надо понимать, как и firewall. На практике нормально работает только whitelist firewall с современными ботами. В эпоху ботнетов с сотнятми тысяч адресов fail2ban только им помогает.
Стандартный порт менять бесполезно. Раньше помогало, теперь уже неактуально.
fail2ban — тоже ни к чему, взломщикам он не помешает, а хозяевам сервера создаст неудобства. По логам видно, что ботнеты специально не заходят с одного и того же IP в течение нескольких месяцев. Блокируй его или не блокируй — ничего это не даст.
Я считаю, что у пользователей вообще не должно быть паролей, никаких.
Вход только по ключам. sudo без пароля.
Странно, что никто не предложил selinux включить. А это как раз та штука, которая позволит предотвратить взлом через торчащий наружу сервис.
fail2ban — тоже ни к чему, взломщикам он не помешает, а хозяевам сервера создаст неудобства. По логам видно, что ботнеты специально не заходят с одного и того же IP в течение нескольких месяцев. Блокируй его или не блокируй — ничего это не даст.
Я считаю, что у пользователей вообще не должно быть паролей, никаких.
passwd -l %username%Вход только по ключам. sudo без пароля.
Странно, что никто не предложил selinux включить. А это как раз та штука, которая позволит предотвратить взлом через торчащий наружу сервис.
Я думаю, что не стали рассказывать, тк его и отлаживать приходится и тд. Не отменяя факта, что это одно из самых эффективных средств сдерживания атакующего, когда он уже на серваке.
Я освоил policycoreutils-python, после чего жизнь с selnux-ом стала простой и беззаботной.
Сначала setenforce 0.
Потом все ставишь, запускаешь.
Недельку поработал.
Все.
Сначала setenforce 0.
Потом все ставишь, запускаешь.
Недельку поработал.
sudo cat /var/log/audit/audit.log | audit2allow -M myselinux
sudo semodule -i myselinux.pp
setenforce 1
Все.
Я Вас полностью поддерживаю, просто почему-то не все хотят даже это делать. Вот не знаю, почему.
Кстати sudo без пароля я бы сделал при условии наличия пасса на ключе. Тогда и утеря ключа не так критична.
Кстати sudo без пароля я бы сделал при условии наличия пасса на ключе. Тогда и утеря ключа не так критична.
А наличие пасса на клиентском ключе разве можно проконтролировать на сервере?
Пароль на sudo ни от чего не защищает, кроме, пожалуй, совершенно дикой ситуации, когда админ открыл терминал и, не залочив, пошел пить чай.
Вроде выше писали. Ну слили ключ, а как привилегированные команды исполнять?
Например, так
Но способов на самом деле много.
alias sudo='sudo -A /tmp/askpass'Но способов на самом деле много.
Можно. Просто все эти лишние движения могут привлечь внимание. sudo с паролем же не универсальное средство защиты, а одна из ступеней защиты. Особенно хорошо, если можно делать сильно ограниченное sudo на пару комманд, сверившись с gtfobins.github.io
SELinux шикарен и бесподобен, его долго разрабатывали, обкатывали и внедряли. Это делали люди, в криворукости и говнокодинге которые замечены не были.
Позволяет дела много интересных вещей (несколько пользователей root с разными возможностями). Только утилитой audit2allow надо пользоваться с осторожностью, и внимательно изучать политику, которую она выдаёт. Там иногда бывают просто феерические права доступа.
Позволяет дела много интересных вещей (несколько пользователей root с разными возможностями). Только утилитой audit2allow надо пользоваться с осторожностью, и внимательно изучать политику, которую она выдаёт. Там иногда бывают просто феерические права доступа.
fail2ban — тоже ни к чему, взломщикам он не помешает, а хозяевам сервера создаст неудобства
Какие неудобства имеются в виду? Я вижу разве что выяснение отношений «кто ввёл неправильный пароль эн раз подряд из нашего офиса» при более одного админа сервера.
На DO есть возможность задать команды, которые будут выполнены при создании сервера сразу, в том числе сразу добавить ключи, включить фаервол и сменить порт. И ничего руками после создания виртуалки делать не надо. Также, я на время первоначальной настройки открываю доступ только с одного ай-пи адреса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита Linux-сервера. Что сделать в первую очередь