Комментарии 23
+
-8
Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub
50к реальных конфигов рабочих серверов? А откуда они на Гитхабе?
0
чего только нет на гитхабе
там народ и пароли находит, и приватные ключи...
+10
IaC подразумевает конфиги держать в git-repo.
+1
А из каких соображений? Быстрый переезд сервера?
0
Гибкость управления конфигурациями.
+1
Из каких соображний что? Использовать Infrastructure as Code? Или, используя IaC, хранить конфиги в git'е? Если первое — чтобы автоматизированно управлять инфраструктурой, дабы снизить влияние человеческого фактора, уменьшить временные затраты на ввод нового сервера и на обновление тоже. Если второе — то где ж при таком подходе их хранить еще?
0
Второе. Где угодно, при условии что доступ к ним имеют не только лишь все желающие…
+1
Ну с одной стороны — зная конфиги можно облегчить злоумышленнику жизнь. С другой — в целом конфиги это не нечто секретное (может быть секретными части конфигов, которые хранятся отдельно), особенно если они хороши :)
0
Вот именно что, и злоумышленник может же не только прочесть конфиги, но и изменить. А раз секретная часть может храниться отдельно, то почему бы весь конфиг целиком не хранить отдельно (непублично)?
0
злоумышленник может же не только прочесть конфиги, но и изменитькаким образом?
А раз секретная часть может храниться отдельнону например потому, что она не меняется, и её можно не шаблоном хранить, а просто статически подключать. Да мало ли причин у людей выбрать гитхаб, а потом еще и не платить за приватность репозитория.
0
1. Теоретически, взломав акк на Гитхабе.
2. ИМХО такое затевается не ради одного сервака под столом и не «домашним» пользователем, можно было бы и раскошелиться на приватность с безопасностью… но это так, умозрительные соображения.
2. ИМХО такое затевается не ради одного сервака под столом и не «домашним» пользователем, можно было бы и раскошелиться на приватность с безопасностью… но это так, умозрительные соображения.
0
История изменений. И автоматическая доставка на сервера через пайплайн.
0
В примере про fastcgi говорится, что даже не пытается проверить наличие файла на диске, но php-fpm может быть вообще на другом хосте, соответственно при всём желании проверить нельзя. Как быть?
0
Статья дельная, спасибо. А можно привести к каждому не правильному примеру правильный? С выделением изменившегося места, что-то вроде таблички: не правильно | правильно. Чтобы можно было вернувшись к статье через год не читать описание каждой ошибки, а сразу понять как нужно сделать.
+3
По умолчанию директива root имеет значение html. В чем опасность не указывать root, если nginx используется только в качестве обратного прокси к контейнерам?
+1
Уже не новая статья, на одном из админских форумов в прошлом году разбирали, процитирую сам себя:
По большей части примеры из статьи крайне редко встречаются в реальных конфигах. Но вот пример с внедрением header'а в результате нормализации переменной $uri заставил меня крепко задуматься. Похоже, имеет смысл переделать часть своих конфигов.
Для тех, кто как и я задумался, что с этим делать и как это поправить, есть такие варианты заново применить urlencode к значению переменной $uri (в приводимых примерах я получаю переменную $safe_uri, которую в дальнейшем использую вместо $uri).
Те, кто используют openresty/lua-nginx-module, могут воспользоваться функцией ngx.escape_uri:
Те, кто его не используют, могут воспользоваться директивой set_escape_uri из модуля set-misc-nginx-module:
Ну а те, кто не могут или не хотят использовать дополнительные модули nginx, могут получить то же самое, отрезав аргументы запроса от переменной $request_uri с помощью директивы map:
Ну и хочу всем напомнить про такой инструмент анализа конфигов nginx, как Gixy:
github.com/yandex/gixy
По большей части примеры из статьи крайне редко встречаются в реальных конфигах. Но вот пример с внедрением 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
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым