Pull to refresh
356
31.6
Alex Efros @powerman

Systems Architect, Team Lead, Lead Go Developer

Send message

Примерно тогда, когда захочется:

  • Обновить конфиг CI/CD во всех репо.

  • Обновить какую-то популярную зависимость в тех (обычно - почти во всех) репо, в которых она используется.

  • Сделать какой-то рефакторинг во всех репо где есть подлежащий такому рефакторингу код.

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

  • Попытаться понять что у нас считается "текущими лучшими практиками" и по аналогии с каким из имеющихся 83 репо создавать 84-й репо с новым проектом.

Порядок, в общем, поддерживать сложно. А бардак развести легко.

Много мелких отдельных репо в какой-то момент начинают жрать слишком много усилий на поддержку этого хозяйства. Если в компании 5 репо - Вы эту проблему не почувствуете, а вот если их уже стало 50 - начнёте что-то подозревать.

С другой стороны, поддержка монорепо тоже требует немало усилий - в статье типичный пример этого.

Разработчикам Go в этом плане повезло: инструментарий языка "из коробки" неплохо работает с "как бы монорепо" - при условии что в этом репо исключительно проекты на Go. В этом случае удаётся получить лучшее из двух миров: и репо всего одно, и типичных для монорепо усилий оно почти не требует (максимум - нужно решить вопрос как раздельно деплоить только изменившиеся проекты, если их одновременный деплой неприемлем для бизнеса).

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

В чём проблема создать подобный функционал в других системах инициализации?

Очевидно в том, что они не хотят превратиться в монстрообразный комбайн а-ля systemd.

Будем откровенны: функционала всех остальных систем инициализации вполне хватает для запуска любых сервисов.

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

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

я слишком переусложнил код приложения в угоду запуска его через старые системы инициализации

Ну да, ну да. А "не переусложнённое" приложение будет работать без systemd? Вот в этом и проблема systemd - он слишком много функционала в себя затянул, и продолжает затягивать (включая вот такой "требующий systemd" совершенно посторонний софт). При этом качество всего этого функционала в systemd не настолько хорошее, чтобы отказ от всех альтернатив и vendor-lock на единственном монстрообразном решении были действительно оправданы. Но продолжать эту тему тут явно не стоит, про это уже всё давно и много раз сказано. Остановимся на общеизвестной идее, не про systemd: монополия - плохо, возможность выбора альтернативных решений - хорошо.

SELinux не могу рекомендовать, но если она есть (а я пользуюсь Fedora на своём домашнем ноутбуке), то отключать её большого смысла нет. При обычном использовании все необходимые правила прописаны в дистрибутиве.

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

Ну, а IPv6 меня просто заинтересовал.

Было бы интересно почитать серьёзный гайд на тему безопасной настройки IPv6 и сопровождения dual stack конфигурации. С описанием всего, что нужно изменить в настройке ядра Linux для повышения безопасности/конфиденциальности IPv6, какие дополнительные приложения/сервисы рекомендуется установить и как их безопасно настроить, что нужно настроить в файрволе IPv6 специфичного для IPv6 и как в нём учитывать специфику IPv6 при настройке аналога типовых задач файрвола IPv4, какие инструменты/процессы использовать чтобы исключить случайное расхождение настроек файрвола/маршрутизации/etc. между IPv4 и IPv6, … Мне вот такие пока не попадались, а Вам?

Спасибо, почитаю. Первая фраза уже порадовала:

В 2023 году люди боятся многих новых для них вещей, например, systemd, SELinux, IPv6 и др.

Как Вы узнали, Вы за мной следите? :-) Нет, я всего этого не "боюсь", а вполне осознанно избегаю из-за переусложнённости этих технологий. Вместо systemd у меня runit и udevd. Вместо SELinux был GrSecurity (пока его не сделали закрытым), сейчас ничего (собираюсь попробовать Apparmor но пока руки не дошли). Простое всегда лучше сложного (пока функционала простого достаточно).

Что нам даёт IPv6

