Открываем исходящий SMTP трафик по IPv6 на DigitalOcean

How to open outgoing IPv6 SMTP traffic on DigitalOcean

Хостинг-провайдер DigitalOcean пользуется большой популярностью среди размещающих свои ресурсы и сервисы в сети Интернет. Не буду перечислять его преимущества, которые и так достаточно широко известны. Остановлюсь лишь на одном из недостатков, который может стать неприятной неожиданностью для впервые использующих ресурсы DigitalOcean, а именно невозможности использовать представляемые IPv6 адреса для исходящего почтового трафика. Для IPv6 заблокированы на выход порты 25, 465 и 587. При этом входящий трафик для IPv6 равно как и SMTP-трафик в обеих направлениях для IPv4 открыт.

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

В качестве возможного решения автор предлагает использовать возможности туннелирования IPv6 адресов внутри IPv4 трафика обепечив, таким образом, использование выделенной подсети на удалённом хосте. Благодаря этому может быть обеспечен обход блокировок исходящего SMTP-трафика и возможность полноценной в этом плане работы на серверах DigitalOcean. Кроме того, получение полного набора адресов IPv6 /64 сети, вместо всего лишь /128 которая предоставляются хостингом, может быть полезно и для других размещаемых сетевых сервисов.

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

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

Антивирусный пакет ClamAV фактически стал стандартом антивирусной защиты для всех, как десктопных, так и серверных open-sourсе систем Также на базе технологий ClamAV существует и развивается несколько пакетов для защиты персональных компьютеров на базе операционных систем семейства Windows, среди которых я бы отдельно выделил Immunet, который единственный из всех существующих на рынке антивирусных мониторов был эффективен против эпидемии WannaCry на начальном этапе её распространения.

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

Рассмотрим на практике процесс подключения неофициальных баз ClamAV.

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

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

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

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

Одним из проявлений этого процесса является массовое внедрение использования шифрования передваемых данных посредством технологии SSL / TLS сертификатов (далее для краткости - просто SSL).

Помимо проблем безопасности, к началу повсеместного применения данной технологии стимулируют и новые системы ранжирования поисковой выдачи, которые учитывают наличие шифрованного соединения для сайтов, а также возможность получения бесплатных SSL сертификатов, которую предоставляет ряд ведущих провайдеров данных услуг, в частности Let's Encrypt.

Однако, несмотря на очевидную пользу, шифрование данных посредством SSL/TLS имеет и ряд ограничений, вызванных особенностями используемых протоколов.

В ходе попытки разобраться с одной из проблем коллеги всплыл интересный момент связанный с работой модуля проверки DKIM в пакете защиты от спама Spamassassin.

В расшифровке начисления Spamassassin баллов входящему письму была замечена строка T_DKIM_INVALID DKIM Signature header exists but is not valid. Несмотря на то, что DKIM подпись у письма была и была корректной, о чём можно было сделать вывод, например, из лога Exim.