Вот месяц назад настраивал ради прикола личный домен с emoji на почту, Postfix по дефолту вам подкинет свинью с Dovecot в паре. Postfix умеет и хочет в SMTPUTF8 из коробки (выключается через smtputf8_enable = no), а Dovecot LMTP не умеет и скорее всего не скоро научится (больше 7 лет данную тему поднимают и все никак), результат? Relay access denied от Gmail (ну и от других почтовиков) который умеет в SMTPUTF8 и от своих же клиентов которые будут слать с клиента почту с поддержкой UTF8 (Thunderbird, etc): SMTPUTF8 is required, but was not offered by host. Под host подразумевается Dovecot. Так же из тех почтовых систем что принимали не ascii символы в адресе получателя я смог найти только 2: gmail и zoho.eu. Причем Zoho был более серверо-независимым — он больше опирался на frontend отображение чем на реально поддержку SMTPUTF8 на стороне получателя, тогда как Gmail принудительно использовал преобразовывал punycode в Unicode своим frontendom всегда. Другие свободные почтовики типа yahoo, yandex, mail.ru, prothonmail etc не имеют поддержки Unicode на сегодняшний день. Вообщем: оно вам надо помнить домен lmao.com как xn--lmao-kp63c.com и каждый раз чуть что пользоватся Win+; и https://www.punycoder.com/?
В кратце: статья написана о програмном обеспечении Snort\Surricata пятилетней давности и не отображает текущих реалий. Это не первая и не последняя статья. Вот буквально сегодня в предложке Google попалась по сути такая же статья на анлоязычном ресурсе о "преймущиствах в производительности Surricata", о том что Snort работает в однопоточном режиме, что его использовать просто глупо и тд. Все это было правдой когдато, но не сейчас. Автору минус в карму за дизинформацию. А тем кто смотрит в сторону ID(P)S советую все же взгялнуть на Snort, как минимум из-за OpenAppsID который как по мне дает нехилые возможности аналога которых у Surricata попросту нет.
А на деле уже никто и не видит EV сертификаты. Выше ссылка на статью Т.Ханта которой уже года 2 о его ресурсе HIBP, в котором был EV, и о том как он его молча заменил на сертификат от Let's Encrypt, сам был свидетелем этого и ничего не заметил. Заметили единицы "везунчиков" за 2 недели, а у сайта посещаемость очень высокая и большинство технические люди. Так что экспериментально доказано — EV бесполезен.
А это по вашему мнению это не значит потеря контроля над доменом? Глобально такую компроментацию проще и быстрее восстановить чем угон у регистратора, но сути дела (скомпроментированный резолвинг) это не меняет, даже наоборот, можно незаметно для всех вносить изменения, когда угон домена с регистратора сложно не заметить.
Если вы потеряли контроль над своим доменом то какая уже разница в том какие сертификаты вы используете на своем сайте. Кто владеет доменом владеет всем что на нем находится. Вас никак EV не спасет.
+++ люди от непонимания и не знания путают Nat с Firewall.
В добавку к всем плюсам IPv6 добавлю что DNSSEC который имеет в мире распространение в 2% всех клиенских зон (3 уровня и выше) на мой взгляд тормозится именно из-за IPv4, ибо SlitDNS с DNSSEC эта та еще боль, которая попросту не нужна в случае использования прозрачной маршрутизации IPv6. Что бы его завести приходится вырубать DNSSEC валидацию для своих субдоменов, либо делать свои приватные DNS публичными и на них настраивать IP Scope
Говорю как параноик, автор неадекват.
Цытата:
менять пароли минимум раз в полгода, используя сложные и уникальные комбинации, которые невозможно предугадать, причем пароли должны отличаться для каждого сервиса и аккаунта;
Зачем менять каждые пол года пароли если они уникальные и не утекшие? Не порите чушь. Раз в пол года садится и перебивать весь KeePass с 500+ паролями по новой?) Даже Microsoft поняли что expiring пароля бесполезен. И это в enterprises...
Мне кажется что их не заинтересует единичные случаи не верной конфигурации их оборудование. Это должно быть массово. Можно просто сказать что их софт потенциально позволяет небезопасную конфигурацию. Но на стаью это точно не растянуть)
Какой mfa, это soho роутер. Вон посмотрите на Dlink, там и логин не нужен, у них все железо как решето, из серии /gui.asp?ROOT_ACCESS=1. А по причине их стоимости они стоят у многих жлобов и не обновляется с момента покупки. Да и обновления не спасут особо, ибо DLink не подерживает железо дольше года, в том числе не латает двры в нем.
Уже не раз поднимался вопрос на международных конференциях о халатных производителях и об отсутствии закона который бы эти инцыденты регулировал. А пункты которым должен соответствовать домашний маршрутизатор простореализуемы:
1. Отсутствие заводского пароля по умолчанию, пароль должен быть сгенерирован в ходе первой настройки.
2. При инициализации и при дальнейшем изменении пароля перед применением пароля, он должен быть проверен на сложность.
3. По умолчанию ни один сервис удаленного доступа не должен быть включен на устройстве.
4. При включении удаленного доступа пользователь должен быть проинформирован, и возможно даже при включении этой функции требоветь указать более сложный пароль если установленный пароль имел минимально допустимую надежность.
5. Автообновление. Это наверное самая спорная, но самая важная функция. Главный плюс — софт будет максимально актуален, главный минус — кривизна реализации данной функции разрабом может привести к катастрофическим последствиям.
6. Ssh не должен быть вообще доступен по паролю, хватило ума его включить, так юзайте rsa ключи, это не сложно.
7. Веб интерфейс настроек маршрутизатора должен быть доступен по https и желательно с возможностью включить авторедирект.
Самое фиговое в этой истории что это далеко не единственный случай. Многие люди не благодарный скот. Если бы ему на сервер залетел по этим же кредам шифровальщик, они бы имели на руках мыло, но не угрожалибы, а плакали ли бы, писали жалобные письма и платили баснословные деньги в битах что бы расшифровать свои данные, если там хоть что то было стоящее.
Есть такое понятие bullet proof hosting. Вы к ним хоть в двери ДЦ стучать будете, они без ордера и без выноса дверей вам не откроют. По этому частенько такие abuse бесполезны.
CAA больше для того что бы не дать другим CA выдать Вам (или тем кто вами прикинется) сертификат и уведомить вас о злоупотреблении (возможно). У меня в CAA везде Let's Encrypted и хорошо себя чувствую. Но в CAA можно прописать несколько СА, многие этого не знают. Учтите что Preload работает только в комбинации с includeSubDomains. И самое важное HSTS с includeSubDomains должен быть как можно выше. Если у вас домен example.com, а сайт находится на www.example.com. То вам нужно редирект делать с http://example.com на https://example.com, а отктуда на www. Иначе ваш hsts будет не валидным для preload, https://hstspreload.org/
А вы почитайте хотябы Wiki, а еще лучше RFC. HSTS это защита от downgrade атак, она не просто говорит что нужно идти по линке https://, она говорит что это соединение обязано быть доверенным. Текст из wiki с посылаем на rfc: If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), the user agent must terminate the connection (RFC 6797 section 8.4, Errors in Secure Transport Establishment) and should not allow the user to access the web application (section 12.1, No User Recourse).
В добавок к прошлому коментарию в любом браузере (кроме разве что Netscape >_<) наличие HSTS header'а не разрешает использование «я знаю что CA не доверенный, но все равно хочу подключиться». Подключение удастся только если CA добавлен в trusted root CAs. Об этом я уже писал выше. Тема закрыта.
Если работодатель не прописал этого в контракте то за такое у него можно отбить свой годовой оклад и испортить имидж в 0. А если он указал это в контракте который вы подписали, то кто Вам доктор? Имея даже права юзера можно легко и без особых навыков проверить есть ли в сети mitm https proxy даже если ваш девайс уже верит CA организации. F12 -> Security -> Show certificate
Я не с Росии и не Казахстана, такого в живую не видел, и надеюсь никогда не увижу. Но наслышан. Что сказать? Первое — гнать такой конекш сами знаете какими тряпками. Второе — тем людям что продолжают использовать такое подключение можно похлопать и посочувствовать. Третье — контраргумент, грамотно написаные мобильные приложения которые передают ценные клиентские данные при такой конструкции сети откажутся рабатать. В IDE включено по умолчанию: не доверять сертификатам из пользовательского хранилища, и эту фичу еще надо прикручивать в коде. А у прошареных вообще настроен Certificate Pinning. Шах и мат.
Вот месяц назад настраивал ради прикола личный домен с emoji на почту, Postfix по дефолту вам подкинет свинью с Dovecot в паре. Postfix умеет и хочет в SMTPUTF8 из коробки (выключается через
smtputf8_enable = no), а Dovecot LMTP не умеет и скорее всего не скоро научится (больше 7 лет данную тему поднимают и все никак), результат? Relay access denied от Gmail (ну и от других почтовиков) который умеет в SMTPUTF8 и от своих же клиентов которые будут слать с клиента почту с поддержкой UTF8 (Thunderbird, etc): SMTPUTF8 is required, but was not offered by host. Под host подразумевается Dovecot. Так же из тех почтовых систем что принимали не ascii символы в адресе получателя я смог найти только 2: gmail и zoho.eu. Причем Zoho был более серверо-независимым — он больше опирался на frontend отображение чем на реально поддержку SMTPUTF8 на стороне получателя, тогда как Gmail принудительно использовал преобразовывал punycode в Unicode своим frontendom всегда. Другие свободные почтовики типа yahoo, yandex, mail.ru, prothonmail etc не имеют поддержки Unicode на сегодняшний день. Вообщем: оно вам надо помнить домен lmao.com как xn--lmao-kp63c.com и каждый раз чуть что пользоватся Win+; и https://www.punycoder.com/?P.s. habr.com сьел моего инопланетянина т_Т
В кратце: статья написана о програмном обеспечении Snort\Surricata пятилетней давности и не отображает текущих реалий. Это не первая и не последняя статья. Вот буквально сегодня в предложке Google попалась по сути такая же статья на анлоязычном ресурсе о "преймущиствах в производительности Surricata", о том что Snort работает в однопоточном режиме, что его использовать просто глупо и тд. Все это было правдой когдато, но не сейчас. Автору минус в карму за дизинформацию. А тем кто смотрит в сторону ID(P)S советую все же взгялнуть на Snort, как минимум из-за OpenAppsID который как по мне дает нехилые возможности аналога которых у Surricata попросту нет.
Ну это мягко говоря не по религии. Сломать кроме психики ничего не должно.
А на деле уже никто и не видит EV сертификаты. Выше ссылка на статью Т.Ханта которой уже года 2 о его ресурсе HIBP, в котором был EV, и о том как он его молча заменил на сертификат от Let's Encrypt, сам был свидетелем этого и ничего не заметил. Заметили единицы "везунчиков" за 2 недели, а у сайта посещаемость очень высокая и большинство технические люди. Так что экспериментально доказано — EV бесполезен.
Если вы потеряли контроль над своим доменом то какая уже разница в том какие сертификаты вы используете на своем сайте. Кто владеет доменом владеет всем что на нем находится. Вас никак EV не спасет.
В добавку к всем плюсам IPv6 добавлю что DNSSEC который имеет в мире распространение в 2% всех клиенских зон (3 уровня и выше) на мой взгляд тормозится именно из-за IPv4, ибо SlitDNS с DNSSEC эта та еще боль, которая попросту не нужна в случае использования прозрачной маршрутизации IPv6. Что бы его завести приходится вырубать DNSSEC валидацию для своих субдоменов, либо делать свои приватные DNS публичными и на них настраивать IP Scope
И что вы будете делать с этими знаниями? Я еще расскажу что у меня есть ПК и мобильный и интернет. Очень информативно)
Говорю как параноик, автор неадекват.
Цытата:
менять пароли минимум раз в полгода, используя сложные и уникальные комбинации, которые невозможно предугадать, причем пароли должны отличаться для каждого сервиса и аккаунта;
Зачем менять каждые пол года пароли если они уникальные и не утекшие? Не порите чушь. Раз в пол года садится и перебивать весь KeePass с 500+ паролями по новой?) Даже Microsoft поняли что expiring пароля бесполезен. И это в enterprises...
Автор не сечет о чем пишет, увы.
Уже не раз поднимался вопрос на международных конференциях о халатных производителях и об отсутствии закона который бы эти инцыденты регулировал. А пункты которым должен соответствовать домашний маршрутизатор простореализуемы:
1. Отсутствие заводского пароля по умолчанию, пароль должен быть сгенерирован в ходе первой настройки.
2. При инициализации и при дальнейшем изменении пароля перед применением пароля, он должен быть проверен на сложность.
3. По умолчанию ни один сервис удаленного доступа не должен быть включен на устройстве.
4. При включении удаленного доступа пользователь должен быть проинформирован, и возможно даже при включении этой функции требоветь указать более сложный пароль если установленный пароль имел минимально допустимую надежность.
5. Автообновление. Это наверное самая спорная, но самая важная функция. Главный плюс — софт будет максимально актуален, главный минус — кривизна реализации данной функции разрабом может привести к катастрофическим последствиям.
6. Ssh не должен быть вообще доступен по паролю, хватило ума его включить, так юзайте rsa ключи, это не сложно.
7. Веб интерфейс настроек маршрутизатора должен быть доступен по https и желательно с возможностью включить авторедирект.
Самое фиговое в этой истории что это далеко не единственный случай. Многие люди не благодарный скот. Если бы ему на сервер залетел по этим же кредам шифровальщик, они бы имели на руках мыло, но не угрожалибы, а плакали ли бы, писали жалобные письма и платили баснословные деньги в битах что бы расшифровать свои данные, если там хоть что то было стоящее.
Есть такое понятие bullet proof hosting. Вы к ним хоть в двери ДЦ стучать будете, они без ордера и без выноса дверей вам не откроют. По этому частенько такие abuse бесполезны.
CAA больше для того что бы не дать другим CA выдать Вам (или тем кто вами прикинется) сертификат и уведомить вас о злоупотреблении (возможно). У меня в CAA везде Let's Encrypted и хорошо себя чувствую. Но в CAA можно прописать несколько СА, многие этого не знают. Учтите что Preload работает только в комбинации с includeSubDomains. И самое важное HSTS с includeSubDomains должен быть как можно выше. Если у вас домен example.com, а сайт находится на www.example.com. То вам нужно редирект делать с http://example.com на https://example.com, а отктуда на www. Иначе ваш hsts будет не валидным для preload, https://hstspreload.org/
А вы почитайте хотябы Wiki, а еще лучше RFC. HSTS это защита от downgrade атак, она не просто говорит что нужно идти по линке https://, она говорит что это соединение обязано быть доверенным. Текст из wiki с посылаем на rfc: If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), the user agent must terminate the connection (RFC 6797 section 8.4, Errors in Secure Transport Establishment) and should not allow the user to access the web application (section 12.1, No User Recourse).
Если работодатель не прописал этого в контракте то за такое у него можно отбить свой годовой оклад и испортить имидж в 0. А если он указал это в контракте который вы подписали, то кто Вам доктор? Имея даже права юзера можно легко и без особых навыков проверить есть ли в сети mitm https proxy даже если ваш девайс уже верит CA организации. F12 -> Security -> Show certificate
Я не с Росии и не Казахстана, такого в живую не видел, и надеюсь никогда не увижу. Но наслышан. Что сказать? Первое — гнать такой конекш сами знаете какими тряпками. Второе — тем людям что продолжают использовать такое подключение можно похлопать и посочувствовать. Третье — контраргумент, грамотно написаные мобильные приложения которые передают ценные клиентские данные при такой конструкции сети откажутся рабатать. В IDE включено по умолчанию: не доверять сертификатам из пользовательского хранилища, и эту фичу еще надо прикручивать в коде. А у прошареных вообще настроен Certificate Pinning. Шах и мат.