Начальная настройка Linux сервера на примере Debian

В этот раз мы будем выполнять базовую настройка сервера Linux на примере дистрибутива Debian 12.

Предисловие

Продолжаем тему администрирования Linux сервера. В прошлые разы мы:

• Установили VirtualBox в Linux Mint
• Установили Debian 12 в VirtualBox
• Подробно рассмотрели процесс подключения к серверу по SSH

Сегодня мы выполним начальную настройку сервера Debian версии 12 перед его дальнейшей эксплуатацией.

Данная инструкция актуальна для настройки как виртуальных серверов, созданных, например в VirtualBox локально или у хостеров, например Virtual Private Server (VPS), так и для классических железных (bare-metal) серверов.

КЛИК, если сервер установлен в VirtualBox

Создание снимка системы

Если вы настраиваете локальный виртуальный сервер, то рекомендую перед началом выполнить создание снимка системы (snapshot). Например, чтобы такое сделать в VirtualBox, нужно нажать на меню виртуальной машины:

Выбрать раздел «Снимки», нажать «Создать», указать имя и описание и нажать «Ок»:

Всё, снимок состояния создан.

Имейте в виду, что снимки состояния виртуальных машин — это не полноценная резервная копия. Это фиксация гипервизором текущего состояния машины, по сути журнал изменений, с помощью которого можно быстро откатиться на нужную точку. Хранить длительное время снимки не рекомендуется, т.к. по мере внесения изменений в ВМ, созданные снимки будут увеличиваться в размерах и ощутимо грузить хостовую систему и саму ВМ.

Поэтому снапшоты рекомендуется делать перед внесением значительных изменений в системе, в качестве подстраховки. А после выполнения работ и всех проверок работоспособности — их желательно удалить.

Для восстановления, нужно выключить машину, зайти в раздел управления снимками, выбрать нужный и нажать «Восстановить»:

Создание виртуального интерфейса хоста

Для удобства связи с сервером, установленного в VirtualBox давайте создадим виртуальный сетевой интерфейс на хост системе, через который мы будем взаимодействовать с нашей ВМ, как будто мы в одной сети.

Для этого нажимаем «Файл» —> «Менеджер сетей хоста» и затем на кнопку «Создать»:

Выполним команду ip a (выводит список сетевых интерфейсов) в терминале хостовой системы, и увидим наш виртуальный интерфейс.

Теперь заходим в сетевые настройки нашей ВМ, далее «Адаптер 2» (первый не трогаем, иначе пропадет доступ в интернет), включаем его и выбираем тип подключения: «Виртуальный адаптер хоста» (виртуальный адаптер выберется автоматически) и затем «Ок»:

Запускаем ВМ. Выполним в ней ip a и узнаем имя нового интерфейса на нашем сервере. На данный момент интерфейс не активен. Чтобы его поднять выполняем:

BASH

Свернуть Копировать

ip link set enp0s8 up

dhclient enp0s8

Нажмите, чтобы развернуть и увидеть больше

Где enp0s8 имя нового сетевого интерфейса. У вас оно может быть другим.

Теперь настроим «автоподнятие» данного интерфейса при старте системы. Открываем на редактирование файл настроек сетевых интерфейсов для Debian:

BASH

Свернуть Копировать

vi /etc/network/interfaces

Нажмите, чтобы развернуть и увидеть больше

И добавляем ниже настроек основного интерфейса, настройки дополнительного. Можно просто скопировать, заменив только имя интерфейса. В моем случае это выглядит так:

Сохраняем и перезапускам ВМ:

BASH

Свернуть Копировать

reboot

Нажмите, чтобы развернуть и увидеть больше

Проверяем:

BASH

Свернуть Копировать

ip a

Нажмите, чтобы развернуть и увидеть больше

После перезапуска VirtualBox почему-то назначает следующий по списку IP (был 101, стал 102), но не будем вдаваться в нюансы работы данного гипервизора. Главное у нас есть IP адрес, который напрямую доступен из хостовой системы. В моем случае это: 192.168.56.102

Проверим связь с ВМ на хостовой машине, а также доступ в интернет у ВМ:

BASH

Свернуть Копировать

# на клиенте
ping -c3 192.168.56.102

# на сервере
ping -c3 google.com

Нажмите, чтобы развернуть и увидеть больше

Как видно, прямая связь хоста с ВМ есть, у ВМ доступ в интернет есть — можем продолжать 😉

Чтобы можно было пользователем root подключится по SSH к ВМ с использованием пароля, необходимо изменить дефолтные значения, запрещающие это. Ниже в статье мы вновь выключим этот параметр.

BASH

Свернуть Копировать

sed -i 's/^#PermitRootLogin.*/PermitRootLogin\ yes/' /etc/ssh/sshd_config

sshd -t

systemctl restart sshd

Нажмите, чтобы развернуть и увидеть больше

После чего проверьте подключение SSH:

BASH

Свернуть Копировать

ssh root@192.168.56.102

