Як вимкнути та видалити непотрібні служби в Linux

При встановленні RHEL 9 система поставляється з мінімальним набором встановлених пакетів та сервісів для забезпечення легкості та безпеки системи.

Однак з часом, у міру встановлення нових пакетів і служб, система може роздутися і стати вразливою для безпеки.

У цій статті ми розповімо, як відключити та видалити непотрібні служби та пакети в дистрибутивах на базі RHEL , таких як Rocky Linux, AlmaLinux і Fedora, забезпечуючи безпеку та функціональність системи.

Якщо ви плануєте використовувати щойно встановлену систему RHEL для розміщення, скажімо, невеликого веб-сайту, що працює на Apache або Nginx, або для надання мережевих послуг, таких як DNS , DHCP , PXE boot, FTP сервер і т.д. або інших послуг, які не вимагають запуску демонів Postifx MTA , CUPS і Avahiто чому ми повинні тримати всі ці непотрібні демони встановленими або навіть працюючими на вашому сервері.

Основними зовнішніми службами, які дійсно повинні бути запущені на сервері після мінімальної установки, будуть лише демон SSH для віддаленого входу в систему і, в деяких випадках, служба NTP для точної синхронізації внутрішніх годин вашого сервера із зовнішніми NTP-серверами.

Установка корисних системних утиліт

Після завершення інсталяції увійдіть на сервер під обліком root або користувачем з привілеями root і виконайте оновлення системи, щоб переконатися, що на вашому сервері встановлені всі пакети та виправлення безпеки.

yum update -y yum upgrade y

Наступним кроком буде встановлення деяких корисних системних утиліт, таких як net-tools (Цей пакет надає стару, але хорошу команду ifconfig), текстовий редактор nano wget для завантаження файлів та curl для передачі URL, lsof (для списку відкритих файлів) та bash-completion, який автоматично завершує набрані команди.

yum install nano bash-completion net-tools wget curl lsof

Вимкнення та видалення небажаних служб у Linux

Тепер ви можете розпочати відключення та видалення встановлених небажаних служб, але перед цим вам потрібно отримати список усіх включених та працюючих служб у вашій системі.

Перевірка включених служб

Перш ніж вимикати служби, необхідно перевірити, які служби у вашій системі.

systemctl list-unit-files --type=service --state=enabled

Запишіть служби, які потрібно відключити.

Визначення непотрібних служб

Перш ніж вимкнути та видаляти непотрібні служби, необхідно визначити, які служби необхідні, а які можна безпечно вимкнути.

Один із способів зробити це – вивчити список включених служб та знайти їх описи, щоб визначити, що вони роблять.

Наприклад, наступна команда покаже список усіх включених служб разом із описом:

systemctl list-unit-files --type=service --all --no-pager

Ви можете вивчити опис кожної служби, щоб визначити, чи потрібна вона для вашої системи.

Інший підхід полягає у використанні такого інструменту, як systemd-analyze, для аналізу часу завантаження системи та виявлення служб, що уповільнюють процес завантаження.

systemd-analyze systemd-analyze blame

Наведена вище команда відобразить список всіх запущених модулів (служб) systemd, відсортованих за часом, який їм знадобився для ініціалізації.

Служби, які не є критичними для роботи системи та уповільнюють процес завантаження, часто можна безпечно вимкнути.

Вимкнення непотрібних служб

Визначивши некритичну службу, яка може уповільнювати завантаження, ви можете вимкнути та зупинити її за допомогою наступних команд.

Хоча вибір служб, які потрібно вимкнути або видалити, залежить від конкретного випадку використання, є кілька загальних служб, які варто відключити або видалити за умови мінімальної установки RHEL .

Postfix

Postfix - Це агент передачі пошти ( MTA ), який використовується для надсилання та отримання електронної пошти у вашій системі. Якщо ви не використовуєте свою систему для роботи з електронною поштою, ви можете вимкнути та видалити цю службу.

sudo systemctl stop postfix sudo systemctl disable postfix sudo yum remove postfix

Avahi

Avahi – це сервіс, який використовується для створення мереж із нульовою конфігурацією, дозволяючи пристроям виявляти та взаємодіяти один з одним в одній мережі.

Якщо вам не потрібна ця функціональність, ви можете вимкнути та видалити службу avahi.

sudo systemctl stop avahi-daemon.socket sudo systemctl disable avahi-daemon.socket sudo yum remove avahi-autoipd avahi-libs avahi-tools

cups

Служба cups використовується для друку. Якщо вашій системі не потрібні можливості друку, ви можете вимкнути та зупинити її:

sudo systemctl disable cups sudo systemctl stop cups suod yum remove cups

Видалення небажаних служб

Крім видалення непотрібних служб, можна також видалити всі пакети, які більше не потрібні. Пакунки, що не використовуються, можуть займати місце на диску і потенційно створювати вразливості в системі безпеки.

Спершу складіть список встановлених пакетів, щоб визначити, які з них пов'язані з небажаними службами:

Щоб дізнатися, який пакет надає ту чи іншу послугу, використовуйте:

rpm -qf /usr/lib/systemd/system/.service

Щоб видалити пакет та пов'язані з ним файли, використовуйте.

Найкращі практики з відключення та видалення служб

При відключенні та видаленні служб необхідно слідувати кращим практикам, щоб ваша система залишалася безпечною та функціональною.

Ось деякі рекомендації, яким слід дотримуватися:

• Перед видаленням служби вимкніть її, щоб вона не працювала у фоновому режимі, що можна зробити за допомогою команди systemctl disable .
• Зупиніть службу, щоб запобігти її запуску в поточному сеансі, що можна зробити за допомогою команди systemctl stop .
• Видаліть усі пакети, які більше не потрібні, щоб звільнити місце на диску та зменшити вразливість системи безпеки, що можна зробити за допомогою команди yum remove.
• Після відключення або видалення служб оновіть демон systemd, щоб переконатися, що зміни набули чинності, що можна зробити за допомогою команди systemctl daemon-reload .
• Після видалення служб перевірте, чи не запущені ще служби-примари, що можна зробити за допомогою команди systemctl list-units .

Висновок

Вимкнення та видалення непотрібних служб та пакетів на RHEL – важливий крок у підтримці безпеки та продуктивності системи.

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

Парашутист зі стажем Багато читаю і слухаю підкасти.

Systemd за п'ять хвилин

Наша компанія займається адмініструванням веб-серверів на базі CentOS. Досить часто наші клієнти використовують веб-додатки на базі python, ruby ​​або java. реліз CentOS 7 і, слідуючи старій традиції «не ставити dot-zero релізи на продакшен», ми починаємо пропонувати клієнтам сервера на базі CentOS 7.1 (1503).

У CentOS7, як і і його батька RHEL7, використовується systemd — менеджер системи та служб для Linux, сумісний зі скриптами ініціалізації SysV і LSB.systemd забезпечує можливості агресивної паралелізації та багато іншого.

Величезний монстр з безліччю можливостей, гнучкими налаштуваннями та мегабайтами документації.

Але що робити, якщо стоїть завдання швидко-швидко, прямо вчора, зробити автозапуск якогось сервісу?
Давайте вичавимо з документації мінімально необхідний набір інформації для створення простих старт-стоп скриптів.

Systemd запускає послуги описані в його конфігурації.
Конфігурація складається з множини файлів, які по-модному називають юнітами.

Всі ці юніти розкладені у трьох каталогах:

/usr/lib/systemd/system/ - юніти зі встановлених пакетів RPM - всякі nginx, apache, mysql та інше
/run/systemd/system/ - Юніти, створені в рантаймі - теж, напевно, потрібна штука
/etc/systemd/system/ — юніти, створені системним адміністратором, — а ось сюди ми й покладемо свій юніт.

Юніт є текстовим файлом з форматом, схожим на файли .ini Microsoft Windows.

Для створення найпростішого юніту треба описати три секції: [Unit], [Service], [Install]

У секції Unit описуємо, що це за юніт:
Назви змінних досить говорять:

Далі слідує блок змінних, які впливають на порядок завантаження сервісів:

Запускати юніт після будь-якого сервісу або групи сервісів (наприклад, network.target):

After=syslog.target
After=network.target
After=nginx.service
After=mysql.service

У результаті змінна Wants виходить суто описовою.
Якщо сервіс є в Requires, але немає в After, то наш сервіс буде запущений паралельно з сервісом, а не після успішного завантаження необхідного сервісу

У секції Service вказуємо якими командами та під яким користувачем треба запускати сервіс:

(за замовчуванням): systemd передбачає, що служба буде запущена негайно. Процес при цьому не повинен розгалужуватися. Не використовуйте цей тип, якщо інші служби залежать від черговості під час запуску цієї служби.

systemd передбачає, що служба запускається одноразово і процес розгалужується із закінченням батьківського процесу. Цей тип використовується для запуску класичних демонів.

Також слід визначити PIDFile=, щоб systemd могла відстежувати основний процес:

Заборона на вбивство сервісу через брак пам'яті та спрацювання механізму OOM:
-1000 повна заборона (такий у sshd стоїть), -100 знизимо ймовірність.

Команди на старт/стоп та релоад сервісу

ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon
ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart

Тут є тонкість - systemd наполягає, щоб команда вказувала на конкретний файл, що виконується. Потрібно вказувати повний шлях.

Таймаут в секундах, скільки чекатиме система відпрацювання старт/стоп команд.

Попросимо systemd автоматично рестартувати наш сервіс, якщо він раптом перестане працювати.
Контроль ведеться за наявності процесу із PID файлу

У секції [Install] опишемо, у якому рівні запуску має стартувати сервіс

multi-user.target або runlevel3.target відповідає нашому звичному runlevel=3 «Розрахований на багато користувачів режим без графіки. Користувачі, як правило, входять до системи за допомогою безлічі консолей або через мережу»

Ось і готовий найпростіший скрипт стартап, він же unit для systemd:
myunit.service

[Unit] Description=MyUnit After=syslog.target After=network.target After=nginx.service After=mysql.service Requires=mysql.service Wants=redis.service [Service] Type=forking PIDFile=/work/www/myunit /shared/tmp/pids/service.pid WorkingDirectory=/work/www/myunit/current User=myunit Group=myunit Environment=RACK_ENV=production OOMScoreAdjust=-1000 ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon ExecStop=/usr /local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart TimeoutSec= 300 [Install] WantedBy=multi-user.target

Кладемо цей файл у каталог /etc/systemd/system/

Дивимося його статус systemctl status myunit

myunit.service - MyUnit Розроблено: loaded (/etc/systemd/system/myunit.service; disabled) Active: inactive (dead)

Бачимо, що він disabled – дозволяємо його
systemctl enable myunit
systemctl -l status myunit

Якщо немає жодних помилок у юніті — то висновок буде такий:

myunit.service - MyUnit Додано: loaded (/etc/systemd/system/myunit.service; enabled) Active: inactive (dead)

Запускаємо сервіс
systemctl start myunit

Дивимося гарний статус:
systemctl -l status myunit

Якщо є помилки – читаємо висновок у статусі, виправляємо, не забуваємо після виправлень у юніті перевантажувати демон systemd

systemctl daemon-reload

Тепер, після ознайомлювального занурення в systemd можна починати самостійні запливи.
Якщо раптом з'являться питання, будемо раді відповісти на ваші листи на адресу [email protected]