Автор статьи: Рустем Галиев

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)


  1. Samhuawei
    13.01.2023 17:46
    +9

    Использование надежных паролей

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

    Ну и в целом колхоз какой-то.


    1. select26
      13.01.2023 23:18
      +2

      Тоже покоробило. Заголовок "Сетевая безопасность Linux: Best practices". И первая же рекомендация: "Использование надежных паролей". Хотя давно уже: "Не использовать пароли вообще". И речь даже не про новомодный zero trust, хотя бы классический RSA ssh key.
      Дальше читать даже не стал.

      Мне вот интересно: это Контент-маркетолог Дмитрий Головин такой бестолковый или IBM Senior DevOps Engineer & Integration Architect, Официальный DevOps ментор и коуч в IBM Рустем Галиев (зато титул прямо как у Великого Князя)?


    1. ivan386
      15.01.2023 11:20

      Я помню что gnupg при генерации ключа вроде как предлагает его зашифровать паролем.


  1. TyVik
    13.01.2023 20:49
    +4

    Bash прост в освоении и использовании

    Вот здесь, конечно, посмеялся. А потом поплакал. Мои студенты первые 2 пары в шоке от синтаксиса. Но увы, это стандарт, так что приходится проходить.


    1. DollyPapper
      13.01.2023 21:31
      -1

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


      1. AVX
        13.01.2023 21:59
        +3

        Не обязательно. Можно на пять строчек скрипта написать 40 строк комментариев с подробным разбором того, что там делается и зачем. А вот если там более-менее сложный регэксп... к скрипту полагается прикладывать как минимум бутылочку коньяка и письмо с извинениями в адрес человека, кто будет в этом разбираться.


        1. DollyPapper
          13.01.2023 22:22
          -1

          А на 10 строчек 80 строк коментов. Что-то это противоречит утверждению о простоте языка. Ну так в целом с маленькими скриптами я согласен, проблем нет. Недавно пришлось отлаживать скрипт на 2000 строк, который впн ставит и конфигурирует. Плюнул - переписал в итоге.


      1. LevOrdabesov
        14.01.2023 16:50
        +1

        Кто в cmd писал, в bash-e радуется..


  1. garwall
    13.01.2023 23:48
    +3

    Bash-скрипты переносимы

    ---

    apt что-то там

    «На берегу Рио-Пьедра села я и заплакала»


    1. garwall
      13.01.2023 23:53
      +4

      Ну и в /etc/shadow хэш чтоль на сложность проверяется? Брависсимо


      1. mc2
        14.01.2023 00:51
        +1

        Теперь остался только один вопрос: если такая девопсия, куда можно отправить резюме)


  1. 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", я скажу, что статья мне не понравилась некорректными утверждениями.

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


  1. MiGuSan
    14.01.2023 03:59
    +2

    1. Зачем вы проверяете хэш паролей в /etc/passwd ? это вам ничего не даст

    2. Настройка firewall в том, чтобы включить SSH ? а что, так можно было ? ))


  1. kaasnake
    14.01.2023 10:27

    Автор, найдите время почитать про Ansible.


  1. shalamberidze
    15.01.2023 19:50

    Ну и плюс ко всему двухфакторная авторизация. Предупреждать надо чо это гоогле а то кто нибудь запустит это и останется без доступа к системе.