Комментарии 170
Я бы даже не стал добавлять в заголовок «Рунета». Описанные вами проблемы характерны для всех отраслей и сфер.
Я пользуюсь одной библиотекой видов, которую регулярно обновляют: на сайте есть жизнь, крупнейшая база видов, информация по генетике и так далее. И вот всё, что вы описали, там присутствует. Сервер можно буквально пинком открыть, даже парсер никто не блокирует. Заходи кто хочешь, бери что хочешь.
Просто ресурс настолько нишевый, что он никому особо не интересен.
Да, согласен, это вообще не только у нас. Просто я гонял именно российские сайты, плюс тут ещё 152-ФЗ сверху, поэтому и Рунет в заголовке.
А нишевые сайты как раз самые интересные) Никто не смотрит, а потом на таком сервере внезапно майнер или фишинг висит. Киньте ссылку на ту библиотеку, если не жалко, прогоню через утилиту, интересно что вылезет
Зачем ограничиваться лишь сайтами рунета? Было бы ещё интереснее оценить состяние глобального интернета.
Интересно когда вы "гоняли" вы сами никакую статью не нарушили ?
а в чем нарушение, если это не используется для получения какой-либо выгоды?
Старался не нарушить. Suveren по умолчанию делает то же, что обычный посетитель: открывает главную и несколько страниц, читает публичные записи DNS и открытые реестры. Портов не сканирует, пароли не подбирает, уязвимости не проверяет. Всё, что выходит за это, включается только для своего сайта после подтверждения владения. Поэтому и названия сайтов в статье не привожу.
Описанные вами проблемы характерны для всех отраслей и сфер.
До чего же метко сказано! Вот подтверждение на примере федеральной сети аптек: https://otzovik.com/review_18715521.html
Службы поддержки уже сродни службам неподдержки. Выполняют функцию tarpit. Деньги выделены, люди чем-то занимаются, ничего полезного права делать не имеют, клиент остается рад зря потраченному времени.
Так ещё и на живого оператора становится всё сложнее попасть. Тупой алгоритм в любой нестандартной ситуации бесполезен примерно на 100%, а у многих и в стандартных сценариях жёстко тупит. Даже признаётся что не понимает вопроса, но звать живого человека открыто отказывается. Так и гоняет по кругу.
В результате клиент остаётся с нерешённым вопросом и прекращает работать с организацией.
Если какой-то непонятный нишевый сервер можно взломать - то могут залить криптолокер и требовать биткоины за ключ для расшифровки. Если данные на сайте ценны и интересны хотя бы его владельцам (а правильную полноценную бэкап-процедуру заменяют три иконки) - то это вполне себе ценный и интересный ресурс для всех, кому интересны деньги.
IP и cookies, которые ушли в Google, это она самая.
"Сомнительно, но окэй." (с)
Но уж пользователю об этом переживать надо в самую последнюю очередь.
Тема DKIM не раскрыта.
Справедливо, в статью не влезло. По цифрам: ключи нашлись у 190 доменов, и у 157 из них (83%) есть ключ на 1024 бита, хотя RFC 8301 советует от 2048. Письма с ними пока принимают, но запас уже небольшой. Ну и селекторы DKIM снаружи не перечислить, утилита пробует типовые имена, так что что-то могла не найти
@marsilid полезная утилита! Но есть нюанс - после проверки одного сайта утилита выводит в консольное окно, где работает (windows) отчёт. Затем предлагает нажать Enter для возврата в меню. Нажатие - прокрутка окна наверх. Если после этого выбрать пункт 1, ввести сайт - новые данные проверки будут писаться прямо поверх старой информации и получается каша. Добавьте cls)
PS если саму утилиту положить в Downloads\reports (который она сама создала после первого отчёта) и запустить еще раз - она создаст Downloads\reports\reports еще раз и так далее. Контролируйте создаваемые папки.
Спасибо, оба подтверждаю. Экран на Windows чистится не до конца, отсюда каша, а папка reports создаётся рядом с exe, даже если он уже внутри неё лежит. Поправлю в следующей версии
Чтоб терминал не глючил при перезаписи строк лучше выводить промежуточный статус через стандартный curses или rich, тогда буфер очищается предсказуемо на любой операционке. И пути к репортам надо сразу лочить через Pathlib относительно рабочего каталога
Любая программа создает папку рядом со своим экзешником, если так задумано. Вы хотите чтобы отчет в папке документы создавался? По мне удобнее когда рядом с exe
Рассуждать в одной статье об опасности МИТМ и одновременно что у сайтов "Но иностранный сертификат" - довольно странно как по мне.
Если что, иностранные сертификаты не запрещены законодательством РФ.
не запрещены законодательством РФ
С учётом, куда движется политика правительства, это лишь вопрос времени.
А Вы позвоните в колл-центр Сбербанка (в настоящий, разумеется). Просто ради интереса. Вам там будут гнать такую же пургу: иностранные сертификаты — это плохо, потому что они иностранные, и только минцифровские нельзя взломать.
Не, я не про то что минцифровские надёжнее. Как раз наоборот, им браузеры не доверяют
Вы считаете, что Минцифры виновато в том, что потребовалось создавать УЦ и выпускать сертификаты? А может быть из-за того, что однажды кое-кто взял и отозвал кое у кого CA-шки? Без объявления войны, регистраций и СМС...
Без объявления войны
ну-ну.
Ну формально как раз объявления войны не было, было объявление SMO :)
Формально твердо и четко объявляли что и вторжения не будет, а теперь маленькое победоносное zvo четыре года. А еще формально текущиее десятилетие - десятилетие науки и технологий, а вот в реальности ученых с инженерами в заключении увеличилось... Это как в той шутке, про теоретически формально элитного деда и практически.
Я никого не виню, отчёт просто показывает два разных риска. Сертификат зарубежного центра не запрещён, и Suveren не считает его нарушением. Это зависимость, как и любой иностранный сервис: в 2022 году некоторые центры правда отзывали сертификаты и переставали их выпускать для части российских компаний. Сертификат Минцифры этот риск снимает, но у него свой: браузеры, кроме Яндекс Браузера и Атома, ему не доверяют, и обычный посетитель увидит ошибку. Поэтому многие ставят оба сертификата. Какой риск важнее, каждый решает сам, моя задача только показать оба.
они могли создать внушающий доверие УЦ, который соответствует стандартам безопасности и прозрачности. но почему-то решили что их эти требования не касаются
Примерно как eMudhra? Всем стандартам соответствует, все сертификации и аудиты прошел. Отличный УЦ.
УЦ сделал глупость и его больше нет(сам закрылся под влиянием тех самых мер, которые против ошибок УЦ применяются). А клиенты благополучно у других УЦ подписываются.
Но теперь представим себя на месте индийских организаций, которые обязаны вот таким государственным пользоваться. Зная, что они вот такие раздолбаи.
Или на месте российских, если кто-нибудь вдруг обнаружит что-то похожее про сертификаты Минцифры. Вопрос, кстати, что при этом произойдет - будет вообще кто-то озабочиваться добавлением его вот во все эти черные списки (как нам напомнили, отзыв - далеко не единственный способ воздействия), или нет.
Тут, кстати, нужно еще раз подумать, полезно или вредно, что кто-то другой решает, кому можно доверять или нет. Не было бы всех этих инструментов воздействия третьими лицами - вообще непонятно, как ситуация бы развивалась. Здоровенная часть клиенты eMudhra, поди, так бы то сих пор ничего и не сделали, оставаясь сидеть на скомпрометированной цепочке.
Конечно будут. Никому не нужно чтобы делали митм на банки. Все заблочат и перевыпустят.
Никому кроме своих-же спецслужб...
А спецслужбам зачем mitm на банки, у них и так доступ ко всему банку есть?
например, чтобы выдать свои действия за чужие и списать всё на хакеров из какой-нибудь недружественной страны.
есть например неединичные случаи где клиенты банков отрицают передачу кодов из смс посторонним (то что его можно угадать с огромной по криптографическим меркам вероятностью пока вынесем за скобки). кто на самом деле передал код? как это проверить?
А где у минцифры факапы сравнимые с eMudrha?
А где у минцифры факапы сравнимые с eMudrha?
Как тут правильно указали, у eMudrha тоже не было. До определенного момента. И потом построенная система сработала более-менее как задумано. В частности - все разбежались от них к другим.
А вот как это все сработает с УЦ Минцифры - вот совсем не очевидно. В частности, разбежаться на другие УЦ уже не получится же?
Так делают уже. Яндекс запустил программу сертификации УЦ.
Вообще сильно не хватает интерфейса расстановки галочек на странах к которым принадлежат УЦ. Каждый чекнул бы "своих" и успокоился.
Я бы форкнул этот чекер и индию (и еще кучу кого) захардкодил бы в блоклист. Остальных раскрасил бы по степени доверия.
Американцы такого не допустят. Контроль им важнее риска рассыпания интернета на части. Все должны доверять их сертификатам и только им.
Да ладно. Способы вставить частные УЦ для корпоративных нужд у всех браузеров и ОС есть. И Минцифровский УЦ пока никто в блеклисты не заносит, хотя он уже порядочно много где стоит. Если будут заносить - наверное. покажут, почему.
Так что "Все должны доверял только им" - это несколько преувеличено.
Система, действительно, порядком кривая, но совсем не по причине целенаправленного желания, а просто потому что забывают думать о том, что в других местностях могут хотеть.
Так им и так доверяют. При чем практически все. Американцы потому, что несанкционированная слежка за своими гражданами там не поощряется. А люди в "недружественных" странах потому, что они не сливают данные кому попало.
Ну ок. Ждём первого МИТМ на Сбер или Госуслуги. До этого вероятно разделегирование домена на американских ДНС серверах будет.
Кто такой серт сейчас подпишет-то? Как раз после eMudhra поставщики браузеров дерганные и злые. Закатают такой УЦ в черный список и не сильно поморщатся.
Да кто угодно. Кто не захочет УЦ лишиться. Ну точнее не лишиться, а быть выкинутым из доверенных в Хроме Винде и далее по списку.
Что-то мне кажется, что сейчас подиписать MitM серт (а это почти наверняка заметят) - гораздо более надежный способ быть выкинутым из доверенных, чем отказаться. Как раз по описанной причине.
Все ровно наоборот. Разделегируют домен, санкции же. Выдают его кому надо. Выпускают сертификат. Все легально.
За отказ выпустить сертификат выкидывают из доверенных за нарушение правил работы.
Так это уже не система сертификатов злономеренно используется, а доменная. Да и то - непонятно, как оно будет работать, пока DNSSec ключи зоны ru - под нашим контролем. Снести всю .ru - это, пожалуй, можно. А вот отельный домен из нее - этот самый DNSSec хоть на уроне пользователей не очень виден, но самими корневыми серверами зон еще как проверяется.
Американские корневые сервера что надо примут. Не переживайте.
Какая злонамеренность? Санкции введут и все будет по их закону. Еще и куча народа в комментариях тут поддержит.
Раньше минусовали карму даже за утверждение что система сертификатов будет использована американцами как оружие. Сбылось. Сейчас за предположение что американцы будут делать митм. И ведь велик шанс что тоже сбудется. Году этак в 28-29, если демы победят.
Это же политический вопрос. После 22 года ни одна компания, опасающаяся американских или европейских санкций, не поставит российский УЦ в список доверенных, чему бы он там не соответствовал.
Так и я о том же. Всех заставили выучить мантру о безопасности серта минцифровского, а какая дыра за ним стоит, сотрудники колл-центра не понимают. Да еще и борзеют: не нравится — вали.
Согласен, это разные риски и я их в статье зря рядом поставил. Иностранный сертификат никак не про MITM и не запрещён, с безопасностью у GlobalSign и Let’s Encrypt всё нормально. Риск там другой: что УЦ откажет в продлении, как было в 2022. Поэтому и написал что зависимость вынужденная, без НУЦ браузеры сайт не откроют
Читаешь текст и вроде как все по делу, но все равно с душком. Слон то в комнате есть.
Это всё даже агенты легко могут проверять и исправлять. Буквально, пара запросов к агенту. Но всё равно, у нас такая ужтсная ситуация. В общем, как всегда, миром правит лень и безалаберность.
"Миром правит не тайная ложа, а явная лажа" :)
строго говоря, Пелевин забыл указать ещё один вариант: "Тайная ложа, совершающая явную лажу". И таких в истории немного есть ))
Не помню откуда, возможно оттуда же - если кто-то некомпетентный занимает своё место, значит это кому-то выгодно. Опять же, если кждый раз в результате "лажи" деньги перемещаются в одном и том же направлении, то можно не сомневаться.
Серверы за границей остались всего у четырёх сайтов из 284, тут крупный бизнес молодец
Ага. Очередной удар по датацентрам, и снова куча ресурсов ляжет. А почти все датацентры в европейской части страны. Довольно легко доступны и слабо защищены. Ну просто молодчинки.👍
Политика держать инфраструктуру в суверенных датацентрах — складывание всех яиц в одну корзинку. Очень удобную для ударов. По возможности, инфраструктуру надо диверсифицировать в другие страны.
Политика держать инфраструктуру в суверенных датацентрах — складывание всех яиц в одну корзинку. Очень удобную для ударов. По возможности, инфраструктуру надо диверсифицировать в другие страны.
Это выбор между: "получить большой штраф сейчас" и "получить возможный удар по инфраструктуре в неопределённом будущем".
... перечитываем девять с половиной правил ведения бизнеса в России...
Уже не совсем актуально:) Один чих ТСПУ и твоя бухгалтерия или что-там в ЦОДе заграничном увы недоступна, продажи стоят, клиенты бесятся, админ/девопс курит дома на удаленке.
Хотя вышеописанный косяк куда как более просто нивелируется, что тушение пожаров в ДЦ в прямом смысле, огнетушителем.
Закон не требует держать в России всю инфраструктуру. Требует, чтобы основная база с данными россиян была здесь (152-ФЗ, ст. 18 ч. 5). Сайт, CDN, почта, бэкапы могут жить где угодно. Копию базы за границу тоже можно отдавать, но с уведомлением в РКН о трансграничной передаче, и страна должна быть из подходящих. Так что выбирать между штрафом и одной корзиной не обязательно. Основную базу держите в двух разных ДЦ в России у разных провайдеров, а резерв там, где вам спокойнее.
Про ТСПУ Trusted_binary прав, зарубежный ДЦ сейчас тоже риск, просто другой. И с огнетушителем тоже прав: два ДЦ у разных провайдеров закрывают и пожар, и падение одного провайдера. Это нужно и без всякого закона.
Думаю, вы забыли добавить новые реалии:
два ДЦ у разных провайдеров теперь не закрывают ни пожар, ни падение одного провайдера. Потому что провайдеры будут оверселить мощности в счет 10% “резерва”, а значит легко выкинут вашу стойку, если придут госы за своими резервами после сгоревшего соседа.
Теперь число резервирования неизвестно: потому что вам надо увернуться от попадания в “резерв”. Это может быть 3, а может и 5, а может и другое число.
Про резервы не слышал, если так, то да, двух может не хватить. Тогда главное, чтобы были свежие бэкапы, которые реально можно быстро поднять в другом месте, а не только вторая стойка.
10% резерва на стадии обсуждения, из соседней новости: https://habr.com/ru/articles/1105758/
Там вроде правило не ограничивалось серверами.
В правильной редакции этих правил было правило номер 0: не надо делать бизнес в России...
С резервированием согласен, держать всё в одном ДЦ в любом случае плохо. Только по 152-ФЗ основная база персданных россиян должна быть в РФ, так что для них скорее разносить по разным регионам и провайдерам плюс бэкапы. А что без персданных, можно и за рубеж, тут каждый сам решает
складывание всех яиц в одну корзинку.
самую большую корзинку в мире?
Уж надёжнее, чем ... Примерно по всему миру в других местах, где просто заблочат из-за российскости
Гениально, чтобы в других странах одним стремительным домкратом все вырубили.
ну как показали события последней недели (Beget и ещё кто-то там), что не только с физической защитой плохо.
Но.
Никто не даст 100% гарантии и на "несуверенные" сервисы.
Политику dmark для большой организации обеспечить в большинстве случаев нереально (админ в Москве не может вникать, как сегодня рассылает почту каждое отделение в своём чуме в тундре). И собственно незачем, потому что email сам по себе в любом случае не является доверенным каналом.
Допустим, вы включили dmark и вынудили злоумышленника отправить письмо от имени vasya@bаnk.ru вместо vasya@bank.ru . Думаете, получатель, который не проверяет заголовки письма (а иначе он бы заметил неладное по Received), это заметит?
Про похожие домены согласен, от них DMARC не спасает, это отдельная история. Но точный адрес и похожий всё-таки разные вещи: письмо с настоящего bank.ru проходит и спам фильтры, и внимательного человека, который как раз посмотрел на адрес. А похожий домен можно ловить, блокировать, регистрировать заранее.
Про отделения в тундре, так для этого p=none с отчётами и придуман. Месяц собираешь rua, видишь кто реально шлёт от твоего имени, потом ужесточаешь. Сложно, но у 101 домена из выборки p=reject стоит, значит выполнимо
Про отделения в тундре, так для этого p=none с отчётами и придуман. Месяц собираешь rua, видишь кто реально шлёт от твоего имени, потом ужесточаешь.
Так после ужесточения это будет постоянно меняться. Тем более в наше неспокойное время.
Сложно, но у 101 домена из выборки p=reject стоит, значит выполнимо
Возможно, у них более централизованная организационная структура.
А похожий домен можно ловить, блокировать, регистрировать заранее.
В большинстве случаев письмо с несуществующего адреса отправителя (а это не то же самое, что домен сервера отправителя) проходит нормально. Собственно, иначе любая проблема с DNS вела бы к катастрофе.
Вот недавно, например, в связи с известными событиями у нас корпоративный домен выпал из DNS на несколько часов. Это ж, наверное, не повод, чтобы я не мог послать письмо сотруднику за соседним столом? Не надо конструировать единую точку отказа.
После ужесточения отчёты rua продолжают приходить. Появился новый отправитель, вы его увидите и добавите в SPF или DKIM, на этом вся поддержка. Для отделений можно сделать проще. На bank.ru ставите reject, а у region.bank.ru оставляете свою запись с p=none, пока там не разберутся. Так что всю организацию ради этого перестраивать не надо.
С несуществующим адресом согласен, тут DMARC ничего не знает про ящики. Он смотрит только на домен в From. Письмо от выдуманного vasya@bank.ru с настоящего сервера банка спокойно пройдёт. Он защищает от другого: чтобы письмо от bank.ru нельзя было отправить с чужого сервера.
А насчёт точки отказа не переживайте. Если DNS домена лёг, получатель и запись DMARC не найдёт, так что и применять ему нечего. Обычно такое письмо просто отложат и попробуют отправить ещё раз. Коллеге за соседним столом письмо вообще идёт через ваш же сервер, там DMARC никто не проверяет. Наружу при упавшем DNS почта всё равно не дойдёт, но уже потому, что у получателя не найдётся ваш MX. С DMARC или без него будет одинаково.
Если не собирать отчеты rua, корпоративная сеть быстро превращается в рассадник фишинга от имени собственного бренда. Никто не заставляет врубать жесткий reject в первый день. Повесь p=none на три месяца, собери IP всех легитимных отправителей и пропиши их в SPF через include...
email сам по себе в любом случае не является доверенным каналом.
Есть куча вариантов, использование которых старательно саботируется.
админ в Москве не может вникать, как сегодня рассылает почту каждое отделение в своём чуме в тундре
админы всё больше в тундре, а в Москве как не вникали, так и не могут, лол ;)
Я так похожие домены фильтрую , допустим компания mycompany.ru, все что от mycompany.xx либо в полиси карантин, либо пометку ВНИМАНИЕ.
А так проверка ptr, spf, dmark/dkim базы спамеров.
URL в теле письма, вложения, архивы, в том числе с паролями - в карантин.
Ну как положено.
Несколько лет назад друг попросил проверит как по номеру телефона можно узнать Ф.И.О. сотрудника. Оказалось только в тлг канале (не помню название)можно по номеру многое чего узнать. Вывод: мы сами доверяем тем же маркетплейсам и прочим сайтам,в которых уровень защиты стремится к нулю. И да, Фамилию не удалось найти, но есть другие
Да, так и есть, эти боты как раз из слитых баз и собраны. Поэтому и обидно, что дыры в основном не хитрые, а вот такие базовые, которые закрываются за вечер
Фамилию не удалось найти
Если речь про обычный сотовый номер, достаточно просто попытаться отправить 10р по СБП, вам "Иванов Иван И" покажут бесплатно, даже деньги переводить не потребуется )) Не 100% способ, но скорей всего сработает )
$ pip install “suveren[browser]” ERROR: Could not find a version that satisfies the requirement suveren[browser] (from versions: none) ERROR: No matching distribution found for suveren[browser]
Нет --verbose/–debug режима, запустил - зависло… Должно быть проблема в переменной окружения https_proxy.
Спасибо! Pip так пишет, если питон старше 3.11, проверьте версию.
С прокси да, косяк. Он специально не берёт https_proxy, чтоб не обходить защиту от запросов во внутреннюю сеть, но молча висеть это не дело. В следующей версии сделаю чтоб сразу писал об этом, и добавлю --verbose
Спасибо! Pip так пишет, если питон старше 3.11, проверьте версию.
Не угадали, Python второй версии.
Понял, тогда pip от второго питона. Попробуйте python3 -m pip install "suveren[browser]", нужен 3.11 или новее.
По логу видно, что у вас наружу только через прокси, а Suveren прокси пока не умеет. Это у меня в планах, будет флаг --proxy. А то, что он минуту ждёт базу DB-IP вместо того, чтобы быстро отвалиться и проверять дальше, это баг, поправлю. Спасибо за лог, очень помог.
Добавил --verbose (или -v) в 2.2.2: у scan, company, batch, research и doctor. Печатает каждый шаг (DNS, HTTP, TLS, WHOIS, браузер) с временем, так что видно, на каком хосте висит. Пишет в stderr, токены и параметры запросов не светит. Спасибо за идею!
Всё равно висит более 54 секунд:
0.8 с ← DNS TXT AS30911.asn.cymru.com (system): 0.0 с
10.9 с ✗ WHOIS whois.iana.org:43 (ru): OSError ([Errno 101] Network is unreachable), 10.5 с
^C 55.2 с ✗ HTTP GET download.db-ip.com/free/dbip-country-lite-2026-11.csv.gz: CancelledError, 54.7 с
55.2 с ✗ этап: DNS, почта, хостинг, сертификат, страница: CancelledError, 55.2 с
Поправил в 2.2.3: если прямого выхода в интернет нет, база стран больше не вешает проверку, она быстро сдаётся и идёт дальше. С прокси пока не умеет, это следующий шаг.
Режим --browser не сработал: не найден браузер: установите Edge или Chrome, для режима --browser установите Playwright:
$ pip3 list | grep playwright
playwright 1.64.1
Хотя повеселило, что на одной из страниц скрипт нашёл ИНН.
И скрипт неправильно ходит по относительным ссылкам, когда на странице стоит <base href="/ru/" />
В логах полная ссылка обрезалась, поэтому непонятно, что скрипт пытался скачать /files/static/v2461354112945/…: код 404, 0.3 с
Не знаю, где скрипт нагаллюционировал и увидел YouTube вместо RUTUBE.
Спасибо, очень помогает!
base href я вообще не учитывал, поэтому и 404, поправлю.
Браузер: Playwright у тебя стоит, а самого Chromium нет. Сделай
python3 -m playwright install chromium, и--browserзаработает. Сообщение поправлю, а то оно путает.Обрезку адресов в логе тоже уберу.
С RUTUBE интересно. Скорее всего, где-то в скриптах просто упоминается youtube.com, и он это посчитал.
Кстати да, что-то подозрительное с этим
Проверка 152-ФЗ SUV-PD-000
Главная страница не загрузилась, проверять нечего.Это он не смог открыть главную, а без неё 152-ФЗ проверять нечего. Может, прямого интернета нет, как у redfox0, может, сайт ботов не пускает или долго отвечает. Прогони с -v и глянь, что там у HTTP GET главной, интересно. И да, надо чтобы он сразу писал причину, а не просто «не загрузилась», поправлю.
Хороший тулчейн получился, проверки по RFC аккуратно сделаны
Спасибо, приятно слышать! Если найдёте место, где проверка с RFC не сходится, пишите, поправлю.
Отвечу сюда, потому что по контексту.
Прямо согласен с пламенным желанием сделать всё хорошо (не по стандарту, а именно хорошо), потому что «делать надо хорошо, а плохо делать не надо».
Вы пишете:
31% серверов до сих пор соглашаются на TLS 1.0 и 1.1, которые стандарт запретил ещё в 2021 году.
В RFC 8996 действительно написано MUST NOT применительно к TLS 1.0 и 1.1. Но сам документ имеет статус Best Current Practice, а не Internet Standard. Это нормативная рекомендация IETF, а не юридический запрет. И, разумеется, RFC не являются законами: за само по себе несоответствие RFC никого не наказывают.
Более того, далеко не всякий владелец сервера технически способен выполнить современные рекомендации. Возможно, у него работает древнее ПО, обновление которого требует замены ОС или вообще всего сервера. Возможно, это небольшой личный сайт, который никто не обслуживает уже пятнадцать лет. Можно справедливо указать на риски такой конфигурации, но не всегда справедливо делать вывод о некомпетентности или безответственности её владельца.
С другой стороны, переиграть в безопасность не всегда хорошо. Меня «умиляет», как сайты с драйверами настраивают свои серверы на TLS 1.3-only. Хотя, если бы администраторы немного подумали о назначении своего сервиса, они бы вспомнили, что за драйверами нередко приходят именно со свежеустановленных или старых ОС, которые TLS 1.3 из коробки не поддерживают. И поддержка TLS 1.0, 1.1 и 1.2 в таком случае была бы вполне разумным компромиссом — тем более, что ничего страшно секретного" в потоке HTTP во время скачивания драйвера (!) я не усматриваю.
Причём железо и ОС бывают не только свежими. И рассуждать в духе «ты ставишь себе Debian 6.0, так тебе и надо» — довольно странная позиция. Случаи разные бывают, сами знаете.
С необходимостью DKIM, DMARC (эти вот только крови выпили, а их никак не внедрят «не только лишь все»), корректных политик безопасности и обновления TLS я не спорю. Вопрос скорее в том, насколько полезно без оговорок переносить требования современной практики на весь исторически сложившийся интернет, не учитывая назначение сервиса, реальные риски и возможности его владельца.
P. S. Меня давно удивляет другое. Мы (человечество) написали огромное количество RFC о том, как правильно предоставлять сетевые сервисы, но так и не получили универсального, общепринятого механизма обратной связи с их администраторами.
Получается странная ситуация: мы умеем автоматически проверять миллионы серверов на соответствие рекомендациям, публиковать проценты нарушений и возмущаться результатами. А вот сообщить конкретному владельцу, что у него что‑то не так и как это исправить, зачастую просто некуда. Правда, мы в ответ и не узнаем, что владелец ресурса в курсе существования TLS 1.3, просто «у него есть обстоятельства».
Более того, в России использование TLS 1.3 на ряде хостингов приводит к ложному срабатыванию ТСПУ и блокировке сайта.
А если сайт для широкой аудитории и только для чтения, то я еще и не вижу смысла 1.0 и 1.1 убирать. Кто-то может сидеть с очень старого устройства (напоминаю, сейчас пенсионер в интернете - не что-то необычное), при этом на безопасность там не повлияло бы даже полное отсутствие шифрования. Просто сейчас незашифрованные сайты плохо выглядят в адресной строке.
Ну у домена всегда есть контакт. Другой вопрос, что с советами по безопасности он ноунейма стопроцентно пошлёт. Но это вопрос не механизма, а доверия.
Справедливо, «запретил» я сказал сильно, это рекомендация, а не закон, и винить владельцев я не хотел. С драйверами хороший пример, там старый TLS оправдан, да и сайту «только почитать» он не страшен. Я больше про банки и магазины, им уже без оправданий.
Про обратную связь согласен. Есть security.txt, где сайт пишет, куда сообщать о проблемах, но его почти никто не ставит. Хотя тут vadimr прав, ноунейму всё равно скорее всего не поверят.
тем более, что ничего страшно секретного" в потоке HTTP во время скачивания драйвера (!) я не усматриваю.
я, честно говоря, вообще не понимаю, зачем мы шифруем весь публичный трафик? мы этим убили каскад кеширующих прокси у провайдеров, которые сильно разгружали каналы и служили своего рода cdn. Чтобы потом на следующей итерации обнаружить тормознутость и заново сделать cdn с терминацией tls, только теперь это могут делать единицы, а раньше мог каждый первый и физически контент находился ближе к клиенту.
В реальности конфиденциальной информации то чуть-чуть относительно публичных данных: какие-нибудь данные форм, токены авторизации, куки. Для остальных же данных, думаю, нам достаточно было гарантии невмешательства (т.е. sha отпечаток на сервере совпадает с полученными данными). И тогда все кеширующие прокси у провайдеров могли остаться работающими.
я, честно говоря, вообще не понимаю, зачем мы шифруем весь публичный трафик?
Сейчас: Сотовый оператор видит, что пользователь ходит по сайтам, ну скажем, дилеров автомобилей. Сливает телефон пользователя рекламным фирмам как 'интересуется автомобилями'.
В мире без шифрования: он видит не только сайты, но и конкретное содержимое тех страниц, которыми пользователь интересовался. Досье для продажи рекламщикам будет гораздо более подробное.
Это не надо не вам, ни Гуглу.
В мире без шифрования: он видит не только сайты, но и конкретное содержимое тех страниц, которыми пользователь интересовался. Досье для продажи рекламщикам будет гораздо более подробное.
у меня стойкое ощущение, что вторую “недостающую” часть им сейчас приносят трекеры соцсетей. Как будто бы рекламщики обошли эту систему на раз-два, а недостатки остались с остальными пользователями навсегда.
Как минимум одна штука раздражала крайне - когда оператор связи вставлял свой код в качаемую тобой страницу.
Хорошая работа.
Вы бы могли монетизировать это сделав сайт с формой проверки, как раньше проверяли всякие сеооптимизации и прочее. Были и другие онлайн сканеры.
Спасибо! Думал про это. Сама утилита останется бесплатной и открытой, а веб-версию с формой, может, и сделаю, если будет спрос. Там есть свои сложности: проверять придётся со своего сервера чужие сайты, значит нужна защита от злоупотреблений, а для полной проверки ещё и подтверждение, что сайт ваш. Если кому-то такое нужно, напишите, это поможет понять, стоит ли браться.
А что с сертификатами tls/ssl не так? Кем пользоваться? Минцифры? Я что, конченая что ли?
С сертификатами всё нормально, Let’s Encrypt и другие иностранные центры работают. Пользоваться сертификатом Минцифры никто не заставляет, Suveren его и не советует. Сертификат попадает в отчёт как иностранная зависимость, а не как ошибка. Смысл такой: в 2022 году часть зарубежных центров отзывала и переставала выпускать сертификаты некоторым российским компаниям. Для большинства сайтов это просто строчка «знать на будущем», делать ничего не надо.
Вот про конченность - это отличная цитата.
Мегня бесит, что банки и сбптвдруг аяали закатываться под минуифру, и скоро по сбп не оплатишь телефоном.
Минцифры при этом для системы сертов ничего не сделала, чтобы популяризировать ее (
В Linux и macOS:
dig +short TXT _dmarc.имя-банка.ru. Смотрите наp=. Если тамreject, всё хорошо.quarantineтерпимо. А еслиnoneили ответа нет вообще, письмо от имени этого банка может прислать кто угодно, и смотреть на адрес отправителя бессмысленно.
$ dig +short TXT _dmarc.yandex.ru
"v=DMARC1; p=none; fo=1; rua=mailto:dmarc_agg@auth.returnpath.net,mailto:dmarc-rua@yandex.ru; ruf=mailto:dmarc_afrf@auth.returnpath.net"Это так должно быть?
Да, у Яндекса сейчас p=none, можно проверить самому. Формально это значит, что DMARC не просит отклонять поддельные письма от yandex.ru. На практике крупные почтовые сервисы проверяют такие письма ещё и своими фильтрами, поэтому подделка под Яндекс до вас скорее всего не дойдёт. Но это заслуга фильтров получателя, а не политики домена. У Яндекса стоят fo=1 и rua, то есть отчёты они собирают. Почему годами не переходят на reject, сказать не могу, у больших почтовых сервисов много пересылок и рассылок, и им сложнее.
Потому что юзеры хотят отправлять письма через почтовый сервер своего провайдера, имея адрес на яндексе. Прописать smtp.yandex.ru в качестве сервера исходящей почты – вообще так себе решение, тормозное; а сильно вдали от Москвы особенно.
Да, это и есть та самая причина: много писем с адресом @yandex.ru уходит через чужие серверы, и reject их бы ломал.
На практике крупные почтовые сервисы проверяют такие письма ещё и своими фильтрами, поэтому подделка под Яндекс до вас скорее всего не дойдёт.
Не только крупные, любой сервер все равно видит, что проверка провалена, p=none это не более, чем рекомендация. По-хорошему все таки письма в любом случае стоит отправлять в карантин.
По-хорошему все таки письма в любом случае стоит отправлять в карантин.
Такие идеи живут до первого не полученного важного письма.
Потом либо параноидальный админ получает по голове от начальства, либо пользователи начинают использовать почтовые ящики на стороне вместо корпоративной почты.
В обычных сценариях цена ложного срабатывания фильтра намного выше, чем цена несрабатывания.
Вы оба правы, поэтому и включают по шагам: сначала p=none с отчётами, смотришь, кто реально шлёт от твоего имени, и только потом quarantine. Тогда важные письма не теряются.
В обычных сценариях цена ложного срабатывания фильтра намного выше, чем цена несрабатывания.
Если проверка не прошла, то есть ненулевая вероятность, что адрес отправителя подменен. В таком случае цена несрабатывания может оказаться гораздо выше, чем цена ложного срабатывания.
А вообще, у всех фильтров довольно гибкие правила, что делать с письмами. Если хочется, то можно добавить к таким письмам дисклеймер большими красными буквами. В общем варианты есть, но просто так пропускать письма провалившие проверку может быть чревато.
У моего хостера, кстати, в инструкции прямо рекомендуется в DNS прописывать именно nonev=DMARC1;p=none
p=none советуют как безопасный старт, чтобы не потерять свою же почту, пока не ясно, какие сервисы шлют письма от имени домена. Это нормальный первый шаг. Но в примере из инструкции нет rua, а без него запись не защищает и отчётов никто не получает. Лучше сразу добавить rua=mailto:ваш_адрес, пару недель смотреть отчёты, потом перейти на quarantine и reject. Порядок расписал здесь: marsilid.github.io/suveren/email-spoofing/
Что можно взломать через уязвимый JQuery?
Зависит от версии и от того, как сайт её использует. У старых версий есть известные дыры. До 3.5 XSS через обработку HTML (CVE-2020-11022 и 11023). До 3.4 prototype pollution в $.extend (CVE-2019-11358). В очень старых, до 1.9, XSS через $(location.hash). Но сама старая версия на странице ещё не взлом. Нужно, чтобы код сайта передавал в эти функции данные от пользователя. Поэтому Suveren ставит предупреждение, а не ошибку: это знак, что библиотеки давно не обновляли, и стоит посмотреть, нет ли там чего похуже.
Никакие действия или бездействия на клиенте не должны нарушать безопасность. Всегда можно модифицировать браузер так что он будет делать вообще что угодно. А уж подгрузить руками любой js проще простого.
За исключением конечно урезанных локальных прав у корпоративных пользователей, но это не решение проблемы.
Помню лет 10 назад на Ютубе вирусился ролик “Взломать за пять минут” Там утверждалась, что по настоящему защищены только 2% сайтов. И самое интересное, что для этого в большинстве случаев не надо дополнительных инструментов. Достаточно знать команды поисковых систем Google и Yandex. Достаточно знать команды этих поисковых систем, что я нашел по запросам к этим же системам. Для интереса проверил на сайтах Microsoft и Кремля. И получил доступ до документов для служебного пользователя
Очень хорошо в сочетании с новостью о подаче онлайн-доносов: проверяем сайт, собираем доказательную базу "у них IP пользователя уходят на зарубежные сервисы!“, отправляем донос...
И не говорите, что никто не будет этим заниматься. Будут, от прямых конкурентов до идейных борцов за суверенитет.
Риск понимаю. Но всё это и так видно в любом браузере через инструменты разработчика, Suveren ничего скрытого не находит. Он для того, чтобы владелец сайта увидел это первым и поправил, пока это не сделал кто-то другой. И отчёт не юридическое заключение, о чём в нём прямо написано.
Тут есть от какой момент:
Допустим, хотите вы напакостить Бобо-Пицце, неважно почему: то ли она у вас клиентов отвела, то ли после их пиццы бо-бо в животе, то ли вы просто считаете пиццу как еду недопустимой в стране. Неважно.
Раньше как? Можно пойти в ОВД писать кляузу - скорее всего вас пошлют, ибо глупо.
Можно "в любом браузере" - но для этого нужна квалификация, техническая - чтобы понимать как смотреть, и юридическая - чтобы понимать что искать.
Это называется "цена вопроса", и она достаточно высока.
Но теперь и "пицца не наша еда!" поддержано в верхах, и инструменты удобные появляются, которыми сможет воспользоваться не только специалист, и цена вопроса падает до уровня "а давай им нагадим?"
Ну это в целом это неизбежно...
Не в тему, конечно, но так люблю когда защищают персданные, а рядом лежат боты для пробива людей. В шутку сидим тремя семейными парами, зашел разговор про пробивы, я в шутку ввел телефон сидевшей девушки, а мне вылазит гостиницы , где она с любовником встречалась, его фио и даже результаты анализов. А я сижу похолодевший и, на мужа ее смотрю.
По поводу "всё строже у гос. сайтов":
- еще недавно почти все сайты областных судов по http работали
- сайт реестра залогов (федеральная нотариальная палата) имел гугловую рекапчу
На мой взгляд у них как раз всё хуже, так как у них бюджеты и всё прочее и чинить то, что не сломано будут в последнюю очередь
Если кто‑то из этих провайдеров завтра решит отключить российских клиентов, у компании разом встанет почта или сайт.
ох уж эти импортозамещатели, а если по цоду со скрепками прилетит то что произойдёт по вашему? (ритарический вопрос))
Реалии современного рунета поражают...
Мы сделали подобный утилиту — Параграф. Сервис непрерывного мониторинга сайта. Бот каждый день обходит сайт, проверяет обязательные страницы и следит почти за 200 показателями — от технического состояния до всех требований законодательства.
Особенно актуально для тех, кто вайбкодит. ИИ периодически что-нибудь ломает: то случайно закроет сайт от индексации в robots.txt, то вёрстка поедет на какой-нибудь внутренней странице, то пропадёт нужный документ, то про запретграм на затитрует на странице или не в курсе про новый закон по англицизмам.
Есть косяк, потестил веб морду моего почтового сервера, в рекомендациях - перенести почту в Яндекс 360 или на сервер в РФ, но сервер и так в РФ и только мой)
Спасибо, похоже на баг. Глянь в отчёте строку про почту: какую страну и какого провайдера он там пишет? Или прогони с -v, там видно, что он нашёл в MX. Если сервер в РФ, совет переносить почту появляться не должен, поправлю.
https://2ip.io/ru/as/207957/
сервер на айпишнике из диапазона 77.239.107.0/24, Москва. MX запись на этот ip указывает
Почти всё чинится за вечер.
Посоветуйте, пожалуйста, хорошее вино на этот самый долгожданный вечер
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мошенникам даже не нужно ничего взламывать: я проверил 284 крупных сайта Рунета