?

Log in

No account? Create an account
Кот Муций
14 January 2019 @ 01:16 am
Вот, скажем, ElasticSearch. Для того, чтобы избежать ситуации split brain, надо конфигурировать три хоста - чтобы при потере любого из них оставшиеся смогли выбрать главного. Допустим, один из них может не хранить данные, а только участовать в выборах - но это всё равно процесс, который надо где-то гонять.

А если у меня есть Windows Failover Cluster с двумя хостами + witness (общий диск или общая папка на третьем хосте), то почему бы не гонять ElasticSearch как "роль" на этом кластере? Это ж просто Windows service, в конце концов. На одном хосте опустили - на другом тут же подняли. Нужен общий диск для данных, конечно, что будет мигрировать вместе с сервисом.

Да, не будет распределения нагрузки и будет некоторый downtime во время фэйловера. Но если это пофигу, то вай бы и нот, действительно?
Tags:
 
 
Current Music: Ghoultown - Drink With The Living Dead
 
 
Кот Муций
11 January 2019 @ 11:32 am
Пара забавных случаев из серии "Муций-автомобилист":

1. Стою как-то на перекрёстке, никого не трогаю. Вдруг замечаю, что моя машинка начинает ощутимо катиться назад. Давлю со всей дури на тормоз - катится. Дёргаю вверх ручник - катится. Перекидываю рычаг на 'parking' катится, блин! А за мной тоже какая-то машинка стоит - ну всё, щас я в неё въеду. Приготовился уже с ейным владельцем неприятный разговор вести.

И тут наконец дошло - слева от меня стояла длиннющая платформа для перевозки автомобилей, ждала своего светофора налево. Наконец дождалась и тихонько двинула вперёд. А поскольку всё поле зрения слева она у меня занимала, то создалась качественная иллюзия, что это не она вперёд, а я назад. Уф!


2. Очнулся как-то, гляжу - сижу в машине, передо мной руль, ночь, я неизвестно где, вокруг какие-то склады. Где я? Как я тут? Наверное, заснул за рулём и куда-то въехал. Может, ещё и убил кого? Может, и сам разбился? Начинаю себя ощупывать - вроде голова цела и переломов нет. Выхожу - да и машина вроде в состоянии приличном.

И тут вспомнил - да я же сам тут полчаса назад припарковался поспать, поскольку носом клевал ощутимо. Ну и хорошо так в сон провалился. Момент ужаса при выныривании обратно был нешуточный.
 
 
Current Music: Rodney Atkins - Take a Back Road
 
 
Кот Муций
В продолжение этой темы: если бы мне нужно было сдизайнить сеть типичной компании с нуля, то, думаю, у меня вообще не было бы понятия "корпоративный LAN / вайфай". Был бы Private VLAN, из которого доступ был бы исключительно на VPN gateway (ну или ещё на Интернет, если мы хотим принимать гостей). Любой доступ к внутренним серверам компании - через VPN.

(Что куда лучше 802.1x, который предоставляет аутентификацию, но не защищает от перехвата трафика, его подделки, replay attacks).

Таким образом и любой трафик за пределами серверной комнаты защищён шифрованием, и правила доступа полностью привязаны к юзерской identity и её принадлежностям к разным группам, и user experience одинаковый, где бы юзер не находился - на работе, дома, в кафешке.

А если при этом для аутентификации использовать ключи в чипе TPM, то можно опознавать не только юзера, но и девайс, с которого он подключается, и строить политики по обоим этим критериям. Если какой-то станции нужен доступ для процессов, не связанных с конкретным юзером (скажем, Windows service) - никаких проблем, вводим правило лишь по девайсу. Опять же, ключ неизвлекаемый - им не поделишься, как паролем, его не потеряешь, как смарткарту (только вместе с устройством).

В общем, ye olde plain IP - лишь до VPN-гейта, а поверх - туннель, и между файерволлами - туннели, туннели, сорок тысяч одних туннелей.

