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

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

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

Greylisting используя Exim ratelimit

Greylisting using Exim ratelimit

Max Kostikov

Составление "серых списков" (greylising) отправителей электронной почты в том или ином виде и работа с ними в почтовых системах являются одной из популярных методик борьбы со спамом. Вкратце, её суть состоит в ограничении и / или откладывании приёма сообщения от подозрительных хостов.

Список этих хостов может формироваться на основании синтаксического разбора начальной сессии или, к примеру, на основании ранее накопленной статистики антиспам-подсистемы на данном сервере (см. статью "Использование статистики Spamassassin в конфигурации Exim"). Главным критерием при этом должно стать обеспечение беспрепятственной и быстрой доставки корреспонденции от хостов с хорошей репутацией и создание трудностей для тех отправителей, которые по принятым критериям потенциально (или реально) могут быть отнесены к рассыльщикам несанкционированной почты. При этом предпологается, то корректно настроенные серверы будут осуществлять повторную отправку через не слишком короткие, со временем увеличивающиеся интервалы, а спамеры будут пытаться осуществлять массированную отправку в кратчайшие сроки, стремясь накрыть как можно больший набор адресатов до момента блокировки и / или включения в общедоступные списки оценки саммеров, такие как DNSBL и на базе контрольных сумм.

Max Kostikov

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

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

Особенностям конфигурирования почтовых систем для беспроблемной работы с такого рода отправками и посвещена данная статья.

Max Kostikov

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

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

Рассмотрим механизм реализации такого двухуровневого квотирования используя возможности POP3 / IMAP4 сервера Dovecot 2.

Max Kostikov

Тема особенностей использования Domain-based Message Authentication, Reporting and Conformance или DMARC уже затрагивалась в рамках этого блога. Теперь хотелось бы остановиться на уже упомянутой в статье "DMARC для борьбы со спам на локальном и глобальном фронтах" особенностью обработки DMARC связанной с использованием возможности постепенного введения в действие политик типа quarantine и reject через использование их процентного модификатора.

К примеру, для отправителей из домена kostikov.co в соответствующей DMARC DNS-записи мы имеем следующее описание.

root@beta:~ # host -t txt _dmarc.kostikov.co
_dmarc.kostikov.co descriptive text "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@kostikov.co"
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=
...