Чешский исследователь безопасности Владимир Смитка (Vladimír Smitka) провёл сканирование около 320 млн доменов и выявил (https://lynt.cz/blog/global-scan-exposed-git), что на 390 тысячах сайтов доступны для загрузки каталоги ".git", которые по недосмотр выставили в публичное пространство без ограничения доступа. В подобных каталогах можно обнаружить закрытую информацию, в некоторых случаях угрожающую безопасности. Например, в каталоге .git могут быть оставлены исходные тексты всех серверных обработчиков сайта (атакующий может использовать из для поиска уязвимостей), а также пароли и ключи доступа к СУБД, API и облачным сервисам.
Сканирование всех доменов в сети заняло около 4 недель, после чего исследователь попытался предупредить владельцев сайтов на которых зафиксирована отдача каталога ".git", организовав рассылку по email.
Адреса электронной почты были взяты из файла /.git/logs/HEAD. Из 390 тысяч сайтов удалось определить emаil для 290 тысяч, из которых 90 тысяч email оказались уникальными. После отправки предупреждения 18 тысяч адресов оказались уже не действующими. В ответ на рассылку было получено почти 2000 писем с благодарностями, 30 сообщений о ложном срабатывании, два письма от спамеров и одна угроза с намерением пожаловаться в полицию.Изучение содержимого каталога ".git" показало, что 96% (186205 из выборки в 194000) сайтов содержат код на языке PHP и по 1% на Node.js (2394), Java (1742), Ruby (1199) и Python (1499). Код на Perl был найден в 504 случаях. 42 тысяча сайтов работают под управлением Ubuntu, 12906 - Debian, 9350 - CentOS, 3204 - Windows Server, 378 - RHEL, 216 - FreeBSD, 170 - Fedora, 152 - Gentoo, 50 - SUSE. Среди систем управления контентом лидирует WordPress - 41139 сайтов, Drupal - 2256, Joomla - 1615, Typo3 - 1258, Bitrix - 330.
URL: https://lynt.cz/blog/global-scan-exposed-git
Новость: https://www.opennet.me/opennews/art.shtml?num=49225
Во всем виноват git? При SVN такого не было!
было же
Отродясь такого не было и вот опять же, ну.
сколько раз за сегодня эту фразу уже слышал =)
При SVN было хуже в несколько раз:
моя сорказм ни панемать
С каких пор 3 тысячи в несколько раз хуже 390 тысяч?Хотя я не понимаю напоркуа там вообще версионка?
Например для Java. Они что весь гит в war засовывают при сборке?
конечно, не было:
<Directory ~ "/(\.svn|RCS|CVS)/">
Satisfy All
Order allow,deny
Deny from all
</Directory>
сразу следом за ~ "^\.ht" и ",v$"
Всё ещё проше!
<Directory ~ "^\.">
Require all denied
</Directory>
<Files ~ "^\.">
Require all denied
</Files>P.S. А вообще нефиг в DOCUMENT_ROOT что-попало сувать, аля вордпресс!
Не самое худшее. Дурпал куда противнее.
Доооо. И нгинкс фронтендом.
не, это анахронизм же. "Во времена svn", когда *писали* такие конфиги, nginx был версии 0.чтототам, его как фронтенд использовали только редкие птицы.а сейчас-то да, nginx frontend, как я, по твоему, скачал этот конфиг? ;-)
Я как ламо люблю собирать всякую фигню из git - доставляет удовольствие, греет ЧСВ.
хостинг во всём виноват. Он должен был блокировать доступ к .git
На хостинг надейся, а сам не плошай.
> 96% (186205 из выборки в 194000) сайтов содержат код на языке PHP«Но похапе тут нипричом! Это погромисты плохие!»
Кто-то забыл служебную информацию от системы контроля версий: виноват ПХП.
Это просто показывает, что среди лопухов, выставляющих .git в общий доступ, пыхеры составляют подавляющее большинство.
Как и среди остальных сайтов
Типичная ошибка выжившего. Сколько там сайтов не на похапэ?
это показывает настоящую популярность языка, а не нахайпленное инфомесиво.
А ничего что подавляющие большинство сайтов на php
Ну да 96% с дырами, и 83% в среднем по миру.https://w3techs.com/technologies/details/pl-php/all/all
Манки-кодеры.
Ну хоть ты не такой.Скорее покажи примеры своего кода, а мы поучимся.
у меня в корне лежит .hg, только ты его не вытащишьпотому что модель *что вижу, то и пою* из всего хоть сколько нибудь популярного есть только в php. и это источник 1000 неочевидных ошибок - избежишь одной, так нарвёшься на другую. 390 тыщ нарвались именно на эту
Расшаренный наружу .git к php ортогонален, он в принципе не может быть ошибкой php, хотя бы потому, что .git наружу в этом случае отдает не php, а apache или nginx.
Проблема здесь не в самом git, а в php-программистах, которые часто не программисты, а говнокодеры, из-за низкого порога вхождения языка. На других языках с более высоким порогом вхождения таких дилетантов по идее должно быть поменьше.
то есть сайт у тебя отдается напрямую через неэффективный, гнилой и дырявый python wsgi? Включая картинки и видеофайлы (впрочем, до видео у вас цивилизация, кажется, еще не дошла) Садись, коноплев, это пять, гордись дальше.возможно, когда и если ты переедешь с дальнего востока куда-то, где не adsl 7мегабит является последним достижением цивилизации, и тебе доверят сайт не с полутора посетителями в час - ты узнаешь, почему остальные так не делают, совершенно независимо от того, какой именно "application service" тормозит на той стороне proxy_pass.
Как бе нормальная практика - это когда приложение может само выдать все свои ресурсы, перехват статики в обход proxy_pass делается уже как оптимизация
ну вот да, охрененная ж нормальная практика - видеоролик в пять гигабайт отдавать через приложение. Нет, что вы, это ж жабка, какой мультикаст, вы о чем... Причем мы ни о sendfile не слышали, ни о других оптимизациях - "приложение" же ж, ему не надо. Вот сейчас чо-та заранее ржу с такого проекта. Или там - сотню мелких css/js, по коннект/exec на каждый (фронтенд-то использует keepalive, и может даже http2, а "приложение" нет), и merge приложение, кстати, не умеет.нормальная практика ровно в обратном - отдавать статику тем, что приспособлено к отдаче статики, а заниматься "оптимизациями" вида "подставь тут ему ведерко с кэшем, потому что добраться до файлов напрямую мы не можем, а потом как-то еще научись этот кэш синхронизировать методом угадава" только когда приложение уже и с динамикой плохо справляется.
А ваша - не "нормальная", а "распространенная", потому что разработчики по другому не обучены, и других у нас не делают.
пхп всегда виноват, потому что гладиолус
Accidentally open source.
SUSE совсем загнулась.
Статистика лишь показывает то, что у нубов популярна убунта и дебиан, а не реальную популярность этих дистров.
Апача же запрещает по-умолчанию доступ к файлам начинающимся с точки, значит во всем виноваты другие неправильно настроенные веб-серверы.
> Апача же запрещает по-умолчанию доступ к файлам начинающимся с точки, значит во
> всем виноваты другие неправильно настроенные веб-серверы..git это не файл, а каталог.
> In keeping with Unix philosophy, Unix systems treat directories as a type of file.
В каждой новости про релиз Апача обязательно найдётся несколько человек вопрошающие а зачем нужен Апач если есть офигенно-бежественно-колбасный что-то там (Блин, каждые пару недель про него новости тут как спам, а название вылетело).
IIS?
По-умолчанию запрещает он только доступ к .ht*. Ты, вероятно, путаешь с дефолтом IndexIgnore: http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#inde...
Действительно, зачем переходить по ссылкам на оригинал статьи, если можно сразу написать комментарий?..
https://lynt.cz/media/blog/git-scan/git-http-servers.png
> доступ к файлам начинающимся с точкиа к каталогам?
> Изучение содержимого каталога ".git" показало, что 96% (186205 из выборки в 194000) сайтов содержат код на языке PHPОбъяснение: сайты на других языках не держат код в DocumentRoot, поскольку это не требуется.
Типа Application Server держат файлы в руте...
так и на пхп не требуется.
> и по 1% на Node.js (2394)Нода из коробки вообще ничего не показывает наружу, как эти 1% ухитрились прострелить себе ногу? static от корня завели? Из php-мира мигрировали со своими привычками?
Фронтенд поставил, для той же самой статики.
Да, от корня - я ничего не понимаю в твоей ноде и не могу переложить статику куда-то еще.все, побежал - тут, говорят, с джангой такая же фигня на двух соседних серверах
тупые девопсики виноваты, 146%
ну так деплойчик же удобненький, гитпулл и гатоооова, можно смузи пить
Даже если неосилятор rsync, ну положи ты сайт в какой-нибудь www/index.html.
Писать html руками - это удобненько только девопсикам, которые на всём готовом.
А если сгенерённые коммитить - это мёржить задолбаешься.
Если бы админы были виндузятниками, то они бы этого не допустили. Потому что для ОС Windows файлы и каталоги, начинающиеся с точки, не являются скрытыми. Но админы использовали Linux, вот и не заметили их
Существо, которое поднимает сайт на Linux и не знает о скрытых файлах - это не админ, а ламер.
Очень уж короткая новость получилась и результаты исследования из статьи надерганы рандомно. Например, если не зацикливаться на абсолютном количестве сайтов на php, а посмотреть на график "Programming Languages by marketshare", то выводы у читателя будут совсем другие. Ну и в целом статья интересно написана. Рекомендую всем перейти по ссылке из новости и прочитать ее. Если есть время и желание, конечно...
Сервера на федоре?
Как бы я не любил федору на десктопе, для сервера это очень своеобразный выбор
ну то есть убунта на сервере вас уже совсем не смущает?(странно, где же gentoo? Не детектится, что-ли?)
Гитом умеем пользоваться :)
У убунты LTS-ветка к концу первого года с релиза становится более-менее стабильной и пригодной для использования, а потом ещё 4 года поддерживается, так что тут не всё так страшно.
К тому же для большинства людей (и большой части быдлокодеров тоже) Linux === Ubuntu, а серверная ОС, это либо (прости Господи) Windows Server, либо Linux (т.е. убунта), следовательно запустят они сервер на убунте.А у Федоры и со стабилизацией пакетов похуже (в том числе из-за rolling-ядра), и релизы надо менять не реже раза в год.
>> К тому же для большинства людей (и большой части быдлокодеров тоже)Молодец! Как всегда поделил людей на быдло и небыдло!
Сам-то ты из какого лагеря, ась?Сам ответишь или постесняешься?
А..ты же барон!!! Я сразу и не заметил! Исчезаю!
запустят убунту в окружении windows server :-)
Gentoo - 152. Написано же.
И да, как бы я не любил этот дистрибутив - для production server - это крайне своеобразный выбор.
А что не так с федорой? У меня все сервера на федоре, нарадоваться не могу.
Слабоумие и отвага, например.
а как часто обновляешь?
Каждый день, обожаю обновления.
1С-Битрикс в десятке!
Ага, плакать надо
Я крайне удивлен, что лишь один ответ был с угрозой.
Коля, звони в полицию!!!1111
Я так понимаю, что следует папку .git размещать уровнем выше чем корневую Apache? Т.е. чтобы та была подпапкой репозитория. Верно?
В одной директории с index
Вообще-то git умеет разделять голый репозиторий и собственно рабочую директорию.
Вот только по умолчанию они в одной директории, а из использующих git очень мало тех, кто знает его дальше пятиминутного введения. Результат предсказуем.
Нет, нужно просто не давать доступ к .git
>некоторых случаях угрожающую безопасности. Например, в каталоге .git могут быть оставлены исходные тексты всех серверных обработчиков сайта (атакующий может использовать их для поиска уязвимостей)это реклама "безопасности" через неясность?
Это все враньё.
Пыхеры не пользуются гитом - они редактируют либо сразу на серваке, либо заливают через ftp
Кстати, кроме шуток. Был в чатике одной довольно модной ныне cms, многие чуваки, да, пользуются ftp и все прочее делают как 15 лет назад, что такое права доступа толком не знают и далее по списку.
через ftp отдаются права доступа и их можно менять.
И как если не через ftp?
scp?
>заливают через ftpНу а что делать, если хостер не умеет rsync? Не заливать же через веб-морду врукопашную по одному файлу.
через sftp наверное.
Что мешает сделать нормальную сборку с одним архивом и ее деплоить?
вывсеврети!
Вчера аутсорсер столкнулся у нас с неодолимыми проблемами - не сумел выложить свой "продукт" на наш сервер, патамушта, барабанная дробь... git clone user@host у него ниработаит!(ну да, ssh наружу закрыт, даже с хоста в dmz, нам рассадник червей не нужен. Вообще-то специально для них открыт веб, но "пользующиеся гитом", видимо, еще не успели прочитать про варианты, отличные от ssh)
будем делать ставки, получу я содержимое http://этахрень/.git/config с первой попытки, когда они все же победят выкладку?
Чот не совсем понял, он не смог ВЫЛОЖИТЬ продукт на ваш сервер, или ЗАБРАТЬ продукт с вашего сервера? Потому что в случае http-транспорта он может его только забрать оттуда. Да и git clone ровно на то же намекает. Тем более, что вы сами олени, вместо нормальной ссылки на репозиторий http://domain.name/yourproject.git отдали человеку какую-то хрень. git clone http://domain.name/yourproject.git как раз сработает совершенно "прозрачно" для пользователя, он даже не заметит, что это не по ssh.Дело в том, что на сервере может быть несколько больше одного урла, и при host=gitserver100500 урла может быть вполне себе http://git.myawesome.org. Т.е. вы человеку дали логин/пароль, что в подавляющем числе случаев означает ssh-доступ, сами ssh-доступ отключили, а потом злорадствуете? У меня для вас плохие новости!
Или вы его в ssh пустили на сервер, с которого исходящие ssh-соединения запрещены? Типа так?
>> ну да, ssh наружу закрыт, даже с хоста в dmz, нам рассадник червей не нужен
В целях борьбы с червями, однако, как правило, запрещают доступ по ssh извне, а не наружу. Иначе это называется "пусть у нас будет рассадник червей, главное - соседям не навредить". Похвально, конечно, но "слабоумие и отвага".
>> будем делать ставки, получу я содержимое http://этахрень/.git/config с первой попытки, когда они все же победят выкладку?
Прикол в том, что если вы git по http открыли, вы получите, как раз доступ к конфигу. Доступ к репе по ssh - это "показать папочку как есть наружу, со всеми вложениями". Иначе работать не будет.
выложить. У него-то на этот сервер есть доступ по ssh (не нам же за его животными лоток выносить). А обратно ему никто вообще-то и не обещал (поскольку он и не просил ;)> Прикол в том, что если вы git по http открыли
о, вы достойны работать у этого аутсорсера (кстати, ему пригодился бы админ). Разница между доступом к repository для деплоя (раз уж не продуманы более приличные варианты, впрочем, это немодно, continious development/delivery наше всьо) - возможно, не кому попало, и возможно, не по голому http даже (хотя ни нам, ни провайдеру нафиг не нужен неуловимый джо, а вот ssh-то я бы и не стал использовать, слишком много умеет лишнего) и оставленным без присмотра клоном уже в задеплоенном проекте вам, очевидно, неведома?
> Да и git clone ровно на то же намекает.лолшто?
С другой стороны, может оно и хорошо, что вы не понимаете, как заливается сайт через git: есть вероятность, что вы случайно выбрали безопасный для ваших "продуктов" вариант. Хотя вот о качестве "продукта" думать даже как-то не хочется, с такими-то познаниями.
можно через git через https загружать. https никто в здравом уме блокировать не будет.
не, нельзя. Во-первых, таки заблокирован (этим конкретно я разрешил, предвидя, хм, ньюансы, но они, как видите, меня перехитрили), во-вторых чтобы раздавать git через https уже не хватит наспех прочитанной первой страницы https://git-scm.com/book/ru/v1/Git-%D0%BD%D0&... - надо дочитать хотя бы до пятой и еще и уметь в апач.(и да, у него вся документация такая вот отвратительная - пять страниц про ssh, одна про git server с восхвалением ненужного протокола и ровно ноль про то, что если нужен нормальный доступ с аутентификацией, то добро пожаловать в мир gogs/gitea/gitlabCE - которые не-админ хрен настроит нормально. Патамушта Линус, шлите ваши патчи в рассылку!)
А hg вы не умеете. :-(
>в здравом уме"Эх, бросить бы всё и уехать в Урюпинск..."
> 378 - RHELА вот и мифическая рука RHEL вам. Где-то в глубокой опе на порядок за Windows.
или они умеют настраивать свои сайты.
Они конкретно умеют, согласен. Или, погодите! 378 - примерно правдоподобная цифра для хост-площадок компании уровня RH! Может быть, это они сами и не умеют? А остальные - просто не пользуются)
я, конечно, свечку не держал, но что-то мне подсказывает, что за rh (учитывая что именно покупают - и это не голый сервер rhel с поддержкой "мы о тебе не помним") платят как раз те, у кого давно уже не плоская инфраструктура, и даже если ты найдешь на фронтенде какой-то .git, то в нем окажется статика, которую имеет смысл держать непосредственно на фронтенде - ну получишь ты из этого гита прошлую версию логотипа, молодец, возьми с полки пирожок. Но скорее всего и статика просто кэшируется, а берется откуда-то, где нет никакого .gitа бэкэнд скорее всего вообще веб-сервера не содержит, и даже если туда как-то ухитришься передать запрос, он содержимое .git попытается выполнить, расстроится и упадет (ничего страшного, докер переподнимет, оно всегда падает).
А еще, в rhel, вы будете смеяться, по сей день нет nginx в дистрибутиве.
https://access.redhat.com/solutions/158763ентер прайс, все дела... с другой стороны, если ты на самом деле продаешь выхлоп веб-сервера - nginx у тебя, скорее всего, самособранный. И может быть даже самопатченный. Независимо от дистрибутива.
у них есть в redhat software collection. За отдельные деньги конечно же.
ну этож отстойник для неосиляторов самим собрать - с тем же успехом можно использовать epel, если уж к nginx repo душа не лежит или про него забыли рассказать. Или даже с большим- судя по частоте секьюрити-рассылки по продуктам из этой "коллекции", присмотра за ней нет никакого.кстати, apache-itk, по-моему, тоже там же только.
типичному покупателю видимо, либо уже-не-надо, либо у него "приложения".
Где он взял столько доменов?
alexa
не угадали.So, I used DNS log from the OpenData Rapid 7 project. This was a 3.5TB text file in JSON format, which shows the individual queries:
{"timestamp":"1530259463","name":"<domain>","type":"<a/cname/mx/..>","value":"<ip>"}
Linux offers lots of handy Gzip tools (zcat,...), so processing such a large volume of data wasn't a big problem.
There was a huge amount of various domains and subdomains on the list and it was necessary to reduce them and select only the "interesting" domains. I only filtered A queries on second-level domains of selected TLDs (generic, European + eu, other major states, popular new TLDs: top, xyz, etc.). That's how I got the list with more than 230 million domains.
https://opendata.rapid7.com/ - качайте на здоровье.
уфф, мне писем от него не приходило :)
ваш почтовый сервер считает почту из чехии - спамом.
Сказочные программисты. Зачем их только с локалхоста выпустили?..
лежит себе, никому не мешает, люди пользуются… нет, обязательно найдётся вот такой вот «исследователь безопасности», который всё испортит.
Я один не понимаю, откуда на сайтах, написанных на Java вообще взялась папка .git в корне? Проект же собирается отдельно и потом деплоится. Я могу понять на скриптовых языках такое - зашел, git pull - и всё, деплой обновления завершен. На Java такое не прокатит. Разве только если шаблоны отдельно хранить и обновлять как скриптовые сайты... Но к ним веб сервер доступ иметь не должен. Значит остаются только ресурсы - картинки и js либы, которые зачем-то хранятся в git, но при этом деплоятся отдельно от кода?Кто-то может поделиться опытом? Как у вас проект организован так, чтобы .git вообще попал в область видимости веб сервера?
> Кто-то может поделиться опытом? Как у вас проект организован так, чтобы .git вообще попал в
> область видимости веб сервера?ты хочешь статику отдавать томкэтом? Нет? Ну, вот...
Ничего такого ужасного-ценного для кульхацкеров в том гите не будет, оно и так все либо доступно в вебе, либо было недавно, но таки да, неаккуратненько.
Смешнее получается, когда и жабаблоб лежит себе ниже docroot, хотя никаким веб-сервером обрабатываться не должен, и его, при некотором энтузиазме, можно добыть как octet-stream. Но уговаривать разработчиков поменять пути - долго, дорого, неприятностей себе на жопу. Приходится работать из того матеръяла, что они навалили.
>Ничего такого ужасного-ценного для кульхацкеров в том гите не будет,Сколько человек думают, что удалив файл с настройками (читай паролями) они сделали его недоступным?
При условии что можно по версионке восстановить что было до того?
>ты хочешь статику отдавать томкэтом? Нет? Ну, вот...Ммм. А тот же war унзипнуть по scp на сервер с nginx/apache религия не позволяет?
В одном скрипте деплоя можно же.Хотя если http сервером рулит другой человек, ему наверно сложно.
>по недосмотру выставили в публичное пространство без ограничения доступаинтересно, каким образом чешский исследователь безопасности Владимир Смитка определил, что выставили именно по недосмотру, а не сознательно, потому что людям нечего скрывать? наверно он серьёзный иксперт, раз смог это определить, сидя на диване в своей чехии...
>потому что людям нечего скрывать
Я же надеюсь это сарказм? Иначе сразу в цитатник "потому что людям нечего скрывать".
на самом деле не плачьте, фанаты редкоупоминаемых дистрибутивов - есть и у вас .git, просто скан был неаккуратный - глянул я в этот apps.json:
|"CentOS": {
"cats": [
28
],
"headers": {
"Server": "CentOS",
"X-Powered-By": "CentOS"
},
"icon": "CentOS.png",
"website": "http://centos.org"
},как-то вот так оно делает. Смотрим ближайший кривонастроенный центос:
GET /.git/config HTTP/1.0
HTTP/1.1 404 Not Found
Server: nginx/1.14.0
Date: Wed, 05 Sep 2018 06:48:53 GMT
Content-Type: text/html
Content-Length: 169
Connection: closeну и чего бы мы тут угадали? Количество сузей и центосов, по сей день использующих фронтендом апач?
Давно пора ввести вход в Интернет "по паспортам" для всех - чтобы не шлялись просто так по чужим ресурсам без авторизации и личного токена, не оставляя следов кроме IP-адреса, с которого произошёл вход. IP-адрес можно подменить, зайти с любого публично, а личный токен для входа в Интернет - вряд ли. Так службам безопасности легче выявлять нарушителей закона о неправомерном доступе к оставленной по каким-то причинам незащищённой информации и персональным данным.
погоди, как это подменить? Мы ж паспорта и так всех заставили проверять?и этих...публичных, тоже.
Если бы не быть знакомым с тобой, то можно было бы подумать, что это лихая шутка.
> а личный токен для входа в Интернет - вряд лиА что этому помешает, интересно? Или ты думаешь, что хомяки токен будут содержать безопаснее чем свои хламежные роутеры и дырявый софт?
впихивайте в разные места
map $query_string $block {
default 0;
"~*[a-zA-Z0-9_]=(\.\.//?)+" 1;
"~*[a-zA-Z0-9_]=/([a-z0-9_.]//?)+" 1;
"~*\=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" 1;
"~*(\.\./|%2e%2e%2f|%2e%2e/|\.\.%2f|%2e\.%2f|%2e\./|\.%2e%2f|\.%2e/)" 1;
"~*ftp\:" 1;
"~*\=\|w\|" 1;
"~*^(.*)/self/(.*)$" 1;
"~*^(.*)cPath=http://(.*)$" 1;
"~*(\<|%3C).*script.*(\>|%3E)" 1;
"~*(<|%3C)([^s]*s)+cript.*(>|%3E)" 1;
"~*(\<|%3C).*embed.*(\>|%3E)" 1;
"~*(<|%3C)([^e]*e)+mbed.*(>|%3E)" 1;
"~*(\<|%3C).*object.*(\>|%3E)" 1;
"~*(<|%3C)([^o]*o)+bject.*(>|%3E)" 1;
"~*(\<|%3C).*iframe.*(\>|%3E)" 1;
"~*(<|%3C)([^i]*i)+frame.*(>|%3E)" 1;
"~*base64_encode.*\(.*\)" 1;
"~*base64_(en|de)code[^(]*\([^)]*\)" 1;
"~GLOBALS(=|\[|\%[0-9A-Z]{0,2})" 1;
"~_REQUEST(=|\[|\%[0-9A-Z]{0,2})" 1;
"~*^.*(\(|\)|<|>|%3c|%3e).*" 1;
"~*^.*(\x00|\x04|\x08|\x0d|\x1b|\x20|\x3c|\x3e|\x7f).*" 1;
"~(NULL|OUTFILE|LOAD_FILE)" 1;
"~*(\.{1,}/)+(motd|etc|bin)" 1;
"~*(localhost|loopback|127\.0\.0\.1)" 1;
"~*(<|>|’|%0A|%0D|%27|%3C|%3E|%00|%22)" 1;
"~*concat[^\(]*\(" 1;
"~*union([^s]*s)+elect" 1;
"~*union([^a]*a)+ll([^s]*s)+elect" 1;
"~*\-[sdcr].*(allow_url_include|allow_url_fopen|safe_mode|disable_functions|auto_prepend_file)" 1;
"~*(;|<|>|’|\"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|md5|benchmark|encode)" 1;
"~*(sp_executesql)" 1;
}
location ~ /\.(?!well-known).* {
deny all;
access_log off;
log_not_found off;
}if ($block) {
# SQL injection - reset conn
return 444;
}
дружище, погугли mod_security и не позорься, занимаясь бесполезной неэффективной фигней.
(когда нагуглишь рекламу третьей версии и о том как nginx прекрасно с ней совместим - найди на их сайте запись вебинара, прослушай первые 30 секунд где представляется ведущий (второй) - закрой нахрен, и сделай выводы - правильные)и да, внезапно, на моих, к примеру, сайтах, есть валидные локейшны, начинающиеся с точки - а никакого ненужного вялоновна - в помине нет.
и да, "впихивайте в разные места" - прекрасный совет, реально отражающий степень вменяемости структуры конфигов nginx. Тут и необходимость (в отличие от апача, кстати) дублировать вторую половину в каждом виртхосте, и возможность ненароком прооверрайдить ее, потому что regex-locations матчатся сверху-вниз до первого попадания, а не longest-match...
вот ещё всякой хренью заниматься ставя всякие модули (и тратя моё время на чтение доков) когда проблема топика решается за 20 сек. И ничего бесполезного там нет. Имя валидного локейшена с точки? Ну так поправь на .git явно и всё. Пихайте в разные места сказано, конечно ,не для идиотов..лол
и действительно, вот еще всякой хренью заниматься, доки какие-то там читать - надо скорей бежать изобретать свой квадратноколесный велосипед.> И ничего бесполезного там нет.
для тебя - может быть (правда, оно совершенно не относится к проблеме .git), для большинства окружающих - совершенно ненужно и вредно. Предлагая какие-то свои наколенные разработки для всеобщего обозрения - стоит иногда убедиться, что мир не придумал давным-давно решения получше и не заточенного под твой единственный-неповторимый сервер.
Ты идиот что-ли? Решать проблему запрета одного локейшена с точками mod_security?
Тебя уволить пора за профнепригодность
да-да, гораздо правильней решать эту проблему простыней анонимовых регекспов.
И да - для остальных глупых недоадминов типа тебя - этот "велосипед" описан в основной документации nginx (когда нагуглишь расскажешь всем)
>и да, внезапно, на моих, к примеру, сайтах, есть валидные локейшны, начинающиеся с точкиЯ аж прям насторожился. А зачем тебе локейшины, начинающиеся с точки?
>>и да, внезапно, на моих, к примеру, сайтах, есть валидные локейшны, начинающиеся с точки
> Я аж прям насторожился. А зачем тебе локейшины, начинающиеся с точки?да как-то так исторически сложилось для технических адресов и механизмов - набирать удобно, по телефону диктовать легко, ни с чем внутри сайта (где механика может быть чужая) не пересечется, мамкины какеры ничего кроме /status не знают - дополнительный уровень защиты от перебора - уж всяко лучше чем навязщий в зубах /admin у не-будем-пальцем-показывать.
Многа непанятных букаф. Но выглядит завораживающе.
> Многа непанятных букаф. Но выглядит завораживающе.говорят же вам - товарищ переизобрел mod_security, с опозданием на пятнадцать лет и криво.
Погуглите, может вам и пригодится - определенный смысл в подобных проверках есть, но, разумеется, не настолько примитивных, и обновлять правила надо постоянно, потому что весь их смысл в защите от zero day в чужом кривом коде.
Дык в чём-годно zero-day может быть - а очередное автообновление правил и под монастырь подвести может
> Дык в чём-годно zero-day может быть - а очередное автообновление правил и под монастырь подвести
> можетможет, конечно, вон, даже меганз отметилась - но сравни, что более вероятно - удачный (попавший в твою версию, твою операционку, твою систему и твои другие слои защиты) remote exec через подсунутый апдейт строчек для фильтра, или звонок в пять утра субботы "у нас на сайте вот такенный $!й стоит!" потому что ты забухал в пятницу на пятнадцать минут раньше, чем всплыла очередная дыра во врот-прессе или еще хз чем, прекрасно блокируемая стандартным паттерном?
И хочется ли тебе знать всю эту кучу муры про баги вротпрессов и жумл вообще, если ты ни разу не их разработчик?
вот ещё всякой хренью заниматься ставя всякие модули (и тратя моё время на чтение доков) когда проблема топика решается за 20 сек. И ничего бесполезного там нет. Имя валидного локейшена с точки? Ну так поправь на .git явно и всё. Пихайте в разные места сказано, конечно ,не для идиотов..лол
> Адреса электронной почты были взяты из файлаКажется спамеры пополнят свои базы...