Нажмите, чтобы развернуть и увидеть больше

Начальная настройка сервера Debian

Вводные данные, используемые в этой статье:

В данной статье, я подразумеваю, что у вас есть root доступ к серверу, так как начало настройки будет выполняться от его имени.

Открываем консоль нашей ВМ и первым делом..

Смена пароля пользователя root

Выполняем:

passwd

и дважды указываем новый пароль:

Теперь можем для удобства подключиться к серверу по SSH и продолжить настройку уже в терминале:

ssh root@192.168.56.102

Установка необходимых утилит

Теперь обновим кэш пакетов, обновим сами пакеты и установим некоторые полезные утилиты, для дальнейшей работы с сервером:

apt update && apt upgrade -y

apt install -y sudo ufw zsh software-properties-common neovim curl wget git mc fzf

Описание устанавливаемых пакетов:

Настройка сети с помощью systemd-networkd

⚠️Если сеть у вас уже настроена, то можете пропустить этот шаг.

В целях унификации я предпочитаю настраивать сеть на Linux серверах с помощью systemd-networkd.

❗Перед внесением каких-либо изменений, обязательно убедитесь, что у вас есть физический доступ к серверу / доступ к консоли ВМ с гипервизора, чтобы вы могли оперативно откатить конфигурацию, если что-то пойдет не так.

Предварительно делаем бэкапы текущих файлов настроек по рекомендации из документации Debian:

mv -v /etc/network/interfaces{,.backup}
mv -v /etc/network/interfaces.d{,.backup}

Если вы используете netplan, то бэкапим и его:

mv -v /etc/netplan{,.backup}

Теперь открываем на редактирование новый файл с настройками сети:

nvim /etc/systemd/network/10-lan0.network

💡Цифра 10 в имени определяет очередность считывания настроек из файлов, если их несколько (10, 20 и т.д).

Для статической адресации наполняем файл примерно таким содержимым:

⚠️Замените сетевые параметры на свои. Подсмотреть их можно в файлах /etc/network/interfaces*.

[Match]
Name=eth0
   
[Network]
Description=Local network
Address=192.168.56.102/24
Gateway=192.168.56.1

Если сетевые параметры вы получаете по DHCP, тогда содержимое будет примерно таким:

[Match]
Name=eth0

[Network]
DHCP=ipv4

systemd-networkd принимает групповые символы. Если у вас несколько интерфейсов получают настройки по DHCP, то можно заполнить файл так:

[Match]
Name=e*

[Network]
DHCP=ipv4

💡Подробнее про все параметры systemd-networkd смотрите тут.

Применяем настройки и активируем автозапуск:

systemctl restart systemd-networkd

systemctl enable systemd-networkd

systemctl status systemd-networkd

💡Для управления сетью используйте стандартные команды systemctl start|stop|restart systemd-networkd.

В составе systemd-networkd идет удобная утилита networkctl, с помощью которой можно смотреть информацию по сетевым подключениям и управлять ими:

networkctl status

Посмотреть статус можно и классическим способом:

ip address

Проверяем доступ в интернет:

ping -c3 r4ven.me

Крайне рекомендуется перезапустить сервер, чтобы убедиться, что автоматическое поднятие сети происходит корректно:

reboot

systemd-networkd позволяет довольно гибко конфигурировать сеть в Linux. Подобным образом в файлах задаются сетевые маршруты, правила маршрутизации, DNS, настройки NTP и так далее.

Настройка DNS с помощью systemd-resolved

⚠️Если у вас DNS уже настроен, то можете пропустить этот шаг.

Во многих современных дистрибутивах Linux для управления DNS используется один из модулей systemd — systemd-resolved.

systemd-resolved — это компонент Systemd, отвечающий за работу DNS. Он управляет запросами, кэширует результаты и поддерживает различные протоколы.

Выполняем установку пакета:

❗Также убедитесь, что у вас есть доступ к консоли сервера, перед внесением изменений.

apt install systemd-resolved

☝️В соответствии с политикой Debian чаще всего устанавливаемые сервисы-демоны запускаются после установки с включением автозапуска при старте системы.

Для редактирования параметров DNS открываем файл конфигурации:

nvim /etc/systemd/resolved.conf

И в блоке Resolve изменяем (или дополняем) директиву DNS= своими значениями:

[Resolve]
DNS=8.8.8.8 1.1.1.1
Domains=~.

☝️Если не указать опцию Domains=~., то systemd-resolved может использовать DNS-серверы из настроек отдельных сетевых интерфейсов, если параметр Domains=~. в них есть. Данная опция не повлияет на запросы доменных имён, которые совпадают с каким-то более точным поисковым доменом из настроек интерфейса.

Сохраняем и перезапускаем службу, на всякий активируем автозапуск + очищаем кэш DNS:

💡В составе пакета systemd-resolved идет утилита управления настройками DNS — resolvectl.

systemctl restart systemd-resolved

systemctl enable systemd-resolved

systemctl status systemd-resolved