Да, и каждый сервер - в собственный VLAN. Чтобы любой трафик через файерволлы тёк.
 
 
Current Music: The Sidh - Iridium (https://www.youtube.com/watch?v=amJ_WLmOKS0)
 
 
Кот Муций
27 December 2018 @ 12:59 pm
Накатал много букв с картинками по поводу своих облачных странствий и изысканий - как построить высокодоступный файлсервер без общих дисков. Авось кому из братьев-админов и пригодится.

Поправки, замечания, идеи - всё приветствуется.

Попутно хочу поблагодарить продакт-менеджеров корпорации Микрософт - эти славные люди взяли две абсолютно разные про природе и функциональности сущности и обозвали их одинаково - "witness". При том, что обе имеют отношение к Failover Cluster, и обе - к shared folders. Чтобы жизнь мёдом не казалась, очевидно.
 
 
Current Music: Larkin Poe - Preachin' Blues
 
 
Кот Муций
23 December 2018 @ 04:52 am
К этому посту: по-моему, эту задачку сегодня вполне несложно решить с помощью on-demand overlay network, типа всяких SDN или FortiGate ADVPN.

То есть, допустим, таким вот образом:

0. У нас есть сеть со множеством файерволлов, которые находятся под управлением разных людей, но принадлежат одной организации и потому доверяют друг другу.

1. Юзер коннектится на файерволл-А по VPN. Файерволл-А проверяет его identity, список групп Active Directory и т.д., и даёт подключиться.

2. Юзер посылает пакет, который, как определяет файерволл-A, предназначен для сети за файерволлом-Б. Файерволл-A строит туннель (GRE, VXLAN, IPsec - неважно) к файерволлу-Б, и как часть метаинформации передаёт детали identity юзера - имя, SID, список групп и т.д. Инкапсулирует пакет и передаёт по этому туннелю.

3. Файерволл-Б проделывает свои проверки этой identity (если нужно; запрашивает сам список групп по LDAP, например), принимает пакет по туннелю и дальше сам решает, что с ним делать, на основе собственных политик.

4. Если пакет передан и на него пришёл ответ, то файерволл-Б отсылает ответ по тому же туннелю.

5. В случае мультикаста туннели строятся на все файерволлы; ну или же на те, за которыми есть зарегистрированные получатели этой группы, если в ходу протокол построения деревьев для мультикаста.

Таким образом:
- каждый файерволл может выстраивать свои собственные политики на основе групп или другой юзерской информации, а не IP-адресов;
- каждый файерволл может быть VPN-гейтом; любой юзер может подключаться на любой из них или на несколько сразу (см. чекпойнтовый Secondary Connect, к примеру).
- каждый пакет от VPN-клиента мы можем привязать к юзерской личности.


Недостатки:
- первые пакеты могут потеряться или прийти с большой задержкой.
- ещё?..

Интересно, уже имплементировал кто?
 
 
Current Music: Trna - Pattern Of Infinity (https://www.youtube.com/watch?v=PInrrLT0mR4)
 
 
 
Кот Муций
12 December 2018 @ 02:30 am
Пришла в голову идея объеденить два VLAN-а в разных облачных датацентрах в один - прокинув между ними туннель VXLAN. Чтобы Ethernet-фреймы между ними ходили, как у себя дома.

Сказано - сделано: разобрался, как это делается на Фортигейте, для пущей безопасности пустил VXLAN поверх IPsec. Сценарий с NAT документирован не был, но ничего, скумекал. Ура, заработал мой туннель. И не успел я возликовать, как получил лопатой по всей морде. Облачко-то на VMware, ограничивает каждую виртуалочку её собственным MAC-адресом, и изменить это возможности не даёт. Стало быть, если мой Фортигейт начнёт вдруг фреймы от других машин передавать, то их жестокий vSwitch выкинет, и конец делу. Элементарная же штука, сто лет её знаю - а вовремя не сообразил. Ну хоть конфигурацию в технобложик задокументировал, и то хлеб.

Попутно это дело зарезало мне ещё пару-тройку идеек. Мир их праху.

Но до чего ж обидно, а! Посылает, скажем, виртуалка ARP-запрос. Фортигейт его принимает, инкапсулирует в VXLAN, шифрует IPsec-ом, суёт в UDP-пакет для NAT traversal, внешний раутер меняет source IP, пакет через ещё надцать раутеров добирается до дальнего датацентра, там всё это декапсулируется обратно, удалённая виртуалка посылает ARP-ответ, тот проходит весь этот путь в обратном направлении - и вот когда осталось Фортигейту своему соседу по VLAN-у ответ вручить, вмешивается таможня и выкидывает его нафиг. Эх.
 
 
Current Music: Kikagaku Moyo - Masana Temples (https://www.youtube.com/watch?v=PNzsRauOeqE)
 
 
Кот Муций
07 December 2018 @ 02:37 am
Давно я Микрософт не ругал.

Понадобилось тут прокинуть 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 и туннелем раз работает, а раз нет. Почему - понять не удалось.

    В общем - если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот.
  •  
     
    Current Music: Dierks Bentley - What Was I Thinkin'?
     
     
    Кот Муций
    25 November 2018 @ 03:16 am
    Замечательный закон о карах за бойкот Израиля помните? А вот и первое применение, и оно маразматичней некуда: русский, инглиш. Это вот письмо, о котором речь.

    Что могу сказать по этому поводу:

    1. Моя надежда на то, что судьи у нас окажутся вменяемей Кнессета, пролетела со свистом. Желание приложить покрепче тех, кто против нас вякать смеет, превозмогает любую логику, представление о приличиях и здравый смысл.

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

    Да, и что иерусалимский суд иск против Airbnb отклонит - тоже надеюсь, но надежда эта очень хиленькая. Ясен пень, щас мы всех уважать себя заставим.
     
     
    Current Music: Aura Blaze (https://www.youtube.com/watch?v=2_y93m9ZQKw)
     
     
    Кот Муций
    24 November 2018 @ 03:33 am
    Настраивал давеча в одной сеточке синхронизацию часов и был поражён, внезапно обнаружив, что в il.pool.ntp.org не осталось ни одного IP-адреса. Совсем недавно была парочка, а теперь всё.

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

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

    Всё ж таки ситуация, когда огромное количество организаций, включая государственные, полагаются на гугловский DNS 8.8.8.8 как на главный и зачастую единственный источник, нездоровая.
    Tags:
     
     
    Current Music: Bustan Abraham - Canaan
     
     
    Кот Муций
    23 November 2018 @ 03:50 am
    Скажите, мне одному кажется, что схема верификации, которую использует 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 как он есть. Это не безопасность, это сапоги всмятку.

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