Мне одному кажется, что с переходом от простых эксперементов к вантовым состояниям, где есть вероятности, у учёных как-то плохо стало с простой логикой? Если ты не можешь определить та ли эта частица или нет после испускания, прохода через барьер и детектирования, то что ты вообще измеряешь, о каких выводах может идти речь? Если ты пытаешься измерить время нахождения в барьере и находишь косвенный метод, но он оказывается в противоречии с превышением предельной скорости, то наверно это метод не подходит (с учётом, что вы нигде не напортачили в эксперементах).
Барьер это сито. Если частица уже смогла пройти сквозь него, то без задержки. Если сито многослойное, то вероятность прохождения без задержки и вообще успешного прохождения падает. Если взять большой барьер, то ничего ты не получишь. Нельзя скорость экстраполировать же ну.
Скорость прохождения барьера за 0,69мс? Как-то тут далеко до скорости света. Может она просто ускоряется как в гравитационных маневрах просто?
Сложность работы с вероятностным нахождением частиц усложняет эксперементы и у учёных плывет реальность, которую они пытаются подстроить под полученные вероятностные результаты с какими-то безумными выводами имхо.
Собственно все забыли, что побеждает всегда здравый смысл рынок. Пусть пользователь выбирает сам. Предоставьте пользователю выбор. Хочет — пусть ставить непонятный софт с сайта разработчика и сам следит за безопасностью, хочет — пусть аутсосит это мантейнерам дистрибутива, которые будут просто следить за базой CVE и списком версий, включенных в конкретный (жирный) пакет, а разработчики в свою очередь пусть предоставляют такой список (включил полностью — напиши какую именно версию в манифест), и будут просто исключать пакеты из своего репозитория, если их что-то не устравивает, чуть ли не в автоматическом режиме. Пользователь будет выбирать сам какой дистрибутив и его политика подходят ему.
Самое интересное, что такая или похожая система уже отработана на примере мобильного софта и это в большинстве случаев срабатывает.
Важно принять это как рабочую модель, а улучшения в виде разделяемых слоёв с одинаковым содержимым можно делать бесконечно.
Как можно что-то вообще объяснять новичкам, снимая при этом видео, и не использовать хотя бы git log --graph?..
Советую новичкам ungit, не кормить сразу читать книги.
Очень сумбурная статья путающая спам и фишинг, жесткие правила и эвристику.
По порядку:
SPF (Sender Policy Framework) представляет из себя текстовую запись в SPF и/или TXT-записи
Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Важно понимать, что SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
анти-спам системы используют… Анализ SPF/DMARC записей домена и цифровой подписи DKIM. Чтобы предотвратить отправку спама/вирусов или другой информации от «вашего имени» достаточно лишь добавить соответствующую SPF/TXT-запись к домену
Вообще говорить о спаме в разрезе SPF/DKIM/DMARC некорректно. Потому что это защиты против фишига. У них жесткие правила, они защищают конкретны вещи. Тогда как антиспам, используя статистику, базы ip, репутационные базы, сложную эвристику текста сообщений запрещают письма с нежелательным содержимым. Если вы направите письмо от microsoft.ru с полезным содержимым, то оно никогда в спам и не попадет, но будет фишингом.
DMARC — это предписывающая запись для результатов проверки DKIM, потом, на всяких случай SPF (если dkim по каким-то причинам сломался или поврежден). SPF защищает только envelope-from (smtp mail from). DKIM — From: (и другие поля) уже в самом письме. И подставить красивый envelope-from не составляет труда для спамера или, наример, при некорректных пересылках писем. Поэтому у всех стоят ~softfail политики, нужные для подстраховки при DMARC проверке, в которой SPF проверятся только как pass.
А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Рекомендуется создавать SPF-записи для всех доменов второго уровня
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
(здесь вы увидите кто отправляет письма от имени вашего домена)
Настраивайте DMARC и вам репорты будут на ваш ящик приходить. Ну или тот же dmarcian.com вам красиво это разложит в статистику.
Итого:
Вся ваша статья должна быть про DMARC! SPF с жесткой политикой (-all) сама по себе принесет скорее вред, чем пользу.
Указывайте запрещающие политики в DMARC для доменов, которые не рассылают почту.
Проверяйте DMARC для других и настраивайте для своих доменов.
Это будет хорошее развитие filter.d/recidive.conf.
После того как я заметил, что Slow Brute Force стал массовым (в плане размера ботнетов) и очень умным, то проспонсировал добавление в fail2ban ignorecommand (позволяет внешнему скрипту указать fail2ban, что ip не нужно банить) и сделал retry=1. Т.е всех банить сразу и надолго, но не банить доверенные ip. Например, которые где-то уже аутентифицировались, известные сети, местная страна и т.д. до 10 попыток, например. Если оно всё еще стучится, то filter.d/recidive его добивает.
Вам определенно стоит почитать как работает fil2ban. Если очень кратко, то заданные логи читаются и пропускаются через заданные фильтры (поставляются с fail2ban). Если фильтр что-то находит и при привышении заданного количества в заданное время сообщений применяются задданные действия (поставляются с fail2ban). Просто приведу названия некоторых действий чтобы вам стало более понятно:
Эти действия можно компоновать и нет никакой проблемы изменить стандартные или написать нужные вам действия. Как раз оно в /etc/ и лежит для этого.
Так вы можете банить командой по сети сразу на вашей системе с файрволлом.
Или банить полностью, а не только порт сервиса.
«Нормальное перемещение» — мне больше нравится дефолтное поведение и еще я поставил активизацию слоя при перемещении что бы быстро искать слои (Preferences — Tools Options — Set layer as active)
«Создание слоя из выделения» — в GIMP немного другая логика с этим. Сначала создается floating selection (Ctrl+Shift+L), потом из него можно сделать новый слой («To New Layer».) или посадить обратно(«Anchor the floating layer»). Это такая промежуточная штука между слоем и выделением. Возможно уже рудиментарная. Вот тут подробней docs.gimp.org/en/gimp-layer-anchor.html
Я не очень понял, вы по $sender_address_domain, т.е по RFC5321.mailfrom, подписываете сообщение? А что если пользователь в From: укажет чужой домен? Ну оно понятно что по DMARC такое письмо будет отброшено, но зачем это делать когда DMARC'а (не с none) еще толком ни у кого нет? Да и вообще отслеживать такое сложнее, чем просто неподписанные письма.
Стандарт конечно допускает, но если локальная политика запрещает создание таких ящиков, то где здесь проблема? Это хорошая тактика против фишеров. Потому что сходу отлитичить smith@example.com и smIth@example.com (upper «i») в подписанном сообщении (т.е где визуально показано, что адрес легитимный) не представляется возможным.
Вообще статья про то, что стандарты должны адаптироваться со временем.
Самое интересное что So1024 еще работает. Можно попытать счастья в vade-retro.com (мне не ответили) Это их фильтр или их технология работает в спамообороне. Или сразу в Dr.Web, цены там адекватные. Но бесплатно не получится, эра in-house почты уходит — 90% почты в руках 10% компаний.
Т.е вебвизор вы тоже закроете? Иначе в нем практически никакого смысла не будет. Разве что тестировать посадочные старницы. Но без доп инофрмации о запросе это малоценно
Не совсем так. Самое главное в грейлистинге это проверка засылающей стороны а) на реализацию корректной обработки ошибок и б) на корректную реализацию очереди с рекомендуемыми в RFC таймаутами. Т.е убеждение, как одна из ряда проверок, что перед нами какой-никакой MTA. Я не фанат данной технологии, но по информации оно срезает от 10% до 50% спама в зависимости от того в какие спам базы вы попали :)
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Это банальный грейлистинг. Скорее всего вы просто недостаточно аутентифитировали свой релей. Стоит начать со следующих ключевых слов: PTR, SPF, DKIM, DMARC.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
Мне одному кажется, что с переходом от простых эксперементов к вантовым состояниям, где есть вероятности, у учёных как-то плохо стало с простой логикой? Если ты не можешь определить та ли эта частица или нет после испускания, прохода через барьер и детектирования, то что ты вообще измеряешь, о каких выводах может идти речь? Если ты пытаешься измерить время нахождения в барьере и находишь косвенный метод, но он оказывается в противоречии с превышением предельной скорости, то наверно это метод не подходит (с учётом, что вы нигде не напортачили в эксперементах).
Барьер это сито. Если частица уже смогла пройти сквозь него, то без задержки. Если сито многослойное, то вероятность прохождения без задержки и вообще успешного прохождения падает. Если взять большой барьер, то ничего ты не получишь. Нельзя скорость экстраполировать же ну.
Скорость прохождения барьера за 0,69мс? Как-то тут далеко до скорости света. Может она просто ускоряется как в гравитационных маневрах просто?
Сложность работы с вероятностным нахождением частиц усложняет эксперементы и у учёных плывет реальность, которую они пытаются подстроить под полученные вероятностные результаты с какими-то безумными выводами имхо.
Вроде не первое апреля…
Судя по описанию там внутри Ceph
здравый смыслрынок. Пусть пользователь выбирает сам. Предоставьте пользователю выбор. Хочет — пусть ставить непонятный софт с сайта разработчика и сам следит за безопасностью, хочет — пусть аутсосит это мантейнерам дистрибутива, которые будут просто следить за базой CVE и списком версий, включенных в конкретный (жирный) пакет, а разработчики в свою очередь пусть предоставляют такой список (включил полностью — напиши какую именно версию в манифест), и будут просто исключать пакеты из своего репозитория, если их что-то не устравивает, чуть ли не в автоматическом режиме. Пользователь будет выбирать сам какой дистрибутив и его политика подходят ему.Самое интересное, что такая или похожая система уже отработана на примере мобильного софта и это в большинстве случаев срабатывает.
Важно принять это как рабочую модель, а улучшения в виде разделяемых слоёв с одинаковым содержимым можно делать бесконечно.
Советую новичкам ungit,
не кормитьсразу читать книги.По порядку:
Если вы заходили на openspf.org, то там с 14 года висит новость о новом RFC7202, который ставит точку в одном из самом неудачном «эксперименте» IETF — вводе переходного периода для ввода нового RR — SPF. Победил TXT — нужно теперь указывать только TXT для SPF записи.
Только если у вас на поддомене есть MX запись! По SMTP RFC вы вообще не должны принимать почту с несуществующих доменов и у которых нет MX записи. (Для гарантированной доставки в RFC всё еще есть отступление на доставку, если у этого же домена есть A запись, но это нужно было, скорее, на заре интернета и сейчас этим можно пренебречь).
Вообще говорить о спаме в разрезе SPF/DKIM/DMARC некорректно. Потому что это защиты против фишига. У них жесткие правила, они защищают конкретны вещи. Тогда как антиспам, используя статистику, базы ip, репутационные базы, сложную эвристику текста сообщений запрещают письма с нежелательным содержимым. Если вы направите письмо от microsoft.ru с полезным содержимым, то оно никогда в спам и не попадет, но будет фишингом.
DMARC — это предписывающая запись для результатов проверки DKIM, потом, на всяких случай SPF (если dkim по каким-то причинам сломался или поврежден). SPF защищает только envelope-from (smtp mail from). DKIM — From: (и другие поля) уже в самом письме. И подставить красивый envelope-from не составляет труда для спамера или, наример, при некорректных пересылках писем. Поэтому у всех стоят ~softfail политики, нужные для подстраховки при DMARC проверке, в которой SPF проверятся только как pass.
у домена нет MX — fallback на A. Поэтому оно вообще было доставлено. Gmail с довольно странными политиками, где-то сверх жесткими и не по RFC, а где-то довольно мягкими. Но реальный спам вы им всё равно не доставите :)
Если нет MX — зачем там SPF? Нужно только DMARC, который защищает от спуфинга в From:, потому что это вы не можете контролировать.
Настраивайте DMARC и вам репорты будут на ваш ящик приходить. Ну или тот же dmarcian.com вам красиво это разложит в статистику.
Итого:
Вся ваша статья должна быть про DMARC! SPF с жесткой политикой (-all) сама по себе принесет скорее вред, чем пользу.
Указывайте запрещающие политики в DMARC для доменов, которые не рассылают почту.
Проверяйте DMARC для других и настраивайте для своих доменов.
Sol 952 (Martian solar day 952)
После того как я заметил, что Slow Brute Force стал массовым (в плане размера ботнетов) и очень умным, то проспонсировал добавление в fail2ban ignorecommand (позволяет внешнему скрипту указать fail2ban, что ip не нужно банить) и сделал retry=1. Т.е всех банить сразу и надолго, но не банить доверенные ip. Например, которые где-то уже аутентифицировались, известные сети, местная страна и т.д. до 10 попыток, например. Если оно всё еще стучится, то filter.d/recidive его добивает.
Эти действия можно компоновать и нет никакой проблемы изменить стандартные или написать нужные вам действия. Как раз оно в /etc/ и лежит для этого.
Так вы можете банить командой по сети сразу на вашей системе с файрволлом.
Или банить полностью, а не только порт сервиса.
Вообще написание хороших примеров — это особое исскусство.
Статья получилась отличная. Только недавно просил на ru.pm чтобы кто-нибудь написал сводную статью про функции. Не хватает только сигнатур из 5.20
Вот хороший однострочник для затравки:
«Создание слоя из выделения» — в GIMP немного другая логика с этим. Сначала создается floating selection (Ctrl+Shift+L), потом из него можно сделать новый слой («To New Layer».) или посадить обратно(«Anchor the floating layer»). Это такая промежуточная штука между слоем и выделением. Возможно уже рудиментарная. Вот тут подробней docs.gimp.org/en/gimp-layer-anchor.html
А в DKIM_DEFAULT_DOMAIN у вас mail.ru?
Вообще статья про то, что стандарты должны адаптироваться со временем.
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
Вот посмотрите youtu.be/2wnCXY4hRHo?t=10m1s