Comments 188
Есть один интересный момент.
Последние несколько дней в РФ осуществляется очередной эксперимент по блокировке протоколов через DPI у разных провайдеров, и на этот раз блокируют как раз таки именно Jabber/XMPP.
Интересный момент заключается в том, что при блокировке находящихся за границей XMPP серверов, конкретно jabber.ru почему-то не блокировали, хотя он находится в Хетцнере.
Очень люборытное совпадение.
Вы про эту тему на форуме ntc.party?
Довольно сложно представить, что Hetzner будет делать такие вещи в интересах России.
Это может для него очень скверно кончиться в самой Германии.
Это может быть «инициативный» сотрудник, а не компания.
Я почти уверен, что сервер начали прослушивать из-за того, что у какого-то киберкриминала (группы, наиболее вероятно) проходило общение через него. Иными словами, в рамках оперативных действий по расследованию какого-то киберпреступления.
Возможно, связано вот с этим или этим.
Тогда этот сотрудник столь инициативен, что успевает работать сразу в двух компаниях — на Linode тоже ведь проявилось.
Помнится, «Хетцнер» всегда был ну очень мутной конторой. Постоянно слышал о каких-то проблемах у тех, кто держал там «железные» сервера в нулевых.
Ребята просто держали
а) Tower'ы
б) меняли в случае выхода из строя б/у железо на б/у (не всегда, но часто)
в) не следили за сданным в аренду оборудованием (то есть пока сам не увидишь, что у тебя ОЗУ сбоит или диск сыпется, Хетцнер не почешется).
г) и имели техподдержку, которая уровнем отличалась от сотрудника к сотруднику
Грубо говоря - обычный low-end хостинг, которому повезло масштабироваться вверх.
То есть все бизнес-процессы были сильно далеки от идеала.
а) у меня были некоторые инсайды, что там не таверы, а свои корпуса, но попросили не разглашать подробности
в) услуга тут "сервер в аренду". У них тупо нет технической возможности мониторить "рам-диск" без добровольной установки какого-то агента юзерами, так что тут вообще мимо. Да, это именно ТВОЯ забота как админа. Не нравится - есть облака, есть вдс - там к железу есть доступ у провайдера и они могут ставить что угодно и мониторить. Суть "аренды железки" именно в том, что к ней очень ограниченный доступ. И есть полное право зашифровать диски без возможности загрузки чего-либо до ввода пароля через консоль (ipmi/kvm/физически подойти)
Это как поставить свой личный сервер в ДЦ и ждать что его состояние будет ДЦ мониторить. Максимум - сомнительную активность на интерфейсах.
Сначала были таверы, потом свои корпуса - https://www.youtube.com/watch?v=5eo8nz_niiM
в) ну, это же не совсем так. У нормальных серверов есть IPMI (или аналоги), и с него собирается health дата нормальными хостерами. И нет, не требует установки дополнительных агентов в клиентскую ОС =)
и как минимум нужно открыть доступ сторонней утилите. И начать надо с заведения логина с правами только чтения.
при этом такие вещи прямо запрещены в том же pci dss, мониторить можно строго с доверенных хостов итд.
Короче, не надо пытаться перекидывать задачи админов на хостеров.
и как минимум нужно открыть доступ сторонней утилите
открыть доступ где? Если IPMI сервера остается в ЗО хостера, то он сам всё делает, а от клиента ничего не требуется.
Могу привести еще более низкоуровневый пример: на сервере есть (платная опция) в виде выдвигающейся фиготени, которая показывает статус всех его компонентов на матрице из светодиодов
в том же pci dss
не каждый хостинг-провайдер соответствует PCI DSS требованиям, это нормально.
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c03243777 зацените, сколько информации можно "считать", тупо стоя рядом с сервером (в том числе аларм/отказ жестких дисков и планок ОЗУ - по отдельному, мать его, светодиоду на каждый слот).
Если IPMI сервера остается в ЗО хостера, то он сам всё делает, а от клиента ничего не требуется.
То есть нужно разрешить хостеру физически воткнуться к серверу чтобы войти в биос и вероятно ещё передать пароль, чтобы какой-то инженер к нему пошёл ногами, воткнулся и имел техническую возможность сделать что угодно. И если потом не сменили доступы - то ничего не мешает инженеру снова подойти и сделать что-то недоброе.
Ни один вменяемый админ не передаст полный доступ "я рукожоп, так что вы настройте сами всё, а потом выставите пароли, скиньте нам и забудьте их. МАКСИМУМ это вместе с сотрудником дц админ ножками подойдёт к серверу, залогинится, сам вводя пароли и введя настройки нужного юзера.
на сервере есть (платная опция) в виде выдвигающейся фиготени
1) с этой "фиготени" нельзя ничего изменить
2) там нет чувствительной инфы
3) это что, сотрудник дц будет каждый день обходить ВСЕ серверы, отрывать стойки (часто они закрыты на ключ клиента, сюрприз, или код который знает только клиент - в настоящих дц именно это норма)
4) да, аппаратные рейды умеют пищать что нужно внимание, о таком сотрудники обычно сообщают, только большинству клиентов это "ок, поставим в план работ на ближайшее полугодие". Другой вопрос что аппаратный рейд денег стоит и в 21 веке уже по факту не нужен.
зацените, сколько информации можно "считать"
можно, да не можно. Нет приватной инфы, и чтобы понять что не так - см выше. Ходить, открывать запертое чужим ключом итд. И главное - смысл? Не проще нанять нормального админа или использовать вдс/облака, где хостер сам всё настроил как посчитал нужным?
разрешить хостеру физически воткнуться к серверу
Мы точно всё еще об аренде выделенных серверов, а не о колокейшене своих?
да.
Это как брать машину в аренду, где будет поставлено несколько камер в салон для слежки за водителем (и возможно даже со звуком). Право имеют? Да. Будут ли активно такое брать, если куча вариантов без слежки? Аналогия очень примерная конечно. Но шанс "они значит и в системе могут бэкдор оставить для своего удобства" сильно не нулевой. Тем более если брать железо бытового уровня, только так можно получить данные с железки, ипми там нет как класса.
Далее. Это сильно больше возни, и ради чего? "удобство клиента"? И см выше про админа, давайте еще хостер будет настраивать ПО на сервере, проблемы решать... Не, конечно за ваши деньги любой каприз, только все будут хотеть это бесплатно. А так можно договориться с хостером, вопрос сколько это будет в месяц.
К слову, у хп был тариф где сервер сам видел проблему, слал в представительство данные и условно через 2 часа-сутки у дверей стоял курьер с деталью на замену. Но - это ПЛАТНАЯ услуга. А бытовое берут кому нужно дёшево.
ЗЫ фаствпс предлагал софт для контроля за теми же дисками, бесплатно (для серверов взятых у них, вроде). Ставили далеко не все.
Основных претензий лично мне видится две
Хецнер известен абсурдной реакцией на абузы в духе "пришла какая-то спам-абуза, срочно отпишите нам что вы будете по этому пооводу делать, указав все свои персданные, включая девичью фамилию матери, мы это передадим автору письма на рассмотрение, а иначе заблокируем сервер". Немецкий менталитет, увы.
народ велся на дешевые цены, но не понимал что это лоукост-хостинг на десктопном железе (конечно не уровня "виртуалка за два бакса в год", но не сильно выше) и как с такими хостингами работать
По отличиям лоукост-хостинга от серьезного:
десктопное железо со всеми вытекающими нюансами (скажем, отсутствие ECC [не везде], iKVM и т.п.)
у "сервера" 1 БП, КЗ у одного сервера - вырубило стойку. Это вам не Tier 3.
в основном ориентированы на использование их готовых образов Linux, установка чего-то своего или починка загрузки через KVM-консоль - возможно, но больно.
По качеству железа - надо привыкнуть, что физические сервера в любом хостинге при принятии стоит всегда хотя бы базово тестировать любым бенчмарком RAM/CPU/SSD, и при возникновении проблем описывать их не как "а вот у нас на сервере зависает наша самописная вундервафля на ноджс, запускаемая в докере через кубернетис на фрибсд под виндой", а как "мы загрузились в ваш Rescue System, запустили memtester/stress и сервер отвалился через час".
"Дорогие" хостинги готовы поменять вам сервер при любом капризе, лоукосты экономят деньги. Да, есть куча сложных проблем, которые не воспроизводятся на простых тестах. У хецнера в таких случаях обычно достаточно просто заказать еще один сервер в такой же конфигурации и отказаться от прошлого, если это конечно не проблема прошивки или совместимости. Nothing personal, just business, не нравится - идите к другому хостеру за минимум двух-трехкратный ценник. Покупать Жигули по цене Жигулей и хотеть от него качества Мерседеса странновато.
Но если вы понимаете чего ждать и на чем можно, а на чем нельзя экономить в вашем случае, особенно если вам нужен не один сервер - деньги экономятся отлично, три "десктопа" на Ryzen 9 с ECC в разных локациях против одной сравнимой супермикры c Xeon в Tier-3 ДЦ с SLA 99.9.
КЗ в БП вырубит стойку в большинстве датацентров. Просто чуть более вменяемые дц дают 2 независимые линии и для серверов с 2 бп это не является проблемой. Слишком дорого и технически сложно мониторить каждый порт питания, обычно это сдвоенный автомат на 0-unit PDU. Чуть проще с 3-фазными, там чаще вырубит одну фазу (треть розеток) (не всегда, у некоторых автомат групповой).
В остальном да, нужно понимать что берёшь и зачем. Но в современном мире уже много лет сколь-либо нагруженные/важные вещи умеют не просто в отвал одного сервера, а всего ДЦ целиком, и в этом случае во всех смыслах лучше брать 3 бытовых железки в разных дц чем 1 брендовую с 2 бп - и всё-равно будет дешевле, значительно, год назад у меня вышло - настоящий сервер в 10 раз дороже бытовой железки и раскидывание на 3 дц в 3.3 раза уменьшает расходы. Конечно, какое-то важное ядро можно поднять на настоящих, но такие вещи как веб-сервер (при заточенном приложении) вообще легко поднимаются на бытовом силой небольшого увеличения объёмов работы, а бонус - ниже цены, шире каналы, выше живучесть, больше гибкости, проще админить (можно просто погасить сервак без месячных согласований на обновление оси например). Работы становится больше (привет кубер и прочие ансиблы), но сама работа проще. Ну и траблы типа "мы пролюбили место на 1 сервере" автоматом спускается до "вернемся из отпуска - починим".
ЗЫ для мелких вещей в итоге сильно выгоднее брать облако/вдс, там и снапшоты, и какие-то бэкапы часто есть, и точно со стороны железа всё работает. Первая же авария "сдохли оба диска, бэкапов нет" перекрывает ту незначительную экономию перед арендой железки.
Да, абузы были отдельной темой для хейта со стороны пользователей, которым они прилетали. Особенно если абузу катала шарага типа clean-mx.de
Довольно сложно представить, что Hetzner будет делать такие вещи в интересах России.
А в интересах местной BND?
Это не связанные вещи, хоть и подозрительно, конечно.
Цой jabber жив! ;)
Вот и все что нужно знать о безопасности сторонних сервисов. Сертификаты, криптография.. Ключи 4096 бит.. А потом оказывается, что один одмин игнорирует ошипки сертификатов где-то внутри инфраструктуры, а другой хакер забывает продлить протухший сертификат..
игнорирует ошипки сертификатов где-то внутри инфраструктуры
Так ведь нет никаких ошибок, ни со стороны сервера, ни со стороны клиента. Все сертификаты валидные.
Ну да ... документы в порядке ... пришёл чувак ... с паспортом на имя ... выписанным от имени МинОна (может МинОна и официальная контора)
но мы даже реально не проверили, на чьё имя выдан паспорт - нас это не интересовало - главное "безопасность" соединения - чтобы никто не подслушал линию связи точка-точка (и не важно с какой точкой мы соединяемся - для нас всё равно все наши собеседники анонимны)
Он не игнорировал ошибки, их не было. Но в любом случае админ не прав: за выданными сертификатами не следил (через certificate transparency или хотя бы тот же let's encrypt), secure dns видимо не настроил.
Вы знаете, у меня смешанные эмоции.
С одной стороны, это крайне досадный случай, где всё в одну кучу: атака со стороны хостера, не прописанные CAA и не включенный DNSSEC, бесплатный сертификат от LE который можно при таком конфиге выписывать хоть раз в час по новому экземпляру.
А с другой -- администратор сервиса, oxpa, только что в MUC'e XMPP Service Operators ничтоже не сумнявшись заявил, что они не обновляли ejabberd с 2016 года. На просьбу включить на сервере принудительный STARTTLS для c2s\s2s ответил, что и дальше продолжит высменивать шифронёрдов.
На опеннете выражаются ещё более обидно, но я тут сдержусь. Яма просто вырыта была самостоятельно. Забивать на мейнтенанс таких сервисов нельзя.
А помогло бы это все? В том смысле, если очень нужно, то, наверно, можно и DNS аналогично за MITM-ить?
Не, тут уже не всё так просто. Если правильно настроен DNSSEC -- спуфнуть записи просто так не удастся. Если правильно настроен ещё и САА -- то и сертификаты как попало выписываться не будут. Можно прибиндить к конкретному ACME-эндпойнту, аккаунту LE и так далее.
<cut> был неправ)
CAA скорее всего не поможет, тем, у кого он настроен на letsencrypt.
Поможет. Тут коллеги подсказывают, что можно биндить как-то так:
issue "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/ACCOUNTNUMBER"
В итоге имеем, что letsencrypt превратился в инструмент для mitm любого домена у которого не настроен CAA и DNSSEC.
И проблема тут не техническая, в том, что они как доверенный центр сертификации выдают сертификаты "коням в пальто" без достаточной проверки.
У меня чешутся руки просто добавить этот "центр сертификации" в черный список браузера, как минимум.
Мне думается, что, во-избежании подобного, letsencrypt ДОЛЖЕН прекратить выдавать сертификаты тем, у кого DNSSEC и CAA не настроены. Совсем прекратить.
Это не вина LE -- это косяк админов, которые будучи уверенными в том, что все эти модные свистелки и перделки не нужны, прохлопали шикарный вектор атаки.
Этой атаки можно было бы избежать, приколхозив, например, public key pinning -- это достаточно легко автоматизируется, и вполне работает и в случае с XMPP. При этом DNSSEC и CAA тут бы не понадобились.
Неа.. весь смысл центров сертификации как раз в том, чтобы удостоверять владельца сайта. Если они выдали сертификат "коню в пально", это их проблема. CAA и DNSSEC нужны чтобы защитить владельца домена от последствий недобросовестных действий со стороны "доверенных" центров сертификации.
Это не дает letsencrypt права совершать эти недобросовестные действия.
Это вектор атаки не специфичный для jabber.ru. Он специфичный для letsencrypt!
Неа.. весь смысл центров сертификации как раз в том, чтобы удостоверять владельца сайта.
В случае с DV сертификатами - они должны только проверять что тот, кто запрашивает сертификат, имеет доступ к домену. И он ведь имеет! Так что все верно. Это актуально не только для LE, но и для остальных УЦ.
В данном случае MiTM устроил хостер. Если бы такой возможности не было, хостеру почти ничто не мешало бы утащить ключи с самой виртуалки напрямую. Просто пошли более простым путем.
Ну, типа все ОК. Все ОК.) К вашему домену имеет доступ кто угодно. Мы подтверждаем) И сертифицируем)
Хотя на самом деле доступа к домену нет) Есть доступ к трафику в сторону этого домена. А он, в некотором объеме, у любого провайдера есть.
Ещё раз оговорюсь: произошедшая ситуация никак не является виной конкретно LE. Подобного же исхода можно было бы ожидать, если бы у атакующего был доступ к диску системы и возможность вычитать ключи. Ничего бы не изменилось.
Если бы доступ к диску системы был получен и использован, то, тогда letsencrypt был бы не виноват. Это единственное, что бы изменилось)
А, т.к. доступ к диску не был получен, и, не использовался при атаке, то сертификат был выдан неправомерно. И Letsencrypt виноват) просто по факту того, что провайдер предпочел не использовать доступ к диску, и намерено сделать letsencrypt виноватым. ОК?
И Letsencrypt виноват)
Вы же понимаете что точно так же был бы "виноват" любой другой УЦ?
Любой другой УЦ который использует уязвимые протоколы установления наличия доступа к домену. Они могут отличаться у других провайдеров.
То есть, любой провайдер, который проверяет данные кредитки и берет деньги за свои услуги, скорее всего гораздо менее для этого уязвим.
То есть, любой провайдер, который проверяет данные кредитки и берет деньги за свои услуги, скорее всего гораздо менее для этого уязвим.
А в чем разница, получил хостер сертификат бесплатно или за 20$, если и тот и тот позволит сделать MiTM?
1 цент или 20 долларов - не важно. Но, если кредитка есть, то на ней есть имя, которое можно, как минимум, сверить с информацией во WHOIS и т.п. и, возможно, проверить по другим каналам.
если кредитка есть, то на ней есть имя, которое можно, как минимум, сверить с информацией во WHOIS и т.п. и, возможно, проверить по другим каналам.
Админ уволился - упсь, протухший сертификат не может никто.
Как вы предоплаченную кредитку из стамбула проверите, вы идиот?
Вообще нет. В большинстве случаев от вас попросят всё то же: выложить файлик на нужном домене по 80 порту и\или создать DNS-запись.
То есть абсолютно всё то же самое, что делают acme.sh или Certbot, только вручную.
То есть, любой провайдер, который проверяет данные кредитки и берет деньги за свои услуги, скорее всего гораздо менее для этого уязвим.
С практической точки зрения это мало что даёт (удостоверяющих центров много, инциденты случались и ранее, и, более того, они в принципе возможны, ну просто прийти спецслужбам нужно будет не к хостеру, а в УЦ). То есть, сама система уязвима, её нужно улучшать, а не бороться с тем, что делает Let's Encrypt — они в целом сделали Интернет намного безопаснее. Слабое звено — не они.
Решить проблему можно, наверное, если требовать две подписи на сертификате, одна — удостоверяющего центра, другая — при помощи некоторого ключа владельца сайта, который может быть постоянным в течение длительного времени, чтобы, при этом, эта проверка была по умолчанию отключена (чтобы не пугать пользователей), но те, кому нужно, могли бы её включать, ну и чтобы владелец сайта также мог обозначить, что проверка должна быть включена при последующих посещениях сайта.
Hsts давно придуман и работает. У него есть и плюсы и минусы. Для настолько раздолбайских сайтов он скорее вреден.
Они молодцы. Но, улучшив безопасность в одном месте, где изначально не было безопасности (HTTP), они создали по сути новый вектор атаки в том месте, где безопасность, как бы, предполагается (https).
По-моему, так себе, размен.
Я согласен, что это общая проблема индустрии. Уже давно везде, где требуется хоть какая-то безопасность, требуется двух-факторная аутентификация. И, одного пароля, передаваемого по защищенному соединению, не достаточно.
А, тут, у нас, по сути, выдача сертификата на основе "пароля"-файла, который еще и по незащищенному соединению проверяется, возведен в стандарт индустрии.
Надо что-то менять.
Что по вашему должен проверять Letsencrypt, выдавая сертификат?
Я не понимаю, что конкретно вы понимаете под "удостоверять владельца сайта". Вряд ли вы ожидаете поход ножками и предъявление удостоверения личности, на имя, совпадающее с записью о владельце домена (кстати, владелец сайта и владелец домена - одно и то же лицо?), именем на карточке, по которой прооизводилась оплата...
Смотрите, вы отошли от компа и не заблокировали сеанс. Некто воспользовался этим, открыл браузер, в котором вы залогинены на Хабре и написал что-то эдакое.
Хабр честно указывает, что коммент написал аккаунт "dorne". Но писали его не вы.
Это задача Хабра убеждаться, что браузер запустили вы? Давайте сделаем так, чтобы перед написанием комментария нужно было сфоткаться с флажком в жопе и паспортом возле лица?
LE удостоверился, что сертификат запрашивает сервер, который имеет право его запрашивать. Всё, больше LE ничего не должен.
Мы подтверждаем)
Обычный сертификат (не EV) подтверждает лишь то, что соединение зашифровано.
Он не подтверждает, что сайт не фишинговый. Тем более он не подтверждает, что легитимный сервер не захвачен спецслужбами или ещё кем-то.
Именно поэтому сейчас все основные браузеры перестают показывать зашифрованное соединение как нечто зелененькое вау. Потому что это не вау, это просто норма, что трафик не открыт каждому узлу на маршруте.
DV все же подтверждает что соединение установлено с тем, кто имеет доступ к домену. Но не более того.
Domain Validation (DV) или проверка на уровне домена требует
только подтверждения права владения адресом, для которого нужен
сертификат. В данном случае центр удостоверяет связь доменного имени с
сервером и сайтом. Это гарантирует пользователю, что он попал именно на
тот домен, на который заходил. Информация кодируется, но сведения о
владельце сертификата не указаны.
Весь смысл центров сертификации - брать деньги за воздух. Ответственности с них абсолютно никакой, что с LetsEncrypt, что с VeriSign. Максимум, повинятся в бложике, и продолжат получать свои бабки в прежнем объёме.
У меня чешутся руки просто добавить этот "центр сертификации" в черный список браузера, как минимум.
Вы сразу потеряете доступ например к этим сайтам:
XHAMSTER, Quora, Stack Overflow, Indeed, DeepL, Slack, Mozilla, StackExchange, SuperUser, Nalog.Ru, Ask Ubuntu, NY Post, T-Online, USA Today, Pikabu. В первой тысяче самых популярных сайтов по версии alexa.com сертификатами LE закрыты 138.
Потеряю. Доступ по HTTPS. Не будет в браузере замочка больше. И, я буду знать, что сайт небезопасен. При доступе к сайту по HTTPS будет предупреждение, что соединение небезопасно. В этом смысл. Чтобы браузер предупреждал о небезопасном соединении. Что с этим делать я при необходимости решу в каждом частном случае.
Из этих сайтов, кстати, вызывает вопросы nalog.ru. А не является ли "использование" ими сертификата LE результатом MitM атаки аналогичной jabber.ru?
У большинства из этих сайтов настроен HSTS. Так что вы просто потеряете к ним доступ, точка. По HTTP они не откроются до тех пор, пока их вебсервер будет анонсировать, что сайт доступен только по HTTPS.
Что до сайта налоговой -- для лендинга нормально использовать бесплатный сертификат, там нет ничего важного. https://lkfl2.nalog.ru/ прикрыт нормальным сертификатом от GlobalSign.
У меня HTTP заблокирован в принципе. Я имел ввиду другое совсем.
Видя предупреждение о сертификате выданном LE, в каждом частном случае, я могу сам проверить, стоит ли доверять этому сертификату на этом сайте. И, правильно оценить риски, прежде чем делать на этот конкретный сертификат исключение.
Раскрывая ваш пример. На nalog.ru я скорее всего сделаю исключение. А вот, если увижу его на https://lkfl2.nalog.ru/, то уже исключения не будет, ибо, это, совсем другой уровень риска.
Если же я не заблокирую сертификат LE, то этого предупреждения не будет. И, я могу просто не заметить.
А вы не сможете на эти сайты добавить исключения. HSTS этого не позволяет: условный Chrome прямым текстом скажет, что раз HSTS включен, а вы лезете или с левым ключом и\или без шифрования, то придётся подождать, пока администратор сайта починит конфиг.
Вам придётся патчить свой браузер, чтобы таки-зайти на подобный сайт.
Я не пользуюсь хромом. А мозилла позволяет делать исключения.
Ну, хорошо, тут это сработает.
Но вообще, вы ерундой занимаетесь -- в худшем случае, что по HTTP, что по HTTPS с отпиленным HSTS, трафик всё равно может быть перехвачен.
Если вы не можете проявлять аккуратности без красного значка в адресной строке -- ну, я не знаю что ещё сказать.
Ну, понятно что любой можно, вопрос в сложности. Практика показала что с LE в некоторых случаях это слишком легко. Что повышает уровень риска.
А блокировка сертификата помимо моей невнимательности еще защищает от автоматической подгрузки сторонних JS скриптов на сайт с других доменов. Которые могут тоже быть за MitM-лены.
идя предупреждение о сертификате выданном LE, в каждом частном случае, я могу сам проверить, стоит ли доверять этому сертификату на этом сайте.
Интересно, как бы вы проверяли кейс, описанный в посте. Да и любой другой тоже. Вот видите сертификат LE - дальше последовательность ваших действий какая для проверки? Какой признак будет говорить вам о том, mitm это или нет?
Проверять сам сертификат в crt.sh, - бесполезно. Надо проверять CAA и DNSSEC, как люди выше писали. И, если там все не настроено должным образом, - просто не пользоваться сайтом.
Потому что, если не настроено, то понять кому-то, кроме админа сайта, mitm это или нет, - невозможно . Со стороны не видно, что сертификат поддельный. А, я не сторонник игры в рулетку для вещей вроде jabber.ru.
В идеале хотелось бы это как-то автоматизировать чем-то вроде плагина.
А можно подробно статью как настроить DNSSEC чтобы такое не проходило или хоть сразу всплывало?
У меня то все проще - DNS и так на Cloudflare (в рамках моей модели угроз - Cloudflare считается доверенным, возможно неправильно) и там есть такая опция как мониторить выпускаемые для доменов сертификаты и слать на почту. И шлют.
DNSSEC может настраиваться по-разному, в зависимости от вашего регистратора. В общем случае, вам нужно будет сгенерировать закрытый ключ, чтобы на его основе каждый раз генерировался корректный публичный, для всех записей вашего сервера. Многие регистраторы предложат сгенерировать ключи за вас, но в таком случае вся затея имеет мало смысла.
Cloudflare умеет автоматически включать DNSSEC, если домен зареган у них. Для мелочёвки с небольшой важностью у меня так оно и работает.
В идеальном случае, надо бы поднимать свой DNS и делегировать на него домен.
В идеальном случае, надо бы поднимать свой DNS и делегировать на него домен.
Не надо. Вам делать что ли больше нечего?
Разносите DNS и хостера в разные юрисдикции и отлично. Юрисдикции должны быть по настоящему разные. Россия+Германия, например. Чтобы и того и другого заставить что-то сделать было неимоверно сложно.
Аргумент с разными юрисдикциями хорош в теории, но мало что даст по факту. Тем временем, поднять собственный DNS не так сложно, а для ленивых всегда есть Mail-in-a-Box.
Поднять все несложно. Сложно поддерживать еще еще один сервис с девятками доступности. Это прямо заметных денег стоит.
Чем именно вам не нравятся разные юрисдикции?
Речь не про то, как просто включить DNSSEC
А про
> Если правильно настроен ещё и САА -- то и сертификаты как попало выписываться не будут. Можно прибиндить к конкретному ACME-эндпойнту, аккаунту LE и так далее.
Выше по комментам я уже написал пример того, как должна выглядеть CAA-запись. Ещё можно почитать https://letsencrypt.org/docs/caa/
они не обновляли ejabberd с 2016 года
Это не означает, например, что они не бэкпортируют патчи для критических уязвимостей.
Мне тут подсказали, что разработчик ejabberd входит в команду jabber.ru. Вероятно, он разбирается в уязвимостях своего же сервера.
В общем, мало информации для того, чтобы делать вывод "у них сервер не обновлялся 7 лет". В каком-нибудь CentOS ядро 2.6 ещё годами эксплуатировалось после прекращения поддержки, поскольку мейнтейнеры переносили исправления из более свежих ядер.
мейнтенанс
Полностью агри с вами, это очень бэд практис. Но, как говорится в аур имменс, дурак маст саффер. Ну или: фейт сыграла с ним бэд джоук. Как угодно.
Что у нас Certificate Transparency по этому поводу говорит? Не ушто не заметили нового сертификата?
Он не был настроен, как я понял
Для того чтобы заметить, нужно за ним следить. Собственно, там и заметили, но уже постфактум.
Там куча выданных сертификатов. Даже по датам совпадает. https://crt.sh/?q=jabber.ru Кому ключи от них достались неизвестно.
Все сработало как полагается. Любой мониторинг заорал бы сразу.
Поздно пить боржоми, как говорят. CT придуман для определения "нечестной игры" и решения "проблем доверия" к центрам сертификации. Наличие там сертификатов показывает системную проблему с доверием к letsencrypt как к центру сертификации.
Конечно. Это просто логи. У которых ровно одна задача: недопустить появление сертификата о котором никто ничего не знает. Чем в общем регулярно пугают обывателей. Они ее решили отлично. Все работает ровно так как и задумано.
LE надо что-то менять в алгоритме валидации тех кому они сертификаты выдают. Пора подумать и о безопасности, а не только об удобстве.
Почему - проблема? Letsencrypt делает ровно что обещал - выдает сертификаты всем кто прошел проверки, а то что ее можно пройти таким вот способом - ну так CT-логи на что?
Логичный собственно вариант - скриптики работы с Letsencrypt доработать чтобы "легальные" запросы писались и есть в CT-логах появляется что-то неожиданное - орать. Мне вообще казалось что в серьезных средствах мониторинга это уже есть, ошибочно похоже.
Логи не дают защиты. Вот увидели вы левый сертификат в логах и что делать? Кроме как тушить сервис я даже придумать ничего не могу. А это так себе решение.
Логи отработали как надо. Проблема понятна. Теперь надо что-то делать чтобы ее решить. А логи покажут если решение снова окажется не очень.
Это не означает что логи не надо мониторить. Надо. Не знать о проблеме это еще хуже.
Любой мониторинг заорал бы сразу.
Мониторинг заметил бы, что у сертификата вдруг fingerprint изменился. Но кто же будучи в здравом уме мониторит сертификаты со стороны каждого клиента..
CT логи мониторить и орать если там есть сертификат который вы не получали. Не?
CT логи мониторить
Готовых шаблонов для zabbix/nagios я не нашел. Нужно строить свой костыль. :/
Сама технология концептуально дырявая и устарела. Хотя в данном случае это лишь косвенную роль сыграло.
Если подменять сертификат не всем, а конкретному пользователю, то это вообще не отследить. Т.е. вполне возможно, что УЦ в какой-нибудь юрисдикции (не буду показывать пальцем) давно клепает их тысячами. Или начнёт в любой момент - нет никаких технических ограничений.
Там давно просится блокчейн в котором пока не опубликуешь, сертификат не действителен. Там же можно и ограничить права повторного перевыпуска други УЦ.
При чем, это блокчейн элементарно накатывается поверх текущей системы.
не понял, то есть теперь какой-то конь в пальто может с нифига выпустить себе сертификаты для моего домена?
Совершенно верно. Любой провайдер который способен перехватывать трафик от вас до сервера letsencrypt.
Для избежания этого и придумали CAA записи в DNS.
А, если сайт уже использует letsencrypt? Что в CAA прописать?
P.S. Там выше ответили в ветке.
CAA 0 issue "letsencrypt.org;validationmethods=dns-01"Нет большого смысла прописывать accounturi вместе с validationmethods=dns-01, т.к если вражина умеет редактировать DNS, то и аккаунт он сменит. Разве что ваш провайдер умеет выдвать API-ключи на редактирование конкретно TXT (или конкретно _acme-challenge.example.com), или же запрещает изменять CAA по апи, но я такого не встречал.
P.S. С точки зрения "плохого хостера", HTTP-способ получается даже безопасней (при наличие CAA записи с аккаунтом, именно так, как вам показали выше). На сервере не хранится dns api key, и при физическом доступе к нему, CAA изменить не смогут.
Не совсем конь в пальто. Для этого надо создать файлик на вашем сайте с нужным именем и содержимым. Провайдер, например, может - ибо у него есть доступ к вашей виртуалке.
Когда сервер letsencrypt этот файлик запрашивает по http любой, кто может сделать mitm между сервером letsencrypt и вашим сервером может скормить letsencrypt-у нужный файлик даже если его нет, и, никогда не было на вашем сервере.
Т.е. если подтверждать LE через Cloudflare API путем изменения DNS, то всё ок? И не совсем понял дискуссию вверху о то, что DNSSEC + САА бы спасло.
Не ОК, потому что, до тех пор, пока старый способ получения не заблокируют, "конь в пальто" все равно, вероятно, сможет получить сертификат.
Но, благодаря настроенным DNSSEC и CAA он его, возможно, не сможет использовать по назначению.
Не используйте этот способ, вот и всё.
Пользователь выбрал HTTP, а виноват LE.
Кроме того, в обсуждаемом случае это бы не спасло. У хостера есть полный доступ к серверу, такой же, как у владельца. Спастись тут можно, разве что, если железо стоит в подконтрольном вам месте (но со всеми вытекающими минусами - построить свой датацентр, не уступающий по качеству Hetzner или Linode, в одиночку вы не сможете).
В данном случае, "пользователь", скорее всего, letsencrypt-ом не пользовался вообще. Им пользовался только злоумышленник, и, очевидно, выбрал наиболее удобный ему, и, при этом, наименее "безопасный" способ верификации. Который злоумышленнику удалось "взломать" через mitm и получить подписанный "поддельный" сертификат для чужого домена.
Администраторы сервера как раз таки и пользовались Let's Encrypt. И именно поэтому, из-за не-настроенного CT и всех остальных упомянутых выше проблем, полгода не замечали атаки.
Но, если бы они им и не пользовались, то, вероятно, атака все равно была бы возможна. просто, было бы заметнее.
Она была бы заметна в момент выдачи постороннего ключа. Все ключи, выдаваемые сейчас, видны в CT -- потому что только такие ключи принимают, например, Chrome и Safari.
https://github.com/SSLMate/certspotter, или, на худой конец, парсилка https://crt.sh/?Identity=jabber.ru решили бы проблему оповещения на корне, после чего сервис можно было бы немедленно тушить, в т.ч. автоматически.
Точно так же атака была бы возможна при явном содействии коммерческого удостоверяющего центра, что не является невозможным в случае задействования правоохранительных органов.
От действий государства защиты не предполагается. Они могут и на корневых серверах ключи поменять, если захотят.
Ну тогда никакой разницы как бы нет. Инструменты, о которых мы говорим, создавались как раз для предотвращения подобных атак. Если ими не воспользовались -- логично, что атака стала возможна.
Разница есть. Для пользователя. Раньше пользователь видя замочек в браузере мог быть уверен что соединение защищено.
А теперь это совсем не так.
Мне бы хотелось увидеть реакцию разработчиков браузеров, в виде отсутствия замочка в случае выключенного DNSSEC+CAA на таких сайтах.
Разницы нет никакой, кроме трудозатрат атакующего. С учетом того, что в этом случае это, скорее всего, были правоохранительные органы Германии -- то вопрос затрат можно вовсе списать. Как Хецнер смогли нагнуть и потребовать перехватить трафик, так и коммерческий CA смогли бы вынудить выдать сертификат для MITM.
Замочек в браузере вообще ничего не значит, кроме того что информация зашифрована в транзите. Именно поэтому его и убирают -- потому что ложное ощущение безопасности ещё хуже чем её отсутствие.
У меня есть обоснованные сомнения, что действовали именно правоохранительные органы в данном случае.
У органов были гораздо более простые пути достижения аналогичного результата. Но, почему-то был выбран способ, который на прямое участие органов не указывает.
Это подозрительно. И намекает на то, что этим способом не только органы могут воспользоваться. Что и есть проблема.
Согласен. Суть проблемы в ложном ощущении безопасности.
Но и делать интернет безопасным тоже нужно. Так что, мне кажется, что, надо менять практики выдачи сертификатов тоже.
Посмотрите внимательно на то, как обустроен один из кампусов Hetzner в этом видео господина der8auer. Туда мышь не проскочит, крот не пукнет: колючка в два слоя, камеры, везде системы доступа по токенам, ещё раз камеры, и системы мониторинга на каждом юните.
Без ведома хостинговой площадки подобная атака выглядит практически невозможной.
Она возможна. Трафик можно перехватить и за пределами сети хостера. Это просто сложнее. Но, ненамного.
Это могло быть сделано с ведома хостера, с ведома или по инициативе недобросовестного сотрудника хостера, они могли действовать не по инициативе органов, а совсем в других интересах, и т.п.
И, не объясняет почему, если это были органы, они действовали именно так.
А как они должны были делать ещё? Субпоену сразу отправить, написать письмо владельцу сервиса? Оперативные разработки ровно так и ведутся.
Было бы странно если бы вам звонили и предупреждали, что теперь прослушивают ваш телефон, а то вдруг вы что-то не то скажете.
Абсолютно нормальное техническое решение. Сделано было с минимальными затратами и почти незаметно. Спалились по глупости, но я подозреваю, что основную задачу всё равно выполнили.
Могли у хостера образ виртуалки попросить где закрытый ключ лежит) В этом случае бы следов в crt.sh не осталось. Странно, не находите?
Партиции конкретно у этого сервиса (мы говорим про jabber.ru) зашифрованы посредством LUKS. Можно хоть десять образов попросить.
Ключи шифрования хранятся у хостера. Так что попросили бы в расшифрованном виде. И, даже если пользователь доп шифрование прикрутил, ключи все равно лежат в оперативной памяти которую хостер может сдампить.
Трафик перехватить проще, чем дампить ОЗУ. Любая ошибка -- и ты ошибся, почитайте хотя бы мемуары о поимке Макса Батлера.
Ключи жде в случае LUKS хранятся в голове у администратора сервиса и вводятся ручками через KVM.
Вектор был выбран отлично: наибольший профит с наименьшим количеством телодвижений. Если бы не истёкший серт, то с тем конфигом мониторинга (вернее, его отсутствием) админы вообще бы ничего не заметили. Ну мигнул сетевой интерфейс, ну бывает.
KVM к которому есть полный доступ у хостера.
Удивитесь, но его тоже можно шифровать. В том числе самоподписанными ключами. Так сделано, например, на всех моих серверах, где у меня есть удалённый доступ к KVM.
Я уверен, что, в случае хостера, возможно вмешаться, т.к. у него есть физический доступ к железу.
Без физической безопасности/защиты любые ухищрения и способы шифрования не работают. Это аксиома.
А, в случае органов, - ее нет.
Куда проще, при возможности физического доступа, применить к администратору сервиса метод терморетального криптанализа -- чем заниматься подобной ерундой.
Да. Если доступ к нему у органов был, могли просто попросить. Я уверен, что в случае органов, скорее всего, терморектального криптоанализа не потребовалось. Потому и сомневаюсь, что это были органы.
Интересанты находятся в Германии, где произошла атака. Владельцы Jabber.ru находятся не в России и не в Германии.
Интересанты находятся в Германии, где произошла атака.
Тоже не факт, кстати.
Мы уже ударяемся в теории заговора, честно говоря. Когда я слышу цоканье копыт, я представляю в первую очередь лошадку, а не зебру. Так и здесь.
Вы просто хватаетесь за остатки ложного чувства безопасности, которое дарит вам ваше доверие к хостерам и шифрованию.
И, боитесь признать, что при физическом доступе к железу интересант может сделать что угодно на этом железе при условии, что пользователь не знает о наличии/использовании доступа этим интересантом.
Это элементарно делается через аппаратные закладки которые при наличии доступа к железу можно сделать. Защиты от этого нет.
Может и сделает, безусловно. Что здесь и произошло -- выбрали самый простой способ перехвата нужной информации из возможных.
Ещё одна аналогия: когда у меня поднимается температура, я пользуюсь жаропонижающими, а не лезу в промышленный морозильник на мясоперерабатывающем заводе.
Так же поступили и здесь.
Это элементарно делается через аппаратные закладки которые при наличии доступа к железу можно сделать.
Можно, но сложно и палевно. Тогда как трюк с MITM, если всплывет, всегда можно спихнуть на другого клиента, который воспользовался уязвимостью.
Ну, не знаю. Во-первых органам, если всплывет, нет необходимости на кого-то спихивать. Они это делают абсолютно законно. С другой стороны они оставили огромный след в crt.sh который привел к тому, что тема оказалась широко освещена. А могли не оставлять следов. Так что, в случае проведения тайного расследования, - это epic fail.
они оставили огромный след в crt.sh который привел к тому, что тема оказалась широко освещена
Ну, оставили. Не следе не написано чей он. В отличие от ситуации, когда герр майор лично приходил и ногой дверь в серверную открывал.
Потому могли получить доступ к серверу и ключам через хостера. Который в Германии и имеет физический доступ к железу. И, не оставляя следов в crt.sh сделать то же самое.
применить к администратору сервиса метод терморетального криптанализа
Администратор может находиться в другой стране.
Партиции конкретно у этого сервиса (мы говорим про jabber.ru) зашифрованы посредством LUKS.
Если это виртуалка - разве нельзя вынуть нужный файл прямо из запущенной виртуалки?
Нет, нельзя. В этом вся суть.
Это совершенно неверно. На самом деле можно. Не совсем понимаю, зачем вы вводите людей в заблуждение. Это сложно, но, более чем возможно при наличии доступа к железу\хосту.
Ну а вы, видимо, вообще не в курсе как работают современные гипервизоры. Не позорьтесь, пожалуйста.
Не, теоретически возможно всё -- и Denuvo побайтово выпилить, развиртуализировав все обфусцированные вызовы (greetings, MKDEV), и из оперативы ключи закрытые сдампить, заморозив чипы жидким азотом, и ввод шифрованного KVM перехватить. Всё это можно сделать, я не спорю.
Но зачем, когда есть более простой способ, который потребовал часа два работы сисадмина средней руки? И который в итоге-то и был использован?
У нас тут недавно закрывали баги вроде SPECTER MELTDOWN DOWNFALL которые чуть ли не из браузера позволяли память оперативную хоста читать, а вы мне тут сказки рассказываете. Не позорьтесь сами уж.
???
Гипервизор умеет читать и изменять память. А вот эта готовая программа заинжектит шелл-код так, что можно будет читать и писать файлы, использовать shell-доступ, запускать произвольные программы.
Нет, нельзя. В этом вся суть.
Если у гипервизора есть доступ к памяти процессов внутри виртуалки, но нет доступа к уже смонтированным разделам внутри этой же виртуалки - я удивлен.
Для того чтобы выковырять что угодно, нужно будет на лету выковыривать из оперативы закрытый ключ. Прозрачного доступа к партиции в любом случае не будет, современные механизмы изоляции этого не позволят.
А можно подробнее про "современные механизмы изоляции"? Я пока не могу вспомнить, что такого гипервизоры делают, что администратор железки не может подкинуть свой процесс в систему или почитать используемый VM диск, как любое блочное устройство.
Или речь про конфиденциальные вычисления, как у AMD SEV-NVP и Intel TME-MK?
Да, это оно, но там куча ограничений:
https://documentation.suse.com/sles/15-SP1/html/SLES-amd-sev/art-amd-sev.html
Это лучше чем полное отсутствие защиты, но защита не абсолютная.
Спалились по глупости, но я подозреваю, что основную задачу всё равно выполнили.
Скорее всего то что хотели услышать - услышали (или не услышали), а команды вернуть все взад не поступило.
так и коммерческий CA смогли бы вынудить выдать сертификат для MITM.
Мне бы вот очень хотелось посмотреть на то, как в случае всплытия этой истории, этот CA объяснял почему он не должен вылететь из браузеров, возможно в варианте "существующие сертификаты про которые не известно достоверно что левые - живут до конца срока действия".
А то помним DigiNotar с CNNIC и Symantec'ом например - за меньшее вылетали из этого бизнеса. И сильно им поможет что "а у нас ордер есть"?.
Если конечно это всплывет. Вот надо чтобы всплыло.
Одно дело, когда Symantec и WoSign выдавали DV не глядя на отлюбись, потому что у них процессы были говно и потому что им было пофиг.
Совсем другое дело -- пришла субпоена и с ней пришлось считаться. Я таких случаев (пока) не видел и о них не слышал, но в Европе и Штатах они теоретически вполне возможны.
Придется ж субпоену еще и браузерам присылать чтобы не выкидывали.
Историю с казахстанским "учениями" и "установите self-signed сертификат" который потом для MITM использовали после чего сертификат забанили в принципе так что даже ручная установка не поможет - помним? А ведь насколько понимаю - он вполне себе законно был выпущен и использовался, ну с точки зрения Казахстанских законов. Или этож-совсем-другое? А собственно почему?
Почему?
Государства бывают разные.
Любое государство будет вас защищать ровно до того момента, пока оно уверено что вы действуете не в ущерб его интересам и в рамках его законов.
То есть, предоставляемые государством гарантии условны. И, государство может их отозвать/ограничить в случае любого подозрения для проведения расследования, которое не обязательно обосновано вашими личными действиями, а может быть результатом действий третьей стороны.
Таким образом, государство может защитить вас от действий третьих лиц, но не от самого себя.
Таким образом, государство может защитить вас от действий третьих лиц, но не от самого себя.
Именно поэтому, в развитых государствах работают (или, скорее, должны работать) механизмы балансировки частей государства, чтобы они не зарывались.
Грубо говоря - есть суд (судебная ветвь власти), в который можно подать на полицию (исполнительную ветвь), и выиграть. И так далее.
Проблема в "плохих" государствах в том, что механизмы балансировки напрочь сломаны т.н. телефонным правом - когда по звонку назначается и убираются судьи, принимаются законы в трёх чтениях за один день, а исполнительная власть ориентируется не на законы, а на волю вышестоящего руководства (которому, как вы догадались, уже позвонили).
Вы фундаментально путаете два разных понятия. "защиту от государства" и "защиту от произвола со стороны государства".
Это совершенно разные вещи, и, тему 2ого я даже не поднимал и развивать далее не хочу.
Потому как в любом, даже "цивилизованном", государстве вас "цивилизованно" обвинят, осудят, и попросят у ваших соседей/хостеров поделиться ключами для расследования при подозрении. Все в рамках закона, через суд, и, суд, возможно, будет не на вашей стороне.
Существует более одного государства. И есть государства которые просьбы некоторых других - проигнорируют из принципа или хотя бы попросят прислать запрос официально (И долго)
Другое государство не сможет вас полностью защитить от того государства в котором вы живете или находитесь в данный момент.
Зато, государство в котором вы находитесь, от действий другого возможно защитить сможет.
А, "своему" государству вы, скорее всего будете должны объяснить, зачем вам понадобилась защита. Объективно и обстоятельно. То есть, расследование по-любому будет. И если выяснится, что законы вами были таки нарушены, то, защиты оно вам может и не предоставить.
То есть, в общем случае, - защиты нет.
Нифига вы тут ребята задвигаете!!! А ведь я даже не гуманитарий :((
если бы купили SSL у GS, и сделали DNS CAA было бы получше
Админ jabber.ru выявил MITM-атаку, проводимую на сервис в сетях немецких хостинг-провайдеров Hetzner и Linode