LINUX.ORG.RU
ФорумAdmin

Подземный стук на веб-сервере (кто-то стучится на него с locahost'а)


0

3

Сегодня заметил в логе веб-сервера lighttpd следующие странные строки:

localhost - - [11/Sep/2011:00:18:20 +0400] "GET  HTTP/1.0" 400 349 "-" "-"
(всего таких уже 28; первая была в 10/Sep/2011:15:58:39, последняя - 11/Sep/2011:00:18:20 +0400). Никакой логики во времени между запросами не наблюдается, сами запросы и ответы одинаковы:
GET  HTTP/1.0

Host: 127.0.0.1

Accept-Encoding: gzip

Connection: close


HTTP/1.0 400 Bad Request

Content-Type: text/html

Content-Length: 349

Connection: close

Date: Sat, 10 Sep 2011 19:17:50 GMT

Server: lighttpd/1.4.29



<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>400 - Bad Request</title>
 </head>
 <body>
  <h1>400 - Bad Request</h1>
 </body>
</html>

Пробовал:

  • iptables -j LOG, ULOG - не записывает PID
  • tcpdump и wireshark - не записывает PID
  • netstat -cntp - не успевает поймать момент ESTABILISHED (получил много строк с TIME_WAIT и без указания имени программы):
    tcp        0      0 127.0.0.1:47651         127.0.0.1:80            TIME_WAIT   -
  • systemtap - не разобрался, какую функцию ловить, чтобы можно было проверять целевой протокол, ip-адрес и порт, а также узнавать PID.

Как отловить басурмана (как минимум PID)?
Умеют ли вообще iptables и libpcap отлавливать PID процесса, отправляющего пакет, или они не работают на том уровне, на котором это возможно (как тогда работает nethogs)?

★★★★★

сделай , чтоб по GET / отрабатывал php/perl скрипт sleep(60), вот и увидишь висящий процесс.

Bers666 ★★★★★
()

емнип, лайти (то ли gam_server используемый им) проверяет таким образом живо ли всё, если сдохло то перезагружается

anonymous
()
Ответ на: комментарий от spunky

> Log the userid of the process which generated the packet.
А мне PID нужен.

AITap ★★★★★
() автор топика
Ответ на: комментарий от Bers666

> по GET /
В том то и дело, что не GET /, а «GET HTTP/1.0».

AITap ★★★★★
() автор топика
Ответ на: комментарий от spunky

Впрочем, всё равно спасибо.

localhost - - [11/Sep/2011:11:08:21 +0400] "GET  HTTP/1.0" 400 349 "-" "-"
Sep 11 11:08:21 Tarkus kernel: [ 1054.782714] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=22248 DF PROTO=TCP SPT=58999 DPT=80 WINDOW=32792 RES=0x00 SYN URGP=0 UID=1005 GID=1005
Sep 11 11:08:21 Tarkus kernel: [ 1054.782753] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=22249 DF PROTO=TCP SPT=58999 DPT=80 WINDOW=32792 RES=0x00 ACK URGP=0 UID=1005 GID=1005  
Sep 11 11:08:21 Tarkus kernel: [ 1054.782812] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=22250 DF PROTO=TCP SPT=58999 DPT=80 WINDOW=32792 RES=0x00 ACK PSH URGP=0 UID=1005 GID=1005
Sep 11 11:08:21 Tarkus kernel: [ 1054.782901] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=22251 DF PROTO=TCP SPT=58999 DPT=80 WINDOW=33768 RES=0x00 ACK URGP=0 UID=1005 GID=1005  
Sep 11 11:08:21 Tarkus kernel: [ 1054.783570] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=22252 DF PROTO=TCP SPT=58999 DPT=80 WINDOW=33768 RES=0x00 ACK FIN URGP=0 UID=1005 GID=1005
[11:12:01][aitap@Tarkus ~]> getent passwd 1005
deluge:x:1005:1005:,,,:/home/deluge:/bin/false

Осталось только понять, баг это, или фича.

AITap ★★★★★
() автор топика
Ответ на: комментарий от ynn

tracker.thepiratebay.org резолвится как 127.0.0.1, но это я наблюдаю отдельно и с нормальным UA:

localhost tracker.thepiratebay.org - [10/Sep/2011:19:14:49 +0400] "GET /announce?info_hash=(удалено)&peer_id=-DE1320-(удалено)&port=(удалено)&uploaded=0&downloaded=0&left=(удалено)&corrupt=0&redundant=0&compact=1&numwant=0&key=(удалено)&no_peer_id=1&supportcrypto=1&event=stopped HTTP/1.0" 404 345 "-" "Deluge 1.3.2"

Точнее, наблюдал, т.к. сегодня эти запросы совсем появляться прекратили (вчера шли вперемешку), и их место заняли неправильные, «GET HTTP/1.0» и без User-Agent.

AITap ★★★★★
() автор топика
Ответ на: комментарий от AITap

Так может он совсем криво прописан, например из нулевого байта состоит, и в результате у клиента парсер сносит. Попробуй, пропадет ли если качалку остановить совсем.

А вообще модульно ищи. Помнится апач подобные запросы штатно сам себе шлет.

ynn
()
Ответ на: комментарий от ynn

Да, если нажать «Pause all», запросы приходить перестают.

AITap ★★★★★
() автор топика
Ответ на: комментарий от ssbury

Владельца пакетов мы выяснили, им оказался deluge. deluge-web у меня не установлен, так что дочерних процессов, которым можно было бы посылать такие запросы, у deluged нет.

AITap ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.