![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Разное сетевое
Aug. 15th, 2020 01:34 amУ Микрософта нашли очередную дыру, и не абы где, а в святая святых, в домен контроллере. В общем, патчим, товарищи, не ленимся.
Там, похоже, читают мой бложик: cтоило обругать Azure Firewall, как в нём появилась именно та фича, которой мне и не хватало. :-) То есть можно указать в качестве destination любое имя, которое резолвится DNS в IP-адрес или список адресов, и Firewall разрешит (ну или заблокирует) соединение на любой из этих адресов, независимо от аппликативного протокола.
Но есть некоторая разница с Фортигейтом - для этой фичи Микрософт требуют превратить Azure Firewall в DNS proxy и настоятельно рекомендуют указать его внутренний адрес в качестве DNS-резолвера для всей живности, что будет через него свой трафик пускать. Делается это для того, чтобы минимизировать ситуации, когда Firewall резолвит то же имя в один список IP-адресов, а клиент - в другой.
Тем не менее, пока эта фича в preview и работает скорее теоретически. В моём опыте, примерно две трети соединений блокировались файерволлом даже тогда, когда он сам же клиенту список IP и резолвил. Правда, у DNS-имени, с которым я экспериментил, был очень короткий TTL, секунд в десять. Ну, будем надеяться, к запуску в продакшен её доведут до ума.
В связи с этими делами, стал стучаться в башку такой вопрос: поле Host в HTTP и SNI в TLS вводили, конечно, не ради файерволлов, а чтобы можно было множество сайтов на один серверный IP вешать. Но тем не менее, получилось довольно удобно, что теперь файерволл, работающий в режиме explicit / transparent proxy, может их использовать для сверки со своими правилами:
- и правила эти можно сделать гораздо более точными, чем если иметь для принятия решения лишь пару destination IP & port;
- и файерволл теперь может самостоятельно новое соединение к цели открыть, согласно собственному DNS lookup, независимо от destination IP в пакете, пришедшему от клиента;
- и заодно серверный сертификат может сверить на соответствие.
Так может стоит эту практику на прочие аппликативные протоколы распространить? Ну скажем, на NTP, IMAP, SMTP. Прописывать в явном виде "авторскую интенцию" - DNS-имя, на которое открывается соединение или посылается запрос.
В наш-то век облачных сервисов, когда то же DNS-имя переводится тем же самым DNS-сервером в разные списки IP в ответ на разные запросы, причём интервал между этими разными ответами может измеряться секундами, с традиционным файерволлом пытаться ограничивать исходящий трафик - практически безнадёжная задача, проще сразу "destination = ALL" прописать.
Из-за того иногда приходится прибегать к разным уродливым костылям, чтобы разрешить нужный исходящий трафик, не разрешая всё на свете. Ну, скажем, нужно позволить посылать письма через smtp.googlemail.com. Но поскольку даже если на файерволле можно прописать этот FQDN, по прежнему вероятна ситуация, когда клиент резолвнет этот адрес в IP1, а файерволл - в IP2 (даже используя тот же DNS-сервер!) и заблокирует соединение, то приходится идти на следующий некрасивый трюк: прописывать на внутреннем DNS-сервере (используемый ими обоими) зону smtp.googlemail.com с постоянным ограниченным набором IP-адресов - а дальше надеяться, что Гугл их в обозримом времени будет поддерживать в рабочем состоянии.
С другой стороны, это мне-то, решающему задачу ограничения исходящего трафика, это было бы удобно. Но вообще-то, это огромный вопрос - должен ли сетевой протокол быть дружелюбным к файерволлу или же напротив, максимально недружелюбным к нему - и вопрос этот политический. Если мы исходим из того, что государственная цензура - зло (а я так и считаю), то напротив, протокол должен быть как более непрозрачен, чтобы затруднить жизнь Великому китайскому файерволлу, Роскомнадзору и их аналогам. И тенденция идёт как раз в этом направлении - см. Encrypted SNI.
Наверное, дело решится настройкой, позволяющей клиенту запускать соответствующий протокол как в firewall-friendly, так и в unfriendly режимах. Корпоративные сети будут использовать первый, частные юзеры - второй. Серверам, по идее, должно быть всё равно.
Технически этот Encrypted SNI представляет собой раздражающий костыль. Давайте посылать юзеру шифровальный ключ в сертификате, а чтобы никто не догадался, какой именно сертификат (и сайт) запрашивается - разместим ещё один ключ в DNS, и пускай клиент свой запрос этим ключом шифрует. Блин, а почему б тогда сам первый ключ в DNS не разместить? А потому, что если враги его подменят, то это будет game over, а так они разве что увидят, на какой сайт юзер лезет. Хорошо, а по DNS-запросам они это не поймут? Поймут, но вот если юзер будет обращаться к заранее известным надёжным DNS-серверам, расположенным за границей, и само соединение с ними шифровать по TLS... Ну хорошо, а если враги запретят с такими серверами соединяться?...
В общем, похоже, пока моё старое предложение располагать крамольный сайт так, чтобы по хостнейму опознать его было нельзя, релевантности не теряет.
Там, похоже, читают мой бложик: cтоило обругать Azure Firewall, как в нём появилась именно та фича, которой мне и не хватало. :-) То есть можно указать в качестве destination любое имя, которое резолвится DNS в IP-адрес или список адресов, и Firewall разрешит (ну или заблокирует) соединение на любой из этих адресов, независимо от аппликативного протокола.
Но есть некоторая разница с Фортигейтом - для этой фичи Микрософт требуют превратить Azure Firewall в DNS proxy и настоятельно рекомендуют указать его внутренний адрес в качестве DNS-резолвера для всей живности, что будет через него свой трафик пускать. Делается это для того, чтобы минимизировать ситуации, когда Firewall резолвит то же имя в один список IP-адресов, а клиент - в другой.
Тем не менее, пока эта фича в preview и работает скорее теоретически. В моём опыте, примерно две трети соединений блокировались файерволлом даже тогда, когда он сам же клиенту список IP и резолвил. Правда, у DNS-имени, с которым я экспериментил, был очень короткий TTL, секунд в десять. Ну, будем надеяться, к запуску в продакшен её доведут до ума.
В связи с этими делами, стал стучаться в башку такой вопрос: поле Host в HTTP и SNI в TLS вводили, конечно, не ради файерволлов, а чтобы можно было множество сайтов на один серверный IP вешать. Но тем не менее, получилось довольно удобно, что теперь файерволл, работающий в режиме explicit / transparent proxy, может их использовать для сверки со своими правилами:
- и правила эти можно сделать гораздо более точными, чем если иметь для принятия решения лишь пару destination IP & port;
- и файерволл теперь может самостоятельно новое соединение к цели открыть, согласно собственному DNS lookup, независимо от destination IP в пакете, пришедшему от клиента;
- и заодно серверный сертификат может сверить на соответствие.
Так может стоит эту практику на прочие аппликативные протоколы распространить? Ну скажем, на NTP, IMAP, SMTP. Прописывать в явном виде "авторскую интенцию" - DNS-имя, на которое открывается соединение или посылается запрос.
В наш-то век облачных сервисов, когда то же DNS-имя переводится тем же самым DNS-сервером в разные списки IP в ответ на разные запросы, причём интервал между этими разными ответами может измеряться секундами, с традиционным файерволлом пытаться ограничивать исходящий трафик - практически безнадёжная задача, проще сразу "destination = ALL" прописать.
Из-за того иногда приходится прибегать к разным уродливым костылям, чтобы разрешить нужный исходящий трафик, не разрешая всё на свете. Ну, скажем, нужно позволить посылать письма через smtp.googlemail.com. Но поскольку даже если на файерволле можно прописать этот FQDN, по прежнему вероятна ситуация, когда клиент резолвнет этот адрес в IP1, а файерволл - в IP2 (даже используя тот же DNS-сервер!) и заблокирует соединение, то приходится идти на следующий некрасивый трюк: прописывать на внутреннем DNS-сервере (используемый ими обоими) зону smtp.googlemail.com с постоянным ограниченным набором IP-адресов - а дальше надеяться, что Гугл их в обозримом времени будет поддерживать в рабочем состоянии.
С другой стороны, это мне-то, решающему задачу ограничения исходящего трафика, это было бы удобно. Но вообще-то, это огромный вопрос - должен ли сетевой протокол быть дружелюбным к файерволлу или же напротив, максимально недружелюбным к нему - и вопрос этот политический. Если мы исходим из того, что государственная цензура - зло (а я так и считаю), то напротив, протокол должен быть как более непрозрачен, чтобы затруднить жизнь Великому китайскому файерволлу, Роскомнадзору и их аналогам. И тенденция идёт как раз в этом направлении - см. Encrypted SNI.
Наверное, дело решится настройкой, позволяющей клиенту запускать соответствующий протокол как в firewall-friendly, так и в unfriendly режимах. Корпоративные сети будут использовать первый, частные юзеры - второй. Серверам, по идее, должно быть всё равно.
Технически этот Encrypted SNI представляет собой раздражающий костыль. Давайте посылать юзеру шифровальный ключ в сертификате, а чтобы никто не догадался, какой именно сертификат (и сайт) запрашивается - разместим ещё один ключ в DNS, и пускай клиент свой запрос этим ключом шифрует. Блин, а почему б тогда сам первый ключ в DNS не разместить? А потому, что если враги его подменят, то это будет game over, а так они разве что увидят, на какой сайт юзер лезет. Хорошо, а по DNS-запросам они это не поймут? Поймут, но вот если юзер будет обращаться к заранее известным надёжным DNS-серверам, расположенным за границей, и само соединение с ними шифровать по TLS... Ну хорошо, а если враги запретят с такими серверами соединяться?...
В общем, похоже, пока моё старое предложение располагать крамольный сайт так, чтобы по хостнейму опознать его было нельзя, релевантности не теряет.