resolvectl flush-caches

Также для совместимости с приложениями, которые не используют библиотечные вызовы, а обращаются к DNS серверу напрямую, рекомендуется создать такой симлинк (с предварительным бэкапом файла resolv.conf):

mv /etc/resolv.conf{,.backup}

ln -sv /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Для подробного ознакомления с процессом настройки DNS посредством systemd-resolved рекомендую ознакомиться c этим вики-материалом.

⚠️ По опыту, в случае systemd-resolved предпочтительным будет перезапустить систему целиком, но это необязательно.

Проверяем работу DNS:

resolvectl status

resolvectl query r4ven.me

ping -c3 r4ven.me

nslookup r4ven.me

💡Для управления DNS используйте стандартные команды systemctl start|stop|restart systemd-resolved.

systemd-resolved имеет гибкие настройки, включая DNSSEC, DNS over TLS, Multicast DNS (mDNS), Link-Local Multicast Name Resolution (LLMNR) и др.

Подробнее про работу подсистемы DNS в Linux читайте тут и тут.

Настройка NTP с помощью systemd-timesyncd

Для многих сервисов в Linux важна точность времени. Чтобы сервер всегда знал точное время рекомендуется настраивать его синхронизацию с билжайшим NTP сервером. Для этой цели воспользуемся модулем systemd-timesyncd.

Выполняем установку:

apt install systemd-timesyncd

Открываем на редактированием конфиг файл сервиса:

nvim /etc/systemd/timesyncd.conf

И наполняем примерно таким содержимым:

⚠️При необходимости замените список NTP серверов на свои.

[Time]
NTP=0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

• NTP= — список основных NTP-серверов, взять их можно, например, отсюда;
• FallbackNTP= — резервные серверы;
• RootDistanceMaxSec= — максимальное расстояние до источника (в секундах);
• PollIntervalMinSec, PollIntervalMaxSec — минимальный и максимальный интервал опроса.

Используемый NTP-сервер будет определяться с помощью следующих правил:

• Приоритет имеют любые NTP-серверы, полученные для конкретного интерфейса из настроек systemd-networkd или через DHCP;
• Серверы NTP, указанные в файле /etc/systemd/timesyncd.conf, будут добавлены к списку серверов каждого каждого интерфейса во время работы, и демон будет обращаться к ним по очереди, пока какой-нибудь сервер не ответит;
• Если после этого рабочий сервер не найдётся, будут использоваться серверы из настройки FallbackNTP=.

Для более подробного описания работы systemd-timesyncd изучите эту wiki-статью.

Перезапускаем сервис, добавляем его в автозапуск и смотрим статус:

systemctl restart systemd-timesyncd

systemctl enable systemd-timesyncd

systemctl status systemd-timesyncd

В составе Systemd идет удобная утилита управления timedatectl. Посмотреть статус службы с ее помощью можно так:

timedatectl status

timedatectl timesync-status

💡Для управления systemd-timesyncd используйте стандартные команды systemctl start|stop|restart systemd-timesyncd.

systemd-timesyncd — удобный и простой в использовании клиент NTP, который позволяет быстро настроить синхронизацию времени по сети.

Добавление нового пользователя

⚠️ Если у вас уже существует локальный пользователь, то можете пропустить данный шаг.

Если вы при установке Debian 12 или настройке ВМ, например, в случае VPS, не создали нового пользователя системы, то создаём:

useradd -m -G sudo -s /bin/bash ivan

passwd ivan

Где в первой команде:

• -m — ключ, который указывает на необходимость создать домашний каталог пользователя (по умолчанию в папке /home);
• ivan — это имя нового пользователя, задайте своё;
• -G sudo — ключ указывающий, добавить нового пользователя в перечисленные группы (в данном случае одна — группа sudo);
• -s /bin/bash — параметр, задающий оболочку по умолчанию, для пользователя. Я указал этот параметр для демонстрации. Если его не задать, по умолчанию пользователю назначится оболочка bash.

А командой passwd мы задаём новому пользователю пароль. По умолчанию у новых пользователей он отсутствует/отключён.

Настройка SSH на клиентском хосте

Постулатами безопасности рекомендуется не работать в Linux-based системах от имени пользователя root напрямую. Подключение под этим пользователем к удалённым серверам обычно отключают. Что и сделаем мы, но чуть позже, а пока настроим подключение с авторизацией по SSH ключу от имени ранее созданного нами пользователя.

Обратите внимание, шаги этого пункты выполняются на пользовательской системе, т.е. не на сервере.

Пару слов, про тип генерируемых ключей. Для генерации ключей используется утилита ssh-keygen, которая по умолчанию создаёт ключи типа RSA. Это довольно старый, созданный еще в 1977 году криптографический алгоритм, но который всё еще очень популярный, т.к. поддерживается большинством систем. Подробнее про него можно почитать на википедии.

