В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:

systemctl mask nginx.service

И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:

# systemctl mask nginx.service

Created symlink from /etc/systemd/system/nginx.service to /dev/null.

# service nginx restart

Redirecting to /bin/systemctl restart nginx.service
Failed to restart nginx.service: Unit is masked.

Снять маску можно командой:

# systemctl unmask nginx.service

Removed symlink /etc/systemd/system/nginx.service.

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):

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

Например, нам нужно запускать все тот же скрипт /root/test.sh после перезагрузки системы. Начнем с создания файла нашей будущей службы:

touch /etc/systemd/system/test-script.service
chmod 664 /etc/systemd/system/test-script.service
nano /etc/systemd/system/test-script.service

Содержимое файла будет следующее:

[Unit]
Description=Template Settings Service
After=network.target
[Service]
Type=oneshot
User=root
ExecStart=/root/test.sh
[Install]
WantedBy=multi-user.target

Основные параметры:

User – пользователь под которым будет запускаться демон

Type=oneshot — процесс будет завершен до запуска дальнейших юнитов

Проверяем и перезапускаем:
# systemctl daemon-reload
# systemctl start test-script.service
# systemctl status test-script.service

● test-script.service - Test
Loaded: loaded (/etc/systemd/system/test-script.service; disabled; vendor preset: disabled)
Active: active (running)

Если вас устроило то, как работает сервис, добавьте его в автозагрузку:

# systemctl enable test-script.service

Created symlink from /etc/systemd/system/multi-user.target.wants/test-script.service to /etc/systemd/system/test-script.service.

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

/ Uninstall Nginx
sudo apt-get remove nginx
sudo apt purge nginx*

//Then, install Nginx following document: http://nginx.org/en/linux_packages.html#Ubuntu
sudo apt install curl gnupg2 ca-certificates lsb-release
echo «deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx»| sudo tee /etc/apt/sources.list.d/nginx.list
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add —
sudo apt update
sudo apt install nginx

Как запретить обновление каких-либо пакетов, то есть зафиксировать версию пакета. Или же запретить автоматическую установку или удаление пакета. Как это сделать.

Воспользуемся утилитой apt-mark, которая доступна в Ubuntu.

sudo apt-mark hold имя пакета

apt-mark showhold

sudo apt-mark unhold имя пакета

 

— просмотр всех открытых портов

– просмотр всех открых TCP-портов

— просмотр всех открых UDP-портов

— просмотр всеx прослушиваемых портов(TCP,UDP,unix-сокеты)

—  просмотр всеx прослушиваемых портов TCP

— просмотр всеx прослушиваемых портов UDP

— просмотр всеx прослушиваемых unix-сокетов

—  просмотр статистики всех протоколов()

—  просмотр статистики TCP-протокола

— просмотр статистики UDP-протокола

– просмотр таблицы маршрутизации

– просмотр статистики сетевых интерфейсов

– просмотр статистики сетевых интерфейсов в режиме реального времени с обновлением каждые 2 секунды.

– просмотр расширенной информации о  сетевых интерфейсах (аналог ifconfig)

 

Использование Netstat для определения DoS/DDoS.

 

Отображение количества подключений на каждый IP-адрес в состоянии ESTABLISHED

или

 

Отобразить все активные Интернет-подключения на 80 порт сервера с их сортировкой

Полезно для определения  большого количества запросов с одного IP-адреса(DoS)

 

Подсчет количества подключений с каждого Ip-адреса на 80-порт сервера.

 

Определение количества запросов на соединение было получено из сети.

Число должно быть достаточно низким(менее 5).Во время DoS/DDoS-атаки такое количество может иметь высокое значение.Однако значение всегда зависит от системы(высокое значение на одном сервере может быть средним на другом)

Список всех IP-адресов, с которых поступают соединения со статусом SYN_RECV

 

Подсчет количества подключений  с каждого IP-адреса

 

Подсчет количества подключений  с каждого IP-адреса по протоколу TCP или UDP.

Утилита lshw выводит на консоль полный список аппаратных компонентов системы вместе с информацией об устройствах. lshw включена во многие современные дистрибутивы Linux по умолчанию; если она отсутствует, ее можно установить стандартным менеджером пакетов

Чтобы вывести на консоль информацию о «железе», нужно ввести следующую команду:

# lshw

Вывести эту информацию в сокращенном виде можно при помощи опции -short:

# lshw -short

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

# lshw -C сpu

— память:

# lshw -C memory

— дисковая подсистема:

# lshw -C disk

Чтобы посмотреть узнать сетевую карту linux и просмотреть подробные сведения о ней, запустите утилиту со следующими параметрами:
lshw -class network

Основы управления юнитами

Базовыми компонентами, которыми управляет systemd, являются юниты (unit). Существует множество типов юнитов; самым распространённым типом является сервис (файлы с расширением .service). основным инструментом для управления сервисами является команда systemctl.

Команда systemctl имеет свой эквивалент для каждой стандартной команды системы инициализации. В качестве примера рассмотрим файл nginx.service.

Примечание: Чтобы получить этот файл, установите Nginx.

Чтобы запустить сервис, введите:

