Перейти к содержимому
Калькуляторы

Отловить процесс Как определить процесс, генерящий большой трафик?

Ос на вебе какая ?

Fedora 6
Зарежте фаерволом пользователю от которого ходит httpd udp совсем, если оно умеет по пользователям.
Это каким образом??
ну и искать запросы сразу ПЕРЕД началом проблемы в логах. Пускач должен же быть...

Какие запросы? От чего?

"Пускач" точно есть, только вот где он живет не могу найти.. Допускаю, что через еще какую-то дыру вредитель заливает необходимый код, запускает его от имени апача и затем все аккуратно за собой подтирает. Как с таким бороться, пока не представляю..

Пока пытаюсь найти место той самой "дыры". Убрал подозрительный сайт, жду результата. Если через пару-тройку дней не проявится, буду пытаться найти дыру в коде движка сайта. Кстати, это последняя версия е107. Может у кого есть информация о слабых местах этого движка, которыми можно воспользоваться именно в таком плане?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я же спросил про ос не зря. Например во фре есть uid и параметрах фаервола ipfw (для локально сгенеренного трафика естественно). Я не очень много пользовался ипитаблес, но гугль говорит, что можно вот так вот http://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html. сотвественно это не на рутере, а на самом веб сервере.

 

Время начала потока Вы знаете. Возьмите апачевые логи за минуту, когда началось и посмотрите что там есть. Глазами. Возьмите другое начало, посмотрите там. Да муторно, но я находил закладку в сайте у хостера так. Можно потихоньку отфильтровывать нормальные запросы, картинки, еще чтото. Сначала гляньте POSTы. Запрос может оказаться вообще 1 для запуска. Тех что много - скорее всего не интересны.

 

чтото типа...

egrep '\[16\/Mar\/2012\:19\:34' log/httpd-access.log | awk  '{ print $6 " " $7  }' | sort | uniq -c

 

(6 и 7 отрихтовать по месту)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пошуршал в логах.. Кое-что нашел, но думаю, это не оно. Вот за минуту до "шторма" один наш китайский товариСЧ пытался что-то наваять в гостевую сайта (но не того, который я подозреваю!)

222.197.190.74 - - [14/Mar/2012:03:52:53 +0400] "GET /index.php HTTP/1.0" 200 10838 "http://mysyte.ru/index.php" 
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) ::ELNSB50::000061100320025802a00111000000000507000900000000"
222.197.190.74 - - [14/Mar/2012:03:53:16 +0400] "GET /index.php?nma=guestbook&fla=index HTTP/1.0" 200 14363 
"http://mysyte.ru/index.php?nma=guestbook&fla=index" 
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) ::ELNSB50::000061100320025802a00111000000000507000900000000"
222.197.190.74 - - [14/Mar/2012:03:53:39 +0400] "GET /index.php?nma=guestbook&fla=add HTTP/1.0" 200 26565 
"http://mysyte.ru/index.php?nma=guestbook&fla=add" 
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) ::ELNSB50::000061100320025802a00111000000000507000900000000"
222.197.190.74 - - [14/Mar/2012:03:54:02 +0400] "POST /index.php?nma=guestbook&fla=add HTTP/1.0" 200 26728 
"http://mysyte.ru/index.php?nma=guestbook&fla=add" 
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) ::ELNSB50::000061100320025802a00111000000000507000900000000"

Скорее всего это ему не удалось, т.к. в гостевой есть защита от записи, если IP отправителя не резолвится в имя (у него точно не отрезолвилось, проверял).

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

Если через два-три дня не объявится, значит засада живет в том сайте, который временно "спрятал".

 

P.S. st_re, кстати, ваша ссылка не рабочая

Page Not Found (Error 404)
The requested URL was not found on this server. The web page you were attempting to view may not exist 
or may have moved - try checking the web address for typos.

 

P.P.S. Нашел в iptables критерий "owner". Наверное будет логичнее использовать ключ не uid, а sid, т.к. апач (родитель) стартует от root, а "детки" от apache и однозначно запретить апачу udp по uid вряд ли получится. А вот по sid вроде как самое то.