Сами разработчики протокола SSH рекомендуют использовать ключи более современного алгоритма шифрования — EdDSA, а именно ed25519. Данный алгоритм основан на эллиптических кривых. Подробнее также на вики. Как утверждается, он является более безопасным и лучше оптимизирован по скорости работы. Его мы и будем использовать.

И так, на нашей desktop системе открываем терминал и генерируем новые ключи (если вы не делали этого ранее):

test -e ~/.ssh || mkdir -v $HOME/.ssh/ && chmod 700 ~/.ssh

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Командой test -e ~/.ssh || mkdir $HOME/.ssh/ && chmod 700 ~/.ssh мы проверили наличие директории файлов SSH, и если такая директория отсутствует — создаём её и выставляем правильные права.

Подробнее про механизм перенаправления и операторы управления выполнением команд можно почитать тут: Контроль выполнения команд: операторы «&&», «||», «;» и «&».

Во время генерации у вас запросят ключевую фразу для шифрования самого файла ключа. Если её задать, то при каждой авторизации с помощью данного ключа система будет запрашивать у вас пароль для расшифровки файла-ключа.

По-хорошему, нужно пароль задать, но тогда пропадает смысл «безпарольной» авторизации на удаленных системах. Тут все зависит от уровня вашей паранойи и места, с которого вы будете подключаться. Если это ваши личные проекты, то для удобства пароль можно не задавать. В этом примере я не буду задавать пароль. Для этого дважды кликаем Enter на запрос парольной фразы для ключа.

Существуют и альтернативные решения, позволяющие зашифровать файл-ключ, но при этом не вводить пароль каждый раз для его расшифровки — это использование утилиты ssh-agent. Но это тема для отдельной заметки)

После генерации в директории ~/.ssh появятся два файла:

• id_ed25519 — приватный ключ, который нельзя никому сообщать;
• id_ed25519.pub — публичный ключ, который не страшно и потерять.

Проверяем:

ls -l ~/.ssh/id_ed*

Теперь копируем наш публичный SSH ключ для входа на наш сервер специальной командой:

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub ivan@192.168.56.102

Не забудьте подставить свои имя пользователя и ip адрес сервера.

При выполнении система запросит пароль нашего пользователя на сервере.

После отработки команды, в домашней директории пользователя на нашем сервере появится файл ~/.ssh/authorized_keys, где будет прописан наш публичный ключ с клиентской машины. Можем это проверить:

• На клиентской машине:

cat ~/.ssh/id_ed25519.pub

• На сервере:

cat /home/ivan/.ssh/authorized_keys

По сути, мы могли и вручную добавить этот ключ/набор символов в файл ~/.ssh/authorized_keys, но утилита сама всё делает + выставляет корректные права на файлы.

Обратите внимание, что права на чувствительные файлы SSH должны быть выставлены исключительно для владельца файлов. А именно:

• 700 для директорий, в т.ч. ~/.ssh
• 600 для файлов, в т.ч. ~/.ssh/authorized_keys

Иначе система просто не позволит вам ими воспользоваться.

Теперь пробуем подключится к серверу с помощью SSH ключа:

ssh ivan@192.168.56.102

Как видим, пароль больше не запрашивается.

Теперь, успешно подключившись к серверу под новым пользователем, продолжаем настройку.

Прежде чем продолжить, хотел бы осветить еще один нюанс. С целью обеспечения большей безопасности и предотвращении нежелательных последствий — работать в консоли Linux рекомендуется от имени обычного пользователя, но у которого есть возможность выполнять команды от имени суперпользователя root.

Другими словами: подключение к системе, выполнение типичных задач, не требующих привилегий и пр. необходимо выполнять от имени обычного юзера. А при необходимости провести более серьезные манипуляции, например, внести какие-то изменения в настройки системы — то использовать команду sudo, при этом не переходя в учётную запись root.

Таким образом повышается общая безопасность и уменьшается вероятность что-то случайно сломать. Конечно временами так бывает не удобно, и никто не запрещает вам просто перейти в root. Не забывайте, что сказанное выше — это рекомендация, которой просто желательно следовать.

Настройка текстового редактора по умолчанию

Читатели моих предыдущих статей уже знают, что в качестве консольного текстового редактора я предпочитаю Vim/Neovim. Если интересно узнать что это такое и почему мой выбор пал именно на него, то прошу к прочтению . Если что, мой конфиг Neovim, по мере настройки, будет дополняться в репе на GitHub.

Чтобы задать в косноли сервера редактора по умолчанию выполним команду:

echo 'SELECTED_EDITOR="/usr/bin/nvim"' > ~/.selected_editor

Создать такой файл можно также и для рута, чтобы везде были одинаковые настройки:

echo 'SELECTED_EDITOR="/usr/bin/nvim"' | sudo tee ~/.selected_editor

Вы вероятно заметили, что для выполнения той же операции, но для пользователя root мы использовали немного другую команду.

Дело в том, что если выполнить: sudo echo 'SELECTED_EDITOR="/usr/bin/nvim"' > /root/.selected_editor — то мы получим ошибку. В случае второй команды — ошибки не будет:

Особенность в том, что хоть и команда echo выполняется через sudo, но перенаправление вывода, перехватываемое оператором > выполняется все еще от обычного пользователя, поэтому мы получаем Permission denied.

В случае второй команды, наоборот: сперва выводим желаемый текст, а затем с помощью команды tee, запускаемой через sudo мы перенаправляем вывод от имени суперпользователя. В реальной практике часто можно встретить такой нюанс в работе механизма привилегий в Linux.

Команда tee — читает стандартный ввод и записывает его в указанный файл и параллельно передает на стандартный вывод.

Подробнее про стандартные ввод/вывод можно почитать в отдельной моей статье: Командная строка Linux, вывод и чтение содержимого: команды echo, cat, less.

Отключение IPv6

Не буду вдаваться в подробности, зачем нужно отключать IPv6, если он не используется. Оставлю это на самостоятельное изучение. Покажу лишь, как это делается в Linux.

Открываем на редактирование системный конфиг:

sudo nvim /etc/sysctl.conf

И в конец файла добавляем следующие строки:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Для перечитывания конфига выполняем:

sudo sysctl -p

Настройка фаервола UFW

На каждом сервере я обязательно активирую и настраиваю сетевой экран. В ОС на базе Linux в состав ядра входит модуль Netfilter, который отвечает за обработку сетевых пакетов. Управляет этим модулем утилита iptables или ее современная версия nftables. Данные утилиты являются низкоуровневыми и их настройка это отдельная тема. Для deb based дистрибутивов существует более простоя и интуитивно понятная утилита управления фаерволом — ufw. В rpm дистрибутивах есть аналогичная программа — firewallcmd. Но так как у нас Debian 12, я использую ufw (установили её на шаге установки пакетов). Выполним базовую настройку защиты сети.

Отключаем IPv6 в UFW. Открываем на редактирование файл конфигурации ufw:

sudo nvim /etc/default/ufw

Меняем строку IPV6=yes на no:

IPV6=no

Далее открываем доступп извне к портам SSH:

sudo ufw allow 22/tcp

sudo ufw allow 27244/tcp

27244 — нестандартный порт для подключения по SSH, который мы зададим ниже в настройках SSH сервера. Стандартные порты сервисов по возможности рекомендуется менять. Т.к. они обычно сканируются ботами.

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

Включаем и перезапускам ufw:

sudo ufw enable && sudo systemctl restart ufw

Нас предупредят, что активация фаервола может дропнуть текущее SSH соединения. Но если вы корректно добавили правило для открытия порта 22 TCP, то все должно быть в порядке.

Если после выполнения команды вы остались на связи, то мои поздравления, продолжаем.

Посмотреть существующие правила в UFW можно так:

sudo ufw status verbose

Тут мы видим, что у нас «открыты» два порта для доступа из вне. Обратите внимание на 3-ю строку — это политика обработки пакетов по умолчанию

Т.е.

• все входящие соединения (кроме прописанных правил) отбрасывать;
• исходящие разрешены;
• маршрутизация между интерфейсами отключена.

Запрет ответов по ICMP

Запрет ICMP с помощью ufw

Если вы настраиваете сервер с внешним IP, возможно вы захотите отключить ответы ping и traceroute по протоколу ICMP.

Для этого откройте на редактирование файл /etc/ufw/before.rules:

sudo nvim /etc/ufw/before.rules

Найдите и закоментируйте блоки правил, касающиеся ICMP:

# ok icmp codes for INPUT
# -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
# -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
# -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
# -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
# -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
# -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
# -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
# -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

После чего перезапустите фаервол:

sudo ufw reload

Попробуйте выполнить ping и traceroute -I до вашего сервера, ответов быть не должно.

Запрет ICMP с помощью параметров ядра

Запретить ICMP ответы в Linux на уровне ядра можно с помощью утилиты sysctl или изменяя файлы в /proc/sys.

💡 sysctl — это удобная обёртка для чтения и записи параметров ядра Linux в виртуальную файловую систему /proc/sys.

Для временного запрета выполните команды:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

# или

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

💡В случае ipv6 замените 4 на 6.

Чтобы вновь разрешить ICMP ответы:

sysctl -w net.ipv4.icmp_echo_ignore_all=0

# или

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all

При необходимости сделать изменения постоянными — добавьте данные параметры в файл /etc/sysctl.conf:

sudo nvim /etc/sysctl.conf

net.ipv4.icmp_echo_ignore_all = 1
net.ipv6.icmp.echo_ignore_all = 1

После чего перечитайте конфиг:

sysctl -p

Стоит обратить внимание, что таким образом не отключается полное взаимодействие по ICMP. Например, стоит изучить следующие параметры:

• net.ipv4.icmp_echo_ignore_broadcasts
• net.ipv4.icmp_ignore_bogus_error_responses
• net.ipv4.icmp_ratelimit0
• net.ipv4.icmp_ratemask