sudo systemctl start nginx.service

Чтобы остановить сервис:

sudo systemctl stop nginx.service

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

sudo systemctl restart nginx.service

Чтобы выполнить перезагрузку, не прерывая работы, введите:

sudo systemctl reload nginx.service

Включение и отключение юнитов

По умолчанию большинство юнитов systemd не запускается автоматически. Чтобы настроить автозапуск юнита, нужно его включить. Это соединит юнит с определённым целевым компонентом, и тогда юнит будет запускаться вместе с ним.

Чтобы настроить автозапуск сервиса, введите:

sudo systemctl enable nginx.service

Чтобы отключить сервис:

sudo systemctl disable nginx.service

Состояние системы

Сервер systemd может предоставить информацию, на основе которой можно сделать вывод о текущем состоянии системы.

К примеру, чтобы получить список всех активных юнит-файлов systemd, введите:

systemctl list-units

Чтобы просмотреть список всех юнитов, которые система systemd загрузила или попыталась загрузить в память (включая неактивные юниты), введите:

systemctl list-units --all

Чтобы вывести на экран список всех установленных юнитов (включая те, которые система systemd не загрузила в память), наберите:

systemctl list-unit-files

 Просмотр логов

Компонент systemd под названием journald собирает и управляет общесистемными записями в журнале – то есть данными логов приложений и ядра.

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

journalctl

По умолчанию эта команда выведет записи текущей и предыдущих загрузок (если инструмент journald настроен для сохранения записей от предыдущих загрузок). Некоторые дистрибутивы включают это поведение по умолчанию, а некоторые – нет. Чтобы включить сохранение записей от предыдущих загрузок, можно:

1. Отредактировать файл /etc/systemd/journald.conf. Измените значение параметра Storage=, указав persistent.
2. Создать постоянный каталог при помощи команды:

sudo mkdir -p /var/log/journal

Чтобы просмотреть только записи текущей загрузки, введите:

journalctl -b

Записи ядра (которые, как правило, представлены как dmesg) можно просмотреть при помощи команды:

journalctl -k

Если совместить флаги -k и –b, можно получить записи ядра только для текущей загрузки.

journalctl -k -b

Состояние юнитов

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

Чтобы узнать текущее состояние юнита, используйте опцию status. Команда вернёт состояние юнита (включен или отключен), сведения о процессе и последние записи в журнале:

systemctl status nginx.service

Чтобы просмотреть все записи в журнале, сделанные определённым юнитом, используйте флаг –u и команду journalctl:

journalctl -u nginx.service

Как и ранее, ограничить вывод текущей загрузкой можно с помощью флага –b:

journalctl -b -u nginx.service

Проверка юнитов и юнит-файлов

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

Каждый юнит-файл содержит параметры, при помощи которых система systemd может запустить и остановить его. Чтобы просмотреть содержимое юнит-файла, введите:

systemctl cat nginx.service

Чтобы просмотреть дерево зависимостей юнита (которые будут включены системой systemd во время запуска юнита), введите:

systemctl list-dependencies nginx.service

Эта команда покажет список зависимых юнитов и юниты target (целевые). Чтобы получить расширенный список зависимостей, введите:

systemctl list-dependencies --all nginx.service

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

systemctl show nginx.service

Эта команда вернёт значения всех параметров, которыми управляет systemd.

Изменение юнит-файлов

Система systemd позволяет изменять юнит-файлы с помощью команды systemctl.

Чтобы добавить сниппет юнит-файла, который в дальнейшем можно использовать для расширения или переопределения параметров стандартных юнит-файлов, используйте опцию edit:

sudo systemctl edit nginx.service

Чтобы полностью отредактировать содержимое файла, не создавая сниппет, используйте флаг –full:

sudo systemctl edit --full nginx.service

Отредактировав юнит-файл, перезапустите процесс systemd, чтобы изменения вступили в силу:

sudo systemctl daemon-reload

Уровни выполнения

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

В системе systemd концепция уровней выполнения заменена так называемыми целями (targets). Цели – это точки синхронизации, при помощи которых сервер может переключать состояния. Сервисы и другие юнит-файлы можно привязывать к целям. Кроме того, система может использовать несколько целей однвременно.

Чтобы просмотреть доступные цели, введите:

systemctl list-unit-files --type=target

Чтобы просмотреть цель по умолчанию, которую система systemd использует сразу после запуска (она в свою очередь запускает все юнит-файлы, которые являются частью её дерева зависимостей), введите:

systemctl get-default

Чтобы изменить цель по умолчанию, используйте опцию set-default:

sudo systemctl set-default multi-user.target


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

systemctl list-dependencies multi-user.target

С помощью опции isolate можно переключать цели. Однако прежде чем переключить цель, убедитесь, что новая цель не отключит важнейшие сервисы.

sudo systemctl isolate multi-user.target

Остановка и перезапуск сервера

Также система инициализации может использовать сокращённые команды. К примеру, чтобы отключить сервер, введите:

sudo systemctl poweroff

Если вы хотите перезапустить сервер, введите:

sudo systemctl reboot

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

sudo systemctl rescue

