Max Kostikov

Вернуться к теме обучения антиспам-фильтров в Dovecot, которая ранее уже затрагивалась в одной из статей на этом сайте, меня заставило недавнее сообщение от всё помнящего "Charlie Root" прекращении поддержки широко используемого для этих нужд расширения Antispam plugin.

To: root@my.server
Subject: my.server weekly security run output
Message-Id: <E1dObLP-000MHX-25@my.server>
From: Charlie Root <root@my.server>
Date: Sat, 24 Jun 2017 05:02:43 +0200

Checking for packages with security vulnerabilities:
dovecot2-antispam-plugin-20130429_29: Tag: expiration_date Value: 2017-07-31
dovecot2-antispam-plugin-20130429_29: Tag: deprecated Value: Use pigeonhole instead. See https://wiki2.dovecot.org/HowTo/AntispamWithSieve

-- End of security output --
Max Kostikov

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

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

Max Kostikov

Вопросы безопасности в целом, и проблемы аутентификации в частности, уже давно являются главной проблемой функционирования сети Интернет. К настоящему времени разработана масса способов, протоколов и стандартов, призванных сделать работу в глобальном киберпространстве надёжной и защищённой от различного рода угроз. К примеру, одним из самых известных и широкоупотребимых механизмов обеспечения безопасности является протокол HTTPS, который предназначен для передачи данных, в основном, во Всемирной паутине на базе криптографических методов SSL / TLS. Последние же неотъемлемо связаны с инфраструктурой удостоверяющих центров (CA), которые через цепочку доверия посредством цифровых подписей призваны гарантировать подлинность того или иного ресурса в сети.

Если удостоверяющий центр включён в список доверенных для данного программного обеспечения, в частности браузера в случае с протоколом HTTPS, то узел сети использующий выданный этим CA сертификат заведомо признаётся подлинным и, следовательно, заслуживающим доверия. Однако, именно здесь и находится главная проблема данной системы. Пользователь вынужден слепо доверять всем сертификатам, которые такие доверенные удостоверяющие центры выдали стороннему по отношению к ним самим ресурсу. При этом, нет никаких гарантий что это было сделано с ведома самого владельца такого ресурса. Ставшие достоянием общественности в последние годы многочисленные прецеденты выпуска известными удостоверяющими центрами сертификатов с серьёзными нарушениями правил их выдачи, самым громким из которых явился случай с DigiNotar, вновь поставили вопрос доверия к самой системе CA со стороны пользователей и заказчиков, а также разработку и внедрение более надёжных методов аутентификации в Интернет.

Max Kostikov

Интернет-технологии, которые давно стали неотъемлемой частью жизни большей части человечества, постоянно развиваются и совершенствуются.

Не является и исключением и один из самых широко распространённых сетевых протоколов - HTTP, являющейся базой для функционирования Всемирной паутины. Появившись на свет в 1992 году, за прошедшее HTTP претерпел множество усовершенствований и измений включая и его вторую версию — HTTP/2, переход на которую в настоящее время набирает обороты. Так, по состоянию на май 2017 года HTTP/2 используется около 14% всех видимых в сети Интернет сайтов.

Если не останавливаться здесь подробно на преимуществах использования второй версии HTTP над предшествующими (с подробным описанием каковых читатель может ознакомиться самостоятельно в многочисленных статьях доступных в сети), то тезисно можно сказать, что, HTTP/2 существенно быстрее HTTP/1 и HTTP/1.1 благодаря бинарной форме передачи данных, наличию встроенного сжатия заголовков, мультиплексированию соединений, а также возможности приоретизировать передачу данных добиваясь, вследствие всего этого, существенно более быстрой отрисовки сайтов у пользователей.

Max Kostikov

Интернет полон руководств о том, как можно просто и удобно организовать поддержку системы электронной почты для собственного корпоративного домена используя возможности, предоставляемые Google.

Казалось бы, ваша корпоративная почта на Google mail получает лишь одни преимущества, к примеру, в виде стандартизированного интерфейса, качественной защиты от спама, наличие общего календаря и доступа к документам. И всё это при простом развёртывании и высокой надёжности системы.

Однако, как и во всякой бочке мёда, здесь возможно отыскать и предостаточно дёгтя. Причём дёгтя настолько горького, что под сомнение может быть поставлена сама целесообразность такого подхода. Особенно болезненным понимание проблем, ограничений и даже угроз, которое может нести использование Google mail для поддержки корпоративной почты может стать для тех, кто изначально полностью положился на такое решение.

Но, обо всё по порядку.

Max Kostikov

Сегодня блогу kostikov.co исполняется один год!

Именно в этот день ровно год назад был опубликован первый пост "Получаем и обновляем SSL сертификат Let's Encrypt" который и спустя год является самым популярным материалом на сайте с 1723 просмотрами на данный момент. И это неудивительно, ведь он появился как раз в тот момент, когда начался взрывной рост перехода сайтов на использование протокола HTTPS.

От недели к неделе автор наблюдает рост посещаемости, которая теперь, спустя год, составляет в не менее 40 посещений ежедневно при 90% новых уникальных заходов. Всё это значит, что идея, которая закладывалась при создании данного блога — делиться знаниями со всеми, кто хочет глубже знать и понимать современные интернет-технологии, удалась.

Max Kostikov

Вопросы обеспечения безопасности различных сервисов в сети Интернет занимают существенное место в тематике статей этого сайта. Это не случайно, поскольку именно эта проблематика с каждым годом становится всё более важной частью работы во всемирной сети являясь существенным стимулом для технологического прогресса.

Среди последних проявлений такого прогресса можно отметить и недавнее решение CA/Browser Forum о необходимости обязательного использования контроля DNS-записей типа CAA (Certification Authority Authorization) в процессе выдачи SSL-сертификатов начиная с сентября 2017 года.

Скрипт синхронизации набора каталогов в облако Mega

Shell-script to syncronize directory list to Mega cloud drive

Max Kostikov

И вновь по просьбам помочь с усовершенствованием скрипта синхронизации с облачным харанилищем Mega, описанным в соответствующей статье, публикую его доработанную с учётом пожеланий версию.

Основным ограничением упомянутого выше скрипта является его направленность на работу исключительно с одним конкретным каталогом (и, конечно же, вложенным в него, подкаталогами и файлами). При этом в качестве маркера времени для отслеживания изменений выступает дата модификации ведущегося файла протокола.

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