Автор статьи: Рустем Галиев
IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM
Linux — это операционная система с открытым исходным кодом, которая широко используется на различных устройствах, включая серверы, ПК и встроенные системы. Важно обеспечить безопасность систем Linux при подключении к сети для защиты от потенциальных угроз и уязвимостей. Существуют различные best practices, которым можно следовать для повышения безопасности систем Linux при подключении к сети, в том числе использование надежных паролей, включение двухфакторной аутентификации, поддержание систем в актуальном состоянии, настройка и включение брандмауэра, а также регулярный мониторинг. журналы и активность системы.
Давайте рассмотрим эти методы подробнее:
Использование надежных паролей. Надежные пароли необходимы для предотвращения несанкционированного доступа к учетным записям.
Включение двухфакторной аутентификации. Двухфакторная аутентификация добавляет дополнительный уровень безопасности, требуя второй формы аутентификации, например кода, отправляемого на телефон или в приложение, в дополнение к паролю.
Поддержание систем в актуальном состоянии: важно поддерживать системы в актуальном состоянии с помощью последних исправлений и обновлений безопасности для устранения известных уязвимостей.
Настройка и включение брандмауэра. Брандмауэры можно использовать для блокировки несанкционированного доступа к системе.
Регулярный мониторинг журналов и системной активности. Регулярный мониторинг журналов и системной активности может помочь обнаружить и предотвратить потенциальные проблемы с безопасностью.
Эти рекомендации можно автоматизировать с помощью сценариев bash, которые представляют собой простые программы, написанные на языке программирования Bash. Написав и используя сценарии bash, можно упростить и автоматизировать многие задачи безопасности, необходимые для обеспечения безопасности систем Linux при подключении к сети.
Почему именно Bash?
Bash скрипты — это мощный и удобный способ автоматизации задач в системах Linux. Есть несколько причин, по которым bash скрипты являются отличным выбором для автоматизации задач в системах Linux:
Bash широко доступен: Bash является оболочкой по умолчанию в большинстве дистрибутивов Linux, поэтому, скорее всего, она уже установлена в вашей системе. Это означает, что вы можете использовать bash-скрипты без установки дополнительного программного обеспечения.
Bash прост в освоении и использовании: скрипты Bash используют простой и понятный синтаксис, что упрощает изучение и использование даже для новичков в программировании.
Bash скрипты гибки: Bash скрипты можно использовать для автоматизации самых разных задач, от простых задач, таких как переименование файлов, до более сложных задач, таких как настройка систем и развертывание приложений.
Bash скрипты эффективны: Bash скрипты интерпретируются, а не компилируются, что означает, что их можно запускать напрямую без необходимости отдельного этапа компиляции. Это делает их очень эффективными и быстрыми в работе.
Bash скрипты переносимы: Bash скрипты можно запускать в любой системе, в которой установлен Bash, что делает их легко переносимыми. Это особенно полезно, если вам нужно автоматизировать задачи в нескольких системах или на разных платформах.
В целом, bash скрипты — отличный выбор для автоматизации задач в системах Linux благодаря их доступности, простоте использования, гибкости, эффективности и переносимости. Используя скрипты bash, вы можете оптимизировать и автоматизировать многие задачи, необходимые для управления и обслуживания ваших систем Linux, экономя время и усилия и помогая обеспечить бесперебойную и эффективную работу ваших систем.
Вот несколько примеров сценариев bash, которые можно использовать для автоматизации каждого из приведенных выше best practices:
Скрипт, который проверяет и применяет надежные пароли:
#!/bin/bash
# Check all users' passwords for strength
for user in $(cut -d: -f1 /etc/passwd); do
# Check the password for strength
if ! grep -qP '^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#\$%\^&\*])(?=.{8,})' <(grep "^$user:" /etc/shadow); then
# If the password is not strong, force the user to change it
chage -d 0 "$user"
fi
done
Скрипт, который проверяет и устанавливает доступные обновления безопасности:
#!/bin/bash
# Update the package repository
apt update
# Install available security updates
apt upgrade -y --security
Скрипт, который настраивает и включает файерволл:
#!/bin/bash
# Install the necessary packages
apt update
apt install -y ufw
# Allow SSH connections
ufw allow ssh
# Enable the firewall
ufw enable
Вот пример bash-скрипта, который проверяет, включена ли двухфакторная аутентификация (2FA), и если нет, устанавливает и настраивает решение 2FA:
#!/bin/bash
# Check if 2FA is installed
if ! which google-authenticator > /dev/null; then
# If 2FA is not installed, install it
apt update
apt install -y libpam-google-authenticator
fi
# Check if the PAM module is configured
if ! grep -q "auth required pam_google_authenticator.so" /etc/pam.d/sshd; then
# If the PAM module is not configured, configure it
echo "auth required pam_google_authenticator.so" >> /etc/pam.d/sshd
fi
# Check if 2FA is enabled for the current user
if ! grep -q "auth required pam_google_authenticator.so" "$(grep "^$USER:" /etc/passwd | cut -d: -f6)/.profile"; then
# If 2FA is not enabled for the current user, enable it
google-authenticator
echo "auth required pam_google_authenticator.so" >> "$(grep "^$USER:" /etc/passwd | cut -d: -f6)/.profile"
fi
# Restart the SSH daemon to apply changes
systemctl restart ssh
Этот скрипт сначала проверяет, доступна ли команда google-authenticator, которая указывает, что 2FA установлена. Если 2FA не установлен, для его установки используется команда apt.
Затем сценарий проверяет, настроен ли модуль PAM для 2FA для демона SSH, выполняя поиск соответствующей строки в файле /etc/pam.d/sshd
. Если модуль PAM не настроен, он добавляет в файл нужную строку.
Затем скрипт проверяет, включена ли двухфакторная аутентификация для текущего пользователя, ища соответствующую строку в файле .profile
пользователя. Если двухфакторная аутентификация не включена, она запускает команду google-authenticator
для настройки.
И немного про sticky bit
(ох, как же в моей команде не любили эту уязвимость, ибо она была самой назойливой). В контексте сетевой безопасности установка липкого бита в доступном для записи каталоге может помочь предотвратить несанкционированное изменение файлов в этом каталоге.
Sticky bit
(я называю его липучкой) — это специальное разрешение, которое можно установить для каталога, чтобы указать, что только владелец файла может удалить или переименовать файл, даже если каталог имеет разрешения на запись для всех. Это может быть полезно в ситуациях, когда несколько пользователей имеют доступ к общему каталогу, и вы хотите запретить им удалять или переименовывать файлы друг друга.
Без липучки любой пользователь с правами на запись в доступный для записи каталог может удалить или переименовать любой файл в этом каталоге, независимо от того, кому он принадлежит. Это может привести к непредвиденным последствиям, таким как случайное удаление важных файлов или несанкционированное изменение файлов.
Установив липкий бит для доступного для записи каталога, вы поможете предотвратить подобные проблемы и улучшите безопасность своей сети. Особенно важно установить липкий бит для каталогов, доступных для записи всем, в ситуациях, когда каталог содержит конфиденциальные или важные файлы, которые не должны изменяться или удаляться неавторизованными пользователями.
Вот bash-скрипт, который можно использовать, чтобы проверить, установлен ли липкий бит в доступных для записи каталогах, и, если нет, установить его:
#!/bin/bash
# Find all world-writable directories
for dir in $(find / -type d -perm -0002); do
# Check if the sticky bit is set
if [ "$(stat -c "%a" "$dir")" -eq "2" ]; then
# If the sticky bit is not set, set it
chmod +t "$dir"
fi
done
Этот скрипт использует команду find
для поиска всех каталогов, имеющих права на запись для всех (-perm -0002
), и перебирает каждый найденный каталог. Для каждого каталога он использует команду stat для проверки разрешений (%a
) и проверяет, установлен ли липкий бит (2
). Если липкий бит не установлен, для его установки используется команда chmod (+t
).
С помощью этого скрипта вы можете автоматизировать процесс установки липкого бита в каталогах, доступных для записи всем, что может помочь повысить безопасность вашей системы и предотвратить несанкционированное изменение файлов в этих каталогах.
Конечно все это выглядит просто. Давайте сделаем что-нибудь поинтереснее, например это:
#!/bin/bash
# Install necessary packages
apt update
apt install -y ufw fail2ban
# Enable the firewall
ufw enable
# Allow SSH connections
ufw allow ssh
# Block all incoming connections by default
ufw default deny incoming
# Allow outgoing connections
ufw default allow outgoing
# Enable IP spoofing protection
echo "nospoof on" >> /etc/host.conf
# Enable SYN cookies
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
# Enable source address verification
echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
# Enable TCP SYN cookies
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
# Enable TCP SYN-ACK cookies
echo "net.ipv4.tcp_synack_retries = 5" >> /etc/sysctl.conf
# Enable IP spoofing protection
echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf
# Enable SYN cookies
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
# Enable source address verification
echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf
# Enable TCP SYN cookies
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
# Enable TCP SYN-ACK cookies
echo "net.ipv4.tcp_synack_retries = 5" >> /etc/sysctl.conf
# Enable TCP SYN cookies
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
# Enable TCP SYN-ACK cookies
echo "net.ipv4.tcp_synack_retries = 5" >> /etc/sysctl.conf
# Enable fail2ban
systemctl enable fail2ban
systemctl start fail2ban
Этот сценарий устанавливает и активирует необходимые пакеты, включая брандмауэр ufw
и средство предотвращения вторжений fail2ban
. Затем он настраивает различные расширенные механизмы сетевой безопасности Linux, включая защиту от спуфинга IP, файлы cookie SYN
, проверку исходного адреса и файлы cookie TCP SYN
.
Сценарий также настраивает фаирволл ufw
так, чтобы он по умолчанию блокировал все входящие подключения и разрешал исходящие. Это может помочь предотвратить несанкционированный доступ к вашей системе и защитить от потенциальных угроз.
Наконец, сценарий включает и запускает службу fail2ban
, которая может помочь предотвратить атаки брутфорс путем блокировки IP-адресов, которые неоднократно не проходили аутентификацию.
С помощью этого сценария вы можете автоматизировать процесс настройки расширенных механизмов сетевой безопасности Linux и повысить безопасность своих систем.
И помните, безопасность она как кислород, пока он есть, вы о нем даже не задумываетесь, но когда его нет - это все о чем вы будете думать.
В заключение приглашаю всех на бесплатный урок, посвященный базовым командам в Linux. Урок подойдет тем, кто практически не знаком с Linux. Вы узнаете, почему важно знать как работать в командной строке. Познакомитесь с bash, научитесь базовым командам для работы с файлами в Linux.
Комментарии (15)
TyVik
13.01.2023 20:49+4Bash прост в освоении и использовании
Вот здесь, конечно, посмеялся. А потом поплакал. Мои студенты первые 2 пары в шоке от синтаксиса. Но увы, это стандарт, так что приходится проходить.
DollyPapper
13.01.2023 21:31-1Тоже посмеялся с этого пункта. Где-то в интернете есть поверие, что баш скрипты одноразовые. Потому что после написания, через пару дней легче написать новый скрипт, чем отладить существующий.
AVX
13.01.2023 21:59+3Не обязательно. Можно на пять строчек скрипта написать 40 строк комментариев с подробным разбором того, что там делается и зачем. А вот если там более-менее сложный регэксп... к скрипту полагается прикладывать как минимум бутылочку коньяка и письмо с извинениями в адрес человека, кто будет в этом разбираться.
DollyPapper
13.01.2023 22:22-1А на 10 строчек 80 строк коментов. Что-то это противоречит утверждению о простоте языка. Ну так в целом с маленькими скриптами я согласен, проблем нет. Недавно пришлось отлаживать скрипт на 2000 строк, который впн ставит и конфигурирует. Плюнул - переписал в итоге.
garwall
13.01.2023 23:48+3Bash-скрипты переносимы
---
apt что-то там
«На берегу Рио-Пьедра села я и заплакала»
saboteur_kiev
14.01.2023 03:23+3Какое жуткое непонимание bash и всего остального ;)
После фразы "простые баш скрипты" идет регулярка на 63 символа с использованием продвинутых конструкций типа look ahead, или с условиями. Это не часть баша, в такие регулярки не каждый сисадмин сходу осилит.То что там сделано со sticky бит вообще за такое руки отрывать. По умолчанию практически ВСЕ каталоги в линуксе - доступны на запись. Для рута. То есть на все каталоги, включая /dev, и включая /proc выставить стики бит? Отличненько, Автор проверял лично на своей системе, лучше сразу в продакшене что произойдет?
Очень, очень многие не понимают, что баш - это шелл для операционной системы.
Это действительно довольно простой язык и интересный язык, с богатыми возможностями даже в POSIX стандарте, без башизмов.
Но его реальное использование глубоко связано с пониманием администрирования линукс да и архитектуры *nix вообще. Без этого понимания, попытки сделать что-то полезное и отличающееся от hello world на bash будут постоянно спотыкаться на непонятные глюки, проблемы и ненадежность. А этим страдает огромное количество разработчиков, которые по непонятной мне лично причине, не разбираются в базовой архитектуре операционных систем. Даже таких базовых вещах как что такое environment variable или stdout/stderr (капец, да?).Та же самая переносимость обеспечивается не баш скриптами, а posix-совместимыми скриптами. Конечно, если быть уверенным, что вам не нужно будет запускать его где-нить в урезанном аналоге busybox, то да, можно юзать и баш с хеш массивами и кучей variable expansion.
Короче. Как человек, который может себе позволить сказать что "я более чем неплохо знаю bash", я скажу, что статья мне не понравилась некорректными утверждениями.
Очевидно, что автор либо не писал эти скрипты сам, либо не имел опыта работы хотя бы с несколькими разными дистрибутивами.
MiGuSan
14.01.2023 03:59+2Зачем вы проверяете хэш паролей в
/etc/passwd
? это вам ничего не дастНастройка firewall в том, чтобы включить SSH ? а что, так можно было ? ))
shalamberidze
15.01.2023 19:50Ну и плюс ко всему двухфакторная авторизация. Предупреждать надо чо это гоогле а то кто нибудь запустит это и останется без доступа к системе.
Samhuawei
Как мне кажется ещё лучше не использовать паролей вообще. Сгенерить ключик, забрать себе публичную часть и ходить на сервак исключительно через ssh.
Ну и в целом колхоз какой-то.
select26
Тоже покоробило. Заголовок "Сетевая безопасность Linux: Best practices". И первая же рекомендация: "Использование надежных паролей". Хотя давно уже: "Не использовать пароли вообще". И речь даже не про новомодный zero trust, хотя бы классический RSA ssh key.
Дальше читать даже не стал.
Мне вот интересно: это Контент-маркетолог Дмитрий Головин такой бестолковый или IBM Senior DevOps Engineer & Integration Architect, Официальный DevOps ментор и коуч в IBM Рустем Галиев (зато титул прямо как у Великого Князя)?
ivan386
Я помню что gnupg при генерации ключа вроде как предлагает его зашифровать паролем.