Большинство операционных систем может использовать традиционные алиасы для наиболее распространённых операций. То есть, вы можете опустить команду systemctl и ввести просто:

sudo poweroff
sudo reboot

Однако имейте в виду: эта функция поддерживается не всегда.

Задача: заменить сбойный диск /dev/sdb.

Прежде всего, смотрим диагностику:

cat /proc/mdstat

или

mdadm --detail /dev/md0

Если вместо [UU] видим [U_], то дело плохо, целостность одного из дисков нарушена — нужно менять диск.

Помечаем раздел как сбойный:

mdadm --manage /dev/md0 --fail /dev/sdb1

Отключаем раздел (удаляем из RAID1):

mdadm --manage /dev/md0 --remove /dev/sdb1

меняем диск.

Создаем через cfdisk или fdisk идентичные разделы, или c помощью sfdisk автоматически копируем структуру разделов первого диска /dev/sda:

sfdisk -d /dev/sda | sfdisk /dev/sdb

Добавляем раздел в RAID1 массив:

mdadm --manage /dev/md0 --add /dev/sdb1

Этим способом можно пользоваться, поскольку в нашем примере «зеркальный» RAID1. При других уровнях (raid level), нужно разбить диск на раздел(ы) и пометить его(их) типом ФС «Linux raid autodetect».

Или еще есть инструкция

I. Удаление диска из массива

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

# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md2 : active raid1 sda4[0] sdb4[1]
      1456504640 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda3[0] sdb3[1]
      7996352 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sda2[0] sdb2[1]
      499392 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

В данном случае массив собран так. Что md0 состоит из sda2 и sdb2, md1 из sda3 и sdb3, md2 из sda4 и sdb4. На этом сервере md0 это /boot, md1 — своп, md2 — корень. Убираем sdb из всех устройств.

# mdadm /dev/md0 --remove /dev/sdb2
# mdadm /dev/md1 --remove /dev/sdb3
# mdadm /dev/md2 --remove /dev/sdb4

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

# mdadm /dev/md0 -f /dev/sdb2
# mdadm /dev/md1 -f /dev/sdb3
# mdadm /dev/md2 -f /dev/sdb4

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

II. Добавление диска в массив после замены

  1. Определение таблицы разделов(GPT или MBR) и перенос её на новый диск

После замены поврежденного диска нужно добавить новый диск в массив. Для этого надо определить какая у нас таблица разделов: GPT или MBR. Для этого будем использовать gdisk Установим gdisk:

# apt-get install gdisk -y

Выполняем:

# gdisk -l /dev/sda

Где /dev/sda — исправный диск находящийся в raid. В выводе будет примерно это для MBR:

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

И примерно это для GPT:

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Перед добавлением диска в массив нам нужно на нем создать разделы в точности такие же как и  на sda. В зависимости от разметки диска это делается по разному.

Копирование разметки для GPT:

# sgdisk -R /dev/sdb /dev/sda

Здесь надо быть внимательным. Первым пишется диск на который копируется разметка, а вторым с которого копируют. Если перепутать их местами, то разметка на изначально исправном диске будет уничтожена.
Даем диску новый случайный UIDD:

# sgdisk -G /dev/sdb

Копирование разметки для MBR:

# sfdisk -d /dev/sda | sfdisk /dev/sdb

Здесь наоборот первым пишется диск с которого переносим разметку, а вторым на который переносим. Если разделы не видны в системе, то можно перечитать таблицу разделов командой:

# sfdisk -R /dev/sdb

  2. Добавление диска в массив

Когда мы создали разделы на /dev/sdb, то можно добавлять диск в массив.

# mdadm /dev/md0 -a /dev/sdb2
# mdadm /dev/md1 -a /dev/sdb3
# mdadm /dev/md2 -a /dev/sdb4

III. Установка загрузчика

После добавления диска в массив нужно установить на него загрузчик. Если сервер загружен в нормальном режиме, то это делается одной командой:

# grub-install /dev/sdb

Если сервер загружен в recovery или rescue, т.е с live cd, то установка загрузчика выглядит следующим образом.
Монтируем корневую файловую систему в  /mnt:

# mount /dev/md2 /mnt

Монтируем boot:

# mount /dev/md0 /mnt/boot

Монтируем /dev, /proc и /sys:

# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys  /mnt/sys

Затем делаем chroot в примонтированную систему:

# chroot /mnt

И устанавливаем grub на sdb:

# grub-install /dev/sdb

Теперь можно попробовать загрузится в нормальный режим.

tail -f *.log | cut -d ‘ ‘ -f 1 | logtop
распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.

grep «любая запись=» /*.access.log | cut -d ‘ ‘ -f 1 | sort | uniq -c | sort -n | tail -n 30
распределение какой-либо строки по IP в логе.

netstat -na | grep «:80\ » | wc -l
— сколько коннектов на 80 порт

netstat -ntu | awk ‘{print $5}’| cut -d: -f1 | sort | uniq -c | sort -nr | more
— с какого ip сколько запросов

netstat -nlp
активные коннекты или

time (netstat -an|grep «:80\ «|wc -l)