Странные журналы доступа Apache
У меня была та же проблема. Взял меня время для нахождения решения. "AppKitPHPError" является довольно вводящим в заблуждение; реальная причина намного более проста легкое для разрешения.
Это просто пропускает учетные данные. Отредактируйте следующие две конфигурации заливка в Вашем корректном входе в систему DB
- /whereveryouricingarootis/icinga-web/app/modules/Web/config/icinga-io.xml
- /whereveryouricingarootis/icinga-web/app/modules/Web/config/icinga-io.site.xml
После этого Вы сделаны, и ошибка исчезнет
Развлекайтесь!!
ranX
Поиск в Google по имени файла обнаруживает несколько копий вашего файла журнала и только одно совпадение, которое, похоже, является журналом загрузки какой-то службы. Вы должны быть в состоянии определить, связан ли этот журнал с вашим сайтом, а я нет.
Ни один из этих пяти IP-адресов не отображается в журнале загрузки, так что это мало что нам говорит. Имена файлов в журнале загрузки кажутся мне правильными. Невозможно сказать, не зная содержимого, соответствует ли содержимое этих файлов их именам.
Что изначально могло быть в файле с именем updatedll.jpg ? Я предполагаю, что кто-то сделал снимок экрана, на котором показано, как обновить некоторую DLL, и загрузил ее в службу, чтобы поделиться ею с другими. Публикация, вероятно, не происходила на публичном веб-форуме, потому что тогда я нашел бы больше просмотров для него.
Почему кто-то думает, что файл находится на вашем хосте? Я не знаю. Я считаю полезным включить \ "% {Host} i \" в Apache LogFormat .
Что касается кода состояния, вы можете сначала попытаться получить доступ к имени файла самостоятельно чтобы увидеть, как это выглядит в файле журнала. Если вы получаете другой код состояния, должно быть что-то другое между вашим собственным запросом файла и их запросом.
Если вы не можете понять, как воспроизвести тот же самый код состояния, то попробуйте создать дамп пакета их трафика. Вы можете использовать что-то вроде tcpdump -pni eth0 -s0 -Uw output.pcap 'host 201.4.132.43 || хост 187.40.241.48 || хост 186.56.134.132 || хост 71.223.252.14 || host 85.245.229.167 '
Позже вы можете проверить вывод с помощью Wireshark, чтобы точно увидеть, как выглядят запросы. Не забудьте использовать обновленную версию Wireshark, если кто-то действительно пытается использовать уязвимость в Wireshark. Когда вы увидите точный запрос, вы сможете воспроизвести ответ с помощью команды telnet.
Вы выполняете перенаправление на основе имени домена? Например, с example.com на www.example.com? Это могло бы объяснить ответ 301.
Если ваш сервер отвечает 301, скорее всего, это не причинит большого вреда. Однако на какой-то странице, вероятно, есть неработающая ссылка на изображение. Чтобы отследить это, вы должны смотреть на заголовок Referer во входящих запросах. Вы можете регистрировать Referers со своего веб-сервера, но, вероятно, проще смотреть на трафик напрямую.
Вместо tcpdump (что предложил kasperd) я бы использовал ngrep:
ngrep 'GET /updatedll.jpg' port 80