Лично мне - исключительно экономию денег на оплату белого IPv4. Но создаваемые внедрением IPv6 сложности лично для меня пока намного значительнее чем экономия этих копеек.

дистро-строители озаботятся более-менее безопасными дефолтами

Точно нет. Безопасность - никогда не была приоритетом. Она обычно вредит удобству и/или функционалу, приоритет которых для абсолютного большинства пользователей считается более высоким. Так что пока у разработчиков дистрибутивов не будет уверенности, что этот функционал ничего никому не сломает - его не включат по умолчанию. А пока он у абсолютного большинства выключен - нет и не будет уверенности, что он ничего не сломает. Тут типичная проблема курицы и яйца. Другое дело, если какая-то уязвимость будет использоваться настолько массово, что это начнёт заметно вредить значительному числу обычных пользователей и поднимется вой в СМИ - тогда да, защитную фичу вполне могут включить даже с риском кому-то что-то сломать. Но во-первых это несколько поздновато (как на мой взгляд), и во-вторых включат только эту фичу, а все остальные (а там их немало) останутся выключенными. Так всё происходило минимум последние лет 25, и я не вижу оснований надеяться, что с этими фичами будет как-то иначе.

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

Это какая-то очень эзотерическая логика.

Да нет, логика вполне обычная. Это просто Вы никак не изучите общепринятое определение обсуждаемого термина.

Чем меньше кода, тем больше его защищённость, серьёзно?

Абсолютно. Многократно подтверждённый факт. Есть даже метрики по среднему количеству багов на 1000 строк кода.

Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.

Не станет. Но половина кода написанного в таком стиле будет содержать в 2 раза меньше багов чем весь такой код - так что принцип продолжает работать.

А почему только за 2023 год?

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

Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?

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

А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)

Явно намного больший, чем виндой. Почти весь IoT и прочие стиральные машины с пылесосами и холодильниками обычно на линухе, большая часть телефонов и планшетов на андроиде (да и эппловские тоже не на винде работают, но как там с умолчаниями для IPv6 я не знаю), все роутеры, "свистки" для телевизоров… ну и заметный процент десктопов тоже.

Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов.

Можете дать ссылки на исследования по этому вопросу, или это ваше личное ощущение?

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

Вот как бы не оказалось, что IPv6 - это новый нетбиос в этом плане, и такие атаки снова вернутся. Атакуют то, что проще/дешевле. Лезть внутрь локалки IPv4 прикрытой NAT-ом было явно не проще и не дешевле. Но в IPv6 это может изменится.

Вот когда от него реально будут готовы избавиться и выпускать IPv6-only устройства - тогда да. А пока IPv4 всё-равно поддерживается такое изменение вряд ли критично скажется на используемых ресурсах.

Ой, вэй! Таки почитайте уже что Вас попросили почитать, чисто чтобы не писать ещё больше глупостей.

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

Но по факту - он таки более уязвим (хоть в данном контексте это и не важно). Просто потому, что он более новый и он менее активно используется - а в таких условиях в коде всегда больше ошибок, если сравнивать с аналогичным но более старым и проверенным. И в этом легко убедиться: поиск "linux ipv4" по CVE выдаёт 4 результата за 2023 год, а аналогичный для ipv6 выдаёт 11.

Это всё прекрасно, честно! Лично я только "за". Но есть одна небольшая проблема: когда несколько месяцев назад на хабре было аналогичное обсуждение я не поленился изучить поддержку в ядре линуха всех таких фич IPv6. И знаете что выяснилось? Все эти "для безопасности/приватности" фичи реализованы, но по умолчанию все они выключены. Как думаете, какой процент устройств в домашних локалках будет их использовать в реальном мире и скажется ли это хоть как-то на общей ситуации с безопасностью? (Вопрос риторический.)

По Вашей же логике, раз уж всё-равно обновлять, почему бы заодно и 240/4 не разблокировать? :-)

Ха. Если бы. Должен блокировать - да. А вот на практике - всё не так однозначно (я тут в одном из комментов приводил в пример CVE двухмесячной давности).

злоумышленнику сперва нужно каким-то образом узнать адрес

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

Адрес - информация не секретная. Он виден на каждом ресурсе, к которому обратился (включая всякие служебные - DNS, NTP, CA revocation list, сервера обновлений разного софта, сервера куда указывают разные механизмы слежки вроде прозрачных пикселей и прочих кук и т.п.), плюс на куче промежуточных серверов по дороге к этим ресурсам плюс нередко в рамках локалки (которая может включать соседей по дому если провайдер не очень хорошо настроил роутер) и при использовании WiFi.

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

подумайте об этом в рамках датацентра

На мой взгляд в рамках ДЦ эта проблема не настолько критична. В ДЦ локалку с NAT обычно делают либо штатным механизмом ДЦ (VPC сотоварищи), либо этим занимается админ компании-клиента ДЦ который понимает, что делает - в отличие от пользователей домашних локалок.

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

Это бесмысленная рекомендация из серии "делай хорошо - будет хорошо".

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

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

Почитайте определение понятия "поверхность атаки". Оно включает много чего, в т.ч. дополнительный код, в котором могут быть уязвимости (стек IPv6 в ядре ОС, например).

Вы про отсутствие политики DROP по умолчанию для FORWARD? Формально Вы правы, но размер этой дыры всё-таки по-меньше, чем в IPv6: чтобы воспользоваться этой дырой в IPv4 необходимо как-то обеспечить роутинг своего пакета предназначенного адресу локалки до WAN интерфейса. По сути это ограничивает возможность её эксплуатации ближайшими соседями по подъезду/дому, максимум - клиентами своего провайдера (если провайдер криво настроил своё оборудование, что маловероятно но не исключено). Из инета такой пакет точно не дойдёт.

дырки в безопасности - из-за домашнего ipv6 не подтверждаются на практике в сетях

Как можно подтвердить отсутствие чего-то? Тут обычные взломы крупные корпорации умудряются не замечать годами, пока хакеры резвятся на их серверах и воруют данные терабайтами, а Вы ждёте что обычные юзеры отследят взлом домашней локалки и напишут об этом в СМИ?

Вот наличие чего-то подтвердить можно. Например поиск "IPv6" по базе CVE выдаёт порядка 50 уязвимостей только за последний год, а всего их 554. Например, вот, пару месяцев назад опубликовали: "D-Link R15 before v1.08.02 was discovered to contain no firewall restrictions for IPv6 traffic. This allows attackers to arbitrarily access any services running on the device that may be inadvertently listening via IPv6.".

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

в IPv6 всё начинает работать само

Если для Вас кто-то (разработчики OpenWRT, например) это уже настроил, то да. Работать - начинает само. А вот насколько оно безопасно настроено - тут уже всё совсем не так очевидно. Для IPv4 все очень давно научились его настраивать безопасно, включая разработчиков всех прошивок роутеров и всех "домашних" админов. А для IPv6 это пока не так.

Ну и там нюансов хватает даже для того, чтобы всё просто работало корректно. Например если попытаться пойти по пути IPv4 и на роутере тупо включить NAT для IPv6, то это может сломать кучу приложений в локалке, просто потому, что если для IPv4 они к поддержке NAT морально готовы, то в IPv6 это крайне нетипичный кейс и они его могут не поддерживать. А самое смешное то, что вариантов NAT для IPv6 существует минимум два (NAT66 и NPTv6), работают они по-разному (причём у одного из них могут быть проблемы с тем же IPSec и т.д.), разные вендоры реализуют что хотят и как хотят, а принятого стандарта для IPv6 NAT всё ещё нет (есть RFC в статусе Experimental).

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

В конечном итоге всё это ведёт только к одному: сложность корректной и безопасной настройки IPv6 параллельно и эквивалентно текущей настройке IPv4 - довольно большая, не смотря на то, что внедрение IPv6 тянется уже столько лет. А польза от него, на сегодня, всё ещё незначительная. Вывод: не сегодня!

Information

Rating
155-th
Location
Харьков, Харьковская обл., Украина
Date of birth
Registered
Activity