Грамматика C++ очень сложная, и очень зависит от контекста. Например, одна и та же строка может обозначать объявление переменной, а может - вызов функции. Не порезолвив символы с учетом контекста и области видимости, этого даже и не поймешь.
Qt-ный moc ведь так и работает, пытается понять C++ и генерирует метаданные. Но он не полностью C++ понимает и в каких-то сложных случаях ошибается. А там его не один человек пишет, и очень давно.
Я обычно дублирую коментарии в сишниках и ашниках. Потому, что программист, который хочет ознакомиться с API, будет последовательно читать ашник, а программист, который идет по коду, пойдет в основном по сишникам.
Мощность - это работа, поделенное на время. Работа - это сила, умноженная на рассстояние. 18 ньютон-метров - это такой момент, что если к двигателю приладить кочергу длинной 1 метр, то он будет тянуть ее дальний конец с силой 18 ньютон. Чтобы получилось 360 ватт, этот конец должен в секунду проделывать путь 360/18 = 20 метров. Конец метровой кочерги за один оборот проходит путь 2Piр = 6.28 метра (округленно). Значит, где-то примерно 3 оборота в секунду.
В линухе сетевой стек довольно далеко ушел от "классического" BSD-ного. Поэтому да, набор утилит поменялся. Условный ifconfig в BSD показывает реальное состояние ядра, а в линухе - эмуляцию. В простых случаях им пользоваться можно, но в сложных конфигурациях его метафора пользовательского интерфейса не будет соответствовать той реальности, в которой живет ядро,
Идея, конечно, хорошая – одним действием решить все проблемы с DNS
Никто, разумеется, не предлагает одним выстрелом убить всех зайцев и нескольких охотников заодно. Ценность мониторинга тоже, разумеется, никто не оспаривает.
И статья в целом про обнаружение DNS-туннелей средством, не влияющим на сеть.
Статья в целом про то, как в массиве данных найти вредоносный паттерн. Чтобы собрать этот массив из реальной сети, в нее все равно придется включиться. Это сравнимо по степени интрузивности с заменой одного DNS-сервера (того, который уже сейчас есть, вряд ли там 8.8.8.8) на другой.
то он сам пойдёт на внешний DNS за такой информацией – по сути, прокинет через себя туннель, доставив информацию получателю.
Он очень сильно сузит этот побочный канал. К примеру, полностью отшибет канал, основанный на порядке и времени отправки запросов. Не позволит включать в запросы лишние параметры и вычистит лишние данные из ответов. Приведет к стандартному виду служебные биты, избавив их от скрытой информации. Сделает невозможным запрашивать "странные" типы записей и "странные" домены пятого уровня.
Кроме того, можно было бы ограничить запросы со "странными" метками в доменных именах (например, "H23xl43"), напоминающими сгенерированные. Вот здесь, как раз, можно было бы натренировать ИИ отличать их от нормальных. Это трудно формализовать, но человеку сразу видно, какое имя "нормальное", а какое "странное" - а на таких задачах ИИ как раз неплох. Редкие false positive срабатывания тут не очень важны, всегда можно поднапрячь админа добавить запись в список исключений.
Фактически, останется возможность манипулировать именами запрашиваемых записей и адресами/именами в ответах.
Само по себе такое сужение канала может сделать его малопригодным для конструирования сколь-либо значимой утечки.
И достоинством данного метода является то, что он понятен и поддается анализу, его эффективность можно оценить. В отличии от основанного на ИИ пассивного мониторинга, про который никогда не скажешь, он ничего не нашел потому, что ничего и не было или потому, что плохо искал.
И наконец, такая защищающая DNS-прокси - хорошее место для сбора данных с целью мониторинга, полезность которого я не отрицаю, но все-таки полагаться на него, как на основной метод защиты я бы поостерегся.
Очень вменяемое введение в ИИ, но невероятно обстоятельный труд. Что может быть и достоинством и недостатком. За пару вечеров не прочтешь, но когда осилишь, узнаешь многое.
Мне кажется, это достойно отдельной статьи, посвященной именно глюкам WiFi
В WiFi предусмотрена перепосылка потерянных пакетов потому, что TCP очень болезненно относится к большому проценту потерь. Он их воспринимает как сигнал о переполнении канала (на проводных сетях это разумное предположение, потому что из-за помех на линии пакеты теряются редко, а вот роутер при переполнении очереди запросто начнет отправлять их в /dev/null), и начинает снижать скорость. Поэтому, чтобы обеспечить сносную работоспособность TCP, WiFi следит за доставкой юникастных пакетов. Но за мультикастами не следит, и там потери будут равны канальным потерям, а при загруженной/забитой/зашумленной сети они запросто могут быть, скажем, 10% или типа того.
Я знаю, что юникастный и мультикастный ключи шифрования в WPA разные, но насколько я помню, при rekeying-е обновляются и те и другие. Я не знал, что в результате клиент может прохлопать смену группового ключа.
Что касается IGMP Snooping, по идее та же самая проблема существует даже на Ethernet-свитчах. Разные устройства, включенные в свитч, могут договориться с ним на разную скорость, и если юникаст будет отправлен на той скорости, на которой договорилось устройство, воткнутое в данную дырку, то бродкаст-мультикаст пойдет на самой маленькой скорости среди всех дырок. Т.е., достаточно, чтобы одно устройство договорилось на 100 мб, и в гигабитной сети мультикасты будут ходить на 100 мб (а некоторые альтернативно одаренные устройства умудряются и на 10 мб договориться). Поэтому если сеть объединена несколькими свитчами, свитчи будут стараться следить, кому на самом деле нужны мультикасты. Формально, wi-fi точка доступа - это тоже свитч, просто одна сторона у нее wifi-ная.
А вот интересно. DNS все же редко используется в качестве универсальной базы данных. По большей части, есть стандартные запросы и стандартные ответы.
Чем весь этот сложный мониторинг городить, обрекая себя на вечное соревнование с атакующими в изобретательности, не проще ли сделать кеширующую DNS-прокси, которая отдает стандартный набор информации на стандартные запросы и просто не пропускает лишнего?
Вообще так, невредно понимать разницу в возможностях между регулярным конечным автоматом, всё состояние которого, грубо говоря, укладывается в одну переменную типа int, и стековым конечным автоматом, состояние которого - стек переменных типа int (тоже грубо говоря).
Например, никакая регулярка не сможет проверить сбалансированность скобок, а стековый автомат сделает это с лёгкостью.
А теперь давайте представим более социально-будоражащий сценарий, в котором беспилотный автомобиль уже успешно распознал присутствие человека на дороге, однако предотвратить столкновение возможно лишь за счёт решительного манёвра, в результате которого машина, с пассажиром в салоне, конечно же, была бы вынуждена резко отклониться от проложенного маршрута для столкновения с деревом. Такая ситуация ставит перед алгоритмом сложнейший этический выбор: кем жертвовать – пассажиром или пешеходом?
Блин. Жертвовать надо программистом, который писал эту программу.
Это же машина, а не космическая ракета. Не знаю, что там у ракет, но у машины завсегда при прокладке "проложенного маршрута" можно учесть варианты, куда деваться, если что пойдет не так. И любую сложную ситуацию завсегда можно сильно упростить, заблаговременно снизив скорость. Более того, ПДД нам как бы даже прямо намекают, что так и надо делать, если что-то непонятно: снижать скорость, пока не станет понятно.
В частности, где узко, где скользко, надо ехать достаточно медленно, чтобы необходимость неожиданного манёвра не приводила к неизбежной встрече с деревом на опасной скорости.
Кстати, и при ручном управлении а/м этот подход тоже работает.
Наверное, те, кто читал RFC 9562, и без того знают обо всем, что написано в этой статье. А кто не читал, ничего не поймут...
Грамматика C++ очень сложная, и очень зависит от контекста. Например, одна и та же строка может обозначать объявление переменной, а может - вызов функции. Не порезолвив символы с учетом контекста и области видимости, этого даже и не поймешь.
Qt-ный moc ведь так и работает, пытается понять C++ и генерирует метаданные. Но он не полностью C++ понимает и в каких-то сложных случаях ошибается. А там его не один человек пишет, и очень давно.
Я обычно дублирую коментарии в сишниках и ашниках. Потому, что программист, который хочет ознакомиться с API, будет последовательно читать ашник, а программист, который идет по коду, пойдет в основном по сишникам.
А разве поддержание одинакового порядка объявлений и реализаций функций - это "очевидная фундаментальная вещь"?
Любопытно было бы узнать, откуда в организациях появляются такие правила оформления исходников...
Ну, это оценка, исходя из тех данных, которые у меня есть...
360 ватт, 18 ньютон-метров
Вспоминаем школьный курс физики.
Мощность - это работа, поделенное на время. Работа - это сила, умноженная на рассстояние. 18 ньютон-метров - это такой момент, что если к двигателю приладить кочергу длинной 1 метр, то он будет тянуть ее дальний конец с силой 18 ньютон. Чтобы получилось 360 ватт, этот конец должен в секунду проделывать путь 360/18 = 20 метров. Конец метровой кочерги за один оборот проходит путь 2Piр = 6.28 метра (округленно). Значит, где-то примерно 3 оборота в секунду.
Докеру очень чего много надо такого, чего в линухе реализовано, а в BSD - нет. Например, namespaces, cgroups...
В линухе сетевой стек довольно далеко ушел от "классического" BSD-ного. Поэтому да, набор утилит поменялся. Условный ifconfig в BSD показывает реальное состояние ядра, а в линухе - эмуляцию. В простых случаях им пользоваться можно, но в сложных конфигурациях его метафора пользовательского интерфейса не будет соответствовать той реальности, в которой живет ядро,
Никто, разумеется, не предлагает одним выстрелом убить всех зайцев и нескольких охотников заодно. Ценность мониторинга тоже, разумеется, никто не оспаривает.
Статья в целом про то, как в массиве данных найти вредоносный паттерн. Чтобы собрать этот массив из реальной сети, в нее все равно придется включиться. Это сравнимо по степени интрузивности с заменой одного DNS-сервера (того, который уже сейчас есть, вряд ли там 8.8.8.8) на другой.
Он очень сильно сузит этот побочный канал. К примеру, полностью отшибет канал, основанный на порядке и времени отправки запросов. Не позволит включать в запросы лишние параметры и вычистит лишние данные из ответов. Приведет к стандартному виду служебные биты, избавив их от скрытой информации. Сделает невозможным запрашивать "странные" типы записей и "странные" домены пятого уровня.
Кроме того, можно было бы ограничить запросы со "странными" метками в доменных именах (например, "H23xl43"), напоминающими сгенерированные. Вот здесь, как раз, можно было бы натренировать ИИ отличать их от нормальных. Это трудно формализовать, но человеку сразу видно, какое имя "нормальное", а какое "странное" - а на таких задачах ИИ как раз неплох. Редкие false positive срабатывания тут не очень важны, всегда можно поднапрячь админа добавить запись в список исключений.
Фактически, останется возможность манипулировать именами запрашиваемых записей и адресами/именами в ответах.
Само по себе такое сужение канала может сделать его малопригодным для конструирования сколь-либо значимой утечки.
И достоинством данного метода является то, что он понятен и поддается анализу, его эффективность можно оценить. В отличии от основанного на ИИ пассивного мониторинга, про который никогда не скажешь, он ничего не нашел потому, что ничего и не было или потому, что плохо искал.
И наконец, такая защищающая DNS-прокси - хорошее место для сбора данных с целью мониторинга, полезность которого я не отрицаю, но все-таки полагаться на него, как на основной метод защиты я бы поостерегся.
Я, вообще-то, не такой уж и знаток ИИ :)
Сейчас я вот эту читаю: https://markoff.science/#book
Очень вменяемое введение в ИИ, но невероятно обстоятельный труд. Что может быть и достоинством и недостатком. За пару вечеров не прочтешь, но когда осилишь, узнаешь многое.
Мне кажется, это достойно отдельной статьи, посвященной именно глюкам WiFi
В WiFi предусмотрена перепосылка потерянных пакетов потому, что TCP очень болезненно относится к большому проценту потерь. Он их воспринимает как сигнал о переполнении канала (на проводных сетях это разумное предположение, потому что из-за помех на линии пакеты теряются редко, а вот роутер при переполнении очереди запросто начнет отправлять их в /dev/null), и начинает снижать скорость. Поэтому, чтобы обеспечить сносную работоспособность TCP, WiFi следит за доставкой юникастных пакетов. Но за мультикастами не следит, и там потери будут равны канальным потерям, а при загруженной/забитой/зашумленной сети они запросто могут быть, скажем, 10% или типа того.
Я знаю, что юникастный и мультикастный ключи шифрования в WPA разные, но насколько я помню, при rekeying-е обновляются и те и другие. Я не знал, что в результате клиент может прохлопать смену группового ключа.
Что касается IGMP Snooping, по идее та же самая проблема существует даже на Ethernet-свитчах. Разные устройства, включенные в свитч, могут договориться с ним на разную скорость, и если юникаст будет отправлен на той скорости, на которой договорилось устройство, воткнутое в данную дырку, то бродкаст-мультикаст пойдет на самой маленькой скорости среди всех дырок. Т.е., достаточно, чтобы одно устройство договорилось на 100 мб, и в гигабитной сети мультикасты будут ходить на 100 мб (а некоторые альтернативно одаренные устройства умудряются и на 10 мб договориться). Поэтому если сеть объединена несколькими свитчами, свитчи будут стараться следить, кому на самом деле нужны мультикасты. Формально, wi-fi точка доступа - это тоже свитч, просто одна сторона у нее wifi-ная.
Хм.
Чего-то ему не хватает, а что именно, признаваться не хочет.
P.S. systemd, кажется, собрался потеснить avahi. Будем теперь всем линухом по второму кругу все грабли проходить...
Наверное, если не знать, что такое сверточные нейронные сети, то ничего и не поймешь. А если знать, то ничего нового и не узнаешь...
А вот интересно. DNS все же редко используется в качестве универсальной базы данных. По большей части, есть стандартные запросы и стандартные ответы.
Чем весь этот сложный мониторинг городить, обрекая себя на вечное соревнование с атакующими в изобретательности, не проще ли сделать кеширующую DNS-прокси, которая отдает стандартный набор информации на стандартные запросы и просто не пропускает лишнего?
avahi-browse разве умеет бровсить произвольные RR-ы?
Хм. Код стандартной библиотеки Go через ваши линтеры не прошел бы...
Спасибо на добром слове!
Вряд ли он WSD. Иначе с ним и sane-airscan бы работал, как с WSD.
Вообще так, невредно понимать разницу в возможностях между регулярным конечным автоматом, всё состояние которого, грубо говоря, укладывается в одну переменную типа int, и стековым конечным автоматом, состояние которого - стек переменных типа int (тоже грубо говоря).
Например, никакая регулярка не сможет проверить сбалансированность скобок, а стековый автомат сделает это с лёгкостью.
Блин. Жертвовать надо программистом, который писал эту программу.
Это же машина, а не космическая ракета. Не знаю, что там у ракет, но у машины завсегда при прокладке "проложенного маршрута" можно учесть варианты, куда деваться, если что пойдет не так. И любую сложную ситуацию завсегда можно сильно упростить, заблаговременно снизив скорость. Более того, ПДД нам как бы даже прямо намекают, что так и надо делать, если что-то непонятно: снижать скорость, пока не станет понятно.
В частности, где узко, где скользко, надо ехать достаточно медленно, чтобы необходимость неожиданного манёвра не приводила к неизбежной встрече с деревом на опасной скорости.
Кстати, и при ручном управлении а/м этот подход тоже работает.