Comments 18
Использование надежных паролей.
Как мне кажется ещё лучше не использовать паролей вообще. Сгенерить ключик, забрать себе публичную часть и ходить на сервак исключительно через ssh.
Ну и в целом колхоз какой-то.
Тоже покоробило. Заголовок "Сетевая безопасность Linux: Best practices". И первая же рекомендация: "Использование надежных паролей". Хотя давно уже: "Не использовать пароли вообще". И речь даже не про новомодный zero trust, хотя бы классический RSA ssh key.
Дальше читать даже не стал.
Мне вот интересно: это Контент-маркетолог Дмитрий Головин такой бестолковый или IBM Senior DevOps Engineer & Integration Architect, Официальный DevOps ментор и коуч в IBM Рустем Галиев (зато титул прямо как у Великого Князя)?
Я помню что gnupg при генерации ключа вроде как предлагает его зашифровать паролем.
Bash прост в освоении и использовании
Вот здесь, конечно, посмеялся. А потом поплакал. Мои студенты первые 2 пары в шоке от синтаксиса. Но увы, это стандарт, так что приходится проходить.
Тоже посмеялся с этого пункта. Где-то в интернете есть поверие, что баш скрипты одноразовые. Потому что после написания, через пару дней легче написать новый скрипт, чем отладить существующий.
Не обязательно. Можно на пять строчек скрипта написать 40 строк комментариев с подробным разбором того, что там делается и зачем. А вот если там более-менее сложный регэксп... к скрипту полагается прикладывать как минимум бутылочку коньяка и письмо с извинениями в адрес человека, кто будет в этом разбираться.
Кто в cmd писал, в bash-e радуется..
Это да. У нас многое девопсовское на баш скриптах. Вы не представляете какой это гемор экранировать параметры, имена файлов и прочее прочее. Нет, на уровне детского сада конечно просто, но если делать по уму чтобы работало всегда - это задача как минимум хорошего инженера который отлично разбирается в системе.
Bash-скрипты переносимы
---
apt что-то там
«На берегу Рио-Пьедра села я и заплакала»
Какое жуткое непонимание bash и всего остального ;)
После фразы "простые баш скрипты" идет регулярка на 63 символа с использованием продвинутых конструкций типа look ahead, или с условиями. Это не часть баша, в такие регулярки не каждый сисадмин сходу осилит.
То что там сделано со sticky бит вообще за такое руки отрывать. По умолчанию практически ВСЕ каталоги в линуксе - доступны на запись. Для рута. То есть на все каталоги, включая /dev, и включая /proc выставить стики бит? Отличненько, Автор проверял лично на своей системе, лучше сразу в продакшене что произойдет?
Очень, очень многие не понимают, что баш - это шелл для операционной системы.
Это действительно довольно простой язык и интересный язык, с богатыми возможностями даже в POSIX стандарте, без башизмов.
Но его реальное использование глубоко связано с пониманием администрирования линукс да и архитектуры *nix вообще. Без этого понимания, попытки сделать что-то полезное и отличающееся от hello world на bash будут постоянно спотыкаться на непонятные глюки, проблемы и ненадежность. А этим страдает огромное количество разработчиков, которые по непонятной мне лично причине, не разбираются в базовой архитектуре операционных систем. Даже таких базовых вещах как что такое environment variable или stdout/stderr (капец, да?).
Та же самая переносимость обеспечивается не баш скриптами, а posix-совместимыми скриптами. Конечно, если быть уверенным, что вам не нужно будет запускать его где-нить в урезанном аналоге busybox, то да, можно юзать и баш с хеш массивами и кучей variable expansion.
Короче. Как человек, который может себе позволить сказать что "я более чем неплохо знаю bash", я скажу, что статья мне не понравилась некорректными утверждениями.
Очевидно, что автор либо не писал эти скрипты сам, либо не имел опыта работы хотя бы с несколькими разными дистрибутивами.
Зачем вы проверяете хэш паролей в
/etc/passwd? это вам ничего не дастНастройка firewall в том, чтобы включить SSH ? а что, так можно было ? ))
Автор, найдите время почитать про Ansible.
Ну и плюс ко всему двухфакторная авторизация. Предупреждать надо чо это гоогле а то кто нибудь запустит это и останется без доступа к системе.
Скачал fail2ban, запустил с дефолтом и вот ты в безопасности :)
Остальное уже и без меня разобрали по косточкам :)
Думал увижу что нить для себя. Хоть я только учусь, но статья улыбнула. Жаль, если такие вот писатели еще и на курсах такому же учат :(
Как влияет на нагрузку и пропускную способность сети эти sysctl.conf hardenings?
Сетевая безопасность Linux: Best practices и баш скрипты