Сравнение производительности сетевых протоколов для систем хранения данных
Пропускная способность — сколько данных можно передать за секунду.
Задержка — сколько времени занимает одна операция.
IOPS — сколько операций можно выполнить за секунду.
продолжение в следующем сообщении
Пропускная способность — сколько данных можно передать за секунду.
Задержка — сколько времени занимает одна операция.
IOPS — сколько операций можно выполнить за секунду.
продолжение в следующем сообщении
Что нужно для NVMe-RoCE
1. Сетевое оборудование
Для RoCEv2 требуется сеть Ethernet с поддержкой RDMA (Remote Direct Memory Access). Ключевые компоненты:
a) Сетевые адаптеры (NIC) с поддержкой RDMA:
Адаптеры должны поддерживать RDMA и RoCEv2.
b) Коммутаторы с поддержкой RoCEv2:
Коммутаторы должны поддерживать PFC (Priority Flow Control) и ECN (Explicit Congestion Notification) для обеспечения качества обслуживания (QoS) и предотвращения потерь пакетов.
Коммутаторы должны быть настроены для работы с RoCEv2, включая настройку приоритетов трафика и буферов.
2. Серверы и системы хранения
a) Серверы:
b) Системы хранения данных:
Системы хранения должны поддерживать NVMe-oF и RoCEv2.
Внутри системы хранения должны быть установлены NVMe-накопители и контроллеры, поддерживающие NVMe-oF.
3. Программное обеспечение
a) Драйверы и утилиты:
На серверах и системах хранения должны быть установлены драйверы для сетевых адаптеров с поддержкой RDMA (например, Mellanox OFED или Intel Ethernet Drivers).
Для Linux:
Установите пакеты nvme-cli, rdma-core и libibverbs.
Проверьте поддержку RoCEv2:
В выводе ищите строку transport_type: RoCE v2.
b) Настройка NVMe-oF:
На стороне системы хранения (Target) настройте экспорт NVMe-устройств через RoCEv2.
На стороне сервера (Initiator) используйте команды nvme connect для подключения к целевым устройствам. Пример:
Где:
-t rdma — тип транспорта (RoCEv2).
-n <nqn> — NQN (NVMe Qualified Name) целевого устройства.
-a <target_ip> — IP-адрес системы хранения.
-s 4420 — порт (по умолчанию 4420 для NVMe-oF).
4. Сеть
a) Требования к сети:
Высокая пропускная способность: Рекомендуется использовать сеть 25 Гбит/с, 40 Гбит/с, 50 Гбит/с или 100 Гбит/с.
Низкие задержки: Для RoCEv2 критически важны низкие задержки, поэтому сеть должна быть настроена для минимизации задержек.
PFC и ECN: Включите Priority Flow Control (PFC) и Explicit Congestion Notification (ECN) на коммутаторах для управления перегрузками.
b) Пример настройки PFC:
На коммутаторе (например, Mellanox Spectrum):
5. Проверка и мониторинг
a) Проверка подключения:
Используйте команду nvme list на сервере, чтобы убедиться, что устройства подключены через NVMe-oF.
Проверка статуса RDMA:
b) Мониторинг производительности:
Используйте инструменты, такие как perf, nvme perf или fio, для тестирования производительности.
Пример теста с fio:
1. Сетевое оборудование
Для RoCEv2 требуется сеть Ethernet с поддержкой RDMA (Remote Direct Memory Access). Ключевые компоненты:
a) Сетевые адаптеры (NIC) с поддержкой RDMA:
Адаптеры должны поддерживать RDMA и RoCEv2.
Примеры популярных адаптеров:
Mellanox ConnectX-5/6 (например, ConnectX-5 EN, ConnectX-6 Dx).
Broadcom NetXtreme-E (например, BCM57414).
Intel Ethernet 800 Series (например, E810-CQDA2).
b) Коммутаторы с поддержкой RoCEv2:
Коммутаторы должны поддерживать PFC (Priority Flow Control) и ECN (Explicit Congestion Notification) для обеспечения качества обслуживания (QoS) и предотвращения потерь пакетов.
Примеры коммутаторов:
Mellanox Spectrum (например, Spectrum-2).
Cisco Nexus 9000 Series.
Arista 7050X/7060X Series.
Коммутаторы должны быть настроены для работы с RoCEv2, включая настройку приоритетов трафика и буферов.
2. Серверы и системы хранения
a) Серверы:
Серверы должны иметь:
Современные процессоры (например, Intel Xeon Scalable или AMD EPYC).
Поддержку PCIe 3.0/4.0 для подключения сетевых адаптеров.
Операционную систему с поддержкой NVMe-oF и RoCEv2 (например, Linux с ядром 4.12+ или Windows Server 2019+).
b) Системы хранения данных:
Системы хранения должны поддерживать NVMe-oF и RoCEv2.
Примеры:
Pure Storage FlashArray//X.
Dell EMC PowerMax.
NetApp AFF A-Series.
Внутри системы хранения должны быть установлены NVMe-накопители и контроллеры, поддерживающие NVMe-oF.
3. Программное обеспечение
a) Драйверы и утилиты:
На серверах и системах хранения должны быть установлены драйверы для сетевых адаптеров с поддержкой RDMA (например, Mellanox OFED или Intel Ethernet Drivers).
Для Linux:
Установите пакеты nvme-cli, rdma-core и libibverbs.
Проверьте поддержку RoCEv2:
ibv_devinfo
В выводе ищите строку transport_type: RoCE v2.
b) Настройка NVMe-oF:
На стороне системы хранения (Target) настройте экспорт NVMe-устройств через RoCEv2.
На стороне сервера (Initiator) используйте команды nvme connect для подключения к целевым устройствам. Пример:
nvme connect -t rdma -n <nqn> -a <target_ip> -s 4420
Где:
-t rdma — тип транспорта (RoCEv2).
-n <nqn> — NQN (NVMe Qualified Name) целевого устройства.
-a <target_ip> — IP-адрес системы хранения.
-s 4420 — порт (по умолчанию 4420 для NVMe-oF).
4. Сеть
a) Требования к сети:
Высокая пропускная способность: Рекомендуется использовать сеть 25 Гбит/с, 40 Гбит/с, 50 Гбит/с или 100 Гбит/с.
Низкие задержки: Для RoCEv2 критически важны низкие задержки, поэтому сеть должна быть настроена для минимизации задержек.
PFC и ECN: Включите Priority Flow Control (PFC) и Explicit Congestion Notification (ECN) на коммутаторах для управления перегрузками.
b) Пример настройки PFC:
На коммутаторе (например, Mellanox Spectrum):
interface ethernet 1/1
priority-flow-control mode on
priority-flow-control priority 3 on
5. Проверка и мониторинг
a) Проверка подключения:
Используйте команду nvme list на сервере, чтобы убедиться, что устройства подключены через NVMe-oF.
Проверка статуса RDMA:
ibv_devinfo
b) Мониторинг производительности:
Используйте инструменты, такие как perf, nvme perf или fio, для тестирования производительности.
Пример теста с fio:
fio --filename=/dev/nvme0n1 --rw=read --bs=4k --iodepth=32 --runtime=60 --name=test
Stateless, Stateful, Serverless, Blockchain, Smart contract, dApp
продолжение в следующих трёх сообщениях
Blockchain (Блокчейн) - в переводе "цепочка блоков". Это децентрализованная база данных, где информация хранится в блоках, связанных в строгую последовательность через хеш-сумму предыдущего блока - непрерывно до первого "генезис" блока, а все данные дублируются на тысячах нод (узлов).
продолжение в следующих трёх сообщениях
Stateless (без состояния) - каждый запрос обрабатывается независимо, сервер не хранит информацию о предыдущих запросах. Весь необходимый контекст сессии (сеанса) сохраняется на стороне клиента и с каждым новым запросом повторно передаётся по сети. Например - большая языковая модель "DeepSeek" - не сохраняет историю переписки с пользователем и не обучается на поступающих запросах, в то время как пользовательский браузер, через который осуществляется взаимодействие с поисковой системой - отправляет чат-боту всю предыдущую историю переписки с ним при каждом новом сообщении (в рамках одного диалога). Примеры архитектур "без состояния": HTTP-протокол, REST API.
Stateful (с состоянием) - сервер сохраняет информацию о состоянии клиента между запросами. Удобно для сложных взаимодействий (например, онлайн-игры), однако сложнее масштабировать и возможны проблемы при отказе сервера. Примеры: сессии в веб-приложениях, базы данных, WebSockets.
HTTPS (протокол защищённой передачи данных) - является stateless. Он состоит из двух stateless частей: HTTP и TLS. HTTP передаёт session_id (идентификатор сессии, созданный в приложении), зашифрованный с помощью session_key в TLS. Session_id не входит в состав HTTPS (поскольку это часть приложения, а не протокола), а session_key может обновиться в любой момент - поэтому временное хранение session_key не делает TLS stateful. А вот backend-приложение, сверяющее расшифрованный session_id со своей базой - вот это уже stateful.
На физическом (L1) и канальном (L2) уровнях, stateful принципиально невозможен - на этих уровнях происходит обмен битами без понятия "сессии". На сетевом уровне (L3), IP-пакеты обрабатываются независимо, кроме тех случаев, когда используется NAT (трансляция адресов), который хранит таблицу соответствий "локальный IP:порт <=> публичный IP:порт". На траспортном уровне (L4), протокол UDP является stateless, так как передача данных происходит без установки соединения, а протокол TCP хранит состояние соединения (SYN/ACK, порядок пакетов, окно перегрузки), поэтому является stateful. Сеансовый урвень (L5) специально создан для управления сеансами (но редко реализуется явно в современных стеках). В качестве примеров stateful L5 можно привести токены авторизации Kerberos и диалоговые сессии в SIP-протоколе (VoIP). На уровне представления (L6) происходит шифрование и компрессия данных, которые обходятся без сохранения состояния, поэтому являются stateless. Прикладной уровень (L7) - является главным "доменом" stateful-логики: Веб-сессии (session_id в куках); Базы данных (транзакции); FTP (сервер помнит текущую директорию); WebSockets.
Serverless — "безсерверный" стиль работы. Конечно же, не означает отсутствие серверов - но означает отсутствие возни с ними. AWS Lambda, Google Cloud Functions, Azure Functions - предоставляют веб-интерфейс, через который можно загрузить в их облако код, который будет выполняться в ответ на события, а провайдер услуги берёт плату только за время выполнения кода. Так же возможно автоматическое масштабирование в случае увеличения роста потребностей у приложения. Однако, есть и минусы - холодный старт (задерка при первом запуске) и ограничения на время выполнения.
Blockchain (Блокчейн) - в переводе "цепочка блоков". Это децентрализованная база данных, где информация хранится в блоках, связанных в строгую последовательность через хеш-сумму предыдущего блока - непрерывно до первого "генезис" блока, а все данные дублируются на тысячах нод (узлов).
Stateful (с состоянием) - сервер сохраняет информацию о состоянии клиента между запросами. Удобно для сложных взаимодействий (например, онлайн-игры), однако сложнее масштабировать и возможны проблемы при отказе сервера. Примеры: сессии в веб-приложениях, базы данных, WebSockets.
HTTPS (протокол защищённой передачи данных) - является stateless. Он состоит из двух stateless частей: HTTP и TLS. HTTP передаёт session_id (идентификатор сессии, созданный в приложении), зашифрованный с помощью session_key в TLS. Session_id не входит в состав HTTPS (поскольку это часть приложения, а не протокола), а session_key может обновиться в любой момент - поэтому временное хранение session_key не делает TLS stateful. А вот backend-приложение, сверяющее расшифрованный session_id со своей базой - вот это уже stateful.
На физическом (L1) и канальном (L2) уровнях, stateful принципиально невозможен - на этих уровнях происходит обмен битами без понятия "сессии". На сетевом уровне (L3), IP-пакеты обрабатываются независимо, кроме тех случаев, когда используется NAT (трансляция адресов), который хранит таблицу соответствий "локальный IP:порт <=> публичный IP:порт". На траспортном уровне (L4), протокол UDP является stateless, так как передача данных происходит без установки соединения, а протокол TCP хранит состояние соединения (SYN/ACK, порядок пакетов, окно перегрузки), поэтому является stateful. Сеансовый урвень (L5) специально создан для управления сеансами (но редко реализуется явно в современных стеках). В качестве примеров stateful L5 можно привести токены авторизации Kerberos и диалоговые сессии в SIP-протоколе (VoIP). На уровне представления (L6) происходит шифрование и компрессия данных, которые обходятся без сохранения состояния, поэтому являются stateless. Прикладной уровень (L7) - является главным "доменом" stateful-логики: Веб-сессии (session_id в куках); Базы данных (транзакции); FTP (сервер помнит текущую директорию); WebSockets.
Serverless — "безсерверный" стиль работы. Конечно же, не означает отсутствие серверов - но означает отсутствие возни с ними. AWS Lambda, Google Cloud Functions, Azure Functions - предоставляют веб-интерфейс, через который можно загрузить в их облако код, который будет выполняться в ответ на события, а провайдер услуги берёт плату только за время выполнения кода. Так же возможно автоматическое масштабирование в случае увеличения роста потребностей у приложения. Однако, есть и минусы - холодный старт (задерка при первом запуске) и ограничения на время выполнения.
Blockchain (Блокчейн) - в переводе "цепочка блоков". Это децентрализованная база данных, где информация хранится в блоках, связанных в строгую последовательность через хеш-сумму предыдущего блока - непрерывно до первого "генезис" блока, а все данные дублируются на тысячах нод (узлов).
Как хранится блокчейн:
1) Полные ноды (Full Nodes): Полные ноды хранят весь блокчейн, то есть каждую транзакцию и каждый блок, начиная с самого первого (генезис-блока). Они выполняют критически важную задачу проверки и обеспечения согласованности сети. Пример: В сети Bitcoin полные ноды поддерживают всю цепочку блоков. На данный момент размер блокчейна Bitcoin составляет около 647 гигабайт. Это данные для полной ноды, которая хранит всю историю транзакций с момента создания сети в 2009 году. Максимальный размер блока сети Bitcoin составляет 1 мегабайт. Это ограничение введено для обеспечения стабильной работы сети и предотвращения слишком больших нагрузок на ноды.
2) Легкие ноды (Light Nodes): Легкие ноды хранят только небольшую часть данных, необходимую для проверки транзакций. Обычно это называется "заголовок блока" (header), который включает в себя хеш и метаданные. Они полагаются на полные ноды для получения детальной информации о цепочке. Используются в мобильных кошельках и приложениях, где важно сохранить низкий объем хранимых данных.
"Классический" блокчейн не фрагментируется между нодами, каждая полная нода хранит одну и ту же копию всей цепочки. Весь блокчейн не "разделен" между узлами, а реплицируется (дублируется) на всех полных нодах сети. В некоторых новых блокчейнах, таких как Polkadot или Solana, применяются подходы для повышения масштабируемости, такие как шрдинг и деление по уровням. Шардинг (Sharding): Делит данные между нодами по сегментам, где каждая нода обрабатывает только часть данных. Однако это сложная технология, и шардинг отличается от традиционной репликации блокчейнов. Хранение в слоях (Layered Storage): Вторая или третья инфраструктура хранит часть менее используемых данных.
Связь хеш-сумм с содержанием блоков и зависимость между всеми следующими друг за другом хеш-суммами говорит о том, что для того, чтобы подделать (подменить) информацию в блоке, который уже был включён в цепь - необходимо пересчитать хеш сумму этого блока, что приведёт к изменению всех остальных следующих из неё хеш-сумм. Это приведёт к тому, что возникнет разница в данных, которые уже были записаны на другие ноды, с новыми данными, которые пытается переписать злоумышленник. До тех пор, пока этот злоумышленник не владеет 51% (и более) вычислительных мощностей всей сети - ему не удастся внести изменения в цепь таким образом, чтобы с ним согласилась вся остальная сеть.
Вся надёжность технологии блокчейна сводится к сложности концентрации более чем 51% ресурсов в руках злоумышленников.
Если атака 51% будет обнаружена, разработчики и сообщество могут принять решение "инициировать форк" - о создании новой цепочки, которая исключает внесенные злоумышленником изменения. Это произошло, например, в результате атаки на Ethereum в 2016 году, когда был инициирован хард-форк, разделивший сеть на Ethereum и Ethereum Classic.
Консенсус — это механизм, с помощью которого ноды (узлы) сети договариваются о текущем состоянии блокчейна. Без консенсуса блокчейн превратился бы в набор противоречивых данных, а децентрализация стала бы невозможной. В традиционных системах (например, банковских) есть центральный сервер, который определяет, какие транзакции valid. В блокчейне нет центрального органа, поэтому ноды должны сами приходить к соглашению: Какие транзакции включать в блок; Какой блок считать "правильным"; Как обрабатывать конфликты (например, если две ноды создали блок одновременно).
Существует несколько алгоритмов консенсуса, но общий принцип такой:
1) Ноды предлагают новые блоки (с транзакциями).
2) Сеть проверяет их по строгим правилам (корректность хешей, подписей и т.д.).
3) Выбирается одна версия блокчейна (та, которую поддерживает большинство).
1) Полные ноды (Full Nodes): Полные ноды хранят весь блокчейн, то есть каждую транзакцию и каждый блок, начиная с самого первого (генезис-блока). Они выполняют критически важную задачу проверки и обеспечения согласованности сети. Пример: В сети Bitcoin полные ноды поддерживают всю цепочку блоков. На данный момент размер блокчейна Bitcoin составляет около 647 гигабайт. Это данные для полной ноды, которая хранит всю историю транзакций с момента создания сети в 2009 году. Максимальный размер блока сети Bitcoin составляет 1 мегабайт. Это ограничение введено для обеспечения стабильной работы сети и предотвращения слишком больших нагрузок на ноды.
2) Легкие ноды (Light Nodes): Легкие ноды хранят только небольшую часть данных, необходимую для проверки транзакций. Обычно это называется "заголовок блока" (header), который включает в себя хеш и метаданные. Они полагаются на полные ноды для получения детальной информации о цепочке. Используются в мобильных кошельках и приложениях, где важно сохранить низкий объем хранимых данных.
"Классический" блокчейн не фрагментируется между нодами, каждая полная нода хранит одну и ту же копию всей цепочки. Весь блокчейн не "разделен" между узлами, а реплицируется (дублируется) на всех полных нодах сети. В некоторых новых блокчейнах, таких как Polkadot или Solana, применяются подходы для повышения масштабируемости, такие как шрдинг и деление по уровням. Шардинг (Sharding): Делит данные между нодами по сегментам, где каждая нода обрабатывает только часть данных. Однако это сложная технология, и шардинг отличается от традиционной репликации блокчейнов. Хранение в слоях (Layered Storage): Вторая или третья инфраструктура хранит часть менее используемых данных.
Связь хеш-сумм с содержанием блоков и зависимость между всеми следующими друг за другом хеш-суммами говорит о том, что для того, чтобы подделать (подменить) информацию в блоке, который уже был включён в цепь - необходимо пересчитать хеш сумму этого блока, что приведёт к изменению всех остальных следующих из неё хеш-сумм. Это приведёт к тому, что возникнет разница в данных, которые уже были записаны на другие ноды, с новыми данными, которые пытается переписать злоумышленник. До тех пор, пока этот злоумышленник не владеет 51% (и более) вычислительных мощностей всей сети - ему не удастся внести изменения в цепь таким образом, чтобы с ним согласилась вся остальная сеть.
Вся надёжность технологии блокчейна сводится к сложности концентрации более чем 51% ресурсов в руках злоумышленников.
Если атака 51% будет обнаружена, разработчики и сообщество могут принять решение "инициировать форк" - о создании новой цепочки, которая исключает внесенные злоумышленником изменения. Это произошло, например, в результате атаки на Ethereum в 2016 году, когда был инициирован хард-форк, разделивший сеть на Ethereum и Ethereum Classic.
Консенсус — это механизм, с помощью которого ноды (узлы) сети договариваются о текущем состоянии блокчейна. Без консенсуса блокчейн превратился бы в набор противоречивых данных, а децентрализация стала бы невозможной. В традиционных системах (например, банковских) есть центральный сервер, который определяет, какие транзакции valid. В блокчейне нет центрального органа, поэтому ноды должны сами приходить к соглашению: Какие транзакции включать в блок; Какой блок считать "правильным"; Как обрабатывать конфликты (например, если две ноды создали блок одновременно).
Существует несколько алгоритмов консенсуса, но общий принцип такой:
1) Ноды предлагают новые блоки (с транзакциями).
2) Сеть проверяет их по строгим правилам (корректность хешей, подписей и т.д.).
3) Выбирается одна версия блокчейна (та, которую поддерживает большинство).
Основные алгоритмы консенсуса:
1) Proof of Work (PoW) — "Доказательство работы": Участники сети (майнеры) решают вычислительно сложные задачи, чтобы найти подходящий хеш. Победитель добавляет блок в цепочку и получает вознаграждение. Где используется: Bitcoin, Ethereum (до перехода на PoS). Плюсы: Надежная защита, атака 51% требует огромных затрат. Минусы: Очень высокое энергопотребление.
2) Proof of Stake (PoS) — "Доказательство доли": Валидаторы блокируют свои монеты (ставят их на кон) для получения права добавлять блоки. Вероятность выбора зависит от размера доли. Где используется: Ethereum (после The Merge), Cardano, Solana. Плюсы: Энергоэффективность, экономичность. Минусы: Удержание власти крупными держателями токенов.
3) Delegated Proof of Stake (DPoS) — "Делегированное доказательство доли": Владельцы токенов голосуют за валидаторов, которые создают блоки от имени сети. Где используется: EOS, TRON. Плюсы: Высокая скорость и низкие затраты. Минусы: Риск централизации из-за малой группы валидаторов.
4) Proof of Authority (PoA) — "Доказательство авторитета": Только валидаторы с подтвержденным статусом получают право добавлять блоки. Где используется: VeChain, Ethereum в частных сетях. Плюсы: Скорость и высокая надежность. Минусы: Централизация и необходимость доверия к валидаторам.
5) Proof of Burn (PoB) — "Доказательство сжигания": Участники уничтожают часть своих токенов, чтобы получить возможность добавлять блоки. Где используется: Slimcoin. Плюсы: Энергоэффективность и простота. Минусы: Потеря части токенов на участие в процессе.
6) Proof of Capacity (PoC) — "Доказательство объема": Участники предоставляют свободное место на своих дисках для хранения данных блокчейна. Где используется: Burstcoin. Плюсы: Экологичность и низкие затраты. Минусы: Требуются значительные ресурсы для хранения.
7) Proof of Activity (PoA) — "Доказательство активности": Комбинация PoW и PoS, где майнеры решают задачи, а валидаторы подтверждают блоки. Где используется: Decred. Плюсы: Баланс между безопасностью и энергоэффективностью. Минусы: Усложнение процесса.
8) Proof of Time and Space (PoTS) — "Доказательство времени и пространства": Узлы выделяют дисковое пространство и время для участия в консенсусе. Где используется: Chia. Плюсы: Низкое энергопотребление. Минусы: Требования к дисковому пространству.
Смарт-контракт - это программный код, который автоматически выполняет заданные условия, записанные в блокчейне. Например, он может автоматически переводить средства при выполнении определённых условий. Смарт-контракт — это "строительный блок" для dApps, обеспечивающий логику работы приложения. Смарт-контракты поддерживаются не всеми блокчейнами, например, Биткоин - не использует смарт-контракты и на нём невозможно запустить свой код. Участники сети Биткоин тратят свои вычислительные ресурсы только на вычисление новых блоков и проведение транзакций - за что и получают свои комиссии. Однако другие блокчейны, такие как Ethereum, позволяют работать со смарт-контрактами, выполняя программный код, записанный в блоках, на нодах-участниках сети, за что они получают плату в виде так называемого "газа" (Gas), который затем "сжигается", чтобы удерживать инфляцию. Пример: Сделка на платформе Ethereum — смарт-контракт может обрабатывать передачу NFT или средств.
dApp (распределённое приложение) - это полноценное приложение, построенное на основе блокчейна, которое включает в себя интерфейс для взаимодействия пользователей и может опираться на один или несколько смарт-контрактов. dApp — это конечный продукт, который использует смарт-контракты для выполнения задач, таких как финансы (DeFi), игры, NFT и т.д. Пример: Uniswap — децентрализованная биржа, использующая множество смарт-контрактов для обработки обмена токенов.
1) Proof of Work (PoW) — "Доказательство работы": Участники сети (майнеры) решают вычислительно сложные задачи, чтобы найти подходящий хеш. Победитель добавляет блок в цепочку и получает вознаграждение. Где используется: Bitcoin, Ethereum (до перехода на PoS). Плюсы: Надежная защита, атака 51% требует огромных затрат. Минусы: Очень высокое энергопотребление.
2) Proof of Stake (PoS) — "Доказательство доли": Валидаторы блокируют свои монеты (ставят их на кон) для получения права добавлять блоки. Вероятность выбора зависит от размера доли. Где используется: Ethereum (после The Merge), Cardano, Solana. Плюсы: Энергоэффективность, экономичность. Минусы: Удержание власти крупными держателями токенов.
3) Delegated Proof of Stake (DPoS) — "Делегированное доказательство доли": Владельцы токенов голосуют за валидаторов, которые создают блоки от имени сети. Где используется: EOS, TRON. Плюсы: Высокая скорость и низкие затраты. Минусы: Риск централизации из-за малой группы валидаторов.
4) Proof of Authority (PoA) — "Доказательство авторитета": Только валидаторы с подтвержденным статусом получают право добавлять блоки. Где используется: VeChain, Ethereum в частных сетях. Плюсы: Скорость и высокая надежность. Минусы: Централизация и необходимость доверия к валидаторам.
5) Proof of Burn (PoB) — "Доказательство сжигания": Участники уничтожают часть своих токенов, чтобы получить возможность добавлять блоки. Где используется: Slimcoin. Плюсы: Энергоэффективность и простота. Минусы: Потеря части токенов на участие в процессе.
6) Proof of Capacity (PoC) — "Доказательство объема": Участники предоставляют свободное место на своих дисках для хранения данных блокчейна. Где используется: Burstcoin. Плюсы: Экологичность и низкие затраты. Минусы: Требуются значительные ресурсы для хранения.
7) Proof of Activity (PoA) — "Доказательство активности": Комбинация PoW и PoS, где майнеры решают задачи, а валидаторы подтверждают блоки. Где используется: Decred. Плюсы: Баланс между безопасностью и энергоэффективностью. Минусы: Усложнение процесса.
8) Proof of Time and Space (PoTS) — "Доказательство времени и пространства": Узлы выделяют дисковое пространство и время для участия в консенсусе. Где используется: Chia. Плюсы: Низкое энергопотребление. Минусы: Требования к дисковому пространству.
Смарт-контракт - это программный код, который автоматически выполняет заданные условия, записанные в блокчейне. Например, он может автоматически переводить средства при выполнении определённых условий. Смарт-контракт — это "строительный блок" для dApps, обеспечивающий логику работы приложения. Смарт-контракты поддерживаются не всеми блокчейнами, например, Биткоин - не использует смарт-контракты и на нём невозможно запустить свой код. Участники сети Биткоин тратят свои вычислительные ресурсы только на вычисление новых блоков и проведение транзакций - за что и получают свои комиссии. Однако другие блокчейны, такие как Ethereum, позволяют работать со смарт-контрактами, выполняя программный код, записанный в блоках, на нодах-участниках сети, за что они получают плату в виде так называемого "газа" (Gas), который затем "сжигается", чтобы удерживать инфляцию. Пример: Сделка на платформе Ethereum — смарт-контракт может обрабатывать передачу NFT или средств.
dApp (распределённое приложение) - это полноценное приложение, построенное на основе блокчейна, которое включает в себя интерфейс для взаимодействия пользователей и может опираться на один или несколько смарт-контрактов. dApp — это конечный продукт, который использует смарт-контракты для выполнения задач, таких как финансы (DeFi), игры, NFT и т.д. Пример: Uniswap — децентрализованная биржа, использующая множество смарт-контрактов для обработки обмена токенов.
Содержание / Contents
Hitachi VSP e590 Volumes Deattach
FC Multimode vs Single mode
Routing L1 L2 L3
OSI Open Systems Interconnection
Subnet Mask CIDR Classless Inter-Domain Routing Бесклассовая адресация
Витая пара Twisted pair RJ45 8P8C gigabit ethernet MDI-X Medium Dependent Interface crossover
Витая пара Twisted pair Cat BASE-T distance speed limits
Serial cable Rollover Cisco Консольный кабель
MAC Media Access Control (OSI L2)
CSMA/CD Carrier Sense Multiple Access with Collision Detection
Межкадровые интервалы Fast Ethernet IPG InterPacket Gap
Ethernet frame VLAN
Ethernet Jumbo frame efficiency
Ethernet frame detailed детализация кадра
EtherType values значения
ARP Address Resolution Protocol, DHCP Dynamic Host Configuration Protocol
IEEE 802 Institute of Electrical and Electronical Engineers
Transport OSI L4 Ports транспортный уровень типы портов
Password reset factory default Сброс паролей (к заводским настройкам) для систем хранения данных HPE MSA
Broadcom Brocade G620 - Сброс паролей доступа к устройству Password factory default reset
LANMAN, NTLM, MD5, SHA-1 and SHA-2 checksum hash
Windows DHCP lifehack
(Legacy) BIOS basic input-output system => MBR master boot record; UEFI; CMOS; Secrue Boot
RAM Random Access Memory; SRAM; DRAM; DIMM; RDIMM; LRDIMM; Channel, Rank, Timings, CAS Latency, Frequency
VPN Virtual Private Network
Bytes and Bits
RAID1 vs RAID0 .. RAID6, RAID-DP; Checksum, Parity, Stripe, Chunk, Column, Row
Cache, Buffer, Index and Register; Partitions and Files; Headers, Dividers and Pointers
Буфер обмена, политики кэширования
Физический диск, указатели, спецсимволы, файлы
Индекс, регистр
CPU's cycles on basic tasks
Шифрование данных, симметричное, ассиметричное, RSA
Процессоры: техпроцесс и маркетинг
Виртуализация
Кластеризация
SQL Structured Query Language; NoSQL
Контейнеризация
Микросервисная архитектура
Процесс, алгоритм, программа, язык программирования, компиляция, декомпиляция, исходный код
Flexibility: Block storage > Object storage > File storage
Размеры блоков, файловые системы
Системы счисления и простые множители - особенности операций с плавающей точкой
CPU - Central Processing Unit Центральный Процессор
Физические Серверы и все остальные виды серверов
Сегментация сетей передачи данных
Виртуальная сеть VLAN, Zoning
Бэкапы: резервное копирование и репликация - синхронная и асинхронная
Snapshot, Incremental, Differential, Full backup
Compression and Deduplication, RLE, RAR, ZIP
Топологии сетей, NAT
Bus, Loopback (localhost), Stack, Cluster, Quorum
Гайд по преднастройке импортозамещённых коммутаторов
Двухфакторная аутентификация (2FA) и защищённый криптопроцессор: средства доверенной загрузки, токены, смарт-карты и электронная цифровая подпись, Авторизация, Аутентификация
Конденсаторы, полупроводники, диоды, биполярные и полевые транзисторы, флеш-память
MOSFET, SRAM, DRAM, NAND, NOR
Операционные, файловые и символьные системы
FAT, NTFS, EXT4, LTFS
Гайд: сервер видеонаблюдения на Raspberry Pi 3 Model B
Peripherals: SCSI vs USB NVMe - Компьютерная переферия, скази и usb
SAS, SATA, Fibre Channel, iSCSI, PCI-e
Etherchannel: Network Interface Controller (NIC) Teaming, Bonding, Link Aggregation Group (LAG)
Multipath I/O (input/output) - многопутевой ввод/вывод
Проектирование информационных систем и схемы межсетевых взаимодействий
Многомерные базы данных (MDB), Онлайн-аналитическая обработка (OLAP)
TCPDUMP
Linux Command Line: Bash
Перехват сетевых пакетов: ARP Spoofing, Man In The Middle, Wireshark, снифферинг
YouTube без VPN!
Побайтовое копирование в Linux: dd
RDP Remote Desktop, VDI Virtual Desktop Infrastructure, RDS Remote Desktop Service
ProxMox
Docker
Kubernetes (K8S)
Ansible
Terraform
Git
Jenkins
Network Bridging, Flooding, Broadcasting, Spanning Tree Protocol, Routing
Таблица маршрутизации (routing table)
VRF (Virtual Routing and Forwarding), VXLAN, BGP, EVPN
Распределённый кэш; от простого до продвинутого: Memcached, Redis, Couchbase, KeyDB
Hitachi VSP e590 Volumes Deattach
FC Multimode vs Single mode
Routing L1 L2 L3
OSI Open Systems Interconnection
Subnet Mask CIDR Classless Inter-Domain Routing Бесклассовая адресация
Витая пара Twisted pair RJ45 8P8C gigabit ethernet MDI-X Medium Dependent Interface crossover
Витая пара Twisted pair Cat BASE-T distance speed limits
Serial cable Rollover Cisco Консольный кабель
MAC Media Access Control (OSI L2)
CSMA/CD Carrier Sense Multiple Access with Collision Detection
Межкадровые интервалы Fast Ethernet IPG InterPacket Gap
Ethernet frame VLAN
Ethernet Jumbo frame efficiency
Ethernet frame detailed детализация кадра
EtherType values значения
ARP Address Resolution Protocol, DHCP Dynamic Host Configuration Protocol
IEEE 802 Institute of Electrical and Electronical Engineers
Transport OSI L4 Ports транспортный уровень типы портов
Password reset factory default Сброс паролей (к заводским настройкам) для систем хранения данных HPE MSA
Broadcom Brocade G620 - Сброс паролей доступа к устройству Password factory default reset
LANMAN, NTLM, MD5, SHA-1 and SHA-2 checksum hash
Windows DHCP lifehack
(Legacy) BIOS basic input-output system => MBR master boot record; UEFI; CMOS; Secrue Boot
RAM Random Access Memory; SRAM; DRAM; DIMM; RDIMM; LRDIMM; Channel, Rank, Timings, CAS Latency, Frequency
VPN Virtual Private Network
Bytes and Bits
RAID1 vs RAID0 .. RAID6, RAID-DP; Checksum, Parity, Stripe, Chunk, Column, Row
Cache, Buffer, Index and Register; Partitions and Files; Headers, Dividers and Pointers
Буфер обмена, политики кэширования
Физический диск, указатели, спецсимволы, файлы
Индекс, регистр
CPU's cycles on basic tasks
Шифрование данных, симметричное, ассиметричное, RSA
Процессоры: техпроцесс и маркетинг
Виртуализация
Кластеризация
SQL Structured Query Language; NoSQL
Контейнеризация
Микросервисная архитектура
Процесс, алгоритм, программа, язык программирования, компиляция, декомпиляция, исходный код
Flexibility: Block storage > Object storage > File storage
Размеры блоков, файловые системы
Системы счисления и простые множители - особенности операций с плавающей точкой
CPU - Central Processing Unit Центральный Процессор
Физические Серверы и все остальные виды серверов
Сегментация сетей передачи данных
Виртуальная сеть VLAN, Zoning
Бэкапы: резервное копирование и репликация - синхронная и асинхронная
Snapshot, Incremental, Differential, Full backup
Compression and Deduplication, RLE, RAR, ZIP
Топологии сетей, NAT
Bus, Loopback (localhost), Stack, Cluster, Quorum
Гайд по преднастройке импортозамещённых коммутаторов
Двухфакторная аутентификация (2FA) и защищённый криптопроцессор: средства доверенной загрузки, токены, смарт-карты и электронная цифровая подпись, Авторизация, Аутентификация
Конденсаторы, полупроводники, диоды, биполярные и полевые транзисторы, флеш-память
MOSFET, SRAM, DRAM, NAND, NOR
Операционные, файловые и символьные системы
FAT, NTFS, EXT4, LTFS
Гайд: сервер видеонаблюдения на Raspberry Pi 3 Model B
Peripherals: SCSI vs USB NVMe - Компьютерная переферия, скази и usb
SAS, SATA, Fibre Channel, iSCSI, PCI-e
Etherchannel: Network Interface Controller (NIC) Teaming, Bonding, Link Aggregation Group (LAG)
Multipath I/O (input/output) - многопутевой ввод/вывод
Проектирование информационных систем и схемы межсетевых взаимодействий
Многомерные базы данных (MDB), Онлайн-аналитическая обработка (OLAP)
TCPDUMP
Linux Command Line: Bash
Перехват сетевых пакетов: ARP Spoofing, Man In The Middle, Wireshark, снифферинг
YouTube без VPN!
Побайтовое копирование в Linux: dd
RDP Remote Desktop, VDI Virtual Desktop Infrastructure, RDS Remote Desktop Service
ProxMox
Docker
Kubernetes (K8S)
Ansible
Terraform
Git
Jenkins
Network Bridging, Flooding, Broadcasting, Spanning Tree Protocol, Routing
Таблица маршрутизации (routing table)
VRF (Virtual Routing and Forwarding), VXLAN, BGP, EVPN
Распределённый кэш; от простого до продвинутого: Memcached, Redis, Couchbase, KeyDB
Содержание / Contents
Высокопроизводительные сети: RDMA, InfiniBand, RoCE v2, QoS, vSAN
Реляционные базы данных, язык SQL
OSI L2 & L3
Сравнение производительности сетевых протоколов для систем хранения данных: FC, iSCSI, RoCE
Stateless, Stateful, Serverless, Blockchain, Smart contract, dApp
Гайд на виртуальный частный сервер (VPS) с нуля
Базовая защита сервера Linux
Высокопроизводительные сети: RDMA, InfiniBand, RoCE v2, QoS, vSAN
Реляционные базы данных, язык SQL
OSI L2 & L3
Сравнение производительности сетевых протоколов для систем хранения данных: FC, iSCSI, RoCE
Stateless, Stateful, Serverless, Blockchain, Smart contract, dApp
Гайд на виртуальный частный сервер (VPS) с нуля
Базовая защита сервера Linux
Гайд на виртуальный частный сервер (VPS) с нуля
Подробная инструкция, как арендовать и настроить свой выделенный сервер - для защиты своего сетевого трафика от анализа третьими лицами (прослушки) и прочих нежелательных сетевых активностей.
Коротко, о чём гайд:
- Сервер Linux Debian 11
- Виртуальная частная сеть Wireguard
- Мониторинг Grafana
- Спасательный круг: backups & snapshots
- Базовая защита от взлома перебором fali2ban
- Фильтр нежелательного контента, приоритезация трафика QoS
продолжение в следующих семи сообщениях, или на хабре
Подробная инструкция, как арендовать и настроить свой выделенный сервер - для защиты своего сетевого трафика от анализа третьими лицами (прослушки) и прочих нежелательных сетевых активностей.
Коротко, о чём гайд:
- Сервер Linux Debian 11
- Виртуальная частная сеть Wireguard
- Мониторинг Grafana
- Спасательный круг: backups & snapshots
- Базовая защита от взлома перебором fali2ban
- Фильтр нежелательного контента, приоритезация трафика QoS
продолжение в следующих семи сообщениях, или на хабре
🔥1
Шаг 1: Выбрать хостинг
Воспользоваться поисковым запросом "список самых дешёвых VPS хостингов" и выбрать, какой больше нравится. Конфигурации и цены бывают разные, самые дешёвые начинаются от двух евро в месяц. Например - hip.hosting
Шаг 2: Выбрать локацию, операционную систему и оплатить аренду сервера
Локацию сервера выбираем из доступных, исходя из своих предпочтений. Обычно - чем ближе локация, тем ниже задержка. Операционную систему я советую Debian.
Шаг 3: Настройка операционной системы
Используя программу Putty и предоставленные IP адрес и пароль, нужно войти на сервер и обновиться:
Для базовой защиты сервера от взлома - рекомендую утилиту fail2ban:
Пример настройки файла конфигурации /etc/fail2ban/jail.local:
Разбанить всех: sudo fail2ban-client unban --all
Установим бесплатный клиент с открытым исходным кодом Wireguard:
Переходим в папку приложения:
Генерируем и записываем ключи:
Приватный ключ надо записать в конфиг Wireguard; здесь Address = это адрес сервера в виртуальной сети, а ListenPort = порт, по которому будут подключаться клиенты (адрес и порт можно задать произвольно):
Далее - надо добавить в этот файл информацию о сетевом адаптере:
После этого, в конфигурационный файл добавляются клиенты:
PublicKey - публичный ключ клиента, которому принадлежит виртуальный адрес AllowedIPs, а маска /32 говорит о том, что это одиночный адрес хоста.
В итоге, конфигурационный файл wg0.conf должен иметь вид типа такого:
где
PrivateKey - приватный ключ сервера
Address - виртуальный адрес сервера
ListenPort - порт сервера
PublicKey - публичный ключ клиента, которому принадлежит виртуальный адрес AllowedIPs из его секции [Peer]
Воспользоваться поисковым запросом "список самых дешёвых VPS хостингов" и выбрать, какой больше нравится. Конфигурации и цены бывают разные, самые дешёвые начинаются от двух евро в месяц. Например - hip.hosting
Шаг 2: Выбрать локацию, операционную систему и оплатить аренду сервера
Локацию сервера выбираем из доступных, исходя из своих предпочтений. Обычно - чем ближе локация, тем ниже задержка. Операционную систему я советую Debian.
Шаг 3: Настройка операционной системы
Используя программу Putty и предоставленные IP адрес и пароль, нужно войти на сервер и обновиться:
sudo apt update && apt upgrade -y
sudo apt-get install iptables ipset net-tools vim rsync parted -y
Для базовой защиты сервера от взлома - рекомендую утилиту fail2ban:
sudo apt install fail2ban -y
vim /etc/fail2ban/jail.local
vim, vi - самый распространённый текстовый редактор linux. Режим редактирования включается кнопкой i, выход из редактирования кнопка esc. Чтобы выйти без сохранения надо ввести ":q!" (без кавычек), выход с сохранением - ":wq!"
Пример настройки файла конфигурации /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 7
bantime = 1d
sudo systemctl restart fail2ban
sudo systemctl enable --now fail2ban
Разбанить всех: sudo fail2ban-client unban --all
Установим бесплатный клиент с открытым исходным кодом Wireguard:
sudo apt install wireguard -y
Переходим в папку приложения:
cd /etc/wireguard/
Генерируем и записываем ключи:
wg genkey | tee privatekey | wg pubkey | tee publickey
Приватный ключ надо записать в конфиг Wireguard; здесь Address = это адрес сервера в виртуальной сети, а ListenPort = порт, по которому будут подключаться клиенты (адрес и порт можно задать произвольно):
echo "[Interface]
PrivateKey = $(cat privatekey)
Address = 10.0.0.1/24
ListenPort = 54545" > wg0.conf
в Putty текст вставляется правой кнопкой мыши. В vim через Putty - клавиша shift+правая кнопка мыши. А для переноса больших объёмов текста в веб-консоль, у меня есть пара удобных инструментов - typewriter и infill.
Далее - надо добавить в этот файл информацию о сетевом адаптере:
INTERFACE=$(ip route | grep default | awk '{print $5}' | head -n1); sudo tee -a wg0.conf <<EOF
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o $INTERFACE -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o $INTERFACE -j MASQUERADE
EOF
После этого, в конфигурационный файл добавляются клиенты:
[Peer]
PublicKey = uJWPI0zpKSB7C4G9LLdy4VMX2bPXs33g7nfdo2CVanw=
AllowedIPs = 10.10.10.30/32
PublicKey - публичный ключ клиента, которому принадлежит виртуальный адрес AllowedIPs, а маска /32 говорит о том, что это одиночный адрес хоста.
В итоге, конфигурационный файл wg0.conf должен иметь вид типа такого:
[Interface]
Address = 10.10.10.1/24
ListenPort = 21212
PrivateKey = qPSUFPcGiHUQkOo2RHPGWeb3XmSjfiSWqSMuPd3SnCs=
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
[Peer]
PublicKey = uJWPI0zpKSB7C4G9LLdy4VMX2bPXs33g7nfdo2CVanw=
AllowedIPs = 10.10.10.30/32
[Peer]
PublicKey = YXnyogyq5930eFdueaFivCqpJCRMEmawJrpP1lcGEDc=
AllowedIPs = 10.10.10.20/32
где
PrivateKey - приватный ключ сервера
Address - виртуальный адрес сервера
ListenPort - порт сервера
PublicKey - публичный ключ клиента, которому принадлежит виртуальный адрес AllowedIPs из его секции [Peer]
🔥1
Публичный ключ клиента можно получить в приложении клиента (например, Wireguard для Windows), где он будет случайно сгенерирован при добавлении нового "пустого" туннеля.
Защитим порт Wireguard от взлома перебором:
После следующего действия сервер станет открытым для передачи трафика через него. Все необходимые настройки безопасности, связанные с этим - я поместил в последний, четвёртый этап настройки, однако если делать всё "максимально красиво" - рекомендую не откладывать это на конец, а наоборот - сделать в самом начале.
В файле системной конфигурации нужно убрать знак комментария "#" в начале строки "net.ipv4.ip_forward=1", чтобы разрешить нашему серверу выполнять роль прокси:
Добавляем туннель в автозагрузку и перезагружаемся:
Готово! Минимальная настройка завершена,
теперь введя в клиент публичный ключ сервера, внутренний IP-адрес клиента и внешний IP-адрес сервера с портом - можно пользоваться сетью.
Установим и настроим мониторинг Grafana для отслеживания сетевой активности по клиентам:
Заполнить файл следующим содержанием, строгое количество пробелов в началах строк!
Чтобы мониторинг запускался со стартом системы, создадим systemd-сервис:
- Эта команда сделает мониторинг Grafana доступным только из внутренней сети Wireguard
Теперь нужно дать пару минут сервису Grafana полностью загрузиться - и можно зайти на веб-панель мониторинга, используя виртуальный адрес своего сервера в сети wireguard и порт 3000: http://your-server-ip:3000.
Для первого входа используются стандартные логин и пароль admin
Защитим порт Wireguard от взлома перебором:
sudo modprobe wireguard
echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo bash -c 'echo -e "[Definition]\nfailregex = ^.Invalid handshake from <HOST>:\\d+.\nignoreregex =" > /etc/fail2ban/filter.d/wireguard.conf'
sudo bash -c 'echo -e "\n[wireguard]\nenabled = true\nport = $(grep -oP "ListenPort\s*=\s*\K\d+" /etc/wireguard/wg0.conf)\nfilter = wireguard\nlogpath = /var/log/syslog\nmaxretry = 5\nbantime = 30d\nfindtime = 7d" >> /etc/fail2ban/jail.local'
После следующего действия сервер станет открытым для передачи трафика через него. Все необходимые настройки безопасности, связанные с этим - я поместил в последний, четвёртый этап настройки, однако если делать всё "максимально красиво" - рекомендую не откладывать это на конец, а наоборот - сделать в самом начале.
В файле системной конфигурации нужно убрать знак комментария "#" в начале строки "net.ipv4.ip_forward=1", чтобы разрешить нашему серверу выполнять роль прокси:
vim /etc/sysctl.conf
Добавляем туннель в автозагрузку и перезагружаемся:
sudo systemctl enable wg-quick@wg0
sudo reboot
Готово! Минимальная настройка завершена,
теперь введя в клиент публичный ключ сервера, внутренний IP-адрес клиента и внешний IP-адрес сервера с портом - можно пользоваться сетью.
Установим и настроим мониторинг Grafana для отслеживания сетевой активности по клиентам:
sudo mkdir -p /etc/apt/keyrings/
apt-get install gpg -y
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install -y prometheus grafana
sudo iptables -A INPUT -i wg0 -j ACCEPT
sudo iptables -A OUTPUT -o wg0 -j ACCEPT
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env
sudo apt install cargo build-essential -y
cargo install clap --version 4.0.26
exec bash
cargo install prometheus_wireguard_exporter
vim /etc/prometheus/prometheus.yml
Заполнить файл следующим содержанием, строгое количество пробелов в началах строк!
global:
scrape_interval: 15s
scrape_configs:
- job_name: wireguard
scrape_interval: 10s
static_configs:
- targets: ['127.0.0.1:9586']
Чтобы мониторинг запускался со стартом системы, создадим systemd-сервис:
sudo cp /root/.cargo/bin/prometheus_wireguard_exporter /usr/local/bin/
sudo chmod +x /usr/local/bin/prometheus_wireguard_exporter
vim /etc/systemd/system/wireguard-exporter.service
[Unit]
Description=Prometheus WireGuard Exporter
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/prometheus_wireguard_exporter --interfaces wg0
Restart=on-failure
User=root
Environment=PATH=/usr/local/bin:/usr/bin:/bin
[Install]
WantedBy=multi-user.target
sudo sed -i "/http_addr/s/^[[:space:]]*http_addr[[:space:]]*=[[:space:]]*.*/http_addr = $(ip -4 -o addr show wg0 2>/dev/null | awk '{print $4}' | cut -d'/' -f1)/" /etc/grafana/grafana.ini
- Эта команда сделает мониторинг Grafana доступным только из внутренней сети Wireguard
sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server
sudo systemctl enable --now wireguard-exporter.service
Теперь нужно дать пару минут сервису Grafana полностью загрузиться - и можно зайти на веб-панель мониторинга, используя виртуальный адрес своего сервера в сети wireguard и порт 3000: http://your-server-ip:3000.
Для первого входа используются стандартные логин и пароль admin
🔥1
Мониторинг можно настроить в разделе "Dashboards". В режиме "edit" - включается сверху справа - выбираем Add - visualisation. Выбираем prometheus, адрес сервера вставляем дефолтный (http://localhost:9090) и save. Сохраняем дашборд под каким-нибудь названием и заходим в него через меню Dashboards. Удаляем все query и создаём новую, по кнопке + Add query. В поле Data source должен быть выбран prometheus. Справа - переключаемся в режим Code, если вдруг выбран Builder. Далее - в поле "Enter a PromQL query..." вставляем следующий запрос:
Нажимаем кнопку Run queries и сверху должен появиться график. Сохраняем дашборд справа сверху. Дальнейшая настройка вполне интуитивна. Чтобы переименовать графики - нужно прокрутить Panel options вниз до кнопки + Add field override, нажав на неё выбрать нужный график и переименовать его.
Далее - продвинутая конфигурация: переход на другую файловую систему, резервное копирование и моментальные снимки, восстановление из резервной копии, фильтрация нежелательного контента и правила для разных типов трафика.
Этап 1: Смена файловой системы и резервное копирование
Иногда случаются различные казусы, после которых возникает острое желание откатиться на некоторое время назад. В большинстве приложений - такой откат на одно последнее действие происходит комбинацией клавиш CTRL+Z, однако не всегда и не везде. В некоторых случаях - полезно иметь полную резервную копию всех данных. Лучше, когда она есть и не нужна, чем когда нужна и её нет.
Базовая файловая система Linux, EXT4 - не обладает функционалом снимков файловой системы - поэтому выполним переход на более продвинутую BTRFS
Смотрим сколько есть места на сервере командой df -h. В моём примере сервер с 10ГБ диском.
Свободное место делим чуть меньше чем пополам и с помощью parted создаём логический том под резервную копию
Синхронизируем содержимое корневого раздела и резервного, без лишних каталогов (и удаляя всё лишнее в целевой директории):
Подменяем разделы для загрузки с бэкапа - редактируем fstab:
И загрузчик grub:
Теперь при следующей загрузке сервер запустится из резервной копии в разделе с файловой системой BTRFS.
После перезагрузки, убедимся, что корень (/) находится на /dev/sda2 командой df -h, затем преобразуем /dev/sda1 в BTRFS:
mkfs преобразует файловую систему, не конвертируя данные, поэтому нам надо вернуть их обратно из резервной копии:
Снова правим GRUB, для загрузки в sda1:
Перезагружаемся и актуализируем fstab
Восстановление из загрузочного меню GRUB RESCUE
Если по какой-то случайности система оказалась в нерабочем состоянии, разбираться в котором нет никакого желания - можно загрузиться в резервную копию через меню загрузчика GRUB.
rate(wireguard_received_bytes_total[10m])
Нажимаем кнопку Run queries и сверху должен появиться график. Сохраняем дашборд справа сверху. Дальнейшая настройка вполне интуитивна. Чтобы переименовать графики - нужно прокрутить Panel options вниз до кнопки + Add field override, нажав на неё выбрать нужный график и переименовать его.
Далее - продвинутая конфигурация: переход на другую файловую систему, резервное копирование и моментальные снимки, восстановление из резервной копии, фильтрация нежелательного контента и правила для разных типов трафика.
Этап 1: Смена файловой системы и резервное копирование
Иногда случаются различные казусы, после которых возникает острое желание откатиться на некоторое время назад. В большинстве приложений - такой откат на одно последнее действие происходит комбинацией клавиш CTRL+Z, однако не всегда и не везде. В некоторых случаях - полезно иметь полную резервную копию всех данных. Лучше, когда она есть и не нужна, чем когда нужна и её нет.
Базовая файловая система Linux, EXT4 - не обладает функционалом снимков файловой системы - поэтому выполним переход на более продвинутую BTRFS
Смотрим сколько есть места на сервере командой df -h. В моём примере сервер с 10ГБ диском.
Свободное место делим чуть меньше чем пополам и с помощью parted создаём логический том под резервную копию
sudo apt install parted btrfs-progs -y
sudo parted /dev/sda
resizepart 1 → указываем новый размер: 4.8GB.
mkpart primary btrfs 4.8GB 100% → создаем /dev/sda2 из оставшегося места.
print → проверяем, что получилось.
q
sudo mkdir /mnt/btrfs_backup
sudo mount /dev/sda2 /mnt/btrfs_backup
Синхронизируем содержимое корневого раздела и резервного, без лишних каталогов (и удаляя всё лишнее в целевой директории):
sudo rsync -aAXv --delete --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/","/mnt/","/media/*","/lost+found"} / /mnt/btrfs_backup/
sudo mkdir /mnt/btrfs_backup/{dev,proc,sys,tmp,run,mnt,media}
Подменяем разделы для загрузки с бэкапа - редактируем fstab:
sudo sed -i "| / |c UUID=$(sudo blkid -s UUID -o value /dev/sda2) / btrfs defaults,compress=zstd,noatime 0 1" /mnt/btrfs_backup/etc/fstab
И загрузчик grub:
sudo mount --bind /dev /mnt/btrfs_backup/dev
sudo mount --bind /proc /mnt/btrfs_backup/proc
sudo mount --bind /sys /mnt/btrfs_backup/sys
sudo chroot /mnt/btrfs_backup
update-grub
grub-install /dev/sda
exit
Теперь при следующей загрузке сервер запустится из резервной копии в разделе с файловой системой BTRFS.
sudo reboot
После перезагрузки, убедимся, что корень (/) находится на /dev/sda2 командой df -h, затем преобразуем /dev/sda1 в BTRFS:
sudo mkfs.btrfs -f /dev/sda1
sudo mkdir /mnt/sda1
sudo mount /dev/sda1 /mnt/sda1
mkfs преобразует файловую систему, не конвертируя данные, поэтому нам надо вернуть их обратно из резервной копии:
sudo rsync -aAXv --delete --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/","/mnt/","/media/*","/lost+found"} / /mnt/sda1/
Снова правим GRUB, для загрузки в sda1:
sudo mount --bind /dev /mnt/sda1/dev
sudo mount --bind /proc /mnt/sda1/proc
sudo mount --bind /sys /mnt/sda1/sys
sudo chroot /mnt/sda1
update-grub
grub-install /dev/sda
exit
Перезагружаемся и актуализируем fstab
sudo reboot
sudo sed -i "s/^UUID=[^ ]* / btrfs/UUID=(blkid -s UUID -o value(findmnt -n -o SOURCE /)") / btrfs/" /etc/fstab
Восстановление из загрузочного меню GRUB RESCUE
Если по какой-то случайности система оказалась в нерабочем состоянии, разбираться в котором нет никакого желания - можно загрузиться в резервную копию через меню загрузчика GRUB.
🔥1
Смотрим список доступных разделов:
Проверяем список на наличие загрузочного сектора:
Если вывод команды показывает файлы типа vmlinuz и initrd.img, значит, это корневой раздел. Для успешного восстановления - нужно выбрать корневой раздел с резервной копией.
Обычно, нумерация разделов такая же, как в операционке, а hd - это номер физического диска (нумерация с нуля)
Загрузка из этого раздела:
После загрузки в резервный раздел - нужно вернуться к действию 5) и копировать резервную копию на основной раздел, а затем перезагрузиться в него (и fstab обновить).
Работа с моментальными снимками
Создадим первый:
Просмотр списка "быстрых сохранений":
Откат системы к моментальному снимку
- Эта команда выполняет откат к последнему снапшоту, после чего перезагружает систему.
Этап 2: Настройка конфигурации клиента и блокировка рекламы на уровне DNS
На стороне устройств, включённых в виртуальную частную сеть, (на стороне клиентов) выполняется следующая настройка конфигурации Wireguard:
- Секция [Interface] относится к виртуальному интерфейсу клиента; ему нужно присвоить (или сгенерировать) приватный ключ подходящего формата (wireguard), публичный отпечаток которого вводится в конфигурацию на стороне сервера. Адрес - во внутренней сети, то бишь в VPN. А DNS - указываем от AdGuard, с блокировкой рекламы и вредоносных сайтов, и запасной от Google, как самый надёжный - к нему сервер будет обращаться только в случае недоступности первого (большая редкость).
- В секции [Peer] указывается публичный ключ нашего сервера, Endpoint - это IP-адрес сервера и его listenport; PersistentKeepalive - это время в секундах когда будет повторно выполнено рукопожатие для поддержания активного статуса подключения, а AllowedIPs - это список сетевых адресов, трафик до которых будет перенаправлен через VPN. Иными словами - если какой-то адрес не входит в диапазоны указанные в этом списке - то трафик до этого адреса не будет идти через VPN. Это может быть полезно, например, для внутренних ресурсов, доступ к которым может быть ограничен с удалённых серверов, или для минимизации задержки в онлайн-играх.
Чтобы "ограничить влияние" VPN на какие-либо сервисы, делаются три действия:
1) определение сетевого адреса, используемого сервисом - проще всего это сделать с помощью поиска в Сети, поскольку разработчики обычно публикуют информацию о используемых адресах, либо с помощью анализаторов типа WireShark
2) с помощью специального калькулятора (https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/) нужно составить корректную строку для AllowedIPs
3) ввести эту строку в секцию AllowedIPs в конфиге клиента (пира)
Пример конфигурации для клиента, с блокировкой рекламы и исключением сети 11.7.0.0/16:
Этап 3: фильтр HTTP рекламы Privoxy
Установим Privoxy и скачаем расширенные листы блокировок:
ls
Проверяем список на наличие загрузочного сектора:
ls (hd0,gpt2)/boot/
Если вывод команды показывает файлы типа vmlinuz и initrd.img, значит, это корневой раздел. Для успешного восстановления - нужно выбрать корневой раздел с резервной копией.
Обычно, нумерация разделов такая же, как в операционке, а hd - это номер физического диска (нумерация с нуля)
Загрузка из этого раздела:
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal
После загрузки в резервный раздел - нужно вернуться к действию 5) и копировать резервную копию на основной раздел, а затем перезагрузиться в него (и fstab обновить).
Работа с моментальными снимками
Создадим первый:
sudo mkdir /snapshots
sudo btrfs subvolume snapshot / /snapshots/root_$(date +%Y-%m-%d_%H-%M)
Просмотр списка "быстрых сохранений":
sudo btrfs subvolume list /
Откат системы к моментальному снимку
sudo btrfs subvolume set-default $(sudo btrfs subvolume list / | sort -n -k2 | tail -1 | awk '{print $2}') / && sudo reboot
- Эта команда выполняет откат к последнему снапшоту, после чего перезагружает систему.
Этап 2: Настройка конфигурации клиента и блокировка рекламы на уровне DNS
На стороне устройств, включённых в виртуальную частную сеть, (на стороне клиентов) выполняется следующая настройка конфигурации Wireguard:
- Секция [Interface] относится к виртуальному интерфейсу клиента; ему нужно присвоить (или сгенерировать) приватный ключ подходящего формата (wireguard), публичный отпечаток которого вводится в конфигурацию на стороне сервера. Адрес - во внутренней сети, то бишь в VPN. А DNS - указываем от AdGuard, с блокировкой рекламы и вредоносных сайтов, и запасной от Google, как самый надёжный - к нему сервер будет обращаться только в случае недоступности первого (большая редкость).
- В секции [Peer] указывается публичный ключ нашего сервера, Endpoint - это IP-адрес сервера и его listenport; PersistentKeepalive - это время в секундах когда будет повторно выполнено рукопожатие для поддержания активного статуса подключения, а AllowedIPs - это список сетевых адресов, трафик до которых будет перенаправлен через VPN. Иными словами - если какой-то адрес не входит в диапазоны указанные в этом списке - то трафик до этого адреса не будет идти через VPN. Это может быть полезно, например, для внутренних ресурсов, доступ к которым может быть ограничен с удалённых серверов, или для минимизации задержки в онлайн-играх.
Чтобы "ограничить влияние" VPN на какие-либо сервисы, делаются три действия:
1) определение сетевого адреса, используемого сервисом - проще всего это сделать с помощью поиска в Сети, поскольку разработчики обычно публикуют информацию о используемых адресах, либо с помощью анализаторов типа WireShark
2) с помощью специального калькулятора (https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/) нужно составить корректную строку для AllowedIPs
3) ввести эту строку в секцию AllowedIPs в конфиге клиента (пира)
Пример конфигурации для клиента, с блокировкой рекламы и исключением сети 11.7.0.0/16:
[Interface]
PrivateKey = e3rmxdsBWO5pcHR4wRaQSiOJ9lrz7w8dALNIKeMUc0M=
Address = 10.10.10.99/24
DNS = 94.140.14.14, 8.8.8.8
[Peer]
PublicKey = Hp3gn3oQOHO2QBWSL0jlYVhrCSNh/HW3a/e+O1jR2Ts=
AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 10.0.0.0/8, 11.0.0.0/14, 11.4.0.0/15, 11.6.0.0/16, 11.8.0.0/13, 11.16.0.0/12, 11.32.0.0/11, 11.64.0.0/10, 11.128.0.0/9, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1
Endpoint = 2.21.189.131:33444
PersistentKeepalive = 60
Этап 3: фильтр HTTP рекламы Privoxy
Установим Privoxy и скачаем расширенные листы блокировок:
sudo apt update && sudo apt install privoxy -y
sudo wget -O /etc/privoxy/easylist https://easylist.to/easylist/easylist.txt && echo "filterfile easylist" | sudo tee -a /etc/privoxy/config && sudo systemctl restart privoxy && sudo systemctl enable privoxy
Для фильтрации всей остальной рекламы - рекомендую приложение uBlock в браузере клиента
Этап 4: правила для разных типов трафика (QoS) и сетевой экран
Установим политики по умолчанию
Разрешить форвард только для клиентов Wireguard:
Включить NAT для выхода в Интернет:
Правила для доступа к управлению сервером и мониторингу из внутренней сети:
Смарт-фильтр CAKE настраиваем на пропускную способность сети сервера (с указанием названия адаптера между dev и root):
Правила для игрового трафика:
Голосовые и видеозвонки:
Видео-стриминг:
Веб-трафик:
Низкий приоритет для всего остального (например, торренты):
Теперь, в качестве главной меры безопасности, блокируем весь внешний доступ к серверу, кроме как из внутренней сети Wireguard
Разрешим localhost:
- Эта команда сделает исключение для порта Wireguard, чтобы он остался открыт
- Здесь после dport надо указать свой нестандартный порт управления (и запомнить его).
В следующей команде используется этот же номер порта; она установит его портом для подключения к secure shell:
Создаём листы блокировок:
Установим политики по умолчанию
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
Разрешить форвард только для клиентов Wireguard:
sudo iptables -A FORWARD -i wg0 -o ens3 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i ens3 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Включить NAT для выхода в Интернет:
sudo iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
Правила для доступа к управлению сервером и мониторингу из внутренней сети:
sudo iptables -A INPUT -i wg0 -j ACCEPT
sudo iptables -A OUTPUT -o wg0 -j ACCEPT
Смарт-фильтр CAKE настраиваем на пропускную способность сети сервера (с указанием названия адаптера между dev и root):
sudo tc qdisc replace dev ens3 root cake bandwidth 100mbit nat
Правила для игрового трафика:
sudo iptables -t mangle -A PREROUTING -i wg0 -p udp -m multiport --dports 27000:27100,3478:3479,4379:4380,3724,4000,5060:5062,6112:6119,6250,12000:64000 -j DSCP --set-dscp-class EF
sudo iptables -t mangle -A PREROUTING -i wg0 -p tcp -m multiport --dports 27015:27050,1119:1120,3074,3724,4000,6112:6120 -j DSCP --set-dscp-class EF
Голосовые и видеозвонки:
sudo iptables -t mangle -A PREROUTING -i wg0 -p udp --dport 3478:3481 -j DSCP --set-dscp-class EF
Видео-стриминг:
sudo iptables -t mangle -A PREROUTING -i wg0 -p tcp --dport 443 -m string --string "youtube" --algo bm -j DSCP --set-dscp-class AF21
Веб-трафик:
sudo iptables -t mangle -A PREROUTING -i wg0 -p tcp -m multiport --dports 80,443 -j DSCP --set-dscp-class BE
Низкий приоритет для всего остального (например, торренты):
sudo iptables -t mangle -A PREROUTING -i wg0 -j DSCP --set-dscp-class CS1
Теперь, в качестве главной меры безопасности, блокируем весь внешний доступ к серверу, кроме как из внутренней сети Wireguard
Разрешим localhost:
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p udp --dport $(grep -i 'ListenPort' /etc/wireguard/wg0.conf | cut -d '=' -f2 | tr -d ' ') -j ACCEPT
- Эта команда сделает исключение для порта Wireguard, чтобы он остался открыт
При желании оставить доступ к серверу не только по защищённой сетке, но и просто по внешнему порту - на случай необходимости подключиться с устройства, на котором не установлен Wireguard, используем эту дополнительную команду с указанием порта, который будет использоваться для SSH:
sudo iptables -A INPUT -p tcp --dport 32123 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
- Здесь после dport надо указать свой нестандартный порт управления (и запомнить его).
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Но можно и не открывать никакого дополнительного порта - чтобы исключить всякую возможность управлять сервером с неавторизованного устройства. Это хорошая мера для безопасности, однако если с подсистемой Wireguard произойдёт какой-то сбой, не исправимый перезагрузкой - то удалённый доступ к серверу может оказаться полностью нерабочим.
Рекомендую всё же оставить один "внешний" порт и потом просто закрыть его в случае следов атаки на сервер в логах fail2ban:
sudo fail2ban-client status sshd
В следующей команде используется этот же номер порта; она установит его портом для подключения к secure shell:
sudo sed -i -E 's|^(#\s*)?Port\s+\S+|Port 32123|' /etc/ssh/sshd_config
sudo systemctl reload sshd
Создаём листы блокировок:
sudo sh -c 'ipset create SSH-BANNED hash:ip hashsize 4194304 maxelem 10000000 timeout 2147483 && ipset create WG-BANNED hash:ip hashsize 4194304 maxelem 10000000 timeout 2147483 && ipset create BANNED hash:ip hashsize 4194304 maxelem 10000000 timeout 2147483'
Блокировка сканеров портов:
В течение срока блокировки, все попытки подключиться с этого адреса будут игнорироваться, даже по правильному
порту:
За десять попыток угадать порт хост попадает в бан:
Оптимизация бан-листа с помощью ipset:
После всех приготовлений, когда все люки задраены - можно начинать погружение; выполним команду, блокирующую весь внешний доступ к серверу:
Если она приведёт к тому, что на сервер не получится зайти (по новому порту), то перезагрузка отменит все изменения iptables и можно будет снова внимательно разобраться, что пошло не так.
Если же все команды введены последовательно и без ошибок - то сервер должен быть в "стелс-режиме": он больше не реагирует на внешние пинги, банит сетевые сканеры, а подключиться для управления можно только по секретному порту (или только из частной сети).
Чтобы конфигурация не слетела при выключении сервера, используем дополнительные инструменты:
Для дополнительной безопасности - откажемся от использования стандартной учётной записи (root).
имя sshadmin можно заменить на любое другое:
указываем свой пароль, желательно от 10 символов
SSH_PORT=$(grep -E "^Port\s+" /etc/ssh/sshd_config | awk '{print $2}') && sudo iptables -A INPUT -p tcp ! --dport $SSH_PORT --tcp-flags FIN,SYN,RST,ACK SYN -m recent --name PORTPROBE --set -j DROP && sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -m recent --name PORTPROBE --set -j DROP && sudo iptables -A INPUT -p tcp --tcp-flags ALL FIN -m recent --name PORTPROBE --set -j DROP && sudo iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m recent --name PORTPROBE --set -j DROP
В течение срока блокировки, все попытки подключиться с этого адреса будут игнорироваться, даже по правильному
порту:
sudo iptables -I INPUT 3 -m set --match-set BANNED src -j DROP
За десять попыток угадать порт хост попадает в бан:
sudo iptables -I INPUT 4 -m recent --name PORTPROBE --rcheck --seconds 86400 --hitcount 10 -j SET --add-set BANNED src
Оптимизация бан-листа с помощью ipset:
sudo sed -i -e '/:\[sshd\]/,/:\[/ s/:banaction = .*/banaction = ipset-only[name=SSH-BANNED]/' -e '/:\[wireguard\]/,/:\[/ s/:banaction = .*/banaction = ipset-only[name=WG-BANNED]/' /etc/fail2ban/jail.local
sudo sh -c 'printf "[Definition]\nactionban = ipset add timeout -exist\nactionunban = ipset del \n" > /etc/fail2ban/action.d/ipset-only.conf'
sudo iptables -I INPUT 3 -m set --match-set SSH-BANNED src -j DROP && sudo iptables -I INPUT 3 -m set --match-set WG-BANNED src -j DROP
После всех приготовлений, когда все люки задраены - можно начинать погружение; выполним команду, блокирующую весь внешний доступ к серверу:
sudo iptables -P INPUT DROP
Если она приведёт к тому, что на сервер не получится зайти (по новому порту), то перезагрузка отменит все изменения iptables и можно будет снова внимательно разобраться, что пошло не так.
Если же все команды введены последовательно и без ошибок - то сервер должен быть в "стелс-режиме": он больше не реагирует на внешние пинги, банит сетевые сканеры, а подключиться для управления можно только по секретному порту (или только из частной сети).
Чтобы конфигурация не слетела при выключении сервера, используем дополнительные инструменты:
sudo apt-get install iptables-persistent ipset-persistent -y
sudo bash -c 'mkdir -p /etc/systemd/system/netfilter-persistent.service.d && \printf "[Unit]\nWants=network-online.target\nAfter=network-online.target\n" \> /etc/systemd/system/netfilter-persistent.service.d/override.conf'
sudo mkdir -p /etc/iptables /etc/ipset && sudo iptables-save > /etc/iptables/rules.v4 && sudo ipset save > /etc/ipset/rules.v4
sudo vim /etc/systemd/system/ipset-save.service
[Unit]
Description=Save ipset rules before shutdown
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c "ipset save > /etc/ipset/rules.v4"
[Install]
WantedBy=shutdown.target reboot.target halt.target
vim /usr/local/bin/apply_qos.sh
#!/bin/bash
tc qdisc replace dev ens3 root cake bandwidth 100mbit diffserv4 nat
sudo chmod +x /usr/local/bin/apply_qos.sh
vim /etc/systemd/system/qos.service
[Unit]
Description=Apply QoS rules
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/apply_qos.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
sudo systemctl enable qos.service
sudo bash -c 'mkdir -p /etc/systemd/system/netfilter-persistent.service.d && \printf "[Unit]\nWants=network-online.target\nAfter=network-online.target\n" \> /etc/systemd/system/netfilter-persistent.service.d/override.conf'
Для дополнительной безопасности - откажемся от использования стандартной учётной записи (root).
имя sshadmin можно заменить на любое другое:
sudo adduser sshadmin
указываем свой пароль, желательно от 10 символов
sudo usermod -aG sudo sshadmin
echo 'sshadmin ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/sshadmin
sudo chmod 440 /etc/sudoers.d/sshadmin
sudo sed -i 's/^#\?\s*PermitRootLogin\s\+.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?\s*PasswordAuthentication\s\+.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
❤1
После успешной настройки - моментальный снимок и перезагрузка сервера, чтобы убедиться, что система устойчива:
Последняя команда - в реальном времени выводит в консоль все попытки достучаться до сервера, пока они не попали в бан (заблокированные адреса просто молча игнорируются) - получается минималистичный мониторинг охранной системы:
sudo btrfs subvolume snapshot / /snapshots/root_$(date +%Y-%m-%d_%H-%M) && sudo reboot
Последняя команда - в реальном времени выводит в консоль все попытки достучаться до сервера, пока они не попали в бан (заблокированные адреса просто молча игнорируются) - получается минималистичный мониторинг охранной системы:
clear && sudo sh -c 'touch /tmp/old_{banned,portprobe}; ipset save BANNED | awk '\''/^add BANNED /{print $3}'\'' > /tmp/old_banned; cat /proc/net/xt_recent/PORTPROBE | awk -F"[ =]" '\''{for(i=1;i<=NF;i++) if($i=="oldest_pkt:") {print $(i-5), $(i+1); break}}'\'' | tee /tmp/old_portprobe | while read ip tries; do port=$(dmesg -T | grep -m1 "SRC=$ip" | grep -oP "DPT=\K\d+"); printf "%s Port [%s] Probe Attempt №%s from %s\n" "$(date +"%F %T")" "${port:-Unknown}" "$tries" "$ip"; done; while sleep 1; do ipset save BANNED | awk '\''/^add BANNED /{print $3}'\'' | grep -xvf /tmp/old_banned | while read ip; do port=$(dmesg -T | grep -m1 "SRC=$ip" | grep -oP "DPT=\K\d+"); printf "%s Port Scanner Banned: %s\n" "$(date +"%F %T")" "$ip"; echo "$ip" >> /tmp/old_banned; done; cat /proc/net/xt_recent/PORTPROBE | awk -F"[ =]" '\''{for(i=1;i<=NF;i++) if($i=="oldest_pkt:") {print $(i-5), $(i+1); break}}'\'' | grep -xvf /tmp/old_portprobe | while read ip tries; do port=$(dmesg -T | grep -m1 "SRC=$ip" | grep -oP "DPT=\K\d+"); printf "%s Port [%s] Probe Attempt №%s from %s\n" "$(date +"%F %T")" "${port:-Unknown}" "$tries" "$ip"; echo "$ip $tries" >> /tmp/old_portprobe; done; done'
security.sh
17.1 KB
Скрипт настройки защиты сервера Linux
Скрипт предназначен для Linux с внешним IP и управлением по SSH через Интернет.
Что он делает:
• Предлагает сменить порт управления
• Предлагает отключить вход для root
• Предлагает установить новое имя сервера
• Предлагает создать нового администратора
• Применяет базовый список правил защиты, которые блокируют хосты после десяти попыток угадать порт, либо после десяти ошибок в пароле - на 24 дня.
Используемый в скрипте инструмент ipset практически не влияет на производительность, даже при огромных списках блокировок.
вставка через Putty - по правой кнопке мыши, а сохранить и выйти - esc, затем ":wq!" без кавычек.
Скрипт предназначен для Linux с внешним IP и управлением по SSH через Интернет.
Что он делает:
• Предлагает сменить порт управления
• Предлагает отключить вход для root
• Предлагает установить новое имя сервера
• Предлагает создать нового администратора
• Применяет базовый список правил защиты, которые блокируют хосты после десяти попыток угадать порт, либо после десяти ошибок в пароле - на 24 дня.
С точки зрения вероятности, десять попыток за три недели, при пароле длиной в десять символов - это достаточно надёжная оборона от любых, даже довольно крупных ботнетов, пытающихся подобрать пароль. Поэтому, для простой защиты - можно даже не заморачиваться отключением логина под root.
Используемый в скрипте инструмент ipset практически не влияет на производительность, даже при огромных списках блокировок.
vi security.sh
вставка через Putty - по правой кнопке мыши, а сохранить и выйти - esc, затем ":wq!" без кавычек.
chmod +x security.sh && ./security.sh
👍2