Описание этих и других параметров ICMP смотрите тут 🧐.

Изменение hostname сервера и правка файла hosts

Чтобы изменить hostname нашей системы открываем на редактирование соответствующий файл:

sudo nvim /etc/hostname

Я задам такой:

r4ven-test

Также добавим наш новый hostname в файл hosts (в Linux данный файл выполняет ту же функцию, что и в Windows):

sudo nvim /etc/hosts

Добавляем:

127.0.0.1    r4ven-test

Создание swap в файле (опционально)

Если swap файл у вас отсутствует, его рекомендуется создать. swap файл может быть как отдельным разделом, так и простым файлом. Даёшь больше виртуальности!

Проверим наличие активного swap в системе:

free -m

Создание и запуск:

# создаём файл размеров 1GB
sudo fallocate -l 1G /swap

# выставляем права на чтение-запись только для владельца (root)
sudo chmod 600 /swap

# создаём swap из файла
sudo mkswap /swap

# активируем его
sudo swapon /swap

Вновь проверяем:

free -m

Мы создали swap файл и запустили его вручную. Но при перезапуске сервера он сам не запуститься. Для этого нужно добавить его в специальный файл, где перечислены файловые системы, которые монтируются при запуске системы — /etc/fstab:

echo "/swap    none    swap    sw    0    0" | sudo tee -a /etc/fstab

Ключ -a для команды tee обязателен! Он указывает tee выполнить добавление в конец файла, а не перезаписать его.

Проверим на всякий случай fstab:

cat /etc/fstab

Пожалуйста, будьте внимательны. Добавляйте swap файл в автозагрузку, только если его создание и активация прошли успешно. Если это не так, то при следующем перезапуске системы, есть риск, что система попросту не загрузится.

Установка и настройка locales и timezone

В каждой системе есть такая сущность, как «локаль» — другими словами локализация. По умолчанию, если во время установки Debian 12, не выбрать иное, устанавливается локаль C.UTF-8 UTF-8. Давайте установим рекомендуемую английскую: en_US.UTF-8 UTF-8 и добавим русскую: ru_RU.UTF-8 UTF-8 локали. Делается это так:

# установка пакета локалей
sudo apt install -y locales

# интерактивная настройка локали
sudo dpkg-reconfigure locales

С помощью клавиши Space (пробел) ставим галочку на en_US.UTF-8 UTF-8 (обязательно) и вторую на нужную вам (в моём случае это ru_RU.UTF-8 UTF-8) локаль. Далее клавишей Tab переводим курсор на кнопку <Ok> нажимаем Enter.

Далее выбираем основную локаль, именно она будет использоваться для отображения системной информации. Английский текст меня не пугает (особенно с переводчиком), поэтому я оставлю en_US.UTF-8:

К слову у меня есть небольшая заметка на крутой переводчик: Crow Translate — Самый удобный переводчик текста.

Клавишей Tab переводим курсор на <Ok> и жмём Enter. Пара секунд и локали сгенерированы:

Теперь зададим часовой пояс для нашего сервера такой командой:

sudo timedatectl set-timezone Europe/Moscow

Список всех доступных таймзон можно посмотреть командой:

timedatectl list-timezones

Ротация системных журналов

По умолчанию в Debian GNU/Linux настроено журналирование системных событий без ограничений на количество хранимых файлов. Дабы в будущем не обнаружить полностью забитый диск журналами системы, рекомендуется задать ограничения.

В Debian 12 за инициализацию системы, в т.ч. и журналирование, отвечает программа systemd. Управление журналами выполняется определенной утилитой из пакета systemd — journald.

Ограничить количество логов с её помощью можно:

• по времени хранения;
• по размеру.

Для этого отредактируйте конфиг службы журналирования:

sudo nvim /etc/systemd/journald.conf

Где SystemMaxUse=800M — ограничение по размеру хранимых журналов, а MaxFileSec=2week — по времени.

Количество дней и размер выбирайте по вашим потребностям, ну или предпочтениям.

Не забываем сохраниться и перезапустить службу:

sudo systemctl restart systemd-journald

Если вы оказались в ситуации, когда журналы уже скопились, очистить их можно специальными командами.

По времени:

sudo journalctl --vacuum-time=15d

По размеру:

sudo journalctl --vacuum-size=800M

Настройка SSH сервера

Открываем файл конфигурации SSH сервера:

sudo nvim /etc/ssh/sshd_config

И устанавливаем следующие параметры:

# меняем стандартный порт подключения
Port 27244

# включаем использование только IPv4
AddressFamily inet

# отключаем возможность подключаться под пользователем root
PermitRootLogin no

# явно разрешаем подключения по ключу
PubkeyAuthentication yes

# отключаем подключения по паролю
PasswordAuthentication no

# отключаем авторизацию с помощью подсистемы PAM
UsePAM no

# опционально, разрешаем подключение только указанным пользователям
AllowUsers ivan

