Какие признаки выхода из строя можно увидеть в SMART NVMe-диска
NVMe-диски имеют совершенно иной, собственный SMART, разработанный для твердотельных накопителей, а не унаследованный от жестких дисков и содержит достаточно простые и понятные показатели, а также отдельный параметр Critical Warning для отображения критических состояний.
Но, как это чаще всего бывает, диск умирает, когда ничто не предвещает беды. Вроде и SMART отличный, а диск все равно умер. Ситуация знакомая еще по жестким дискам и сразу скажем, что SMART – это не панацея, но есть определенные параметры, изменение которых может указывать на проблемы с диском.
Начнем со следующей пары:
🔹 Media and Data Integrity Errors - ошибки целостности данных и носителя – данный счетчик фиксирует случаи, когда информация из ячейки не смогла быть прочитана и восстановлена при помощи механизмов коррекции. Указывает на ошибки и износ памяти.
🔹 Error Information Log Entries - записи в журнале ошибок – это другой тип ошибок, происходящих на уровне общения диска с внешним миром, могут указывать на кривые драйвера, плохой разъем, перегрев и ошибки контроллера и не обязательно означают неисправность самого диска.
Поэтому если у вас начал расти первый показатель – это повод серьезно напрячься и задуматься о дальнейшем здоровье диска. Если растет второй – то прежде всего изучите внешние условия и режимы эксплуатации, скорее всего проблема не в самом диске, а в окружающей инфраструктуре.
Также крайне полезно контролировать еще один параметр:
🔹 Available Spare - количество запасных ячеек, в норме это значение равно 100%.
Есть еще один связанный параметр - Available Spare Threshold – который показывает при снижении запасных ячеек до какого количества диск выбросит критическую ошибку, разные производители устанавливают разные значения: от 1% до 10%.
Если же у нас вместе с ростом Media and Data Integrity Errors наблюдается падение Available Spare – то можно говорить о том, что диск посыпался и его следует заменить. Не ждите появления критической ошибки, если процесс пошел, то в какой-то момент он может начать развиваться лавинообразно и до предупреждения диск может не дожить.
В ответственных системах следует поставить эти два показателя на мониторинг.
NVMe-диски имеют совершенно иной, собственный SMART, разработанный для твердотельных накопителей, а не унаследованный от жестких дисков и содержит достаточно простые и понятные показатели, а также отдельный параметр Critical Warning для отображения критических состояний.
Но, как это чаще всего бывает, диск умирает, когда ничто не предвещает беды. Вроде и SMART отличный, а диск все равно умер. Ситуация знакомая еще по жестким дискам и сразу скажем, что SMART – это не панацея, но есть определенные параметры, изменение которых может указывать на проблемы с диском.
Начнем со следующей пары:
🔹 Media and Data Integrity Errors - ошибки целостности данных и носителя – данный счетчик фиксирует случаи, когда информация из ячейки не смогла быть прочитана и восстановлена при помощи механизмов коррекции. Указывает на ошибки и износ памяти.
🔹 Error Information Log Entries - записи в журнале ошибок – это другой тип ошибок, происходящих на уровне общения диска с внешним миром, могут указывать на кривые драйвера, плохой разъем, перегрев и ошибки контроллера и не обязательно означают неисправность самого диска.
Поэтому если у вас начал расти первый показатель – это повод серьезно напрячься и задуматься о дальнейшем здоровье диска. Если растет второй – то прежде всего изучите внешние условия и режимы эксплуатации, скорее всего проблема не в самом диске, а в окружающей инфраструктуре.
Также крайне полезно контролировать еще один параметр:
🔹 Available Spare - количество запасных ячеек, в норме это значение равно 100%.
Есть еще один связанный параметр - Available Spare Threshold – который показывает при снижении запасных ячеек до какого количества диск выбросит критическую ошибку, разные производители устанавливают разные значения: от 1% до 10%.
Если же у нас вместе с ростом Media and Data Integrity Errors наблюдается падение Available Spare – то можно говорить о том, что диск посыпался и его следует заменить. Не ждите появления критической ошибки, если процесс пошел, то в какой-то момент он может начать развиваться лавинообразно и до предупреждения диск может не дожить.
В ответственных системах следует поставить эти два показателя на мониторинг.
👍31👌14❤1👨💻1
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍25❤3🤮2👌1
Zabbix – а куда делся мой ресурс SSD?
Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно…
Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется.
Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию.
А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ.
Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца.
👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.
Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно…
Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется.
Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию.
А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ.
Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца.
👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.
👍27🤡4🔥1
Почему CoW увеличивает WAF? Часть 1
Использование файловых систем с копированием при записи (Copy-on-Write / CoW), таких как ZFS и Btrfs, оказывает специфическое влияние на коэффициент усиления записи (WAF — Write Amplification Factor) на SSD. Из-за своей архитектуры они могут как лавинообразно увеличивать WAF, так и уменьшать его.
Но критичным является именно увеличение WAF, которое при непонимании происходящих процессов может привести к самым неприятным последствиям.
Основная причина усиления записи лежит в том, что файловые системы с CoW никогда не изменяют существующие блоки. Новые данные всегда пишутся на свободное место, а затем изменяются указывающие на них метаданные.
Даже при изменении одного байта запускается следующая цепочка событий:
▫️Записывается новый блок данных
▫️ Изменяется указывающий на него блок метаданных
▫️ Изменяется родительский блок метаданных, и так далее до корневого узла
Стоит отметить, что CoW системы оперируют достаточно крупными размерами блоков, скажем в ZFS вполне нормально увидеть блок в 128 КБ.
Таким образом активно пишущая база данных, скажем MySQL и оперирующая блоками по 4 КБ генерирует сотни килобайт записи на одну операцию, критически увеличивая объем реальной записи во флеш. Далее его умножит еще и сам твердотельный накопитель за счет алгоритмов уборки мусора.
При заполнении диска более чем на 80-85% (а при активной мелкоблочной записи и при меньших числах) происходит очередное лавинообразное увеличение WAF, потому что контроллер, не имея свободных ячеек для записи пытается на лету очищать текущие.
Таким образом худшие сценарии для CoW файловых систем и SSD это:
🔹 Базы данных с интенсивной случайной записью (OLTP): PostgreSQL, MySQL/MariaDB, Oracle. Постоянные мелкие транзакции (обычно по 8 или 16 КБ) и частые вызовы fsync вызывают колоссальный WAF.
🔹 Образы виртуальных машин: Запуск баз данных или активных ОС внутри raw-образов или qcow2 поверх CoW. Накладываются две ФС друг на друга, что умножает WAF.
🔹 Заполнение пула > 80-85%: В CoW-системах при дефиците места механизмы аллокации начинают тратить огромные ресурсы на поиск свободных блоков, что перегружает и ФС, и контроллер SSD.
🔹 Использование потребительских (Consumer) SSD: Бюджетные диски без DRAM-буфера и с агрессивным SLC-кэшированием при высоком WAF быстро теряют производительность и выходят из строя.
Чтобы минимизировать это явление можно использовать:
🔹 Включение встроенного сжатия (LZ4 / ZSTD). Если данные хорошо сжимаются, физический объем данных, отправляемых на SSD, уменьшается (например, в 2 раза). Это пропорционально снижает WAF. Даже с учетом накладных расходов на метаданные, итоговый износ диска часто оказывается ниже, чем на ext4 без сжатия.
🔹 Выравнивание блоков (Recordsize / Volblocksize). Размер блока ФС должен строго соответствовать размеру блока приложения. Если СУБД оперирует блоками по 8 KБ, то на ZFS также ставьте recordsize=8k
🔹 Ограничение синхронной записи. Если потеря последних 5 секунд данных при сбое питания не критична, можно установить sync=disabled (в ZFS), что уберет двойную запись через ZIL.
Последнее требует отдельного пояснения, так как синхронная запись не должна быть потеряна, ZFS использует ZIL (ZFS Intent Log), куда синхронные записи (fsync) пишутся немедленно. Это означает, что одни и те же данные сначала пишутся в лог (для отказоустойчивости), а затем, спустя короткое время, сбрасываются на диск.
Отказ от синхронной записи также позволяет более эффективно использовать:
🔹 Агрегирование записи в оперативную память. ZFS собирает все асинхронные записи в транзакции (Transaction Groups) в RAM и сбрасывает их на диск раз в несколько секунд большими линейными пачками.
На этом сегодня закончим, но на самом деле это только начало, в следующих публикациях мы разберем особенности, связанные с использованием виртуальных машин и снапшотов, которые тоже способны преподнести множество неприятных сюрпризов.
Использование файловых систем с копированием при записи (Copy-on-Write / CoW), таких как ZFS и Btrfs, оказывает специфическое влияние на коэффициент усиления записи (WAF — Write Amplification Factor) на SSD. Из-за своей архитектуры они могут как лавинообразно увеличивать WAF, так и уменьшать его.
Но критичным является именно увеличение WAF, которое при непонимании происходящих процессов может привести к самым неприятным последствиям.
Основная причина усиления записи лежит в том, что файловые системы с CoW никогда не изменяют существующие блоки. Новые данные всегда пишутся на свободное место, а затем изменяются указывающие на них метаданные.
Даже при изменении одного байта запускается следующая цепочка событий:
▫️Записывается новый блок данных
▫️ Изменяется указывающий на него блок метаданных
▫️ Изменяется родительский блок метаданных, и так далее до корневого узла
Стоит отметить, что CoW системы оперируют достаточно крупными размерами блоков, скажем в ZFS вполне нормально увидеть блок в 128 КБ.
Таким образом активно пишущая база данных, скажем MySQL и оперирующая блоками по 4 КБ генерирует сотни килобайт записи на одну операцию, критически увеличивая объем реальной записи во флеш. Далее его умножит еще и сам твердотельный накопитель за счет алгоритмов уборки мусора.
При заполнении диска более чем на 80-85% (а при активной мелкоблочной записи и при меньших числах) происходит очередное лавинообразное увеличение WAF, потому что контроллер, не имея свободных ячеек для записи пытается на лету очищать текущие.
Таким образом худшие сценарии для CoW файловых систем и SSD это:
🔹 Базы данных с интенсивной случайной записью (OLTP): PostgreSQL, MySQL/MariaDB, Oracle. Постоянные мелкие транзакции (обычно по 8 или 16 КБ) и частые вызовы fsync вызывают колоссальный WAF.
🔹 Образы виртуальных машин: Запуск баз данных или активных ОС внутри raw-образов или qcow2 поверх CoW. Накладываются две ФС друг на друга, что умножает WAF.
🔹 Заполнение пула > 80-85%: В CoW-системах при дефиците места механизмы аллокации начинают тратить огромные ресурсы на поиск свободных блоков, что перегружает и ФС, и контроллер SSD.
🔹 Использование потребительских (Consumer) SSD: Бюджетные диски без DRAM-буфера и с агрессивным SLC-кэшированием при высоком WAF быстро теряют производительность и выходят из строя.
Чтобы минимизировать это явление можно использовать:
🔹 Включение встроенного сжатия (LZ4 / ZSTD). Если данные хорошо сжимаются, физический объем данных, отправляемых на SSD, уменьшается (например, в 2 раза). Это пропорционально снижает WAF. Даже с учетом накладных расходов на метаданные, итоговый износ диска часто оказывается ниже, чем на ext4 без сжатия.
🔹 Выравнивание блоков (Recordsize / Volblocksize). Размер блока ФС должен строго соответствовать размеру блока приложения. Если СУБД оперирует блоками по 8 KБ, то на ZFS также ставьте recordsize=8k
🔹 Ограничение синхронной записи. Если потеря последних 5 секунд данных при сбое питания не критична, можно установить sync=disabled (в ZFS), что уберет двойную запись через ZIL.
Последнее требует отдельного пояснения, так как синхронная запись не должна быть потеряна, ZFS использует ZIL (ZFS Intent Log), куда синхронные записи (fsync) пишутся немедленно. Это означает, что одни и те же данные сначала пишутся в лог (для отказоустойчивости), а затем, спустя короткое время, сбрасываются на диск.
Отказ от синхронной записи также позволяет более эффективно использовать:
🔹 Агрегирование записи в оперативную память. ZFS собирает все асинхронные записи в транзакции (Transaction Groups) в RAM и сбрасывает их на диск раз в несколько секунд большими линейными пачками.
На этом сегодня закончим, но на самом деле это только начало, в следующих публикациях мы разберем особенности, связанные с использованием виртуальных машин и снапшотов, которые тоже способны преподнести множество неприятных сюрпризов.
3👍39❤3🤔1
Как централизованно бекапить Mikrotik и не только их?
Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
О важности регулярного копирования конфигурации сетевого оборудования мы говорить не будем, это очевидно. При этом резервное копирование должно быть системным и централизованным, с единой точкой контроля и управления.
Также немаловажно не только делать резервные копии конфигурации сетевых устройств, но и иметь возможность контролировать изменения в них. Это способно сильно помочь при поиске неисправностей или при расследовании инцидентов.
Мы предлагаем установить и использовать для этой цели Oxidized - простую систему управления конфигурациями с открытым исходным кодом.
Oxidized - это универсальное решение, поддерживающее более 130 типов устройств, поэтому вам достаточно установить и настроить его один раз и использовать затем без оглядки на применяемое оборудование. Это значительно удобнее, чем решения, предназначенные для оборудования какого-либо отдельного производителя.
✅ Читать далее: https://interface31.ru/post/ustanavlivaem-i-nastraivaem-sistemu-upravleniya-konfiguraciyami-setevogo-oborudovaniya-oxidized/
Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
О важности регулярного копирования конфигурации сетевого оборудования мы говорить не будем, это очевидно. При этом резервное копирование должно быть системным и централизованным, с единой точкой контроля и управления.
Также немаловажно не только делать резервные копии конфигурации сетевых устройств, но и иметь возможность контролировать изменения в них. Это способно сильно помочь при поиске неисправностей или при расследовании инцидентов.
Мы предлагаем установить и использовать для этой цели Oxidized - простую систему управления конфигурациями с открытым исходным кодом.
Oxidized - это универсальное решение, поддерживающее более 130 типов устройств, поэтому вам достаточно установить и настроить его один раз и использовать затем без оглядки на применяемое оборудование. Это значительно удобнее, чем решения, предназначенные для оборудования какого-либо отдельного производителя.
✅ Читать далее: https://interface31.ru/post/ustanavlivaem-i-nastraivaem-sistemu-upravleniya-konfiguraciyami-setevogo-oborudovaniya-oxidized/
👍15🤝2🥱1
Bottles - как Wine, только лучше
В одной из наших прошлых публикаций мы подробно разобрали установку и работу с WineHQ, который позволяет запускать программное обеспечение для Windows в среде Linux. Но у него есть существенный недостаток - слишком много ручной работы. Вам самим нужно каждый раз настраивать окружение префикса, устанавливать библиотеки и зависимости.
Поэтому, если вы хотите просто работать с Windows-программами, обратите внимание на Bottles - графическую оболочку для управления вашим Wine-окружением.
Как мы помним, работа Wine строится вокруг экземпляров виртуального окружения - префиксов. В Bottles решили облегчить этот процесс и сделать его максимально автоматизированным. Понятие "бутылки" в Bottles соответствует отдельному префиксу Wine и сделан основной акцент на идее одно приложение - одна "бутылка".
Но Bottles это не просто графический менеджер префиксов, каждая "бутылка" представляет предварительно настроенное окружение с базовым набором библиотек и зависимостей, которые удобно управляются из единого графического интерфейса и вам больше не нужен Winetricks.
Таким образом Bottles берет на себя все то, что вы делали в Wine руками и позволяет сосредоточиться непосредственно на запуске Windows-программ, а не на подготовке среды.
✅ Читать далее: https://interface31.ru/post/bottles-kak-wine-tolko-luchshe/
В одной из наших прошлых публикаций мы подробно разобрали установку и работу с WineHQ, который позволяет запускать программное обеспечение для Windows в среде Linux. Но у него есть существенный недостаток - слишком много ручной работы. Вам самим нужно каждый раз настраивать окружение префикса, устанавливать библиотеки и зависимости.
Поэтому, если вы хотите просто работать с Windows-программами, обратите внимание на Bottles - графическую оболочку для управления вашим Wine-окружением.
Как мы помним, работа Wine строится вокруг экземпляров виртуального окружения - префиксов. В Bottles решили облегчить этот процесс и сделать его максимально автоматизированным. Понятие "бутылки" в Bottles соответствует отдельному префиксу Wine и сделан основной акцент на идее одно приложение - одна "бутылка".
Но Bottles это не просто графический менеджер префиксов, каждая "бутылка" представляет предварительно настроенное окружение с базовым набором библиотек и зависимостей, которые удобно управляются из единого графического интерфейса и вам больше не нужен Winetricks.
Таким образом Bottles берет на себя все то, что вы делали в Wine руками и позволяет сосредоточиться непосредственно на запуске Windows-программ, а не на подготовке среды.
✅ Читать далее: https://interface31.ru/post/bottles-kak-wine-tolko-luchshe/
👍24
Нам 17 лет!
В июле этого года нашему проекту исполняется 17 лет, для технического сайта это солидный возраст, а для персонального проекта – тем более. Многие из тех, с кем я начинал и на кого ориентировался давно закрыли и забросили свои детища.
И их прекрасно можно понять. Энтузиазм – дело такое, надолго его не хватает, а реальность никуда не делась и диктует свои условия. А информационный проект – это работа, местами рутинная, причем работа постоянная.
Но проект – это не просто контент, это еще и позиционирование как по темам, так и по аудитории. Нужно понимать не только о чем ты пишешь, но и для кого, а также – зачем. Найти основные темы, отказаться от второстепенных.
При этом не забывать держать руку на пульсе, технологии развиваются быстро, немного проспал – и ты уже на обочине прогресса и то, о чем ты пишешь интересно только еще парочке таких же динозавров.
Кроме технологий меняются и способы общения с аудиторией. Пережили свой расцвет и ушли куда-то в туман форумы, а живое общение с аудиторией сместилось из комментариев и соцсетей в мессенджеры.
Менялся сам веб и представление о том, как должен выглядеть современный сайт. Мы менялись вместе с ним. А недавно закончили одно из самых масштабных преобразований за всю историю – полностью сменили движок и архитектуру проекта.
Сегодня перед нами стоят новые вызовы – искусственный интеллект, который не просто ищет сайты, но и читает их вместо пользователя отдавая тому готовую выжимку, что, конечно, деморализует и демотивирует многих авторов.
Но таков современный мир и нужно либо меняться вместе с ним или уходить на обочину и давать дорогу молодым. Закон эволюции – выживает тот, кто лучше всего умеет приспосабливаться.
Потому что все равно сайт, несмотря на обилие различных других форматов подачи информации все равно является самым удобным как для автора, так и для читателя. Поэтому будем двигаться дальше, планы уже есть.
А пока просто посмотрим на скриншоты и вспомним как все это было.
В июле этого года нашему проекту исполняется 17 лет, для технического сайта это солидный возраст, а для персонального проекта – тем более. Многие из тех, с кем я начинал и на кого ориентировался давно закрыли и забросили свои детища.
И их прекрасно можно понять. Энтузиазм – дело такое, надолго его не хватает, а реальность никуда не делась и диктует свои условия. А информационный проект – это работа, местами рутинная, причем работа постоянная.
Но проект – это не просто контент, это еще и позиционирование как по темам, так и по аудитории. Нужно понимать не только о чем ты пишешь, но и для кого, а также – зачем. Найти основные темы, отказаться от второстепенных.
При этом не забывать держать руку на пульсе, технологии развиваются быстро, немного проспал – и ты уже на обочине прогресса и то, о чем ты пишешь интересно только еще парочке таких же динозавров.
Кроме технологий меняются и способы общения с аудиторией. Пережили свой расцвет и ушли куда-то в туман форумы, а живое общение с аудиторией сместилось из комментариев и соцсетей в мессенджеры.
Менялся сам веб и представление о том, как должен выглядеть современный сайт. Мы менялись вместе с ним. А недавно закончили одно из самых масштабных преобразований за всю историю – полностью сменили движок и архитектуру проекта.
Сегодня перед нами стоят новые вызовы – искусственный интеллект, который не просто ищет сайты, но и читает их вместо пользователя отдавая тому готовую выжимку, что, конечно, деморализует и демотивирует многих авторов.
Но таков современный мир и нужно либо меняться вместе с ним или уходить на обочину и давать дорогу молодым. Закон эволюции – выживает тот, кто лучше всего умеет приспосабливаться.
Потому что все равно сайт, несмотря на обилие различных других форматов подачи информации все равно является самым удобным как для автора, так и для читателя. Поэтому будем двигаться дальше, планы уже есть.
А пока просто посмотрим на скриншоты и вспомним как все это было.
6👍95🔥24👏7❤5🤝5
Как я искал вчерашний день
Третьего дня заглянул я в список аренды IP-адресов своего роутера и сразу глаз зацепился за некоторую неправильность – в списке присутствовало сразу два устройства с классом android-dhcp-14.
Что здесь неправильного? А то, что я точно знаю, что Android 14 в домашней сети есть на единственном устройстве – телефоне сына. А если появился второй, то значит в сеть подключилось некое неопознанное устройство.
Ситуация сама по себе непонятная и неприятная, особенно если ты привык считать, что полностью контролируешь свою сеть.
Кто же это может быть? Может сын что принес или установил какой эмулятор? Спросил. Нет, ничего такого он не делал, он вообще последнее время RGB-тюнингом нового ПК занят.
МAC? А что MAC? Мобильные устройства давно генерируют его случайным образом при подключении к новой сети. Ну даже и выяснишь ты, что это какой-нибудь Mediatek, дальше что?
Будем изучать, начнем с сетевой активности. Сетевая активность ничем не отличается от телефона в состоянии покоя. Никуда особо не лазит, трафик не генерирует, обращается в основном к сервисам гугла и погоде.
Точно телефон. Но чей? Дальнейший анализ показал, что устройство подключено к точке в центре квартиры. Тут еще интереснее. Ладно бы к той, что на кухне, там от подъезда за нее зацепиться можно, но эта…
Тем более что мощность передатчиков я прикрутил, чтобы не светили далеко. Соседи? Да вроде не похожи они на хакеров…
Ладно, будем смотреть дальше. В мое отсутствие устройство активности не проявляло, вечером тоже ушло с радаров. Но утром и днем снова появилось. Причем активное, постоянно продляющее аренду.
Снова ушел – и оно пропало, вернулся – появилось. Что за ерунда???
Снял логи с точек доступа и выяснил, что устройство эпизодически перемещается между точками и время как-то подозрительно совпадает…
Так, а где был в это время мой собственный телефон? Там же где и это устройство.
Бинго! Это же новые умные часы Samsung, которые умеют в Wi-Fi и внутри которых новая WearOS на базе Android 14. Захожу в часы – MAC и IP адрес совпадают. А так как часы умные, то в целях энергосбережения они отключают Wi-Fi, когда он не нужен.
Вечером часы снова пропадают с радаров. Прошу жену прислать чего-нибудь в мессенджер. Тишина, хотя сообщение на часы пришло. А если с фоткой? Ага, вот и Wi-Fi включился. Правильно, чего насиловать медленный Bluetooth, когда можно быстро получить все по Wi-Fi.
Поэтому днем, пока активно приходят сообщения и ты смотришь их на часах – они активны и светятся в сети, а вечером выключают сеть и отдыхают.
Такая вот история. Мораль из этой истории проста: принесли и подключили новое устройство – посмотрите какой у него MAC, какой адрес оно получило, как представилось DHCP-серверу и как вообще отображается в сетевом окружении, мониторинге и т.д.
Это добавит спокойствия и уверенности, а также избавит от подобных поисков вчерашнего дня.
Третьего дня заглянул я в список аренды IP-адресов своего роутера и сразу глаз зацепился за некоторую неправильность – в списке присутствовало сразу два устройства с классом android-dhcp-14.
Что здесь неправильного? А то, что я точно знаю, что Android 14 в домашней сети есть на единственном устройстве – телефоне сына. А если появился второй, то значит в сеть подключилось некое неопознанное устройство.
Ситуация сама по себе непонятная и неприятная, особенно если ты привык считать, что полностью контролируешь свою сеть.
Кто же это может быть? Может сын что принес или установил какой эмулятор? Спросил. Нет, ничего такого он не делал, он вообще последнее время RGB-тюнингом нового ПК занят.
МAC? А что MAC? Мобильные устройства давно генерируют его случайным образом при подключении к новой сети. Ну даже и выяснишь ты, что это какой-нибудь Mediatek, дальше что?
Будем изучать, начнем с сетевой активности. Сетевая активность ничем не отличается от телефона в состоянии покоя. Никуда особо не лазит, трафик не генерирует, обращается в основном к сервисам гугла и погоде.
Точно телефон. Но чей? Дальнейший анализ показал, что устройство подключено к точке в центре квартиры. Тут еще интереснее. Ладно бы к той, что на кухне, там от подъезда за нее зацепиться можно, но эта…
Тем более что мощность передатчиков я прикрутил, чтобы не светили далеко. Соседи? Да вроде не похожи они на хакеров…
Ладно, будем смотреть дальше. В мое отсутствие устройство активности не проявляло, вечером тоже ушло с радаров. Но утром и днем снова появилось. Причем активное, постоянно продляющее аренду.
Снова ушел – и оно пропало, вернулся – появилось. Что за ерунда???
Снял логи с точек доступа и выяснил, что устройство эпизодически перемещается между точками и время как-то подозрительно совпадает…
Так, а где был в это время мой собственный телефон? Там же где и это устройство.
Бинго! Это же новые умные часы Samsung, которые умеют в Wi-Fi и внутри которых новая WearOS на базе Android 14. Захожу в часы – MAC и IP адрес совпадают. А так как часы умные, то в целях энергосбережения они отключают Wi-Fi, когда он не нужен.
Вечером часы снова пропадают с радаров. Прошу жену прислать чего-нибудь в мессенджер. Тишина, хотя сообщение на часы пришло. А если с фоткой? Ага, вот и Wi-Fi включился. Правильно, чего насиловать медленный Bluetooth, когда можно быстро получить все по Wi-Fi.
Поэтому днем, пока активно приходят сообщения и ты смотришь их на часах – они активны и светятся в сети, а вечером выключают сеть и отдыхают.
Такая вот история. Мораль из этой истории проста: принесли и подключили новое устройство – посмотрите какой у него MAC, какой адрес оно получило, как представилось DHCP-серверу и как вообще отображается в сетевом окружении, мониторинге и т.д.
Это добавит спокойствия и уверенности, а также избавит от подобных поисков вчерашнего дня.
👍28👀7🔥4🥱3👏2
Используем режим ARP reply-only для повышения безопасности сети на оборудовании Mikrotik
Безопасность небольших сетей - больная тема для большинства администраторов, особенно если это сети небольших филиалов, торговых точек и т.д. и т.п.
Обычно ситуация усугубляется ограниченными бюджетами на оборудование и отсутствием самого понятия информационной безопасности у пользователей таких сетей.
Вполне распространённой практикой является свободный доступ к сетевому оборудованию и гуляющий по рукам пароль Wi-Fi. Что можно сделать в такой ситуации?
Довольно многое, если у вас на руках оборудование Mikrotik, а как - расскажем в данной статье:
https://interface31.ru/post/ispol-zuem-rezhim-arp-reply-only-dlya-povysheniya-bezopasnosti-seti-na-oborudovanii-mikrotik/
Безопасность небольших сетей - больная тема для большинства администраторов, особенно если это сети небольших филиалов, торговых точек и т.д. и т.п.
Обычно ситуация усугубляется ограниченными бюджетами на оборудование и отсутствием самого понятия информационной безопасности у пользователей таких сетей.
Вполне распространённой практикой является свободный доступ к сетевому оборудованию и гуляющий по рукам пароль Wi-Fi. Что можно сделать в такой ситуации?
Довольно многое, если у вас на руках оборудование Mikrotik, а как - расскажем в данной статье:
https://interface31.ru/post/ispol-zuem-rezhim-arp-reply-only-dlya-povysheniya-bezopasnosti-seti-na-oborudovanii-mikrotik/
1👍17❤1
Проходной двор
Сегодня, в качестве спонсорской помощи одному пожилому родственнику делал апгрейд сильно тормозящего ноутбука.
Ситуация классическая, ноут еще не старый, на Intel N-серии, но с жестким диском в базовой комплектации, что означает – привет вечные тормоза. На плате обнаружился M.2 и я решил туда поставить 256 ГБ SSD, который раньше стоял в ноутбуке жены.
Ноутбук был примерно на такой-же аппаратной платформе и система завелась без переустановки. А после у меня со стуком упала на пол челюсть и задергался глаз: автоматически подключился корпоративный VPN и следом запустилось корпоративное приложение…
Ну и что тут такого? А то, что на этом месте работы жена уже более года не работает. И это не какой-то Торговый дом Рога и Копыта, а банк, не самый крупный, но и далеко не последней величины.
Но, как показывает практика, в большинстве организаций, вне зависимости от размеров и количества ИТ и ИБ персонала рано или поздно устанавливается режим проходного двора.
В отсутствие реальных инцидентов, связанных с безопасностью, вся система приходит в расслабленное состояние.
Начинается с малого – послабления в политике безопасности для привилегированных пользователей.
Ну тут оно понятно, VIPы очень не любят напрягаться и приходят в дурное расположение духа забыв пароль, поэтому им надо что-то попроще. А там пошло-поехало.
Ну и тревожить небожителей тоже лишний раз не хочется, поэтому политика смены паролей тоже не про них.
А дальше приехали партнеры, пошли в баню, там, естественно Wi-Fi и пароль на него вполне может совпадать с паролем от учетной записи в домене.
И вот у нас режим проходного двора во всей своей красе.
На некоторых объектах я сталкивался с ситуацией, когда в информационной системе годами присутствовала учетка типа test с простым паролем вроде 1q2w3e, которую мы использовали на стадии настройки и тестирования системы (и правами доменного администратора).
В других местах установленный нами тестовый пароль становился паролем по умолчанию. Местами доходило до смешного. Заказчик забыл пароль суперпользователя СУБД:
- Попробуйте что ли PaSSword-1
- Спасибо, подошло!!!
И, самое интересное, как-то живут годами, причем выставляя подобные сервисы за периметр.
Все что тут остается – это вспомнить про Неуловимого Джо, которого никто не ловит, потому что он никому не нужен.
Сегодня, в качестве спонсорской помощи одному пожилому родственнику делал апгрейд сильно тормозящего ноутбука.
Ситуация классическая, ноут еще не старый, на Intel N-серии, но с жестким диском в базовой комплектации, что означает – привет вечные тормоза. На плате обнаружился M.2 и я решил туда поставить 256 ГБ SSD, который раньше стоял в ноутбуке жены.
Ноутбук был примерно на такой-же аппаратной платформе и система завелась без переустановки. А после у меня со стуком упала на пол челюсть и задергался глаз: автоматически подключился корпоративный VPN и следом запустилось корпоративное приложение…
Ну и что тут такого? А то, что на этом месте работы жена уже более года не работает. И это не какой-то Торговый дом Рога и Копыта, а банк, не самый крупный, но и далеко не последней величины.
Но, как показывает практика, в большинстве организаций, вне зависимости от размеров и количества ИТ и ИБ персонала рано или поздно устанавливается режим проходного двора.
В отсутствие реальных инцидентов, связанных с безопасностью, вся система приходит в расслабленное состояние.
Начинается с малого – послабления в политике безопасности для привилегированных пользователей.
Ну тут оно понятно, VIPы очень не любят напрягаться и приходят в дурное расположение духа забыв пароль, поэтому им надо что-то попроще. А там пошло-поехало.
Ну и тревожить небожителей тоже лишний раз не хочется, поэтому политика смены паролей тоже не про них.
А дальше приехали партнеры, пошли в баню, там, естественно Wi-Fi и пароль на него вполне может совпадать с паролем от учетной записи в домене.
И вот у нас режим проходного двора во всей своей красе.
На некоторых объектах я сталкивался с ситуацией, когда в информационной системе годами присутствовала учетка типа test с простым паролем вроде 1q2w3e, которую мы использовали на стадии настройки и тестирования системы (и правами доменного администратора).
В других местах установленный нами тестовый пароль становился паролем по умолчанию. Местами доходило до смешного. Заказчик забыл пароль суперпользователя СУБД:
- Попробуйте что ли PaSSword-1
- Спасибо, подошло!!!
И, самое интересное, как-то живут годами, причем выставляя подобные сервисы за периметр.
Все что тут остается – это вспомнить про Неуловимого Джо, которого никто не ловит, потому что он никому не нужен.
👍30😁15❤2👨💻1🤝1
Sniffnet – простой кроссплатформенный монитор трафика
Бывает иногда интересно посмотреть на сетевую жизнь компьютера, чтобы быстро, просто и наглядно. Кто, куда, зачем и почему.
Можно поставить Wireshark, но это как из пушки по воробьям, да и работа с ним требует определенных знаний и навыков. В этом случае стоит посмотреть на Sniffnet – простую кроссплатформенную утилиту, которая быстро покажет весь расклад в предельно простой и наглядной форме.
Утилита доступна для Windows, Linux и Mac, в т.ч. и для ARM архитектуры. Ставится быстро и просто. Есть перевод на русский язык.
Возможности не слишком богатые, но все что нужно – есть, в том числе и подробная информация по соединениям. Но, напоминаем, это именно монитор, а не анализатор пакетов.
Польза от такого софта не только в выявлении тайной сетевой жизни хоста, но и более практическая, когда вам нужно точно узнать куда ходит то или иное приложение, либо какие ресурсы использует сайт, сами знаете для составления каких списков.
✅ Страница проекта: https://github.com/GyulyVGC/sniffnet
Бывает иногда интересно посмотреть на сетевую жизнь компьютера, чтобы быстро, просто и наглядно. Кто, куда, зачем и почему.
Можно поставить Wireshark, но это как из пушки по воробьям, да и работа с ним требует определенных знаний и навыков. В этом случае стоит посмотреть на Sniffnet – простую кроссплатформенную утилиту, которая быстро покажет весь расклад в предельно простой и наглядной форме.
Утилита доступна для Windows, Linux и Mac, в т.ч. и для ARM архитектуры. Ставится быстро и просто. Есть перевод на русский язык.
Возможности не слишком богатые, но все что нужно – есть, в том числе и подробная информация по соединениям. Но, напоминаем, это именно монитор, а не анализатор пакетов.
Польза от такого софта не только в выявлении тайной сетевой жизни хоста, но и более практическая, когда вам нужно точно узнать куда ходит то или иное приложение, либо какие ресурсы использует сайт, сами знаете для составления каких списков.
✅ Страница проекта: https://github.com/GyulyVGC/sniffnet
2👍20🤝3🤷♂1
Защита Mikrotik от брутфорса через SSH
Атаки на SSH – пожалуй самый распространенный тип атак, стоит только выставить 22 порт наружу как начнутся попытки подбора пароля.
Хороший вариант – настроить аутентификацию по ключу и запретить вход с логином и паролем, но у RouterOS нет такой возможности.
Поэтому будем выкручиваться другими методами, а именно считать пакеты со статусом NEW в течении некоторого небольшого времени, скажем 5 минут.
Здесь мы исходим из того, что легальный пользователь пришлет всего один такой пакет. Далее соединение будет установлено и пакеты пойдут со статусом ESTABLISHED. Ну максимум два, если пользователь неверно указал логин или не переключил раскладку (вход с паролем).
Поэтому оставим три легальных попытки, а каждый, кто будет превышать это количество отправится в бан.
Ловить пакеты мы будем в mangle – PREROUTING и отправлять их в отдельную цепочку FB-SSH, где и будем выполнять все проверки.
Адрес источника каждого нового пакета на 22 порт мы помещаем в список FB-SSH-1 на пять минут. Если пришел повторный новый пакет, то отправляем адрес уже в список FB-SSH-2 на 15 минут.
Третий новый пакет отправится в список FB-SSH-3 уже на час и теперь если в течении часа последует еще одна попытка подключения – адрес источник улетит в бан на сутки.
Такая схема с увеличением таймаутов позволяет бороться с умными ботами, которые не долбятся сразу, а выдерживают некие паузы, чтобы не попасть в блокировку.
Все это в терминале:
Банить будем в raw, на самом подлете:
Данный способ не обладает изяществом, но позволяет эффективно блокировать попытки подбора паролей к SSH, это сразу становится видно по сообщениям лога, точнее по их отсутствию.
Но будьте осторожны, чтобы самому не попасть под собственный фильтр и оставляйте запасные пути, например, через VPN.
Атаки на SSH – пожалуй самый распространенный тип атак, стоит только выставить 22 порт наружу как начнутся попытки подбора пароля.
Хороший вариант – настроить аутентификацию по ключу и запретить вход с логином и паролем, но у RouterOS нет такой возможности.
Поэтому будем выкручиваться другими методами, а именно считать пакеты со статусом NEW в течении некоторого небольшого времени, скажем 5 минут.
Здесь мы исходим из того, что легальный пользователь пришлет всего один такой пакет. Далее соединение будет установлено и пакеты пойдут со статусом ESTABLISHED. Ну максимум два, если пользователь неверно указал логин или не переключил раскладку (вход с паролем).
Поэтому оставим три легальных попытки, а каждый, кто будет превышать это количество отправится в бан.
Ловить пакеты мы будем в mangle – PREROUTING и отправлять их в отдельную цепочку FB-SSH, где и будем выполнять все проверки.
Адрес источника каждого нового пакета на 22 порт мы помещаем в список FB-SSH-1 на пять минут. Если пришел повторный новый пакет, то отправляем адрес уже в список FB-SSH-2 на 15 минут.
Третий новый пакет отправится в список FB-SSH-3 уже на час и теперь если в течении часа последует еще одна попытка подключения – адрес источник улетит в бан на сутки.
Такая схема с увеличением таймаутов позволяет бороться с умными ботами, которые не долбятся сразу, а выдерживают некие паузы, чтобы не попасть в блокировку.
Все это в терминале:
firewall mangle
add action=jump chain=prerouting connection-state=new dst-port=22 in-interface=ether1 jump-target=FB-SSH protocol=tcp
add action=add-src-to-address-list address-list=FB-SSH-BAN address-list-timeout=1d chain=FB-SSH connection-state=new dst-port=22 protocol=tcp src-address-list=FB-SSH-3
add action=add-src-to-address-list address-list=FB-SSH-3 address-list-timeout=1h chain=FB-SSH connection-state=new dst-port=22 protocol=tcp src-address-list=FB-SSH-2
add action=add-src-to-address-list address-list=FB-SSH-2 address-list-timeout=15m chain=FB-SSH connection-state=new dst-port=22 protocol=tcp src-address-list=FB-SSH-1
add action=add-src-to-address-list address-list=FB-SSH-1 address-list-timeout=5m chain=FB-SSH connection-state=new dst-port=22 protocol=tcp
Банить будем в raw, на самом подлете:
firewall raw
add action=drop chain=prerouting src-address-list=FB-SSH-BAN
Данный способ не обладает изяществом, но позволяет эффективно блокировать попытки подбора паролей к SSH, это сразу становится видно по сообщениям лога, точнее по их отсутствию.
Но будьте осторожны, чтобы самому не попасть под собственный фильтр и оставляйте запасные пути, например, через VPN.
👍30❤5😱1🤝1
А если просто поговорить?
Все мы привыкли к определенному формату общения с нейросетями: роль → задача → контекст → формат и т.д. Да, в большинстве случаев это оправдано, так как позволяет направить ИИ по нужному пути и заставить его действовать нужным вам образом, в рамках установленных вами ограничений.
Но это хорошо тогда, когда вы четко знаете, что вам нужно сделать и какой результат получить. Но работа системного администратора зачастую далека от этого и подбрасывает задачи со множеством неизвестных переменных.
Также у каждого из нас есть устоявшийся опыт, который тоже оказывает сильное влияние на восприятие IT-систем и принимаемые нами решения. А это не всегда хорошо.
Есть такой термин – туннельное мышление, когда человек сосредотачивается на одном решении проблемы и не видит альтернативных вариантов. И это не говорит о недостатке квалификации или опыта, так устроен наш мозг: мы автоматически выбираем те методики, которые давали результат в прошлом.
Но иногда это может сыграть злую шутку, сосредоточившись на одном конкретном решении вы можете долго биться лбом в стену, ИИ будет снова и снова водить вас по кругу, хотя если взять паузу, посмотреть, и подумать – то можно найти альтернативное решение, не лучше и не хуже, просто другое.
Поэтому иногда следует отойти от жестких промптов и просто пообщаться с ИИ, не загоняя его изначально в жесткие рамки. Просто изложите ему проблему и попросите помочь с решением, не направляя и не намекая. Максимально общим запросом.
Да, он расскажет вам много интересного, где-то может даже что-то придумать, но он же сможет неожиданно открыть вам глаза и показать проблему с другой стороны, с которой вы на нее еще не смотрели или подсказать вам иной, более актуальный или современный метод, нежели тот, что вы привыкли использовать.
Такой подход также полезен если вы вообще не знаете, как подойти к этому вопросу или хотите посмотреть, как его решают сейчас, а не тогда, когда вы последний раз с этим сталкивались.
А еще лучше вообще абстрагироваться от конкретной технической задачи и обсудить с ИИ вопрос, который вы хотите этой задачей решить. Потому что любая техническая задача в конечном итоге решает какую-то проблему пользователя или создает для него дополнительную ценность.
Такие беседы, на первый взгляд, могут выходить довольно пространными и ни о чем или уводить далеко от первоначального запроса, но именно такой формат общения позволяет максимально расширить кругозор и избавиться от шор и туннельного мышления.
Ну а когда вы нащупали новые идеи – то снова переходите к привычному формату промпта, сужая шаг за шагом контекст от общей идеи до конкретного набора задач.
Все мы привыкли к определенному формату общения с нейросетями: роль → задача → контекст → формат и т.д. Да, в большинстве случаев это оправдано, так как позволяет направить ИИ по нужному пути и заставить его действовать нужным вам образом, в рамках установленных вами ограничений.
Но это хорошо тогда, когда вы четко знаете, что вам нужно сделать и какой результат получить. Но работа системного администратора зачастую далека от этого и подбрасывает задачи со множеством неизвестных переменных.
Также у каждого из нас есть устоявшийся опыт, который тоже оказывает сильное влияние на восприятие IT-систем и принимаемые нами решения. А это не всегда хорошо.
Есть такой термин – туннельное мышление, когда человек сосредотачивается на одном решении проблемы и не видит альтернативных вариантов. И это не говорит о недостатке квалификации или опыта, так устроен наш мозг: мы автоматически выбираем те методики, которые давали результат в прошлом.
Но иногда это может сыграть злую шутку, сосредоточившись на одном конкретном решении вы можете долго биться лбом в стену, ИИ будет снова и снова водить вас по кругу, хотя если взять паузу, посмотреть, и подумать – то можно найти альтернативное решение, не лучше и не хуже, просто другое.
Поэтому иногда следует отойти от жестких промптов и просто пообщаться с ИИ, не загоняя его изначально в жесткие рамки. Просто изложите ему проблему и попросите помочь с решением, не направляя и не намекая. Максимально общим запросом.
Да, он расскажет вам много интересного, где-то может даже что-то придумать, но он же сможет неожиданно открыть вам глаза и показать проблему с другой стороны, с которой вы на нее еще не смотрели или подсказать вам иной, более актуальный или современный метод, нежели тот, что вы привыкли использовать.
Такой подход также полезен если вы вообще не знаете, как подойти к этому вопросу или хотите посмотреть, как его решают сейчас, а не тогда, когда вы последний раз с этим сталкивались.
А еще лучше вообще абстрагироваться от конкретной технической задачи и обсудить с ИИ вопрос, который вы хотите этой задачей решить. Потому что любая техническая задача в конечном итоге решает какую-то проблему пользователя или создает для него дополнительную ценность.
Такие беседы, на первый взгляд, могут выходить довольно пространными и ни о чем или уводить далеко от первоначального запроса, но именно такой формат общения позволяет максимально расширить кругозор и избавиться от шор и туннельного мышления.
Ну а когда вы нащупали новые идеи – то снова переходите к привычному формату промпта, сужая шаг за шагом контекст от общей идеи до конкретного набора задач.
👍26💯10🤮4
Система отслеживания состояния соединений conntrack, часть 1
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
1👍12❤10🔥5🤔1👌1