Category: it

Category was added automatically. Read all entries about "it".

(no subject)

Внезапно пригодился генератор ругательств шекспировской эпохи, который когда-то доставленный [personal profile] el_d в Удел. Я на него перенаправляю незаконные запросы к API.



За последнее время много работаю с микрософтовым облачком, Azure - весь вокабуляр этого генератора очень хочется приложить к его, облачка, создателям. Там есть много что ругать - и невозможность переименовывать объекты, и скорость внесения изменений (вместе прекрасный эффект выходит: хочешь исправить опечатку - стирай-пересоздавай кучу всего, убей на это часа четыре) - но больше всего бесит сваливание ответственности за функционирование и безопасность платформы на пользователя.

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

Звучит клёво. Да только при первой же попытке это построить натыкаешься на вот такущий список исключений, который ты обязан реализовать - и в раутинге, и в фильтрации - и все они относятся к общению между этим микрософтовским продуктом, ASE, и другими микрософтовскими же сервисами в том же Ажуре, и всё это общение должно почему-то проходить через твою типа частную сеть. Причём список этот максимально недружелюбен - не во всякий файерволл его и вобьёшь. Хочешь просто указать IP-диапазоны? - а хрен тебе. Нет, на тебе стопиццот хостнеймов, причём их один и тот же DNS-сервер будет резолвить в разное время в разный список IP-адресов. Мало тебе? - на ещё и wildcard-хостнеймы, которые файерволлу вообще указать нельзя, тут transparent proxy нужен. И причём отделить трафик собственно ASE от трафика живущих в нём приложений нельзя по определению - всё из того же сабнета.

А не реализуешь по списку - ну пожалуйста, либо у тебя дыра в безопасности будет, либо наш замечательный ASE возьмёт и сломается, сам будешь виноват, дурень.

И то же самое с каждым ихним изобретением - к каждому прилагается список УРЛов, без регулярного общения с которыми оно помрёт, хорошего вам настроения.

Какого чёрта? Почему я должен отвечать за связность микрософтовского продукта с микрософтовскими сервисами в микрософтовском же облаке? Почему нельзя вывести всю эту радость в отдельную сеть, оставив мне мой трафик? Доступ-то физических серверов к Windows Update вы же как-то осилили, не сбрасывая его организацию на клиентскую шею?

Подозрение, что это делается с целью заставить использовать Azure Firewall, не добавляет желания всем этим пользоваться. Файерволл, кстати, хороший, с фичей transparent proxy, частично удолетворяющих моим мечтаниям. Но есть и раздражающий момент: указать ему хостнейм, чтобы он сам его перевёл в IP-адрес или список адресов, нельзя. Фортигейт умеет, а он нет. Точнее, умеет, но лишь для тех протоколов, что поддерживает его proxy - HTTP(S) и MSSQL. А для всех остальных шиш, вбивайте по IP.

Ye roguish sour-faced cutpurses!

(no subject)

Задумался вот. Допустим, пишем мы вебсайт, к которому есть такое интересное требование - non-repudiation. То есть если юзер выполняет на нём некое действие - он не должен иметь возможности отрицать, что он его совершил, даже если сайт вместе со своей датабазою взломан вдребезги и пополам.

На первый взгляд, всё довольно тривиально - даём юзеру смарт-карту с секретным ключом, им подписывается тело любого POST- или PUT-запроса на сайт. Запросы сохраняются в лог и хранятся там, пока релевантность не отпадёт.

На второй - немного сложнее. Насколько я понимаю, не существует никакой возможности обращаться к ключам на смарткартах, TPM, Windows store и т.д. из бегущего в браузере JavaScript-а. И по хорошей причине - такая возможность дала бы недобросовестным сайтам выполнять операции с юзерскими ключами (подписывать или расшифровывать что-то) без ведома юзера. Даже если юзер должен разрешить доступ к ключу введением кода - ему неоткуда знать, как именно ключ используется, приходится полагаться на приложение.

Существует "Web Cryptography API", но он, насколько я понимаю, не позволяет обращаться к смарткартам и прочим устройствам PKCS#11 - он позволяет генерить ключи прямо в браузере и хранить их в local storage и т.д. Защитой, необходимой для non-repudiation, такие ключи не обладают.

Существует также проект "Web eID", который позволяет это ограничение обойти за счёт установки расширений к браузеру - но он предполагает, насколько опять же понимаю, доверие к сгруженному с сервера Джаваскрипту, а нам именно это Заратустра и не позволяет.

Таким образом выходит, что клиентская часть должна быть обычным десктопным приложением и её логика не должна задаваться на серверной стороне. Так ведь?



Ну а для контента, выдаваемого сервером, организовать non-repudiation не в пример легче, и не дорого - генерим неизвлекаемый ключ в каком-нибудь online HSM, скажем, в том же Azure Key Vault, и подписываем отсылаемые файлы.



То, что смарт-карта не должна позволять экспорт ключей, тривиально - а вот есть ли смарт-карты, не разрешающие также и импорт? Чтобы ключ можно было бы сгенерировать лишь в ней, и быть уверенным, что он существует лишь в единственном эксземпляре?
Это свойство и для аутентификации полезно, но для non-repudiation - особенно.



Даже и в этом случае хитрый юзер мог бы отпираться "я не я и корова не моя" - мало ли что в сертификате написано, может, админ CA сам его себе на моё имя выписал. А смарткарту и потерять можно. Способ это побороть - заставить расписаться (ручкой по бумажке) при получении смарткарты, с указанием thumbprint сертификата - для каждого ключа уникального. Ну или использовать такие карты, от которых особо не пооткрещиваешься, типа нового израильского "биометрического" удостоверения личности - хоть там косяков и полно.
  • Current Music
    Машина времени - Рыбак рыбака
  • Tags
    ,

(no subject)

Azure Key Vault - очей разочарованье. Читаешь - вау, круто, хардверная защита, неэкспортируемые ключи, файерволлы, managed identities, access control!
Вникаешь в детали - и тут же выясняется, что для SSL защита ключей нерелевантна. Потому что то, что реально происходит, это:
- сертификаты с секретными ключами просто сохраняются где-то на диске,
- ажурные виртуалки, на которых бегают App Services или App Gateways, попросту переписывают их себе - вместе с ключами - и используют локально.

Таким образом:
- HSM вообще не при делах,
- да и импортировать ключ в этот HSM тоже нельзя - только сгенерировать внутри (поправка: не точно, но для того требуется исходный HSM, так что один хрен),
- да и просто сохраняемый на диске software-protected key тоже экспортируемым быть обязан - иначе для SSL он неприменим. То есть любой, имеющий доступ к Key Vault, его скачает без проблем.

Умом, впрочем, и так понимаешь, что не могёт того быть, чтобы для любой новой SSL-сессии к HSM обращаться - а всё одно обидно.

(no subject)

В продолжение мечтаний:

Вот интересно, существует ли на белом свете сетевая хреновина типа файерволла, умеющая обрабатывать исходящий HTTPS-трафик следующим образом:
1. Ответить на попытку установить TCP-соединение на любой адрес - от имени этого адреса.
2. Получить от юзера пакет "Client Hello", прочесть оттуда хостнейм из поля SNI - сегодня его посылают практически все.
3. Проверить по DNS, на какие IP-адреса резолвится этот хостнейм.
4. И лишь после этого искать подходящую firewall policy и проверять:
  • соответствует ли хостнейм из SNI тому адресу, на который было запрошено соединение,
  • или тому, что указано как destination в этой полиси - а это могут быть как и диапазоны адресов (в таком случае надо проверить, попадает ли адрес, используемый юзером - или же адреса, полученные от DNS - в эти диапазоны), или же текстовые правила типа регулярных выражений (тогда надо на них проверить хостнейм),
  • соответствует ли сертификат, посланный сервером, этому хостнейму - по полям CN и SAN.

    Ну и в качестве вишенки на торте, чтобы проверяла полученный сертификат по ограниченному списку CA и чтоб deep inspection умела делать. Ну ещё и заголовками HTTP манипулировала, мечтать так мечтать.

    Фортигейтов Explicit Proxy умеет многое из этого, но это прокси. Клиентов надо настраивать к нему обращаться. Но вообще-то без малого 2020-й год на дворе, было бы неплохо уметь делать умную обработку трафика и прозрачным для юзеров образом.

    Если нет такого - так выпьем же за то, чтобы в наступающем новом году!..

    Windows RRAS как IPsec-клиент

    Давно я Микрософт не ругал.

    Понадобилось тут прокинуть site-to-site IPsec-туннель между FortiGate и Windows-сервером. Документации по такому сценарию нагуглилось ноль, пришлось действовать методом проб и ошибок. Благодаря сниффингу, дебаггингу и молитвам к известной матери построить таки получилось - см. описание в технобложике. Но до чего ж я в процессе пыли нажрался, и всё благодаря замечательным качествам Windows RRAS (Routing & Remote Access Service).

    Сюрприз первый - ограничить принимаемые сертификаты от второй стороны только выписанными определённым CA нельзя. Можно жмякнуть по галке "Verify Name and Usage attributes of the server's certificate", и на этом всё. То есть да, будет проверено, что в сертификате значится хостнейм, к которому мы обращаемся, что сертификат не протух и что он подписан валидным CA. Да только этих валидных CA на любом Windows - несколько десятков!

    То есть если между двумя сторонами сидит хакер, который может направить трафик на адрес Фортигейта на свой сервер (через DNS ли, через раутинг ли) - то он может как нефиг делать получить на этот хостнейм сертификат от LetsEncrypt, с их-то смехотворной верификацией. И затем выдавать себя за Фортигейт. Подключиться к Фортигейту от имени RRAS ему не выйдет - Фортигейт-то как раз проверяет, какой CA удостоверил вторую сторону. Но если обе стороны - Windows, то вот вам полноценный рецепт на man-in-the-middle.

    В общем-то, эта проблема касается практически всех VPN-клиентов для рабочих станций, но для гейтов, связывающих сети разных организаций, хотелось бы большего.

    (Справедливости ради, Windows позволяет использовать поверх IPsec протокол EAP, а вот там-то CA ограничивать можно. Но:
  • это усложняет инфраструктуру - нужен RADIUS (и проверяется сертификат именно RADIUS, а не VPN-гейта)
  • документации по такому использованию EAP у Фортинета примерно ноль, но в этом не Микрософт виноват,
  • это поверх - уже после аутентификации IPsec; проверяет оно юзера, и клиентский сертификат должен сидеть в профиле юзера. Как это заставить работать с автоматическим подключением RRAS? Может, если запустить certmgr.msc под SYSTEM и импортировать туды, то и выгорит...
    В общем, дикие траблы. Скорее всего, не взлетит. Да и точно ли это устраняет MiTM?)

    Этого можно было бы легко избежать, попросту перейдя с сертификатов на pre-shared keys, однако тут нас ждёт сюрприз второй - это работает примерно с десятого раза на двадцатый. Подозреваю баг. Девять раз получаешь "authentication failed", на десятый неожиданно подключаешься. Забиваешь PSK заново - сразу подключаешься; если отключишься, то по новой. Причём, похоже, работает только если сессию инициирует Фортигейт.

    Сюрприз третий - назначить статический адрес диал-ап интерфейсу нельзя, настройки игнорируются. Because fuck you. В какой-то момент получилось через "netsh interface ipv4 add address", потом снова обломись.

    Сюрприз четвёртый - банальный forwarding между LAN и туннелем раз работает, а раз нет. Почему - понять не удалось.

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

    (no subject)

    Настраивал давеча в одной сеточке синхронизацию часов и был поражён, внезапно обнаружив, что в il.pool.ntp.org не осталось ни одного IP-адреса. Совсем недавно была парочка, а теперь всё.

    В Израиле публичных NTP-серверов не дофига. Попытался использовать сервер Israel Internet Association, timeserver.iix.net.il - но и тут вышел облом. Он, похоже, лишь израильские IP обслуживает - а у моей сеточки, так уж вышло, они значатся как зарубежные. Плюнул и пошёл тянуть время с иностранных серверов.

    Всё-таки, мне кажется, должен быть какой-то минимум сетевых служб, которое приличное государство должно поддерживать для своих жителей - без тоталитарных попыток заставить пользоваться только ими, и без дурацких попыток ограничить доступ к ним лишь определённым сетям. Я бы в перечень включил DNS, NTP, e-mail и службу аутентификации, IdP.

    Всё ж таки ситуация, когда огромное количество организаций, включая государственные, полагаются на гугловский DNS 8.8.8.8 как на главный и зачастую единственный источник, нездоровая.
    • Current Music
      Bustan Abraham - Canaan
    • Tags

    (no subject)

    Скажите, мне одному кажется, что схема верификации, которую использует LetsEncrypt - это издевательство над логикой?

    Работает так:
    * клиент хочет сертификат для сайта example.org;
    * пускай он разместит нечто по адресу http://example.org/some/path - мы это нечто проверим, и если оно окажется тем, что мы ожидаем увидеть, то это послужит доказательством того, что юзер - законный владелец этого имени хоста и вправе получить на него сертификат.

    Но ведь это же абсурд. Сертификат нам затем и нужен, чтобы удостоверять подлинность сайта - как же можно считать обращение к сайту доказательством его подлинности, когда сертификата ещё нет?

    Да, они там важно надувают щёки, что дескать все посылаемые значения криптографически заверены - но откуда берётся это доверие изначально, как можно знать, что чувак, зарегистрировавшийся в LetsEncrypt с каким-то там личным ключом и подписавший им это самое нечто, вообще имеет право на этот сайт?

    И если ни личный ключ, ни запрос на сайт не доказывают ничего, то как может являться доказательством их гибрид?

    Для того, чтобы оценить маразм идеи, достаточно знать следующее: в новой версии Google Sites при создании сайта с custom domain Гугл автоматически выписывает ему сертификат от LetsEncrypt. Автоматически. LetsEncrypt у держателя домена не проверяет ничего. Сразу выдаёт сертификат Гуглу. Всё. Совершенно не нужно ничего понимать в криптографии, чтобы понять, какая это профанация.

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

    Да, более традиционные процедуры domain validation тоже не лишены слабых мест: и создание DNS-записей с рандомальными значениями, и уж тем более получение мейла на адрес вида admin@example.org. Но то, что позволяет LetsEncrypt - это man-in-the-middle как он есть. Это не безопасность, это сапоги всмятку.

    Поразительно, сколько админов в Сети радостно пишут: сертификаты! бесплатно! бежим брать! - совершенно не задаваясь вопросом, что именно те сертификаты удостоверяют. Бесплатный сыр удивительно эффективно отключает мозги.

    TLS v1.3 0-RTT replay attack

    Зашёл почитать, что новенького есть в новой версии шифровального протокола TLS, в девичестве SSL (которая скоро будет использоваться всякий раз, когда мы жмём на линк с https:// и во многих, многих других случаях) - и был крайне сильно шокирован. Прямо в RFC, официальном документе, описывающем протокол, открытым текстом признаётся, что он подвержен replay attack, и что борьба с этим - ответственность разработчиков серверного приложения: вот вы, мол, и постройте систему так, чтобы это было неважно.

    Collapse )
    Collapse )
    Collapse )
    Collapse )
    Collapse )

    В общем, брат-админ, где фичу 0-RTT увидишь - там её и прибей.

    P.S. Полезные ссылочки: 1, 2, 3.

    Облака - белогривые лошадки

    За последнее время много вожусь с IaaS-облаком; хочется излить несколько наблюдений, как подходы, принятые в обычных, невиртуализированных системах некритически переносятся в облачную среду:

    1. Неоднократно наблюдал, как на облачных серверах баз данных или там Exchange люди привычно ставят диск для баз, и отдельно - диск на transaction logs, думая, что это улучшит производительность. Да с чего бы? На обычном железе в этом был простой, понятный смысл: на диске баз данных считывающая головка может прыгать между секторами как угодно, а на диске логов будет большую часть времени просто записывать в хвост. Соответственно, лучше, чтобы диски были разные.
    Но зачем это делать в облаке, где все эти диски - всего лишь файлы на датасторе? Если они хранятся на одном и том же физическом хард-диске - ну так значит, он обречён крутиться псевдорандомально. Но даже если мы разнесём их на разные хранилища - один чёрт каждое из них используется тучей прочего народу. Предсказать, как реально будут крутиться хард-диски в этих хранилищах - абсолютно невозможно.

    Впрочем, по мере ухода магнитных дисков этот вопрос отпадёт окончательно. Хотя и тогда по инерции админы будут разносить базы и логи - у нас так заведено.


    2. Продолжая тему дисков - объясните мне кто-нибудь, а какой смысл в локальных дисках в облаке? Почему не определить любой, или хотя бы любой data disk как shared? (Шишков, прости...) Это в физическом мире у нас есть либо SAN, либо просто SCSI-кабель к дискам, который больше чем в один компьютер не воткнёшь. А в виртуальном какая разница, какое устройство эмулировать - SCSI-контроллер или HBA какой-нибудь? Один чёрт наши диски - просто файлы на каком-то датасторе.

    Сегодня облака shared disks обычно не предоставляют, и поэтому, чтобы завести какой-нибудь кластер на виртуалках, который их требует (да хотя бы файлсервер на микрософтовском Failover Cluster) нужно сооружать дикие турусы на колёсах. А как было бы просто: кликаешь в облачном портале мышкой пару раз - вот тебе виртуалка с диском. Кликаешь ещё - вот тебе вторая, третья, восьмая виртуалка, и все видят тот же диск. А дальше дело твоё, как их координировать: либо только главный сервер кластера юзает диск, либо ставь файловую систему, поддерживающую доступ со многих, типа VMFS или GFS2.


    3. VLANs и, шире говоря, Ethernet вообще. Как-то упускается из виду, что в обычных локальных сетях broadcast domains существуют не от хорошей жизни, а оттого, что каждый компьютер в порт файерволла не воткнёшь. Хотелось бы инспектировать трафик между любыми двумя хостами - но что делать, свитчи функциональностью современного файерволла не обладают, а если такие и есть, то цена у них заоблачная, pun intended. Поэтому, если не хочется угробить производительность, приходится разбивать сеть на какие-то секьюрити-зоны, отказываться от возможности фильтровать трафик внутри них и удолетворяться фильтрацией между ними. Кроме того, VLAN-ы позволяют с лёгкостью гонять групповой и широковещательный трафик.

    Но это не то, что я хотел бы от облака! Там-то мне возможность фильтровать трафик между двумя любыми машинами гораздо чаще пригождалась бы, чем преимущества broadcast domains.

    Пример: допустим, у меня классический расклад - 20 вебных фронтэндов, за ними SQL Server. По логике секьюрити-зон, мне надо засунуть фронтэнды в один VLAN, SQL - в другой, и контролировать трафик между ними. Но тогда фронтэнды могут между собой неограниченно общаться - а зачем мне это надо? Им нужно говорить с HTTP-клиентами и с SQL-сервером, а друг дружке им что-либо передавать незачем.

    Тут пригодился бы Private VLAN, но облако такое не предоставляет. Наштамповать отдельный VLAN под каждый фронтэнд можно, но мы упрёмся в иные ограничения. Приходится сажать их в общий, а это лишний риск.

    Надо сказать, что Микрософт это как раз осознали - в Azure классического Ethernet-а нету, они там наворотили что-то своё на Layer2 (апдейт - таки да). В результате можно фильтровать трафик между любыми машинами, даже если они сидят в одном сабнете - но любой неюникастовый и, шире, любой не-IP трафик не поддерживается. По-моему, выбор в правильную сторону.


    А у вас какие наблюдения?

    (no subject)

    Проделал небольшой экспериментик - при установке очередного Windows-домена проинтегрировал его в общий DNS. Обычно админы такого не делают - и из нежелания, чтобы их внутренние DNS-записи мог запрашивать любой желающий, и чтобы домен-контроллеры наружу не открывать или отдельные сервера под это дело не городить.

    Но поскольку сеточка тестовая, то секретность ейной внутренней структуры мне пофигу, а вот выигрыш от открытости есть: какие бы DNS-сервера не были прописаны у юзеров, каким бы методом они не подключались - по личному VPN, по site-to-site VPN из другой сети, да хоть напрямую - записи будут им доступны. Поскольку вечные приколы VPN с сетевыми настройками задрали уже давно, универсальности хочется.

    Что до домен-контроллеров, то открывать их во всеобщий доступ и мне не хотелось, по двум соображениям:
  • Чтобы не подставлять их под DoS или ещё какую пакость,
  • Чтобы не отключать на них рекурсию. Я хочу, чтобы они предоставляли внешнему миру информацию лишь о моём домене, а не о любом в мире. Можно, конечно, отключить, но тогда для машин во внутренней сети надо дополнительно что-то городить - лишнее усложнение.

    Collapse )
    • Current Music
      Stonila - Between Two Worlds
    • Tags