Пожалуйста, будьте осторожны с настройками SSH сервера. Демонстрируемая мной конфигурация сильно ограничивает возможности подключения к серверу. Разрешая подключения лишь по SSH ключам и только для указанных пользователей.

Если что-то настроить неверно, вы можете потерять доступ к своему серверу. Помните, что данная статья носит рекомендательный характер. Все действия вы выполняете на свой страх и риск.

В целом, файл конфигурации неплохо документирован комментариями разработчиков. Настройка не должна вызвать трудностей.

Выполним проверку корректности конфигурационного файла специальной командой:

sudo sshd -t

Вот пример, если конфиг не прошел проверку:

Система говорит нам, что указан недопустимый параметр на строке 15. Исправим, затем вновь:

sudo sshd -t

И если вывод пустой, значит проверка прошла. Перезапускаем сервер SSH:

sudo systemctl restart sshd

Если вы везунчик и вас не дропнуло, то теперь, не отключаясь от текущей сессии SSH, откройте новое окно или вкладку терминала и попробуйте подключится к серверу. Не забывайте, что мы изменили порт подключения SSH со стандартного 22 на 27244. Чтобы команде ssh указать другой порт используется ключ -p:

ssh ivan@192.168.56.102 -p 27244

Если авторизация проходит успешно, я вас поздравляю. Если нет поговорим об этом потом, вернитесь в соседнюю сессию и проверьте, что вы сделали не так. Не закрывайте эту резервную сессию, пока не добьётесь других успешных авторизаций.

Закрытие 22-го порта в UFW

Теперь можно смело закрыть 22-й порт в ufw. Чтобы удалить правило, нужно перед командой добавления правила вставить слово delete:

sudo ufw delete allow 22/tcp

sudo ufw reload

sudo ufw status verbose

Настройка защиты от брутфорса — fail2ban

Fail2Ban — это инструмент сетевой безопасности для Linux, который автоматически блокирует IP-адреса, совершающие подозрительную активность (например, многократные неудачные попытки входа по SSH). Он анализирует логи (текстовые файлы или journald) и применяет временные или постоянные баны через iptables или nftables.

Данный шаг особенно полезен, если вы не отключили подключение к серверу по SSH с использованием пароля (не рекомендую так делать).

❗Пожалуйста, перед внесением следующих изменений убедитесь, что у вас есть физический доступ к серверу или к его консоли с гипервизора.

Ниже покажу базовую настройку fail2ban для защиты сервера от брутфорс-атак на примере SSH.

Устанавливаем пакет из стандартных репозиториев:

sudo apt install -y fail2ban

💡 Основные файлы/директории конфигурации fail2ban:

• /etc/fail2ban/fail2ban.conf — сновной конфиг демона;
• /etc/fail2ban/jail.conf — шаблон настроек jail-ов (его мы НЕ ТРОГАЕМ);
• /etc/fail2ban/jail.local — локальная конфигурация jail-ов (редактировать будем ЕГО);
• /etc/fail2ban/filter.d/ — шаблоны фильтров (регулярные выражения для логов);
• /etc/fail2ban/action.d/ — шаблоны действий (что делать при нарушении);

В пакете уже идет набор готовых фильтров для популярных сервисов, таких как sshd, nginx, apache и т.д. (загляните в /etc/fail2ban/filter.d/) и и действий: iptables, nftables, firewall-cmd и т.д. Также никто не запрещает писать собственные фильтры, если вы разбираетесь в регулярках😉.

Открываем пользовательский конфиг файл на редактирование:

sudo nvim /etc/fail2ban/jail.local

⚠️ Не перепутайте с основным конфигом /etc/fail2ban/jail.conf, редактировать который не рекомендуется.

И наполняем:

[DEFAULT]
# исключения для локальных сетей
ignoreip = 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
# время блокировки IP (s|m|h)
bantime = 1h
# период за который считаются неудачные попытки
findtime = 10m
# кол-во неудачных попыток до блокировки
maxretry = 5
# используем nftables для бана
banaction = nftables-multiport
# действие по умолчанию
action = %(action_)s

[sshd]
# активируем защиту для ssh
enabled = true
# порт SSH сервера, используется для правил фаервола
port = 27244
# какие читать журанылы (тут может быть путь до текстового файла)
logpath = %(sshd_log)s
# бэкенд для чтения логов - journald
backend = systemd

☝️Бан-действие фаервола по умолчанию — reject, что подразумевает отправку сообщения об отказе соединения заблокированным адресам. Чтобы не отправлять это уведомление измените действие в параметре banaction на nftables-multiport[blocktype=drop].

Активируем автозапуск сервиса, перезапускаем его и смотрим статус:

sudo systemctl enable fail2ban

sudo systemctl restart fail2ban

sudo systemctl status fail2ban

Для просмотра статуса блокировок используйте команды:

sudo fail2ban-client status

sudo fail2ban-client status sshd

Теперь на другом устройстве (не на том, на котором настраиваете сервер!), а если на сервере белый IP то и из другой посети, попытайтесь произвести 5 неуадчных попыток подключения по SSH. Пример:

ssh test@192.168.56.102 -p 27244

💡Стоит отметить, что банятся также те IP, из под которых пытались неудачно подключиться по приватному ключу. Но по умолчанию при таком подключении не банятся адреса, использующие логины существующих пользователей. Чтобы банить и такие подключения добавьте в секцию [DEFAULT] параметр mode = aggressive. Но будьте осторожны, не заблокируйте сами себя☝️.

Командой ниже можно смотреть статус блокировок sshd в реальном времени:

sudo watch -n2 fail2ban-client status sshd

☝️ Команда watch в Linux выполняет запуск переданной в аргументе команды с заданным интервалом, в моем примере 2 сек.

К составе пакета fail2ban также идет утилита проверки регулярных выражений и совпадений по ним записей в журналах. В случае SSH можно посмотреть совпадения так:

sudo fail2ban-regex systemd-journald /etc/fail2ban/filter.d/sshd.conf

В Debian 12 в качестве фаервола используется nftables. Посмотрим правила, созданные демоном fail2ban:

sudo nft list table inet f2b-table

Чтобы разбанить нужный адрес используйте команду:

sudo fail2ban-client set sshd unbanip 1.2.3.4

Список доступных команд ктилиты-клиента с описаниями смотрите на man странице.

Итоговая перезагрузка

После проведения всех проверок, выполняем профилактический перезапуск сервера Debian 12, чтобы убедиться, что мы все настроили корректно:

sudo reboot

Через некоторое время пробуем вновь подключится к серверу:

ssh ivan@192.168.56.102 -p 27244

Ура, это маленькая победа) Как видим и hostname обновился.

Теперь можно, например, настроить Zshell по моей статье или еще что-нибудь.

Установка и настройка ZSH (опционально)

Если лень читать всю статью целиком, приложу TLDR:

# установливаем Z-Shell и вспомогательных утилит
sudo apt update && sudo apt install -y zsh fzf git curl

# проверяем все ли установилось в нашу систему
whereis {zsh,fzf,git,curl}

# установливаем Oh-My-Zsh - отвечаем yes
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# устанавливаем плагин zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# устанавливаем плагин fast-syntax-highlighting
git clone https://github.com/zdharma-continuum/fast-syntax-highlighting ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/fast-syntax-highlighting

# устанавливаем плагин cmdtime
git clone https://github.com/tom-auger/cmdtime ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/cmdtime

# меняем тему на agnoster
sed -i 's/^ZSH_THEME=.*/ZSH_THEME="agnoster"/' ~/.zshrc

# отключаем автообновления Oh-My-Zsh
sed -i "s/^#.*omz:update.*disabled/zstyle ':omz:update' mode disabled/" ~/.zshrc

# активируем установленные плагины
sed -i 's/^plugins=\(.*\)/plugins=\(git zsh-autosuggestions fast-syntax-highlighting fzf cmdtime\)/' ~/.zshrc

# задаем цвета для плагина fzf (это всё одна команда)
echo "export FZF_DEFAULT_OPTS=$FZF_DEFAULT_OPTS'
        --color=fg:#e5e9f0,bg:#3b4252,hl:#81a1c1
        --color=fg+:#e5e9f0,bg+:#3b4252,hl+:#81a1c1
        --color=info:#eacb8a,prompt:#bf6069,pointer:#b48dac
        --color=marker:#a3be8b,spinner:#b48dac,header:#a3be8b'\n\n\
        $(cat ~/.zshrc)" > ~/.zshrc

# применяем внесенные изменения
source ~/.zshrc

# для минималистичного prompt
echo "prompt_context() [ ]" >> ~/.zshrc && source ~/.zshrc

## настройка Oh-My-Zsh для root пользователя

# копируем файлы нашего пользователя в директорию пользователя root
sudo cp -r {~/.oh-my-zsh,~/.zshrc} /root/

# меняем оболочку по умолчанию у root
sudo chsh -s /usr/bin/zsh

# переключаемся в root для проверки
sudo -s

Послесловие

Ну вот, мы выполнили начальную базовую настройку Linux сервера Debian 12. В дальнейшем на основе такой конфигурации я буду выполнять установку и настройку различного серверного ПО и, конечно, писать статьи об этом.

Так что подписывайтесь на нашу телегу, чтобы не пропустить новые материалы. Спасибо, что читаете, пингвины (:

Материалы по теме

• Установка сервера Debian 12 в VirtualBox
• Установка VirtualBox в Linux Mint 21
• SSH — Безопасное подключение к удалённым хостам: введение
• VIM — Консольный редактор: знакомство
• Neovim — конфигурация редактора: базовая настройка
• ZSH — Интерактивная командная оболочка для Linux + Oh-My-Zsh

👨‍💻Ну и…

Не забывайте про нашу телегу📱и чат 💬 Всех благ✌️

That should be it. If not, check the logs 🙂