Pull to refresh

Comments 23

всё понимаю, но что за клинические идиоты за плюсик наставили минусиков — плюсики это оскорбление чуЙств верующих или что (как)? )))

Хочу ещё больше минусиков — нападайте, отмечайтесь ;P
+++++++++++++++++++++++++++++++++++++++++++++++
Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub

50к реальных конфигов рабочих серверов? А откуда они на Гитхабе?

чего только нет на гитхабе
там народ и пароли находит, и приватные ключи...

А из каких соображений? Быстрый переезд сервера?
Гибкость управления конфигурациями.
Все равно не понял, но спасибо за попытку просветить ;)
Из каких соображний что? Использовать Infrastructure as Code? Или, используя IaC, хранить конфиги в git'е? Если первое — чтобы автоматизированно управлять инфраструктурой, дабы снизить влияние человеческого фактора, уменьшить временные затраты на ввод нового сервера и на обновление тоже. Если второе — то где ж при таком подходе их хранить еще?
Второе. Где угодно, при условии что доступ к ним имеют не только лишь все желающие…
Ну с одной стороны — зная конфиги можно облегчить злоумышленнику жизнь. С другой — в целом конфиги это не нечто секретное (может быть секретными части конфигов, которые хранятся отдельно), особенно если они хороши :)
Вот именно что, и злоумышленник может же не только прочесть конфиги, но и изменить. А раз секретная часть может храниться отдельно, то почему бы весь конфиг целиком не хранить отдельно (непублично)?
злоумышленник может же не только прочесть конфиги, но и изменить
каким образом?

А раз секретная часть может храниться отдельно
ну например потому, что она не меняется, и её можно не шаблоном хранить, а просто статически подключать. Да мало ли причин у людей выбрать гитхаб, а потом еще и не платить за приватность репозитория.
1. Теоретически, взломав акк на Гитхабе.
2. ИМХО такое затевается не ради одного сервака под столом и не «домашним» пользователем, можно было бы и раскошелиться на приватность с безопасностью… но это так, умозрительные соображения.
Представил себе злоумышленника, получившего доступ к аккаунте с кодом на гитхабе, но изменяющий конфиги сервера.

История изменений. И автоматическая доставка на сервера через пайплайн.

В примере про fastcgi говорится, что даже не пытается проверить наличие файла на диске, но php-fpm может быть вообще на другом хосте, соответственно при всём желании проверить нельзя. Как быть?

Мне показалось что там проблема не в настройках nginx а в том что бэкенд не обрабатывает ситуацию когда в переменной может прилететь какая-то дичь.
Статья дельная, спасибо. А можно привести к каждому не правильному примеру правильный? С выделением изменившегося места, что-то вроде таблички: не правильно | правильно. Чтобы можно было вернувшись к статье через год не читать описание каждой ошибки, а сразу понять как нужно сделать.

По умолчанию директива root имеет значение html. В чем опасность не указывать root, если nginx используется только в качестве обратного прокси к контейнерам?

Уже не новая статья, на одном из админских форумов в прошлом году разбирали, процитирую сам себя:

По большей части примеры из статьи крайне редко встречаются в реальных конфигах. Но вот пример с внедрением header'а в результате нормализации переменной $uri заставил меня крепко задуматься. Похоже, имеет смысл переделать часть своих конфигов.

Для тех, кто как и я задумался, что с этим делать и как это поправить, есть такие варианты заново применить urlencode к значению переменной $uri (в приводимых примерах я получаю переменную $safe_uri, которую в дальнейшем использую вместо $uri).

Те, кто используют openresty/lua-nginx-module, могут воспользоваться функцией ngx.escape_uri:
set_by_lua_block $safe_uri { return ngx.escape_uri(ngx.var.uri) }

Те, кто его не используют, могут воспользоваться директивой set_escape_uri из модуля set-misc-nginx-module:
set_escape_uri $safe_uri $uri;

Ну а те, кто не могут или не хотят использовать дополнительные модули nginx, могут получить то же самое, отрезав аргументы запроса от переменной $request_uri с помощью директивы map:
map $uri $safe_uri {
~^([^?]*) $1;
}

Ну и хочу всем напомнить про такой инструмент анализа конфигов nginx, как Gixy:
github.com/yandex/gixy
В последнем примере я слегка ошибся, в map надо использовать не $uri, а $request_uri:
map $request_uri $safe_uri {
~^([^?]*) $1;
}
Sign up to leave a comment.