Я вижу повторяющиеся запросы, подобные этим, в моих журналах доступа к Apache, и они съедают весь мой процессор.
У меня обычная установка WordPress. Все, что я изменил в конфигурации Apache, - это изменение DocumentRoot с / var / www / html на / var / www как для ssl, так и для конфигурации по умолчанию.
Кроме того, файл, указанный в запросах (updatedll.jpeg), не существует на моем сервере, а также не упоминается в исходном коде, обслуживаемом какой-либо страницей веб-приложения.
Может ли это быть угрозой безопасности? Что это на самом деле и что я могу сделать, чтобы их остановить.
Я изменил IP-адрес своего сервера. Они продолжали идти. Это означает, что кто-то на самом деле использует доменное имя, а не IP-адрес.
Почему мой сервер отправляет 301 для этих запросов? Разве он не должен отправлять 404? Это потому, что Wordpress установлен в моем корневом каталоге, а файл .htaccess для Wordpress отправляет 301 редирект?
Мои журналы доступа к диску также периодически имеют высокие пики. Но на самом деле никто не имеет доступа к сайту. Я не вижу журналов доступа, кроме приведенных ниже.
Кроме того, я вижу, что все запросы, похоже, поступают с одного из следующих 5 IP-адресов.
201.4.132.43 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; BTRS103681; GTB7.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; AskTbATU3/5.15.29.67612; BRI/2)"
187.40.241.48 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
186.56.134.132 - - [05/Jun/2014:07:35:10 -0400] "GET /updatedll.jpg HTTP/1.0" 301 428 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
71.223.252.14 - - [05/Jun/2014:07:35:13 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)"
85.245.229.167 - - [05/Jun/2014:07:35:14 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MAAU; .NET4.0C; BRI/2; .NET4.0E; MAAU)"
ОБНОВИТЬ
Кажется, это 32 разных IP-адреса, которые, похоже, сейчас попадают на мой сервер.
Кроме того, вывод команды «ngrep 'GET /updatedll.jpg' port 80» приведен ниже:
T 75.172.162.70:1616 -> 162.243.34.213:80 [AP]
GET /updatedll.jpg HTTP/1.1..Accept: */*..Accept-Encoding: gzip, deflate..U
ser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506
.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)..Connection: Kee
p-Alive..Host: www.reinventweb.com....
###############
T 85.245.0.83:65166 -> 162.243.34.213:80 [AP]
GET /updatedll.jpg HTTP/1.1..Accept: */*..UA-CPU: x86..Accept-Encoding: gzi
p, deflate..User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648;
.NET CLR 3.5.21022)..Host: reinventweb.com..Connection: Keep-Alive....
######
Вы перенаправляете на основе доменного имени? Например, с example.com на www.example.com? Это могло бы объяснить ответ 301.
Если ваш сервер отвечает 301, скорее всего, это не причинит большого вреда. Однако на какой-то странице, вероятно, есть неработающая ссылка на изображение. Чтобы отследить это, вы должны посмотреть заголовок Referer во входящих запросах. Вы можете регистрировать Referers со своего веб-сервера, но, вероятно, проще смотреть на трафик напрямую.
Вместо tcpdump (что предлагал касперд) я бы использовал ngrep:
ngrep 'GET /updatedll.jpg' port 80
Поиск в Google по имени файла обнаруживает несколько копий вашего файла журнала и только одно совпадение, которое выглядит как журнал загрузки из какой-то службы. Вы сможете определить, связан ли этот журнал с вашим сайтом, а я нет.
Ни один из этих пяти IP-адресов не отображается в журнале загрузки, так что это мало что нам говорит. Имена файлов в журнале загрузки кажутся мне правильными. Невозможно сказать, не зная содержимого, соответствует ли содержимое этих файлов их именам.
Что изначально могло быть в файле с именем updatedll.jpg? Я предполагаю, что кто-то сделал снимок экрана с тем, как обновить некоторую dll и загрузил ее в службу, чтобы поделиться ею с другими. Публикация, вероятно, не происходила на публичном веб-форуме, потому что тогда я нашел бы больше просмотров для него.
Почему кто-то думает, что файл находится на вашем хосте? Я не знаю. Я считаю полезным включить \"%{Host}i\" в апаче LogFormat.
Что касается кода состояния, вы можете сначала попытаться получить доступ к имени файла самостоятельно, чтобы увидеть, как это выглядит в файле журнала. Если вы получили другой код состояния, должно быть что-то другое между вашим собственным запросом на файл и их запросом.
Если вы не можете понять, как воспроизвести тот же самый код состояния, попробуйте создать пакетный дамп их трафика. Вы можете использовать что-то вроде tcpdump -pni eth0 -s0 -Uw output.pcap 'host 201.4.132.43 || host 187.40.241.48 || host 186.56.134.132 || host 71.223.252.14 || host 85.245.229.167'
Позже вы можете проверить вывод с помощью Wireshark, чтобы точно увидеть, как выглядят запросы. Не забудьте использовать обновленную версию Wireshark, если кто-то действительно пытается использовать уязвимость в Wireshark. Когда вы увидите точный запрос, вы сможете воспроизвести ответ с помощью команды telnet.