Max Kostikov

Вероятно, постоянные читатели блога kostikov.co заметили, что он, как, впрочем, и ряд других поддерживаемых автором HTTP-серверов, работают на базе Lighttpd. Действительно, этот быстрый и лёгкий веб-сервер снискал широкую популярность и был широко распространён в качестве лучшей альтернативы стандартному Apache. Однако, с течением времени и неизбежным прогрессом в сетевых технологиях разработчики Lighttpd заметно отстали в их поддержке, а конкуренты, в лице, главным образом, Nginx, за тот же интервал существенно нарастил функционал и стал куда более распространённым решением.

Наиболее существенным недостатком Lighttpd представляется отсутствие в настоящее время поддержки им современной версии протокола HTTP/2, которая имеет большое количество преимуществ перед предыдущими версиями. Также минусом этого веб-сервера является отсутствие поддержки протокола Online Certificate Status Protocol (OCSP), который начинает приобретать важное значение в свете борьбы со злоупотреблениями при выпуске SSL-сертификатов.

В связи с вышеизложенным, после изучения возможных альтернатив, автор принял решение о переносе блога на HTTP/2 сервер H2O, которому ранее была посвещена обзорная статья, как на наиболее прогрессивный и перспективный в обозримом будущем вариант.

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 благодаря бинарной форме передачи данных, наличию встроенного сжатия заголовков, мультиплексированию соединений, а также возможности приоретизировать передачу данных добиваясь, вследствие всего этого, существенно более быстрой отрисовки сайтов у пользователей.

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

Shell-script to syncronize directory list to Mega cloud drive

Max Kostikov

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

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

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

Max Kostikov

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

Цифровые подписи DNSSEC в целях безопасности имеют ограниченный срок действия. Увидеть его, равно как и дату подписи, можно в специально предназначенной для этого DNS-записи RRSIG.

root@beta:~ # drill -D peek.ru
...
peek.ru.        86400   IN      A       78.40.219.163
peek.ru.        86400   IN      RRSIG   A 6 2 86400 20161211171306 20161113171306 15134 peek.ru. ABZnLbVjEnQFk7sHoPH2iEX8KRygMjsRSsGzdMVy2scDrMsr8TQSCbs=
...
Max Kostikov

Использование механизма DKIM в системе оборота электронной почты в последние годы получило широкое распространение.

Вкратце, суть его состоит в использовании цифровой подписи (пара открытый и закрытый ключи) к набору заголовков и тексту сообщения, которая позволяет подтвердить легитимность его происхождения. Благодаря этому DKIM в связке с механизмом SPF в надстройке в виде политик DMARC, в настоящее время являются одними из популярных способов борьбы с несанкционированными рассылками (спамом).

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

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