Какие S3-хранилища можно использовать взамен MiniIO
В связи с уходом с рынка открытой версии MiniIO возникает закономерный вопрос – чем заменить и куда мигрировать. Варианты есть и на первый взгляд их достаточно много, но мы сразу отсечем крайности и будем рассматривать простые решения для малого и среднего бизнеса или домашней лаборатории.
Поэтому мы не будем рассматривать таких монстров как Ceph и аналогичные ему решения, а также небольшие проекты, уровня энтузиастов и домашних лабораторий, хотя они интересны и мы посвятим им отдельную заметку.
А пока состав игроков у нас плавно сокращается всего до двух проектов.
🔹 Garage – проект французских разработчиков под лицензией AGPL v3 написанный на Rust цель которого предоставить вам простое и понятное S3-хранилище с небольшими системными требованиями.
Вам потребуется от одного ядра и 512 МБ ОЗУ, развернуть вы его можете даже на Raspberry Pi.
Развертывание предельно простое через докер, не требует каких-то особых знаний и позволяет быстро и просто развернуть S3-хранилище буквально за несколько минут.
При необходимости система легко расширяется до кластера, причем все реализовано в самом Garage и не требует сторонних зависимостей, репликация отлично работает даже с удаленными системами на плохих каналах связи. По словам разработчиков именно на это направлены основные усилия проекта.
Производительность – средняя, не рекомендуется превышать хранимый объем данных более 50 TБ.
В общем, Garage – отличный выбор для домашней лаборатории или небольших организаций, где в первую очередь требуется простота и геораспределенность. А также нет сотрудников с особыми компетенциями по S3.
Здесь вы получаете все нужно буквально из коробки и у вас нет никаких дополнительных сущностей, просто экземпляр Garage и ничего более.
🔹 SeaweedFS – распределенная файловая система и объектное хранилище, для которого S3 – только один из доступных интерфейсов, имеет более сложную архитектуру и более высокий порог входа.
Несмотря на это также может быть быстро и относительно просто развернут в докер, но эксплуатация и поддержка системы потребует уже несколько более глубоких знаний.
SeaweedFS написан на Go и использует СУБД для хранения метаданных, в результате чего он показывает просто отличную производительность, особенно при работе с большим количеством мелких файлов (не миллионы, миллиарды).
Также может горизонтально расширяться в геораспределенные системы. Поэтому будет неплохим выбором для CDN, размещения медиафайлов и прочих задач, для которых важна производительность.
За это приходится платить более сложной архитектурой системы и требованием наличия определенных компетенций у обслуживающего персонала.
👆 Выводы: если вам нужно простое S3-хранилище и ваш объем данных не превышает 50 ТБ, а также вы не желаете вникать в тонкости – берите Garage, если же вам нужно больше возможностей, высокая производительность на мелких файлах, и вы готовы посвятить некоторое время на освоение системы – обратите внимание на SeaweedFS.
В связи с уходом с рынка открытой версии MiniIO возникает закономерный вопрос – чем заменить и куда мигрировать. Варианты есть и на первый взгляд их достаточно много, но мы сразу отсечем крайности и будем рассматривать простые решения для малого и среднего бизнеса или домашней лаборатории.
Поэтому мы не будем рассматривать таких монстров как Ceph и аналогичные ему решения, а также небольшие проекты, уровня энтузиастов и домашних лабораторий, хотя они интересны и мы посвятим им отдельную заметку.
А пока состав игроков у нас плавно сокращается всего до двух проектов.
🔹 Garage – проект французских разработчиков под лицензией AGPL v3 написанный на Rust цель которого предоставить вам простое и понятное S3-хранилище с небольшими системными требованиями.
Вам потребуется от одного ядра и 512 МБ ОЗУ, развернуть вы его можете даже на Raspberry Pi.
Развертывание предельно простое через докер, не требует каких-то особых знаний и позволяет быстро и просто развернуть S3-хранилище буквально за несколько минут.
При необходимости система легко расширяется до кластера, причем все реализовано в самом Garage и не требует сторонних зависимостей, репликация отлично работает даже с удаленными системами на плохих каналах связи. По словам разработчиков именно на это направлены основные усилия проекта.
Производительность – средняя, не рекомендуется превышать хранимый объем данных более 50 TБ.
В общем, Garage – отличный выбор для домашней лаборатории или небольших организаций, где в первую очередь требуется простота и геораспределенность. А также нет сотрудников с особыми компетенциями по S3.
Здесь вы получаете все нужно буквально из коробки и у вас нет никаких дополнительных сущностей, просто экземпляр Garage и ничего более.
🔹 SeaweedFS – распределенная файловая система и объектное хранилище, для которого S3 – только один из доступных интерфейсов, имеет более сложную архитектуру и более высокий порог входа.
Несмотря на это также может быть быстро и относительно просто развернут в докер, но эксплуатация и поддержка системы потребует уже несколько более глубоких знаний.
SeaweedFS написан на Go и использует СУБД для хранения метаданных, в результате чего он показывает просто отличную производительность, особенно при работе с большим количеством мелких файлов (не миллионы, миллиарды).
Также может горизонтально расширяться в геораспределенные системы. Поэтому будет неплохим выбором для CDN, размещения медиафайлов и прочих задач, для которых важна производительность.
За это приходится платить более сложной архитектурой системы и требованием наличия определенных компетенций у обслуживающего персонала.
👆 Выводы: если вам нужно простое S3-хранилище и ваш объем данных не превышает 50 ТБ, а также вы не желаете вникать в тонкости – берите Garage, если же вам нужно больше возможностей, высокая производительность на мелких файлах, и вы готовы посвятить некоторое время на освоение системы – обратите внимание на SeaweedFS.
👍35⚡5🤮3
Перспективные проекты S3-хранилищ
Вчера мы рассмотрели рабочие аналоги MiniIO представляющие из себя уже состоявшиеся проекты, пригодные для развертывания в продуктивной среде, сегодня же рассмотрим ряд развивающихся альтернатив.
🔹 RustFS – высокопроизводительное распределенное S3-хранилище призванное стать альтернативой MiniIO, по тестам разработчика имеет производительность в среднем в 2,3 раза выше.
Как уже понятно из названия, написан на Rust, поддерживает Windows, Linux, macOS, а также может быть развернут в Docker.
Из всех альтернативных проектов наиболее зрелый и обладает всеми необходимыми функциями для одиночного хоста, кластеризация находится в разработке и тестировании.
🔹 HS5 – высокопроизводительное хранилище для одиночного узла. Авторы проекта сразу говорят, что их задача создать быстрое, производительное и масштабируемое S3-хранилище для тех случаев, когда скорость обработки данных важнее надежности их хранение.
Тесты показывают, что HS5 действительно быстрее RustFS и MiniIO, а если вам не хватает скорости, то со слов разработчиков можно просто добавитьводы памяти и процессорных ядер.
Кластеризация в планах разработчиков не стоит, также следует понимать, что проект молодой и находится в стадии активной разработки.
Развернуть его можно как скачав единственный бинарный файл, так и через Docker, поддерживается только Linux на платформах x86-64 и ARM.
Ставить HS5 в продуктивный контур пока рано, но для домашней лаборатории это может быть неплохим решением, особенно там, где вам некритично потерять некоторые данные.
🔹 Alarik – еще один проект S3-хранилища от немецких разработчиков, написанный на Swift. В планах создать альтернативу MiniIO с безопасной для коммерческих пользователей разрешительной лицензией (Apache 2.0).
Разработка Alarik – мера вынужденная, его авторы занимаются разработкой бухгалтерского ПО и в своей работе активно использовали MiniIO, после известных событий они оказались перед выбором альтернативы.
После чего они обнаружили, что ни один из имеющихся вариантов их не устраивает, а также как опасно, когда отрасль ориентируется на единственную программу, ставшую де-факто «эталоном».
Поэтому они решили создать собственную реализацию, которая будет уметь все, что умел MiniIO и будет с ним максимально совместимой. Проект пока находится в стадии ранней альфы и активно изменяется, но разработчики обещают твердо идти к своей цели, так как это нужно им для собственного бизнеса.
Проект можно развернуть через Docker, но в настоящий момент он интересен сугубо для тестирования, хотя является перспективным вариантом и заслуживает внимания.
Вчера мы рассмотрели рабочие аналоги MiniIO представляющие из себя уже состоявшиеся проекты, пригодные для развертывания в продуктивной среде, сегодня же рассмотрим ряд развивающихся альтернатив.
🔹 RustFS – высокопроизводительное распределенное S3-хранилище призванное стать альтернативой MiniIO, по тестам разработчика имеет производительность в среднем в 2,3 раза выше.
Как уже понятно из названия, написан на Rust, поддерживает Windows, Linux, macOS, а также может быть развернут в Docker.
Из всех альтернативных проектов наиболее зрелый и обладает всеми необходимыми функциями для одиночного хоста, кластеризация находится в разработке и тестировании.
🔹 HS5 – высокопроизводительное хранилище для одиночного узла. Авторы проекта сразу говорят, что их задача создать быстрое, производительное и масштабируемое S3-хранилище для тех случаев, когда скорость обработки данных важнее надежности их хранение.
Тесты показывают, что HS5 действительно быстрее RustFS и MiniIO, а если вам не хватает скорости, то со слов разработчиков можно просто добавить
Кластеризация в планах разработчиков не стоит, также следует понимать, что проект молодой и находится в стадии активной разработки.
Развернуть его можно как скачав единственный бинарный файл, так и через Docker, поддерживается только Linux на платформах x86-64 и ARM.
Ставить HS5 в продуктивный контур пока рано, но для домашней лаборатории это может быть неплохим решением, особенно там, где вам некритично потерять некоторые данные.
🔹 Alarik – еще один проект S3-хранилища от немецких разработчиков, написанный на Swift. В планах создать альтернативу MiniIO с безопасной для коммерческих пользователей разрешительной лицензией (Apache 2.0).
Разработка Alarik – мера вынужденная, его авторы занимаются разработкой бухгалтерского ПО и в своей работе активно использовали MiniIO, после известных событий они оказались перед выбором альтернативы.
После чего они обнаружили, что ни один из имеющихся вариантов их не устраивает, а также как опасно, когда отрасль ориентируется на единственную программу, ставшую де-факто «эталоном».
Поэтому они решили создать собственную реализацию, которая будет уметь все, что умел MiniIO и будет с ним максимально совместимой. Проект пока находится в стадии ранней альфы и активно изменяется, но разработчики обещают твердо идти к своей цели, так как это нужно им для собственного бизнеса.
Проект можно развернуть через Docker, но в настоящий момент он интересен сугубо для тестирования, хотя является перспективным вариантом и заслуживает внимания.
👍17❤3🤮2🤝2
Что такое объектное хранилище S3 и в чем его основные особенности.
S3 (Simple Storage Service) – объектное хранилище и одноименное API доступа разработанное компанией Amazon и в настоящее время широко используемое многими облачными провайдерами, также существуют решения для создания собственных S3 хранилищ.
Первый раз сталкиваясь с S3 многие пользователи не понимают в чем его отличия от традиционных файловых хранилищ, какие преимущества и недостатки.
Начнем с того, что S3 – это не файловое хранилище, а объектное. Что это значит? А это значит, что мы можем хранить в нем не только файлы, а вообще любые двоичные данные, в любом формате.
Ведь что такое файл? Это именованная область на диске для хранения неких данных. В зависимости от типа хранимых данных используются разные форматы файлов, но это только один из частных случаев их, данных, размещения, хотя и самый привычный.
Например, те же данные мы можем хранить в базе данных в виде отдельных записей или даже их набора. А можем вообще хранить в сыром виде на блочном устройстве в виде RAW образа, и не важно, что там внутри, для устройства хранения это будет просто набор блоков.
S3 представляет собой плоское объектное хранилище, где данные организованы по принципу ключ – значение. Ключ – это уникальный идентификатор, значение – объект. Объектом может быть все что угодно – файл, сырые или форматированные данные, в любом случае для S3 это будет некоторый набор байтов, связанный с ключом – идентификатором.
Для работы со всем этим используется протокол HTTP(S) и специальное S3 API, что серьезно упрощает работу с объектами на программном уровне. Вам не нужны клиенты, поддержка протоколов и файловых систем, просто нужно отправить запрос по HTTP и получить или разместить данные.
Такой подход прежде всего удобен для разработчиков, теперь приложению не нужно сохранять или загружать данные через промежуточную прослойку – файл, а можно напрямую разместить или получить их из хранилища.
Это удобно и для облачных провайдеров, так как позволяет сделать простую и понятную тарификацию, по объему скачанного или загруженного трафика. И, главное, такая тарификация будет предельно понятна для пользователя.
А плоская иерархия, точнее ее отсутствие, дает неограниченные возможности горизонтального масштабирования и упрощает доступ к данным на уровне хранилища, так как не требуется поддержка иерархии системы хранения и поиска по ней.
Для удобства пользователя S3 хранилище позволяют создавать псевдоиерархические структуры, т.н. контейнеры (бакеты, bucket), но на самом деле они являются всего лишь префиксами ключа и не создают никаких дополнительных сущностей в системе хранения.
Как мы уже говорили, S3 – это хранилище наборов сырых данных, каждому из объектов которого соответствует свой ключ. Любые дополнительные абстракции в виде файловых систем, файлов или папок отсутствуют. А что именно там лежит – хранилищу абсолютно неинтересно, набор байтов он и в Африке набор байтов.
Собственно, исходя из этого и следует рассматривать плюсы и минусы хранилищ S3. При этом всегда следует отталкиваться от решаемых задач, потому что одни и те же особенности S3 могут быть как плюсами, так и минусами.
И разворачивая S3 локально также следует понимать с какой целью и для каких задач вы это делаете. Потому как это не замена файловому серверу или облачному хранилищу, а совершенно отдельная сущность, предоставляющая простой доступ к объектам и их хранение в любых объемах без лишних накладных расходов и без ограничения по форматам и размерам.
S3 (Simple Storage Service) – объектное хранилище и одноименное API доступа разработанное компанией Amazon и в настоящее время широко используемое многими облачными провайдерами, также существуют решения для создания собственных S3 хранилищ.
Первый раз сталкиваясь с S3 многие пользователи не понимают в чем его отличия от традиционных файловых хранилищ, какие преимущества и недостатки.
Начнем с того, что S3 – это не файловое хранилище, а объектное. Что это значит? А это значит, что мы можем хранить в нем не только файлы, а вообще любые двоичные данные, в любом формате.
Ведь что такое файл? Это именованная область на диске для хранения неких данных. В зависимости от типа хранимых данных используются разные форматы файлов, но это только один из частных случаев их, данных, размещения, хотя и самый привычный.
Например, те же данные мы можем хранить в базе данных в виде отдельных записей или даже их набора. А можем вообще хранить в сыром виде на блочном устройстве в виде RAW образа, и не важно, что там внутри, для устройства хранения это будет просто набор блоков.
S3 представляет собой плоское объектное хранилище, где данные организованы по принципу ключ – значение. Ключ – это уникальный идентификатор, значение – объект. Объектом может быть все что угодно – файл, сырые или форматированные данные, в любом случае для S3 это будет некоторый набор байтов, связанный с ключом – идентификатором.
Для работы со всем этим используется протокол HTTP(S) и специальное S3 API, что серьезно упрощает работу с объектами на программном уровне. Вам не нужны клиенты, поддержка протоколов и файловых систем, просто нужно отправить запрос по HTTP и получить или разместить данные.
Такой подход прежде всего удобен для разработчиков, теперь приложению не нужно сохранять или загружать данные через промежуточную прослойку – файл, а можно напрямую разместить или получить их из хранилища.
Это удобно и для облачных провайдеров, так как позволяет сделать простую и понятную тарификацию, по объему скачанного или загруженного трафика. И, главное, такая тарификация будет предельно понятна для пользователя.
А плоская иерархия, точнее ее отсутствие, дает неограниченные возможности горизонтального масштабирования и упрощает доступ к данным на уровне хранилища, так как не требуется поддержка иерархии системы хранения и поиска по ней.
Для удобства пользователя S3 хранилище позволяют создавать псевдоиерархические структуры, т.н. контейнеры (бакеты, bucket), но на самом деле они являются всего лишь префиксами ключа и не создают никаких дополнительных сущностей в системе хранения.
Как мы уже говорили, S3 – это хранилище наборов сырых данных, каждому из объектов которого соответствует свой ключ. Любые дополнительные абстракции в виде файловых систем, файлов или папок отсутствуют. А что именно там лежит – хранилищу абсолютно неинтересно, набор байтов он и в Африке набор байтов.
Собственно, исходя из этого и следует рассматривать плюсы и минусы хранилищ S3. При этом всегда следует отталкиваться от решаемых задач, потому что одни и те же особенности S3 могут быть как плюсами, так и минусами.
И разворачивая S3 локально также следует понимать с какой целью и для каких задач вы это делаете. Потому как это не замена файловому серверу или облачному хранилищу, а совершенно отдельная сущность, предоставляющая простой доступ к объектам и их хранение в любых объемах без лишних накладных расходов и без ограничения по форматам и размерам.
👍25🤮3❤2🤔2🤝2
Нейросети - Qwen 3.5
На этой неделе Alibaba представила Qwen 3.5 – новую бесплатную модель, которая, согласно тестам, идёт на уроне с GPT-5.2, Claude Opus 4.5 и Gemini 3 Pro, уступая только в программировании и математических задачах.
Но меня последнее время интересует еще и режим глубокого исследования, когда ты хочешь изучить какой-либо вопрос и даешь сети задание выполнить это самое исследование. Причем не просто нагнать пурги, а сделать дайджест с ссылками на источники.
До сих пор лучше всего это делал Perplexity с подпиской Pro, благо она стоит, если знать где брать, копейки. Да, подобные подписки не так давно блокировали и у меня тоже, но цена там смешная, можно спокойно позволить завести новую.
Так вот, на мой взгляд Perplexity в режиме глубокого исследования лучше всего пылесосило интернет и после чего давала весьма годную выжимку со ссылками на источники. Потому как верить на слово нейросетям не стоит.
Но и игнорировать их возможности также глупо, то, что накопала, прочитала и дала краткую выжимку сетка за пару-тройку минут я самостоятельно искал бы пару часов. Польза от сеток есть и большая, главное – правильно использовать этот инструмент.
С выходом Qwen 3.5 мне захотелось попробовать эту сеть в режиме глубокого исследования, я закинул в нее запрос из Perplexity, которым пользовался буквально на днях и стал смотреть за результатом.
И Qwen 3.5 меня не разочаровал, он вполне способен проводить бесплатные глубокие исследования с большой глубиной контекста (заявляется до 1 млн. токенов), что позволяет многократно уточнять и корректировать результаты.
Сама по себе Perplexity слаба, как и ее модель, вывозит она за счет подключения других моделей в платной версии, теперь у нее появился серьезный конкурент. Нет, китайцы были и ранее неплохи, но не более, теперь же они уже дышат в спину.
Поэтому советую всем попробовать Qwen 3.5, возможно вы найдете то, что искали, при этом – бесплатно и без ограничений.
На этой неделе Alibaba представила Qwen 3.5 – новую бесплатную модель, которая, согласно тестам, идёт на уроне с GPT-5.2, Claude Opus 4.5 и Gemini 3 Pro, уступая только в программировании и математических задачах.
Но меня последнее время интересует еще и режим глубокого исследования, когда ты хочешь изучить какой-либо вопрос и даешь сети задание выполнить это самое исследование. Причем не просто нагнать пурги, а сделать дайджест с ссылками на источники.
До сих пор лучше всего это делал Perplexity с подпиской Pro, благо она стоит, если знать где брать, копейки. Да, подобные подписки не так давно блокировали и у меня тоже, но цена там смешная, можно спокойно позволить завести новую.
Так вот, на мой взгляд Perplexity в режиме глубокого исследования лучше всего пылесосило интернет и после чего давала весьма годную выжимку со ссылками на источники. Потому как верить на слово нейросетям не стоит.
Но и игнорировать их возможности также глупо, то, что накопала, прочитала и дала краткую выжимку сетка за пару-тройку минут я самостоятельно искал бы пару часов. Польза от сеток есть и большая, главное – правильно использовать этот инструмент.
С выходом Qwen 3.5 мне захотелось попробовать эту сеть в режиме глубокого исследования, я закинул в нее запрос из Perplexity, которым пользовался буквально на днях и стал смотреть за результатом.
И Qwen 3.5 меня не разочаровал, он вполне способен проводить бесплатные глубокие исследования с большой глубиной контекста (заявляется до 1 млн. токенов), что позволяет многократно уточнять и корректировать результаты.
Сама по себе Perplexity слаба, как и ее модель, вывозит она за счет подключения других моделей в платной версии, теперь у нее появился серьезный конкурент. Нет, китайцы были и ранее неплохи, но не более, теперь же они уже дышат в спину.
Поэтому советую всем попробовать Qwen 3.5, возможно вы найдете то, что искали, при этом – бесплатно и без ограничений.
🔥36👍8🤮5❤2👌2
Зачем мне нужен S3?
Такой вопрос уже не раз задавали в комментариях наши читатели, какие преимущества дает эта система хранения и чем она лучше традиционных систем.
Начнем с кардинальных различий: S3 – объектное хранилище, в то время как файловые системы – иерархические. Т.е. не ожидайте от S3 свойств присущим файловым системам, это плоский набор объектов, связанных по принципу ключ-значение.
Вам не важно, где именно расположен объект и как он хранится, зная ключ вы всегда можете получить его значение или записать туда же новую версию объекта. Объектом тоже может быть что угодно, любые цифровые данные.
Это позволяет S3 отлично горизонтально масштабироваться и поддерживать большие, очень большие наборы данных без снижения производительности.
Также S3 умеет в версионирование, когда при перезаписи у нас остается одна или несколько версий объекта, которые мы можем получить в любое время, также мы можем настроить количество и срок хранения версий.
Дополнительно к этому многие S3 решения предлагают механизмы WORM и Object Lock, когда данные пишутся в хранилище один раз, а потом только читаются, а также блокирование объектов, когда удалить или перезаписать их в течении указанного срока хранения не может даже суперпользователь.
Я думаю, что вы уже догадались, один из сценариев для дома или небольшого предприятия с использованием S3 – это резервное копирование, и очень многие утилиты, а также серьезные системы бекапов хранилища S3 поддерживают. А с учетом того, что это не файловая система – получаем более высокую защиту от шифровальщиков и т.п.
Еще одна особенность S3 из коробки – это кластеризация и геораспределенность. Для повышения надежности мы можем добавлять дополнительные узлы, с дисками разного типа и размера, размещенные в разных географических локациях.
Это защищает не только от отказов оборудования, но и полной потери локации (пожар, затопление, кража и т.д.), все это без дополнительных инструментов. Это только добавит плюсов нашей системе резервного копирования.
Второй сценарий – это именно геораспределенные системы, например, дом – офис – загородный дом, в каждом из которых вы будете иметь актуальную копию данных и сильно не задумываться об их синхронизации. S3 все сделает сам, причем многие реализации изначально рассчитаны на работу с нестабильными каналами связи.
Таким образом вы можете убить двух зайцев – обеспечить себя в любом месте актуальным архивом рабочих документов и работать даже при отсутствии связи с внешним миров, попутно обеспечив данным защиту от случайной потери или изменений.
Еще один практический сценарий, более подходящий для дома – это хранение медиаконтента (фото, видео с телефонов и прочих гаджетов и т.п.), здесь мы получаем все те же самые плюсы (защита контента, распределенное хранение, простота и дешевизна).
Берем три Raspberry Pi с дисками требуемого объема, поднимаем S3-кластер, развозим в разные локации и более не боимся за свой медиаконтент. Клиентов с поддержкой этого типа хранилища для носимых дейвайсов хватает.
Это только некоторые, небольшие сценарии, которые используем мы лично и которые, конечно же не покрывают все возможности S3, но дают понимание для чего вам может пригодиться данная технология.
Такой вопрос уже не раз задавали в комментариях наши читатели, какие преимущества дает эта система хранения и чем она лучше традиционных систем.
Начнем с кардинальных различий: S3 – объектное хранилище, в то время как файловые системы – иерархические. Т.е. не ожидайте от S3 свойств присущим файловым системам, это плоский набор объектов, связанных по принципу ключ-значение.
Вам не важно, где именно расположен объект и как он хранится, зная ключ вы всегда можете получить его значение или записать туда же новую версию объекта. Объектом тоже может быть что угодно, любые цифровые данные.
Это позволяет S3 отлично горизонтально масштабироваться и поддерживать большие, очень большие наборы данных без снижения производительности.
Также S3 умеет в версионирование, когда при перезаписи у нас остается одна или несколько версий объекта, которые мы можем получить в любое время, также мы можем настроить количество и срок хранения версий.
Дополнительно к этому многие S3 решения предлагают механизмы WORM и Object Lock, когда данные пишутся в хранилище один раз, а потом только читаются, а также блокирование объектов, когда удалить или перезаписать их в течении указанного срока хранения не может даже суперпользователь.
Я думаю, что вы уже догадались, один из сценариев для дома или небольшого предприятия с использованием S3 – это резервное копирование, и очень многие утилиты, а также серьезные системы бекапов хранилища S3 поддерживают. А с учетом того, что это не файловая система – получаем более высокую защиту от шифровальщиков и т.п.
Еще одна особенность S3 из коробки – это кластеризация и геораспределенность. Для повышения надежности мы можем добавлять дополнительные узлы, с дисками разного типа и размера, размещенные в разных географических локациях.
Это защищает не только от отказов оборудования, но и полной потери локации (пожар, затопление, кража и т.д.), все это без дополнительных инструментов. Это только добавит плюсов нашей системе резервного копирования.
Второй сценарий – это именно геораспределенные системы, например, дом – офис – загородный дом, в каждом из которых вы будете иметь актуальную копию данных и сильно не задумываться об их синхронизации. S3 все сделает сам, причем многие реализации изначально рассчитаны на работу с нестабильными каналами связи.
Таким образом вы можете убить двух зайцев – обеспечить себя в любом месте актуальным архивом рабочих документов и работать даже при отсутствии связи с внешним миров, попутно обеспечив данным защиту от случайной потери или изменений.
Еще один практический сценарий, более подходящий для дома – это хранение медиаконтента (фото, видео с телефонов и прочих гаджетов и т.п.), здесь мы получаем все те же самые плюсы (защита контента, распределенное хранение, простота и дешевизна).
Берем три Raspberry Pi с дисками требуемого объема, поднимаем S3-кластер, развозим в разные локации и более не боимся за свой медиаконтент. Клиентов с поддержкой этого типа хранилища для носимых дейвайсов хватает.
Это только некоторые, небольшие сценарии, которые используем мы лично и которые, конечно же не покрывают все возможности S3, но дают понимание для чего вам может пригодиться данная технология.
👍39🤡5🤝5🥱2
Семь раз проверь, один отрежь
Пользователи Windows привыкли качать ПО из интернета, при этом мало кто задумывается о его подлинности и проверяет цифровые подписи.
Недавно активные пользователи 7-Zip обратили внимание на сайт 7zip[.]com стилизованный под официальный сайт. На момент обнаружения он находился в выдаче Google на четвертой строке с заголовком Secure and Fast Download for Windows - Get 7-Zip.
Также данный сайт широко рекламировался на YouTube в коротких видео как скачать и поставить 7-Zip.
Проверка выявила, что при установке данного пакета кроме собственно архиватора вы получите в системе еще два вредоносных файла, первый открывает на компьютере прокси-сервер, второй является загрузчиком и может по команде из центра загрузить любой иной вредоносный код.
К сожалению, это не новое слово в распространении вредоносного ПО, практически каждый популярный пакет имеет сайты-двойники, где вам предложат все тоже самое, но с дополнительной нагрузкой.
В лучшем случае это будет какое-то партнерское ПО, но чаще всего это разной степени бесполезности рекламное ПО, которое тем не менее не является вредоносным, что позволяет таким сайтам жить долго и счастливо.
Ну а бывает, как в этом случае – вам доставят откровенно вредоносное ПО.
Самое странное, что средство от этого есть давно – Магазин Windows, куда уже давно можно добавлять не только современные приложения, но и обычное ПО. Это, не считая официальный и неофициальные менеджеры пакетов.
Но по странному стечению обстоятельств эти инструменты в основной массе пользователей игнорируются. Причем теми же людьми, которые с удовольствием используют пакетные менеджеры в Linux.
Хотя переход на магазинную схему если бы не решил всех проблем, то снял бы большую их часть, потому что даже имея опыт никогда нельзя сказать попал ты на официальный сайт или двойник-подделку.
Поэтому там, где можно использовать магазин или репозиторий – используйте магазин или репозиторий. А для простых пользователей, клиентов, друзей, знакомых и родственников не давайте рекомендации найти и скачать что-то в Google или Яндексе. Просто пошлите им ссылку или уже скачанный файл.
Пользователи Windows привыкли качать ПО из интернета, при этом мало кто задумывается о его подлинности и проверяет цифровые подписи.
Недавно активные пользователи 7-Zip обратили внимание на сайт 7zip[.]com стилизованный под официальный сайт. На момент обнаружения он находился в выдаче Google на четвертой строке с заголовком Secure and Fast Download for Windows - Get 7-Zip.
Также данный сайт широко рекламировался на YouTube в коротких видео как скачать и поставить 7-Zip.
Проверка выявила, что при установке данного пакета кроме собственно архиватора вы получите в системе еще два вредоносных файла, первый открывает на компьютере прокси-сервер, второй является загрузчиком и может по команде из центра загрузить любой иной вредоносный код.
К сожалению, это не новое слово в распространении вредоносного ПО, практически каждый популярный пакет имеет сайты-двойники, где вам предложат все тоже самое, но с дополнительной нагрузкой.
В лучшем случае это будет какое-то партнерское ПО, но чаще всего это разной степени бесполезности рекламное ПО, которое тем не менее не является вредоносным, что позволяет таким сайтам жить долго и счастливо.
Ну а бывает, как в этом случае – вам доставят откровенно вредоносное ПО.
Самое странное, что средство от этого есть давно – Магазин Windows, куда уже давно можно добавлять не только современные приложения, но и обычное ПО. Это, не считая официальный и неофициальные менеджеры пакетов.
Но по странному стечению обстоятельств эти инструменты в основной массе пользователей игнорируются. Причем теми же людьми, которые с удовольствием используют пакетные менеджеры в Linux.
Хотя переход на магазинную схему если бы не решил всех проблем, то снял бы большую их часть, потому что даже имея опыт никогда нельзя сказать попал ты на официальный сайт или двойник-подделку.
Поэтому там, где можно использовать магазин или репозиторий – используйте магазин или репозиторий. А для простых пользователей, клиентов, друзей, знакомых и родственников не давайте рекомендации найти и скачать что-то в Google или Яндексе. Просто пошлите им ссылку или уже скачанный файл.
👍34❤3🍌3👎2😁1
WinGet (Windows Package Manager) - пакетный менеджер для Windows
Пакетный менеджер - хорошо знакомый любому Linux администратору вид ПО, который позволяет централизованно управлять программным обеспечением в системе и легко автоматизировать этот процесс.
Пользователи Windows долгое время были лишены подобного инструмента, собственно, как вообще какого-то централизованного подхода к управлению ПО, но затем в Windows появился Магазин, а затем и менеджер пакетов, названный просто - Windows Package Manager или WinGet.
В целом, если вы имеете опыт работы с любым пакетным менеджером, то начать работу с WinGet будет несложно, но есть определенные отличия. Начнем с того, что в Linux системах репозиторий является доверенным источником приложений, который связан либо с дистрибутивом, либо с разработчиком ПО и мы всегда понимаем из какого источника мы получаем тот или иной пакет.
В WinGet имеется два источника пакетов: магазин Windows и собственный репозиторий, поддерживаемый Microsoft. Но данный репозиторий является лишь одним из каналов распространения ПО независимыми поставщиками. Грубо говоря репозиторий WinGet является просто каталогом ссылок на скачивание инсталляторов того или иного ПО из различных источников, предлагаемых их разработчиками.
Это, конечно же лучше, чем искать и скачивать пакеты в интернет, но серьезно отличается от принятой в Linux модели: если там, скачивая пакет из репозитория дистрибутива мы можем быть уверены, что пакет протестирован именно под вашу версию дистрибутива, то здесь все вопросы к разработчику, если пакет нестабильно работает или не работает под вашу версию ОС, то WinGet ничем вам тут не поможет.
Равно как вопрос доверия к дистрибутиву и репозиторию как единому целому меняется на вопрос доверия к каждой отдельной программе, поэтому будьте внимательны и осмотрительны в выборе ПО при использовании пакетного менеджера Windows.
Возможности WinGet доступны начиная с Windows 10 1709 и во всех актуальных выпусках он предустановлен по умолчанию, в противном случае его можно получить в Магазине Windows под названием App Installer
✅ Читать далее
Пакетный менеджер - хорошо знакомый любому Linux администратору вид ПО, который позволяет централизованно управлять программным обеспечением в системе и легко автоматизировать этот процесс.
Пользователи Windows долгое время были лишены подобного инструмента, собственно, как вообще какого-то централизованного подхода к управлению ПО, но затем в Windows появился Магазин, а затем и менеджер пакетов, названный просто - Windows Package Manager или WinGet.
В целом, если вы имеете опыт работы с любым пакетным менеджером, то начать работу с WinGet будет несложно, но есть определенные отличия. Начнем с того, что в Linux системах репозиторий является доверенным источником приложений, который связан либо с дистрибутивом, либо с разработчиком ПО и мы всегда понимаем из какого источника мы получаем тот или иной пакет.
В WinGet имеется два источника пакетов: магазин Windows и собственный репозиторий, поддерживаемый Microsoft. Но данный репозиторий является лишь одним из каналов распространения ПО независимыми поставщиками. Грубо говоря репозиторий WinGet является просто каталогом ссылок на скачивание инсталляторов того или иного ПО из различных источников, предлагаемых их разработчиками.
Это, конечно же лучше, чем искать и скачивать пакеты в интернет, но серьезно отличается от принятой в Linux модели: если там, скачивая пакет из репозитория дистрибутива мы можем быть уверены, что пакет протестирован именно под вашу версию дистрибутива, то здесь все вопросы к разработчику, если пакет нестабильно работает или не работает под вашу версию ОС, то WinGet ничем вам тут не поможет.
Равно как вопрос доверия к дистрибутиву и репозиторию как единому целому меняется на вопрос доверия к каждой отдельной программе, поэтому будьте внимательны и осмотрительны в выборе ПО при использовании пакетного менеджера Windows.
Возможности WinGet доступны начиная с Windows 10 1709 и во всех актуальных выпусках он предустановлен по умолчанию, в противном случае его можно получить в Магазине Windows под названием App Installer
✅ Читать далее
🔥16👍9👌6❤4🍌3
AnyDesk похоже всё…
Еще с прошлой недели наблюдаются проблемы с работой AnyDesk – долгое подключение, неустойчивая связь, переподключения. С чем это связано – непонятно.
Начиная с сегодняшнего дня работать в AnyDesk практически невозможно, сеанс продолжается буквально несколько минут, после чего обрывается с сообщением «Сетевое соединение было неожиданно прервано».
Проблема массовая, от провайдера и типа доступа в интернет не зависит. У многих работа оказалась полностью парализована, особенно кто использовал AnyDesk для удаленного доступа на рабочее место или поддержки.
Ситуация осложняется, если подключаться приходится к сеансу с пониженными правами, в этом случае приходится сажать с той стороны человека, который будет постоянно разрешать повышение прав или за вас нажимать кнопки на экране.
А если там действительно ограниченные права, то сажать придется уже местного администратора (которого тоже не всегда можно найти на месте).
Использование КВН проблемы не решит, так как это придется делать массово и у себя, и у заказчиков, что проблемно, особенно если заказчики небольшие и работы нерегулярные. Плюс нет никакого понимания природы проблемы.
Это может быть как отечественное небезызвестное ведомство, которое пристально следит, чтобы никто не пошел туда, не надо куда, либо могут быть сами владельцы AnyDesk в свете выполнения каких-нибудь очередных санкции или борьбы с халявщиками.
В общем будем думать и смотреть, а пока потихоньку переводим заказчиков на Ассистент, который видится более-менее полноценной заменой AnyDesk.
Еще с прошлой недели наблюдаются проблемы с работой AnyDesk – долгое подключение, неустойчивая связь, переподключения. С чем это связано – непонятно.
Начиная с сегодняшнего дня работать в AnyDesk практически невозможно, сеанс продолжается буквально несколько минут, после чего обрывается с сообщением «Сетевое соединение было неожиданно прервано».
Проблема массовая, от провайдера и типа доступа в интернет не зависит. У многих работа оказалась полностью парализована, особенно кто использовал AnyDesk для удаленного доступа на рабочее место или поддержки.
Ситуация осложняется, если подключаться приходится к сеансу с пониженными правами, в этом случае приходится сажать с той стороны человека, который будет постоянно разрешать повышение прав или за вас нажимать кнопки на экране.
А если там действительно ограниченные права, то сажать придется уже местного администратора (которого тоже не всегда можно найти на месте).
Использование КВН проблемы не решит, так как это придется делать массово и у себя, и у заказчиков, что проблемно, особенно если заказчики небольшие и работы нерегулярные. Плюс нет никакого понимания природы проблемы.
Это может быть как отечественное небезызвестное ведомство, которое пристально следит, чтобы никто не пошел туда, не надо куда, либо могут быть сами владельцы AnyDesk в свете выполнения каких-нибудь очередных санкции или борьбы с халявщиками.
В общем будем думать и смотреть, а пока потихоньку переводим заказчиков на Ассистент, который видится более-менее полноценной заменой AnyDesk.
😁23👍15😢9😱4🤮2
Почему не следует предоставлять заказчикам использование собственной инфраструктуры
В комментариях к заметке о проблемах с AnyDesk некоторые читатели указали, что поднимаете свой сервер Aspia/Rustdesk и подключаете клиента через него, даже разового.
Многие также предоставляют клиенту платно или бесплатно (а также в рамках абонплаты) некоторые ресурсы собственной инфраструктуры, скажем сервера для синхронизации, инструменты мониторинга, место под резервные копии, хостинг и т.д. и т.п.
С одной стороны, это удобно и позволяет на «ровном месте» заработать дополнительную копеечку. Так думают многие, особенно небольшие аутсорсеры или самозанятые в этой области. Многие вообще не документируют подобные услуги и считают, что это обезопасит их от подобных претензий.
Но тут мы вступаем на скользкую тропу юридических вопросов, которые нужно принимать во внимание, если мы в один не очень прекрасный день не хотим получить крайне серьезный набор проблем на ровном месте.
Начнем с того, что если вы имеете свой сервер удаленного доступа, файлообменник, чат-сервер, тикет-систему и т.д. и используете ее исключительно в рамках оказания услуг клиенту – это одно, все это – просто инструмент для оказания услуги и отдельной услугой не является.
Но как только вашими услугами смогут воспользоваться третьи лица для связи между собой, даже если это два сотрудника вашего заказчика – то ситуация с юридической точки зрения кардинально меняется.
Если бухгалтер заказчика через ваш сервер удаленного доступа получает доступ к своему рабочему месту или сотрудники техподдержки заказчика общаются с работниками заказа в общем чате техподдержки на базе вашей инфраструктуры – то вы становитесь оператором услуг по передаче данных. А ваша инфраструктура становится шлюзом, через которую взаимодействуют третьи лица.
При этом не важно – берете вы за это деньги, не берете, оформили это как-то документально или нет – вы осуществляете деятельность характерную для оператора связи. Именно на характер деятельность смотрят Роскомнадзор и суды.
А деятельность оператора связи требует лицензирования, что уже является составом административного правонарушения, если не повлекло более серьезных последствий.
Если вы предоставляете заказчику возможность размещать у вас любые ресурсы доступные неограниченному кругу лиц, то вы становитесь организатором распространения информации (ОРИ) со всеми вытекающими оттуда требованиями.
И если вы еще как-то можете откреститься от предоставления услуг связи, то от обязанностей ОРИ отвертеться уже не получится, потому как отрицать очевидное (размещение ресурса заказчика на вашей инфраструктуре) вы не сможете.
Либо, переложив эту функцию на заказчика вы тут же станете оператором связи без лицензии.
Но это все цветочки, чтобы вас прижали на этой теме нужно либо прицельно попасть на карандаш регулирующим органам, либо органы должны заинтересоваться вашим клиентом и через это выйти на вас.
Сценарий редкий, но сбрасывать его со счетов не стоит, клиент может не только где-то накосячить, но и пройти потерпевшим, а там снова начнется разбор полетов: что, откуда, зачем и как.
Сегодня гораздо большую угрозу представляет законодательство о персональных данных (ПДн) где последнее время серьезно закрутили гайки и серьезно увеличили штрафы.
Если через ваш сервер проходят персональные данные клиентов – поздравляем, вы оператор, хотя вы можете их не собирать, не сохранять, не обрабатывать. Если среди ваших заказчиков есть клиенты с особыми требованиями к ПДн, скажем, медицина – то становится еще более весело.
А если вас дернуло использовать для своей инфраструктуры зарубежный хостинг, то это уже трансграничная передача ПДн и вы попали. Возможно, крепко попали.
Причем попасть тут можно легче легкого, вас может просто сдать ваш клиент, как по недомыслию, просто указав в уведомлении об обработке ПДн, так и умышленно, переведя стрелки при проверке или каких-либо нарушениях. Мол ничего не знаю, все они.
А можно оказаться вообще между двух огней, скажем если у вас была трансграничная передача ПДн, а клиент об этом ни сном, ни духом.
В комментариях к заметке о проблемах с AnyDesk некоторые читатели указали, что поднимаете свой сервер Aspia/Rustdesk и подключаете клиента через него, даже разового.
Многие также предоставляют клиенту платно или бесплатно (а также в рамках абонплаты) некоторые ресурсы собственной инфраструктуры, скажем сервера для синхронизации, инструменты мониторинга, место под резервные копии, хостинг и т.д. и т.п.
С одной стороны, это удобно и позволяет на «ровном месте» заработать дополнительную копеечку. Так думают многие, особенно небольшие аутсорсеры или самозанятые в этой области. Многие вообще не документируют подобные услуги и считают, что это обезопасит их от подобных претензий.
Но тут мы вступаем на скользкую тропу юридических вопросов, которые нужно принимать во внимание, если мы в один не очень прекрасный день не хотим получить крайне серьезный набор проблем на ровном месте.
Начнем с того, что если вы имеете свой сервер удаленного доступа, файлообменник, чат-сервер, тикет-систему и т.д. и используете ее исключительно в рамках оказания услуг клиенту – это одно, все это – просто инструмент для оказания услуги и отдельной услугой не является.
Но как только вашими услугами смогут воспользоваться третьи лица для связи между собой, даже если это два сотрудника вашего заказчика – то ситуация с юридической точки зрения кардинально меняется.
Если бухгалтер заказчика через ваш сервер удаленного доступа получает доступ к своему рабочему месту или сотрудники техподдержки заказчика общаются с работниками заказа в общем чате техподдержки на базе вашей инфраструктуры – то вы становитесь оператором услуг по передаче данных. А ваша инфраструктура становится шлюзом, через которую взаимодействуют третьи лица.
При этом не важно – берете вы за это деньги, не берете, оформили это как-то документально или нет – вы осуществляете деятельность характерную для оператора связи. Именно на характер деятельность смотрят Роскомнадзор и суды.
А деятельность оператора связи требует лицензирования, что уже является составом административного правонарушения, если не повлекло более серьезных последствий.
Если вы предоставляете заказчику возможность размещать у вас любые ресурсы доступные неограниченному кругу лиц, то вы становитесь организатором распространения информации (ОРИ) со всеми вытекающими оттуда требованиями.
И если вы еще как-то можете откреститься от предоставления услуг связи, то от обязанностей ОРИ отвертеться уже не получится, потому как отрицать очевидное (размещение ресурса заказчика на вашей инфраструктуре) вы не сможете.
Либо, переложив эту функцию на заказчика вы тут же станете оператором связи без лицензии.
Но это все цветочки, чтобы вас прижали на этой теме нужно либо прицельно попасть на карандаш регулирующим органам, либо органы должны заинтересоваться вашим клиентом и через это выйти на вас.
Сценарий редкий, но сбрасывать его со счетов не стоит, клиент может не только где-то накосячить, но и пройти потерпевшим, а там снова начнется разбор полетов: что, откуда, зачем и как.
Сегодня гораздо большую угрозу представляет законодательство о персональных данных (ПДн) где последнее время серьезно закрутили гайки и серьезно увеличили штрафы.
Если через ваш сервер проходят персональные данные клиентов – поздравляем, вы оператор, хотя вы можете их не собирать, не сохранять, не обрабатывать. Если среди ваших заказчиков есть клиенты с особыми требованиями к ПДн, скажем, медицина – то становится еще более весело.
А если вас дернуло использовать для своей инфраструктуры зарубежный хостинг, то это уже трансграничная передача ПДн и вы попали. Возможно, крепко попали.
Причем попасть тут можно легче легкого, вас может просто сдать ваш клиент, как по недомыслию, просто указав в уведомлении об обработке ПДн, так и умышленно, переведя стрелки при проверке или каких-либо нарушениях. Мол ничего не знаю, все они.
А можно оказаться вообще между двух огней, скажем если у вас была трансграничная передача ПДн, а клиент об этом ни сном, ни духом.
💯27👍20❤8👀5🥱4
Zabbix get – получаем информацию от Zabbix через CLI
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
Или аптайм:
А вот при попытке получить утилизацию памяти в % получим ошибку:
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
apt install zabbix-get
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
Server агента, в противном случае вы получите ошибку:Check access restrictions in Zabbix agent configuration
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
zabbix_get -s host-name-or-IP [-p port-number] -k item-key
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
zabbix_get -s 192.168.101.198 -p 10050 -k agent.ping
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
zabbix_get -s 192.168.101.198 -p 10050 -k system.cpu.util
Или аптайм:
zabbix_get -s 192.168.101.198 -p 10050 -k system.uptime
А вот при попытке получить утилизацию памяти в % получим ошибку:
zabbix_get -s 192.168.101.198 -k vm.memory.util
ZBX_NOTSUPPORTED: Unknown metric vm.memory.util
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
👍31❤5🤮1
По мотивам реальных событий
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
🔹
🔹
👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'
UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
-F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.🔹
{avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.🔹
END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
nvme-pci-0100
Adapter: PCI adapter
Composite: +37.9°C (low = -0.1°C, high = +114.8°C)
(crit = +119.8°C)
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
sensors | grep nvme-pci-0100 -A 2
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
sensors | grep nvme-pci-0100 -A 2 | tail -n 1
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
👍37❤4🔥3🤮1
Маска /31
Если говорить о современных сетях, то там хватает достаточно интересных особенностей. Одной из них являются сети с маской /31.
Чем интересна эта маска? А тем, что она занимает 31 бит из 32 возможных и на указание адреса хоста у нас остается единственный бит, что подразумевает только два значения.
Но позвольте, в сети первый адрес является адресом сети, а последний широковещательным адресом. Получается, что в сети /31 не может быть ни одного адреса хоста и зачем нужна такая сеть?
А давайте немного отойдем в сторону и вспомним о существовании таких соединений как точка-точка (Point-to-Point, PtP).
Их особенностью является то, что для работы такого соединения IP-адреса не нужны, любой пакет, направленный на один конец такого соединения, будет отправлен на противоположную сторону средствами протокола PPP.
Но для нормальной работы сетевых служб, использующих IP такие адреса нам, понадобятся в количестве 2 шт. на одно соединение. Такой вот парадокс.
Кстати, этим свойством можно пользоваться на практике, например, вам нужно указать маршрут на шлюз провайдера через PPPoE который имеет динамический адрес.
В таком случае просто присваиваете обоим концам туннеля произвольные свободные адреса и используете их, на работу соединения PPPoE это абсолютно никак не повлияет.
Если у вас таких соединений единицы, ну или даже десяток – то особой проблемы нет. Вы можете щедрой рукой раздавать PtP линкам хоть /24 сети из серых диапазонов (одного диапазона 10.0.0.0/8 хватит надолго).
Но все меняется если вы становитесь крупным провайдером или испытываете ограничения в используемом адресном диапазоне.
Минимальная сеть на 2 хоста – сеть /30, но при этом она ужасно неэффективна с точки зрения расходования адресного пространства. На два адреса сети у нас теряется еще два адреса на саму сеть и широковещание. В итоге мы теряем половину адресного пространства на служебные нужды.
Чтобы этого избежать в далеком 2000 году был принят стандарт RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links разрешающий использовать сети /31 для соединений точка-точка.
В этом случае мы используем два доступных адреса для каждой стороны соединения, чем достигается существенная экономия адресов.
Но у таких сетей есть свои особенности, например, в них не будут работать широковещательные протоколы, так как широковещательного адреса у нас нет, он занят под адрес узла.
При необходимости можно использовать адрес ограниченного широковещания 255.255.255.255, но на сегодняшний момент это не представляет проблему, все современные протоколы нормально умеют работать с такими сетями.
С другой стороны, это можно рассматривать как плюс, так как повышается устойчивость таких каналов к некоторым типам DDoS-атак, использующих широковещание.
Единственной существующей проблемой для сетей /31 является их поддержка со стороны производителей оборудования, особенно класса SOHO и не только.
К примеру, нормальная поддержка /31 отсутствует в оборудовании Mikrotik, хотя возможность такого использования есть, хоть и не очень очевидная.
Если говорить о современных сетях, то там хватает достаточно интересных особенностей. Одной из них являются сети с маской /31.
Чем интересна эта маска? А тем, что она занимает 31 бит из 32 возможных и на указание адреса хоста у нас остается единственный бит, что подразумевает только два значения.
Но позвольте, в сети первый адрес является адресом сети, а последний широковещательным адресом. Получается, что в сети /31 не может быть ни одного адреса хоста и зачем нужна такая сеть?
А давайте немного отойдем в сторону и вспомним о существовании таких соединений как точка-точка (Point-to-Point, PtP).
Их особенностью является то, что для работы такого соединения IP-адреса не нужны, любой пакет, направленный на один конец такого соединения, будет отправлен на противоположную сторону средствами протокола PPP.
Но для нормальной работы сетевых служб, использующих IP такие адреса нам, понадобятся в количестве 2 шт. на одно соединение. Такой вот парадокс.
Кстати, этим свойством можно пользоваться на практике, например, вам нужно указать маршрут на шлюз провайдера через PPPoE который имеет динамический адрес.
В таком случае просто присваиваете обоим концам туннеля произвольные свободные адреса и используете их, на работу соединения PPPoE это абсолютно никак не повлияет.
Если у вас таких соединений единицы, ну или даже десяток – то особой проблемы нет. Вы можете щедрой рукой раздавать PtP линкам хоть /24 сети из серых диапазонов (одного диапазона 10.0.0.0/8 хватит надолго).
Но все меняется если вы становитесь крупным провайдером или испытываете ограничения в используемом адресном диапазоне.
Минимальная сеть на 2 хоста – сеть /30, но при этом она ужасно неэффективна с точки зрения расходования адресного пространства. На два адреса сети у нас теряется еще два адреса на саму сеть и широковещание. В итоге мы теряем половину адресного пространства на служебные нужды.
Чтобы этого избежать в далеком 2000 году был принят стандарт RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links разрешающий использовать сети /31 для соединений точка-точка.
В этом случае мы используем два доступных адреса для каждой стороны соединения, чем достигается существенная экономия адресов.
Но у таких сетей есть свои особенности, например, в них не будут работать широковещательные протоколы, так как широковещательного адреса у нас нет, он занят под адрес узла.
При необходимости можно использовать адрес ограниченного широковещания 255.255.255.255, но на сегодняшний момент это не представляет проблему, все современные протоколы нормально умеют работать с такими сетями.
С другой стороны, это можно рассматривать как плюс, так как повышается устойчивость таких каналов к некоторым типам DDoS-атак, использующих широковещание.
Единственной существующей проблемой для сетей /31 является их поддержка со стороны производителей оборудования, особенно класса SOHO и не только.
К примеру, нормальная поддержка /31 отсутствует в оборудовании Mikrotik, хотя возможность такого использования есть, хоть и не очень очевидная.
👍35🤔8❤4🤮1🤝1
VPN и шифрование
VPN сейчас в тренде, понятно, время такое. Но вот то, что иногда делают с ним, вроде бы технически грамотные люди – решительно непонятно.
Любимое народное развлечение – это накрутить на туннель шифров, да побольше, да посильнее. Особенно любят баловаться этим на Mikrotik.
И мы сейчас не про VPN для удаленного доступа, а про тот который пойди туда не знаю куда. После чего сразу поступают вопросы – а чего это все так медленно?
Вот здесь и хочется спросить: а что и от кого вы шифруете? И зачем?
Безопасность на уровне приложений решается с помощью SSL (HTTPS) и это действительно надежно.
Хотим приватности от провайдера - добавляем DNS over HTTPS и этого достаточно.
Если вам ходить туда, не знаю куда - то вам нужна только "труба" с точкой выхода там, не знаю где. Все что должно быть зашифровано - и так зашифровано, что нет - так и пойдет открытым текстом от точки выхода до пункта назначения.
Здесь хватит простого и быстрого шифра и нет никакого смысла во всяких AES-256 + SHA-512. Разве что дома холодно, и вы решили погреться от роутера.
VPN сейчас в тренде, понятно, время такое. Но вот то, что иногда делают с ним, вроде бы технически грамотные люди – решительно непонятно.
Любимое народное развлечение – это накрутить на туннель шифров, да побольше, да посильнее. Особенно любят баловаться этим на Mikrotik.
И мы сейчас не про VPN для удаленного доступа, а про тот который пойди туда не знаю куда. После чего сразу поступают вопросы – а чего это все так медленно?
Вот здесь и хочется спросить: а что и от кого вы шифруете? И зачем?
Безопасность на уровне приложений решается с помощью SSL (HTTPS) и это действительно надежно.
Хотим приватности от провайдера - добавляем DNS over HTTPS и этого достаточно.
Если вам ходить туда, не знаю куда - то вам нужна только "труба" с точкой выхода там, не знаю где. Все что должно быть зашифровано - и так зашифровано, что нет - так и пойдет открытым текстом от точки выхода до пункта назначения.
Здесь хватит простого и быстрого шифра и нет никакого смысла во всяких AES-256 + SHA-512. Разве что дома холодно, и вы решили погреться от роутера.
👍41🤔10🥱4🤝3🔥1
Еще раз про Load Average и логические / виртуальные ядра
Сегодня в очередной раз столкнулся с неверным пониманием такого важного параметра, как Load Average.
Уже неизвестно откуда пошла такая теория, что логические, а тем более виртуальные ядра искажают значение LA просто потому, что они «ненастоящие». Но она оказалась живучей и до сих пор бродит в IT-среде как призрак коммунизма.
На самом деле это не так, потому что Load Average – это не физический параметр и тем более не показатель нагрузки на CPU или его производительности.
Это относительное значение, показывающее доступность вычислительных ресурсов в системе.
Мы знаем, что процессор выделяет каждому нуждающемуся в вычислениях процессу некоторое время, называемое тиком, в течении которого процесс получает доступ к вычислительным ресурсам ЦПУ.
Если мы возьмем некоторое время, а при вычислении LA берется промежуток из 5000 тиков, то это самое количество тиков мы можем принять за
Таким образом значение
А если процессов больше, чем доступных тиков? Возникает очередь и LA начинает принимать значения выше единицы. При этом
Таким образом тормозная дисковая подсистема также может сильно увеличить значение LA при фактическом простое процессора.
Корректно ли это? Да, корректно, так как процесс нуждается в вычислительных ресурсах, но не может их получить, по какой причине – это уже совсем отдельная история.
Что будет если мы добавим еще одно ядро, не важно физическое, логическое или виртуальное. У нас появятся еще 5000 тиков и полной нагрузке на систему будет соответствовать
Означает ли это, что производительность выросла вдвое? Нет. Производительность зависит от того, сколько операций за единицу времени может выполнить конкретное ядро.
Но теперь за одну и ту же единицу времени доступ к CPU получат уже не 5 000, а 10 000 процессов. А, как известно, лучше плохо ехать, чем хорошо стоять.
Таким образом максимальный LA всегда считается по количеству доступных системе ядер, а их происхождение неважно.
✅ Читать далее
Сегодня в очередной раз столкнулся с неверным пониманием такого важного параметра, как Load Average.
Уже неизвестно откуда пошла такая теория, что логические, а тем более виртуальные ядра искажают значение LA просто потому, что они «ненастоящие». Но она оказалась живучей и до сих пор бродит в IT-среде как призрак коммунизма.
На самом деле это не так, потому что Load Average – это не физический параметр и тем более не показатель нагрузки на CPU или его производительности.
Это относительное значение, показывающее доступность вычислительных ресурсов в системе.
Мы знаем, что процессор выделяет каждому нуждающемуся в вычислениях процессу некоторое время, называемое тиком, в течении которого процесс получает доступ к вычислительным ресурсам ЦПУ.
Если мы возьмем некоторое время, а при вычислении LA берется промежуток из 5000 тиков, то это самое количество тиков мы можем принять за
100% или единицу. Таким образом значение
1 для LA означает, что все тики были отданы процессам, но очереди не возникло. А если LA = 0.25 – то это значит, что процессы использовали только четверть доступных тиков.А если процессов больше, чем доступных тиков? Возникает очередь и LA начинает принимать значения выше единицы. При этом
LA > 1 вовсе не означает недостатка именно процессорных ресурсов, процесс может не использовать свой тик по причине ожидания, например, дискового ввода вывода. Таким образом тормозная дисковая подсистема также может сильно увеличить значение LA при фактическом простое процессора.
Корректно ли это? Да, корректно, так как процесс нуждается в вычислительных ресурсах, но не может их получить, по какой причине – это уже совсем отдельная история.
Что будет если мы добавим еще одно ядро, не важно физическое, логическое или виртуальное. У нас появятся еще 5000 тиков и полной нагрузке на систему будет соответствовать
LA = 2.Означает ли это, что производительность выросла вдвое? Нет. Производительность зависит от того, сколько операций за единицу времени может выполнить конкретное ядро.
Но теперь за одну и ту же единицу времени доступ к CPU получат уже не 5 000, а 10 000 процессов. А, как известно, лучше плохо ехать, чем хорошо стоять.
Таким образом максимальный LA всегда считается по количеству доступных системе ядер, а их происхождение неважно.
✅ Читать далее
👍15🔥4❤2🤮1🤝1
Настраиваем Uptime Kuma с обратным прокси-сервером Caddy и TLS-защитой
Популярная система мониторинга Uptime Kuma представляет собой обычное веб-приложение и не имеет встроенных средств защиты, поэтому для ее публикации во внешнюю сеть нам потребуется обратный прокси, который будет брать на себя работу с TLS-сертификатами.
Традиционно это решается при помощи Certbot и Nginx, но есть способ проще – веб-сервер Caddy, который крайне прост в настройках и показывает отличную производительность при скромном потреблении ресурсов.
В целом особой проблемы запустить связку Uptime Kuma и Caddy нет, но всегда полезно читать официальную документацию. Так в документации Uptime Kuma мы нашли отсылку к проекту Caddy-Docker-Proxy, который работает с контейнерами Docker при помощи меток.
Таким образом нам вообще практически не надо ничего настраивать, плюс мы получаем возможность использовать Caddy и для других развернутых на этом хосте контейнеров, получив своего рода Traefik «на минималках».
Интересно? Тогда приступим. Нам потребуется следующий docker-compose.yml
Все, что вам потребуется в нем поменять – это вместо uptime.example.com указать свой домен.
После чего просто делаем
И переходим в браузере по указанному адресу.
Если вам нужно использовать этот же контейнер Caddy для других контейнеров, то просто добавьте к нему метки:
Где вы указываете желаемый внешний домен и порт внутреннего контейнера. Теперь при его запуске Caddy на лету изменит свою конфигурацию и начнет проксирование для нового сервиса.
Популярная система мониторинга Uptime Kuma представляет собой обычное веб-приложение и не имеет встроенных средств защиты, поэтому для ее публикации во внешнюю сеть нам потребуется обратный прокси, который будет брать на себя работу с TLS-сертификатами.
Традиционно это решается при помощи Certbot и Nginx, но есть способ проще – веб-сервер Caddy, который крайне прост в настройках и показывает отличную производительность при скромном потреблении ресурсов.
В целом особой проблемы запустить связку Uptime Kuma и Caddy нет, но всегда полезно читать официальную документацию. Так в документации Uptime Kuma мы нашли отсылку к проекту Caddy-Docker-Proxy, который работает с контейнерами Docker при помощи меток.
Таким образом нам вообще практически не надо ничего настраивать, плюс мы получаем возможность использовать Caddy и для других развернутых на этом хосте контейнеров, получив своего рода Traefik «на минималках».
Интересно? Тогда приступим. Нам потребуется следующий docker-compose.yml
networks:
default:
name: "proxy_network"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
restart: unless-stopped
volumes:
- /srv/uptime:/app/data
labels:
caddy: uptime.example.com
caddy.reverse_proxy: "* {{upstreams 3001}}"
caddy:
image: "lucaslorentz/caddy-docker-proxy:ci-alpine"
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- /srv/caddy/:/data
restart: unless-stopped
environment:
- CADDY_INGRESS_NETWORKS=proxy_network
Все, что вам потребуется в нем поменять – это вместо uptime.example.com указать свой домен.
После чего просто делаем
docker compose up -d
И переходим в браузере по указанному адресу.
Если вам нужно использовать этот же контейнер Caddy для других контейнеров, то просто добавьте к нему метки:
caddy: service.example.com
caddy.reverse_proxy: "* {{upstreams 8080}}"
Где вы указываете желаемый внешний домен и порт внутреннего контейнера. Теперь при его запуске Caddy на лету изменит свою конфигурацию и начнет проксирование для нового сервиса.
51👍28🤝2
Имитация плохого канала в Mikrotik
Время от времени требуется проверить работу сетевых приложений и служб в условиях плохого канала.
Это легко сделать на оборудовании Mikrotik при помощи опции Random в правилах брандмауэра. Допустимые значения от 1 до 100, которые указывают вероятность срабатывания правила в процентах.
Затем создаем правило, которое будет блокировать пакеты, ставим ему нужную вероятность и поднимаем на самый верх цепочки, во всяком случае выше правила для ESTABLISHED и RELATED.
Самый простой пример:
Данное правило будет блокировать случайным образом 3% проходящих через него пакетов.
Но этим возможности не ограничиваются, вы можете составлять собственные правила с использованием всех доступных критериев. Т.е. имитировать сбои только по определенным протоколам и направлениям.
В общем инструмент есть, а как его применить – это уже каждый думает самостоятельно.
Время от времени требуется проверить работу сетевых приложений и служб в условиях плохого канала.
Это легко сделать на оборудовании Mikrotik при помощи опции Random в правилах брандмауэра. Допустимые значения от 1 до 100, которые указывают вероятность срабатывания правила в процентах.
Затем создаем правило, которое будет блокировать пакеты, ставим ему нужную вероятность и поднимаем на самый верх цепочки, во всяком случае выше правила для ESTABLISHED и RELATED.
Самый простой пример:
add action=drop chain=forward in-interface=bridge1 out-interface=ether5 random=3
Данное правило будет блокировать случайным образом 3% проходящих через него пакетов.
Но этим возможности не ограничиваются, вы можете составлять собственные правила с использованием всех доступных критериев. Т.е. имитировать сбои только по определенным протоколам и направлениям.
В общем инструмент есть, а как его применить – это уже каждый думает самостоятельно.
🔥29👍12❤4🤔2🤮1
Самозаверенные сертификаты. Мифы и реальность.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
👍27🥱6❤2🤔1🤝1