allow-query { any; }; # это нормально, если сервер поднимается для поддержки доменов. другие клиенты будут спрашивать и должны получать ответ для этих доменов.
recursion no; # - убрать
поставить :
allow-recursion { 127.0.0.1; };
Полностью ошибки query (cache) denied это НЕ погасит. Однако ошибки при самых частых запросах 127.0.0.1 не будут возникать.
Данная ошибка свидетельствует о неправильной настройке клиента или домена или cache poisoning атаке.
Тут вопрос неоднозначный нужно ли ее вообще гасить. Я сначала не заметил 127.0.0.1 и агитировал за то чтобы вообще ничего не делать.
broken, раз уж вы решили использовать свой локальный dns на 127.0.0.1, вместо того, который вам дал провайдер, проще всего исключить причину их появления. у вас к этому bind посылаются запросы от программ на сервере. наверное и до обновления посылались, но ошибки не писались.
вроде раньше достаточно было
allow-recursion {
127.0.0.1;
};
или что-то в bind совсем поменялось ??
coolwebsearcher, ну приведи пример своих ACL . пусть ТС убоится и поймет что ему проще ничего не делать.
классические опции уже не работают? почему их там нет в дефолтном конфиге ?
coolwebsearcher, ну вот включишь ты это кеширование и увеличишь вероятность успеха Атаки Каминского (dns cache poisoning)
согласно концепции zeroadministration не нужно вообще читать непонятные сообщения.
Не читай, не меняй дефолтные настройки и радуйся. Когда что-то произойдет пользователи тебя найдут сами.
Andreyka, ну глупо же. при хорошей раздаче на клиентском порте всегда почти забито 80-95 мбит. Хоть идет на него ддос, хоть не идет - цифру snmp выдаст одинаковую. На ненагруженном сервере перекачка бекапов и прочие работы могут на длительное время забивать клиентский порт до максимума из-за чего возникнут ложные срабатывания.
Исходя из этих фактов, вы, скорее всего, не эксплуатировали подобную схему. Зачем же предлагать настройку?
многие так думают. опасность в том что скрипты можно заставить делать совсем не то, для чего они предназначены. подобные возможности и называются "дырами".
нет. найдется еще 500 вариантов. защищенность - показатель вероятностный.
но да, сценарий с перехватом пароля требует перехвата трафика в незащищенной сети. при обычном домашнем подключении и установленном антивирусе вероятность перехвата низкая.
ну он же не знает пароль, поэтому скрипт в админке даже не запустится.
Andreyka, так какую именно они информацию отдают по snmp? на основании чего принимается решение о блокировании IP ? почему это лучше чем netflow или программный фильтр трафика?
не вижу обоснования механизма определения факта ddos и поэтому не могу вам довериться.
ну а если клиентский порт 100 мбит и при нормальной работе уже забит под завязку, как понять на какого из клиентов пошел ddos свыше 100 мбит с помощью snmp?
у вас план какой-нибудь есть или как обычно?
ну так ТС и спрашивал. ЧЕМ мониторим?
запуск скрипта в запароленном таким образом url без знания пароля невозможен. это не значит, что скрипт нельзя будет запустить воздействуя на поведение других скриптов по другому незапароленному URL.
но вообще это слабая непрактичная защита. администратор приходит в макдоналдс и хакер за соседним столиком спокойно подслушивает пароль и пользуется им для полного доступа к функциям админки, а может быть и внедрением закладок на сайт.
как этот вопрос вообще мог возникнуть? авторизацию изображает apache и он на поведение php никак не влияет - это разные модули.
обычно требования к качеству "админского" кода снижены именно из-за того, что кто попало туда не попадет.
но если админка многоуровневая, то завладев вроде бы неважным паролем например, контент-менеджера, можно с помощью инъекций и прочих уязвимостей в коде админки что-то еще сделать.
