Компания Яндекс опубликовала (https://github.com/yandex/gixy) исходные тексты проекта Gixy, в рамках которого развивается статистический анализатор, предназначенный для выявления проблемных настроек в файлах конфигурации nginx, которые могут отрицательно повлиять на безопасность. Код написан на языке Python и распространяется (https://github.com/yandex/gixy) под лицензией MPL 2.0.
В настоящее время Gixy включает следующие плагины, выявляющие различные классы проблем:
- ssrf (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/s...) - выявляет уязвимость Server Side Request Forgery, позволяющую выполнять различного рода запросы от имени Nginx. Проблема возникает, когда атакующий может контролировать адрес проксируемого сервера (второй аргумент директивы proxy_pass);
- http_splitting (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/h...) - выявляет уязвимость HTTP Splitting, возникающую из-за неправильной обработки входных данных. Уязвимость может применяться для атак на приложение стоящее за Nginx (HTTP Request Splitting) или на клиентов приложения (HTTP Response Splitting).
- origins (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/o...) - выявляет проблемы с проверкой заголовка запроса Referer или Origin, обычно возникающие из-за некорректного составления регулярного выражения;- add_header_redefinition (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/a...) - выявляет проблемы с переопределением "вышестоящих" заголовков ответа директивой "add_header";
- host_spoofing (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/h...) - определяет возможность подмены заголовка запроса Host;- valid_referers (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/v...) - выявляет проблемы при конфигурировании модуля ngx_http_referer_module, вызванные использованием "none" в качестве принимаемого значения заголовка Referer;
- add_header_multiline (https://github.com/yandex/gixy/blob/master/docs/ru/plugins/a...) - определяет факты использования многострочных заголовков ответа.URL: https://news.ycombinator.com/item?id=14315277
Новость: http://www.opennet.ru/opennews/art.shtml?num=46535
Статический анализ, статический анализ везде....Методология растёт и ширится. И это неизбежно. Сложность и размер программных проектов растёт и чем дальше, тем сложнее будет обходиться без вспомогательных средств статического анализа. Просто невозможно уже всё знать, помнить и иметь возможность просмотреть.
А вы почему раньше Яндекса ничего не сделали?
Потому-что внимательно читает документацию по настройке нгинкса.
И описанные аля мисконфигурейшен не страшен локалхостам с дефолтовым конфигом, просто складывается такое ощущение, что в яндексе криворукие нгинкс админы, вот и написали этот анализатор, а написали - ИБешники, как я понял.
>в яндексе криворукие нгинкс админыYandex распался несколько лет назад. Многие крутые дяди (и тети), которые там работали с начала 2000х разошлись в разные стороны. А современный Yandex это уровень студентов и школоты. Доказательства этому будут все чаще и чаще появляться.
Ах да, криворукие у них не только админы. Удивил HR с психическим расстройством. Были все признаки панической атаки, когда не дал ему ответ в течении нескольких дней.
>>в яндексе криворукие нгинкс админы
> Yandex распался несколько лет назад. Многие крутые дяди (и тети), которые там
> работали с начала 2000х разошлись в разные стороны. А современный Yandex
> это уровень студентов и школоты. Доказательства этому будут все чаще и
> чаще появляться.ну потому там и мигрировали на *бунту ;-)
У тебя комплекс неполноценности.
> У тебя комплекс неполноценности.обоснуй;)
> ну потому там и мигрировали на *бунту ;-)Ну да, а во фрю коммитят чисто из альтруистических соображений:
commit fed97f3094ee0c71bc2ae864dce888257108122c
Author: ae <ae@FreeBSD.org>
Date: Mon Apr 17 09:42:05 2017 +0000MFC r316435:
Add ipfw_pmod kernel module.
...
Obtained from: Yandex LLC
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D10150commit 7a6d766f1284a41887dd6302256d4bb01df92e5c
Author: ae <ae@FreeBSD.org>
Date: Mon Apr 17 09:36:35 2017 +0000MFC r316434:
Add O_EXTERNAL_DATA opcode support.
This opcode can be used to attach some data to external action opcode.
And unlike to O_EXTERNAL_INSTANCE opcode, this opcode does not require
...
Obtained from: Yandex LLC
Sponsored by: Yandex LLCcommit 1f5f6e71571eeaab683b65e91887222f4a6ece97
Author: ae <ae@FreeBSD.org>
Date: Mon Apr 3 08:50:54 2017 +0000MFC r304041:
Move logging via BPF support into separate file.
* make interface cloner VNET-aware;
* simplify cloner code and use if_clone_simple();
* migrate LOGIF_LOCK() to rmlock;
* add ipfw_bpf_mtap2() function to pass mbuf to BPF;
...
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
MFC r304046, 304108:
Add ipfw_nat64 module that implements stateless and stateful NAT64.
The module works together with ipfw(4) and implemented as its external
action modulecommit ae659ef435156d011821295969f63c5f4dcfb1d2
Author: ae <ae@FreeBSD.org>
Date: Mon Apr 3 07:40:38 2017 +0000MFC r307570:
Add support for non-contiguous IPv6 masks in ipfw(8) rules.
For example fe::640:0:0/ffff::ffff:ffff:0:0 will match
addresses fe:*:*:*:0:640:*:*
Submitted by: Eugene Mamchits <mamchits at yandex-team dot ru>
Obtained from: Yandex LLC
Sponsored by: Yandex LLCcommit ab3e7e42d2f4196cc40513ff5d86b05bb15355e8
Author: ae <ae@FreeBSD.org>
Date: Thu Mar 30 14:20:27 2017 +0000MFC r303018:
Add named dynamic states support to ipfw(4).
>> ну потому там и мигрировали на *бунту ;-)
> Ну да, а во фрю коммитят чисто из альтруистических соображений:
>
> commit fed97f3094ee0c71bc2ae864dce888257108122c
> Author: ae <ae@FreeBSD.org>..
>ну не нужно путать NOCов и проектных админов. Вменяемые проектные закончились - набрали убунтоголовых и как-то живут.
Закончится ae@ (и еще 1 товарищ) в ноках - наймут цискоголовых убунтоводов - мигрируют и там.
p.s. до этого еще melifaro@ был там же где и ae@. был.
если присмотреться к патчам - там далеко не один ae@ - просто не всем дано напрямую комитить (или не у всех есть столько лишнего времени).Кстати, недавно случилось чудо: https://svnweb.freebsd.org/base?view=revision&revision=316770 - кто в теме, оценит
- это ж сколько, лет десять уже, наверное?
> если присмотреться к патчам - там далеко не один ae@ - просто
> не всем дано напрямую комитить (или не у всех есть столько
> лишнего времени).речь выше шла о конкретной компании. и там реально мало кого осталось с коммит-битом в порты/src фри. а раньше ребята из поиска были, давно:)
> Кстати, недавно случилось чудо: https://svnweb.freebsd.org/base?view=revision&revision=316770
> - кто в теме, оценит
> - это ж сколько, лет десять уже, наверное?не скажу, что прямо капец как в теме, но от момента обсуждения бага в рассылке uafug и до того коммита прошло с недельку, примерно, включая стадии "у меня не работает вот так" "а попробуй вот так" "о, работает" и "попробуй патч (от ae@)" "ага. так тоже все работает!"
багу, то, может и Х лет, но где же Ваш забытый багрепорт о нем?
> речь выше шла о конкретной компании. и там реально мало кого осталось с коммит-битомработать приходится, да, а не "развивать опенсорсе" в рабочее время, кризис говорят в стране какой-то.
Я говорил про тех, чьи имена упоминаются в патчах и репортах, хотя они и не могут коммитить - их существенно больше одного. То есть где-то в недрах яндекса пара (десятков ;-) фрей видимо еще уцелела, как и тех, кто умеет их готовить.
А глобально выбор в сторону линухов был еще в 2011м, как минимум (впрочем, полагаю, на самом деле гораздо раньше).> не скажу, что прямо капец как в теме
видимо, совсем не. Это (ломание csum offload) очень хорошо натоптанные грабли, то есть просто вот все, кто когда либо делал vpn-сервера (и не только) на фре, либо сами по лбу получали, либо уже были в курсе. И оно так с совсем незапамятных времен было.
> но где же Ваш забытый багрепорт о нем
мертвых PR без патчей (да и с патчами, пришедшимися не ко двору) и без меня мильен с тыщами. А уж тем более по неинтересной мне фигне.
Тут забавно было как раз то, что человек в теме, пробегая мимо, походя поправил то, что все привычно перешагивали.
> Потому-что внимательно читает документациючтение документации совершенно не помогает от ошибок.
> И описанные аля мисконфигурейшен не страшен локалхостам с дефолтовым конфигом
и с недефолтным тоже. Это верно. В трех недефолтных строках очень сложно ошибиться.
Пока конфиг можно прочитать, пару раз нажав pg-dn, ошибки в нем бывают в основном те, которые nginx -t покажет. А когда он громадный, потому что система, ну надо же, посложнее твоего локалхоста не в разы, а на пару порядков - то очень быстро превращается в очень запутанный ком спагетти. Там и собственно структура конфига весьма этому помогает, но в первую очередь - сложность задачи, которая очень маловероятно имеет простые решения.
И оно именно что может работать, до определенного момента, вылезая в каких-то специфических случаях, которые не так просто или совсем нельзя протестировать "вживую".В общем, кто писал конфиги для больших систем, тому это и так понятно, а у кого локалхост, на тех пофиг, какие б нынче плохие не были в яндексе hr'ы, вас все равно туда не возьмут на должность, предполагающую хоть какое-то самостоятельное мышление.
P.S. напишите уже кто-нибудь анализатор конфигов asterisk, 1.4-style хотя бы. Без lua ;-)
"анализатор конфигов asterisk"
Если Вы про диалплан, то рассматривать/работать с ним, как с конфигом — фатальная ошибка. Последствия которой я изредка разбираю, делая терпилам разбор слива через какой-нибудь freepbx|asterisknow.
У себя в профильной конторе я делал по этому поводу ORM, открытая часть выложена в районе https://github.com/ds-voix/VX-PBX/tree/master/UPSERT https://github.com/ds-voix/VX-PBX/tree/master/VX
("Закрытая" часть содержит ряд известных ошибок и (до их исправления) на github публиковаться не будет.)
> "анализатор конфигов asterisk"
> Если Вы про диалплан, то рассматривать/работать с ним, как с конфигом —
> фатальная ошибка.если работать как с программой на нечеловеческом языке, не уверен что анализатор от этого проще станет писать.
> У себя в профильной конторе я делал по этому поводу ORM, открытая
ну, может для профильной конторы это и метод (а кто будет писать анализатор уже теперь исходного формата? ;-)
для отдельно взятого админа, которому приходится возиться с унаследованными системами, вряд ли подойдет. (ну да, можно, конечно, подождать пока там на пару лямов переговоров с Парагваем набежит)
>>чтение документации совершенно не помогает от ошибок.http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...
Внимательное чтение этого уже защитит от спуфинга Host заголовка
>>то очень быстро превращается в очень запутанный ком спагетти.
какой ком ? какой спагетти код ? программировать на конфигах нгинкса не нужно, не нужна на нём никакая логика вынесенная из контроллеров приложения.
> Внимательное чтение этого уже защитит от спуфинга Host заголовкаосспди... вы вообще конфиги нетривиальных систем-то видели хоть по телевизору?
(я уж молчу, что "от спуфинга хост заголовка" в принципе ничего не защитит, не надо ему доверять вообще, если ты его не сам только что установил - но это генитальным программистам еще надо суметь разжевать)>>>то очень быстро превращается в очень запутанный ком спагетти.
> какой ком ? какой спагетти код ? программировать на конфигах нгинкса нев общем, админ локалхоста детeктед.
> нужно, не нужна на нём никакая логика вынесенная из контроллеров приложения.
вас не будут в яндексе спрашивать, что нужно, а что не нужно. И ни в одном более-менее крупном проекте тоже не будут, это не яндекс такой плохой. Некоторые, не будем показывать пальцем, еще и на lua туда писают.
P.S. интересно, среди чудо-скриптов есть скрипт проверки на "квадратик" ?
> вы вообще конфиги нетривиальных систем-то виделиЯ (другой аноним) не видел. Можете показать примерчик, чтоб понимать, о чём речь?
>> вы вообще конфиги нетривиальных систем-то видели
> Я (другой аноним) не видел. Можете показать примерчик, чтоб понимать, о чём
> речь?список рассылки нгинкса вам в помощь )) там куча нетривиальных конфигов, иногда ржачных
> список рассылки нгинкса вам в помощья что-то очень сомневаюсь, что вы там увидите хоть один кусок конфига крупных проектов, и совершенно уверен, что не увидите его целиком, что позволило бы оценить масштабы бедствия.
локалхост админы, такие локалхост админы - думают, что то что они видят вокруг себя ("список рассылки" в том числе) - это и есть весь мир.
для тех, кому непонятно, почему оно так - разжевываю: если бы во времена работы в данной области я наткнулся на какие-то проблемы с конфигурацией - я бы просто потыкал палочкой в старшего товарища, через стол. Если бы, внезапно, оказалось что это какая-то серьезная проблема, а не я чего-то не понял - мы бы оторвали задницы, и дошли в соседнюю комнату - где сидела группа разработки (мы не яндекс, у нас компания была маленькая - те во внутреннюю рассылку бы писали, и неделю ждали снисхождения). Там либо разжевали бы нам, что оно вот так и задумано, а мы не поняли глубины идеи (впрочем, "либо" тут лишнее ;-) либо с пятого раза удалось бы их убедить, что в этой задумке что-то не то. И вот тогда, по результатам, в "список рассылки" уехал бы уже патч. И уезжали, не один раз. (на самый крайний случай на фронтах был логин sysoev ;-)
>> вы вообще конфиги нетривиальных систем-то видели
> Я (другой аноним) не видел. Можете показать примерчик, чтоб понимать, о чём
> речь?не, не могу - даже если б унес на память, там потроха конкурента яндекса, унылые, но вряд ли даже сейчас их можно обнародовать.
Когда столкнетесь - поймете. (не, править не заставят, это обычно удел пары-тройки страдальцев, оно такое не на фронтах и не на конечных нодах, если, конечно, сеть не сплели жопой, при обычной работе их не трогают ;)
Ключевой момент первый аноним,на самом деле, понял правильно, но не понял что это так везде - в большой конторе тебе не удастся легко и просто заставить разработчиков изменить бэкэнд, даже если ситуация совсем хреновая (они, кстати, не очень-то и могут) - поэтому неизбежно ты будешь затыкать дырки в их чудо-системе собственными средствами. "С таким параметром - сюды, а с вот таким - вот туды, а то сюды ломается, а это вот я вообще не знаю что такое и кто это обрабатывает, давайте его на следующий уровень пробросим, наверное, оно там используется или планировалось".Особенно "приятно" потом эту логику еще и на тестовую систему переносить, тем хуже - когда сам ты не очень понимаешь, как оно работает.
>>осспди... вы вообще конфиги нетривиальных систем-то видели хоть по телевизору?хех с основания нгинкса вижу )) ток они не содержат логику приложений
>>не надо ему доверять вообще,
в принципе суть в том, что реальный "пряморукий" админ нгинкса должен знать рфс протокола ХТТП, а если он знает - зачем какой-то ещё анализатор ))
>>в общем, админ локалхоста детeктед.
))) ну пусть будет так, админ локалхоста с 10+ лет стажем думаю наизусть выучит конфигурирование нгинкса, нежеле, студент админ нетривиальных систем, на годовой стажировке в яндексе.
>>вас не будут в яндексе спрашивать, что нужно, а что не нужно.
всё правильно, так и есть - главное чтобы работало, вот и бесятся ИБ-ешники яндекса от таких админов и проггеров, решили написать скрипт для "статического анализа" ))))))))
>>И ни в одном более-менее крупном проекте тоже не будут, это не яндекс такой плохой.я кстате не говорил, что яндекс плохой. Я предположил, что у них на столько криворукие нгинкс админы, что ИБ-ешники, которые замучались от их косяков, решили написать "анализатор"
>>Некоторые, не будем показывать пальцем, еще и на lua туда писают.
АГА )))) эт уже другая тема )) ждём ещё статического анализатора для lua, js, perl и тд ))
>>P.S. интересно, среди чудо-скриптов есть скрипт проверки на "квадратик" ????
> А вы почему раньше Яндекса ничего не сделали?Потому что опенсорс живёт по принципу DIY (do it yourself). Вот новичок боится запутаться в конфигах и думает "хорошо бы написать утилиту для проверки конфигов на типичные ошибки". Садиться писать. В процессе изучает все детали конфигурации и способы настройки. Потом понимает, что можно не продолжать написание инструмента - ему он уже не нужен.
Только использовать для этого Питон - это надо себя сильно не любить. У вас там ведь весь код анализатора, скорее всего, сплошь из ветвлений. На Питоне их нужно все проверять. :-)
> Только использовать для этого Питон - это надо себя сильно не любить.
> У вас там ведь весь код анализатора, скорее всего, сплошь из
> ветвлений. На Питоне их нужно все проверять. :-)так говорю же эт тока ИБ-ещники так любят питон, вот и накалякали анализатор на коленке )
ммм, NGINX-Studio
Между прочим, масса ниш ещё не занято. Выбирай и делай. И анализаторы потихоньку пишут, кто для Ada, кто для 1C. Тренд (хотя конечно маленький в сравнении, скажем, с играми для телефонов).
Техническая сингулярность всё ближе. Вокруг куча способов прострелить себе ногу.
Я имел короткий опыт разработки на JavaScript. Из-за автоматического приведения типов заведомо ошибочный код работал. И самое страшное, что работал правильно. Но при этом код совсем не соответствовал спецификации.
Ошибаться больно. Мне повезло, что ошибку я заметил сразу, отладка могла растянуться на недели
Да еще вспомнити npm leftpad...
> Между прочим, масса ниш ещё не занято.Да. Только сложно, извините, поляну не испоганить. В науке, к которой OSS по своим свойствам близок, есть такое понятие. Это когда один кадр берётся за задачу, довольно криво и плохо её решает. И, с одной стороны, решения нет, а с другой стороны, делать правильное - это выступать в роли дворника.
хорошо было бы вдобавок выпустить анализатор кода анализатора файлов конфигурации nginx. вдруг в нём самом ошибка и он неверно толкует конфигурацию nginx? ведь в конфигурации nginx полно можно мест найти что вызывают сомнения - с виду работают, но не корректно. к примеру add_header и proxy_pass_header (и другие подобные) - для сервера целиком, для пути и т.п при использовании mod_proxy.
Проверил. Ошибок нет. Непонятно, то ли конфиги хорошие, то ли тулза плохая...
Просто тулза - не панацея. В статье описано, что она проверяет. Неправильно сконфигурированный location под php или случаи, когда ты думаешь, что запрос придётся на один location, а он приходится на другой этот анализатор не выявит. А эти ошибки случаются куда чаще.
> Просто тулза - не панацея. В статье описано, что она проверяет. Неправильно
> сконфигурированный location под php или случаи, когда ты думаешь, что запросзависит от того, что такое "неправильный". Не так заполняет переменные - не выявит, конечно.
> придётся на один location, а он приходится на другой этот анализатор
> не выявит. А эти ошибки случаются куда чаще.и их статически вряд ли выявишь.
Ну или писать полный парсер регексов и к нему набор тестов под каждую новую ситуацию.
> Ну или писать полный парсер регексовТы каждый раз, когда тебе нужны регексы, пишешь свой парсер?
> Ты каждый раз, когда тебе нужны регексы, пишешь свой парсер?Тебе в данном случае нужны не регексы в общем виде, а _проверка_ что написанное совпадает с желаемым (и с учетом остального конфига). Так что да, придется именно свой - regex предназначена чтоб скрыть от разработчика ненужные детали, а тебе их наоборот анализировать надо.
Занятие представляющееся мне унылым до чрезвычайности.
> _проверка_ что написанное совпадает с желаемымlibpcre + libastral решат проблему. Правда лицензия на libastral дороговата, но как без неё — я не представляю.
еще раз, медленно: pcre не помогает анализировать регексы, совсем.
Так же как си-компилятор не помогает анализировать сишный код.Наоборот - по сути компилятор ты и будешь писать - только производящий не код, а паттерны для анализа.
А что в них анализировать-то, в регексах? Ну, допустим, можно отсеять регексы, который в принципе никогда не могут ни с чем совпасть, или совпадут с любой строкой, но при этом отличаются от /.*/. Это очень малый процент ошибок, которые можно допустить, ради этого и заморачиваться не стоит.
> А что в них анализировать-то, в регексах?для начала, как обычно - typical human error, когда написано одно, а подразумевалось другое.
Сложнее - когда у тебя их пачка, в экран, даже большой, не умещаются, и где-то кто-то когда-то вляпал нечто, что вроде бы работает, а на самом деле ему достается паттерн, предназначенный другому regexp.
В принципе, даже более-менее понятно, как второе автоматизировать, но, слава тебе, Г-ди, что я не девоп.
> typical human error, когда написано одно, а подразумевалось другое.Вот я и спрашиваю, что это за ошибки такие могут быть, что их можно отловить без libastral? Регулярки — не C, в них мало конструкций, которые однозначно можно идентифицировать как некорректные.
> Вот я и спрашиваю, что это за ошибки такие могут быть, чтоя ж говорю - я, слава Аллаху, не девоп, мои ошибки могут быть нереферрентными. Надо брать статистику с большого проекта, и ловить типичные для него.
> их можно отловить без libastral? Регулярки — не C, в них
> мало конструкций, которые однозначно можно идентифицировать как некорректные.если бы в си была однозначность - не были бы нужны монстроидальные анализаторы, просто комплиятор выдал бы ошибку.
Кстати, из свеженького личного - банальный копипаст, когда из трех скопированных блоков один исправить забыли. Пресловутый pvs вон вполне такое отлавливает, тут даже разбирать содержание не шибко надо.