--sid-owner
Пример	iptables -A OUTPUT -m owner --sid-owner 100
Описание	Производится проверка Session ID пакета. Значение SID наследуются дочерними процессами от "родителя", 
так, например, все процессы HTTPD имеют один и тот же SID (примером таких процессов могут служить HTTPD Apache и Roxen)

Упс.. Получил отлуп от установленного iptables 1.4.8 - нет в нем ключа --sid-owner.. Устарела видимо опция.. Остались только uid-owner, gid-owner, да еще добавился непонятный socket-exists..

Ну и до кучи оказалось, что ядро собрал без "XT_MATCH_OWNER".. Либы есть, а модуль ядра увы...

Так-что пока подожду с запретом udp. Кстати, есть сомнение - если запретить апачу udp, не повлияет ли это на нормальное функционирование сервиса?

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если запретить апачу udp, не повлияет ли это на нормальное функционирование сервиса?

Не повлияет.

У Вас вообще UDP-сервисы есть?

"netstat -nulp" что говорит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У Вас вообще UDP-сервисы есть?

"netstat -nulp" что говорит?

UDP сервисы есть. Как уже писал, это игровые сервера. Ну и системные службы.

netstat -nulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
udp        0      0 0.0.0.0:2049                0.0.0.0:*                               -
udp        0      0 192.168.33.1:27015          0.0.0.0:*                               7574/hlds_i686
udp        0      0 192.168.33.1:27016          0.0.0.0:*                               7564/hlds_i686
udp        0      0 192.168.33.1:27017          0.0.0.0:*                               7570/hlds_i686
udp        0      0 0.0.0.0:57485               0.0.0.0:*                               -
udp        0      0 0.0.0.0:786                 0.0.0.0:*                               3153/rpc.rquotad
udp        0      0 0.0.0.0:28960               0.0.0.0:*                               7578/cod4_lnxded
udp        0      0 0.0.0.0:161                 0.0.0.0:*                               16688/snmpd
udp        0      0 0.0.0.0:810                 0.0.0.0:*                               3178/rpc.mountd
udp        0      0 0.0.0.0:10800               0.0.0.0:*                               8149/nfsuserver
udp        0      0 192.168.33.1:16567          0.0.0.0:*                               7542/bf2
udp        0      0 0.0.0.0:29900               0.0.0.0:*                               7542/bf2
udp        0      0 0.0.0.0:55124               0.0.0.0:*                               7542/bf2
udp        0      0 0.0.0.0:55125               0.0.0.0:*                               7542/bf2
udp        0      0 192.168.33.1:6112           0.0.0.0:*                               7524/bnetd
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               2998/portmap
udp        0      0 XX.XX.XX.XY:123             0.0.0.0:*                               3132/ntpd
udp        0      0 XX.XX.XX.XZ:123             0.0.0.0:*                               3132/ntpd
udp        0      0 192.168.33.1:123            0.0.0.0:*                               3132/ntpd
udp        0      0 10.254.213.5:123            0.0.0.0:*                               3132/ntpd
udp        0      0 127.0.0.1:123               0.0.0.0:*                               3132/ntpd
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               3132/ntpd

Запретить UDP апачу можно конечно (по GID-у, т.к. SID упразднили в iptables), но во-первых, есть ли смысл? А во-вторых, как уже писал, без пересборки ядра, такой финт ушами на этом сервере не прокатит. Нужно ли оно вообще? Хотелось бы изловить врага и поставить заслон, и лечить причину, а не последствия..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А может тупо сделать листинг всех файлов сайтов по дате? по идее всплывут файлы, недавно исправленные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может там руткит?

Что-то типа того.

Через известную дыру в движке е107 (файлик contact.php), неизвестный доброжелатель заливал на сервак php и perl скрипты, которые использовали мою машину в качестве генератора DDoS.

"Стартер" и "коммандер" располагаются похоже на irc чате newiss-trynitynetwork.net. Оттуда по-видимому и поступают данные о новой жертве, ну и собственно запуск флудера с атакующих машин.

В схеме я возможно и ошибся. Предположение сделал на основе анализа текста заливаемых скриптов, но суть вообщем понятна.

Кстати, скрипты каждый раз разные по содержанию.

Вообщем, дырку залатал, сплю спокойно, по утрам в логе апача читаю свежие вумные скрипты. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.