Category: it

(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

    (no subject)

    Недавно мимо меня пробегало новенькое израильское удостоверение личности (теудат зеут) - уже не бумажка, а смарткарта - и я, конечно, тут же его зацапал глянуть, что на ентой смарткарте есть. Мда. После потрошения ейного сертификата могу честно сказать - построено ужасно, просто ужасно.
    Collapse )

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

    Если кто хочет повтыкать в детали сам - припадайте. "Leaf" сертификат со смарткарты не выкладываю из соображений приватности владельца, а правительственные - на здоровье.

    (no subject)

    У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
    - общая сложность для понимания и настройки,
    - сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
    - сложность с отзывом сертификатов, необходимость держать доступными точки CRL и OCSP, что может быть довольно геморройно, если у нас не общий Интернет, а изолированые сети,
    - нельзя защитить часть сайта - скажем, чтобы https://hostname/public был доступен всем, а https://hostname/private требовал сертификата для опознания юзера. Точнее, этого результата можно добиться, но лишь при применении определённых хитростей.
    - отсутствует нормальный logout - для того, чтобы сайт перестал тебя опознавать, надо полностью закрывать браузер (или изначально заходить в incognito-окне).

    Но есть одно крутое преимущество - по сравнению с другими методами логина поверх SSL, она сильно усложняет проведение атаки man-in-the-middle, она же SSL interception. Вплоть до "вообще никак".

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

    Способов добавить сертификат в список доверяемых есть масса, начиная с домейновых group policies и windows update, и заканчивая малварью и банальной социальной инженерией. Более того, тот же Avast antivirus делает это просто по дефолту - добавляет сертификат своего типа-CA в "Trusted Root Certification Authorities" и расшифровывает трафик.

    Но когда требуется сертификат ещё и клиентский, то всё намного усложняется, посколько тогда система-перехватчик должна подменить и его тоже. А сервера куда недоверчивее в этих вопросах, чем браузеры. Им, как правило, просто указывают - сертификаты от этого CA и от этого принимать, а остальных лесом. К примеру, в FortiGate при создании PKI-юзера надо в явном виде задать и CA, которым его сертификат должен быть подписан, и что у этого сертификата должно быть в Subject. К тому же, тот может быть и вовсе самоподписанным. Тут не разгуляешься.

    А подменить серверный сертификат, не подменяя клиентский, посылая его как есть - не выйдет. У сервера банально циферки не сойдутся, на чём подключению и конец.

    Так что стоящая вещь, товарищи, пользуйтесь. :-)

    (Это я тут с админом одной сеточки пообщался - негодовал, что не может инспектировать наш SSL-VPN. Ну, мои тебе соболезнования, приятель. :-))

    (no subject)

    Поругаю для разнообразия Микрософт:

    1. Ознакомился с возможностями Point-to-Site VPN в Azure, ихнем облаке. Впечатлён - редкостное убожество. Аутентификация предусмотрена только по сертификатам, но и это реализовали по-идиотски: заливаешь корневой сертификат в список доверенных, после чего все его потомки признаются доверенными - если только ты explicitly не указал, что вот конкретно этому, этому и этому доверять нельзя. Причём CRL тянуть оно не умеет - указывай там же, на ихнем портале.

    То есть чудесно: если у меня и у Васи есть сертификат от, скажем, Comodo, и я хочу организовать нам доступ - то заливая корневой сертификат Comodo я даю доступ к своим облачным сетям всем, у кого тоже есть сертификат от Comodo!

    Наиболее приемлемый способ использования этой муры: создавать специальный CA только для юзеров VPN, наштамповать им сертификатов только для этой цели и не забывать указывать их как отозванные, когда доступ кому-то из юзеров уже не нужен. Да, и надеяться, что до лимита отозванных не дойдёшь.

    Удивительно: это компания, сделавшая в своё время VPN-гейт с наилучшим набором фич для аутентификации из всех, что я видел - я имею в виду ForeFront TMG. А теперь они выкатывают эту хрень. А TMG они убили! Убили, Карл!

    Вообще, опознаванию на сертификатах как-то не везёт, как Булгакову на экранизации. Вот в FortiGate сделали гораздо правильнее: заливаешь корень и перечисляешь список значений поля Subject, которые надо принимать - а все прочие идут лесом. Но при этом не подумали, что если этих фортигейтов в организации больше, чем один, то ведение этих списков превращается в management hell.


    2. Сломался у меня давеча скрипт, что CRL в облако публиковал. Полез разбираться - и что же вы думаете? Скрипт мне поломала славная корпорация Микрософт. Я пользовался програмкой cURL - а эти добрые люди решили, что они сейчас пойдут навстречу потребителю и в новой версии PowerShell обозначили curl как синоним своего коммандлета Invoke-WebRequest. Изменение команды на curl.exe решило проблему, но вашу же душу, благодетели!..
    • Current Music
      Flogging Molly - The Worst Day Since Yesterday
    • Tags
      ,