AlKov Опубликовано 27 февраля, 2012 (изменено) · Жалоба Есть роутер на CentOS 5, на котором выпускаем народ в Интернет (NAT). С недавнего времени на нём завелся какой-то гад, который периодически (хаотично) вызывает громадный всплеск (практически во всю ширину аплинка) исходящего трафика. Длится эта мерзость практически всегда около 3-х минут (см. рис.), может быть один раз в сутки, может два-три. В это же время ровно на этот же период подскакивают pps и загрузка проца. Между "всплесками" никакого постоянства.. В логах машины ни единого намёка.. Генератором этой гадости явно является роутер, т.к. в моменты всплеска трафика и ппс на подключённых к нему NAS-ах наблюдается небольшой провал как исходящего, так и входящего трафика. Соответственно появилось непреодолимое желание, узнать фамилию это гада (процесса). Вопрос - как реализовать попроще? Изменено 27 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 февраля, 2012 · Жалоба А при чём тут процесс? Может это просто кто-то прокачивает много трафика? Сделайте небольшой костыль такого плана: если скорость превышает XXX Мбит/с, то запускаете tcpdump на 5 секунд или с помощью iptables сливаете весь трафик в ULOG. И поставьте такой скриптик в крон * * * * * Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 · Жалоба А при чём тут процесс? Может это просто кто-то прокачивает много трафика? Почему именно процесс? Да потому-что если бы это был кто-то из пользователей, то на NAS-ах в этот момент был бы аналогичный рост, а там как раз наоборот - провал, причём очень незначительный. Ну как будьто на аплинке полка (собственно так оно и получается, только на исходящем трафе). Напрямую в Интернет никто попасть не может, только через NAS-ы. Сделайте небольшой костыль такого плана: если скорость превышает XXX Мбит/с, то запускаете tcpdump на 5 секунд или с помощью iptables сливаете весь трафик в ULOG. И поставьте такой скриптик в крон * * * * * А если отслеживать по всплеску загрузки процессора и вылавливать топовый процесс? Непонятно только с помощью чего мониторить проц. и как ухватить именно всплеск загрузки.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_INF_ Опубликовано 27 февраля, 2012 · Жалоба Подключить Epel. Затем yum install nethogs и собственно запуск nethogs eth0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 · Жалоба Подключить Epel. Затем yum install nethogs и собственно запуск nethogs eth0 И как этим воспользоваться? Сидеть пялиться в монитор? Да и вывод у софтины совсем не информативный.. NetHogs version 0.7.snapshot PID USER PROGRAM DEV SENT RECEIVED 0 root ..1:62274-74.125.168.182:80 0.000 1.944 KB/sec 0 root ..49.42:2144-85.94.1.229:80 0.000 1.699 KB/sec 0 root ...225:80-XX.XX.XX.41:65255 0.000 1.513 KB/sec 0 root ..8.248:80-XX.XX.XX.42:3705 0.000 1.446 KB/sec 0 root ..2.19:80-XX.XX.XX.42:49982 0.000 1.413 KB/sec 0 root ...106:80-XX.XX.XX.42:56843 0.000 1.391 KB/sec PID-а нет, IP тоже ни о чём (ХХ.ХХ.ХХ - это мои НАТ IP). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apm Опубликовано 27 февраля, 2012 · Жалоба Сходу не соображу насчет pid Да и чем он поможет если процесс уже завершится к моменту когда вы доберетесь. Но может от характера трафика плясать? я б начал с анализа netflow файлов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 (изменено) · Жалоба Сходу не соображу насчет pid Да и чем он поможет если процесс уже завершится к моменту когда вы доберетесь. По PID можно будет вычислить имя процесса. И почему процесс уже завершится? 3 мин. не так уж и мало, чтобы изловить процесс. Не ручками конечно же, а скриптом. Вопрос только в том, за что зацепиться.. Кстати, еще раз сделаю акцент на этот факт. Практически почти всегда всплеск имеет одну и ту же продолжительность - около 3 мин. И максимум практически всегда равен ширине аплинка. Но может от характера трафика плясать? я б начал с анализа netflow файлов netflow собираются на NAS-ах, на роутере нет коллектора. P.S. Кстати, может я не на той "стороне" копаю? Аплинк, или коммутатор (DGS-3100), в который включен роутер, не могут являться "инициаторами" проблемы? Изменено 27 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 27 февраля, 2012 · Жалоба Какаянить хрень типа atop там у Вас собирается/есть ? Умеет писать логи с нужной переодичностью, в том числе по сетевой активности. Вообще трафик бы снять, да глянуть, че там такое интересное прет. Трафик на порту коммутатора снять можно ? Там оно тоже есть ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 27 февраля, 2012 · Жалоба Правильно пишут, снимите нетфлоу прямо на шлюзе, и проанализируйте всплеск. Потом отключите сбор... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 (изменено) · Жалоба Какаянить хрень типа atop там у Вас собирается/есть ? Умеет писать логи с нужной переодичностью, в том числе по сетевой активности. "Хрень типа atop" собралась. :) Еще бы кто подсказал, как ей пользоваться. ;) Самостоятельно, думаю, придется долго изучать.. Вообще трафик бы снять, да глянуть, че там такое интересное прет. Трафик на порту коммутатора снять можно ? Там оно тоже есть ? Да, на порту коммутатора, смотрящему непосредственно в аплинк, картина один в один. А вот насчет снять траф с порта пока проблематично - нет свободного порта, куда можно зеркалировать траф. Все забито под завязку.. :( Да и свободной машинки с гиговым портом, куда можно было бы сливать траф, пока тоже нет.. Правильно пишут, снимите нетфлоу прямо на шлюзе, и проанализируйте всплеск. Потом отключите сбор... Надо подумать.. Хотелось бы "малой кровью" обойтись, да видимо, не судьба.. Изменено 27 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 27 февраля, 2012 · Жалоба Запустить типа: /usr/local/bin/atop -w /opt/atop/atop_20120227 1 потом посмотреть, кусок из мана: View the contents of the standard logfile of 2012, Feb 27 from 02:00 PM onwards interactively: atop -r 20120227 -b 14:00 и там нажать n Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 (изменено) · Жалоба Запустить типа: /usr/local/bin/atop -w /opt/atop/atop_20120227 1 потом посмотреть, кусок из мана: View the contents of the standard logfile of 2012, Feb 27 from 02:00 PM onwards interactively: atop -r 20120227 -b 14:00 и там нажать n ОК. Попробуем.. Осталась пара вопросов - сколько Гб на диске может "нагенерить" atop хотя бы за 12 час.? И второе - поигрался чутка, все вроде более-менее понятно. НО! На "буковку" n софтина матюгнулась No kernel-patch installed; request ignored! Ядро патчить совсем нет желания.. :( Изменено 27 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 27 февраля, 2012 · Жалоба тоды ой.. но хотябы можно посмотреть, кто грузил проц, память, диск в тоже время.. логи занимают копейки. Трафик надо снять, конечно :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 февраля, 2012 · Жалоба Ну что ж, попробую для начала посмотреть, что запишет atop. Если не поможет, запущу сбор нетфлоу непосредственно на роутере, все необходимое (fprobe и flowtools) вроде установилось без проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 28 февраля, 2012 (изменено) · Жалоба Зацепил atop-ом нужный момент.. ATOP - bras 2012/02/28 04:25:54 ------ 1s elapsed PRC | sys 1.04s | user 0.00s | #proc 122 | #trun 2 |1#tslpi 134 | #tslpu 0 | #zombie 0 | clones 0 | | #exit 0 | CPU | sys 23 | user 0% | irq 138% | idle 263% | wait 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 100% | idle 0% | cpu002 w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 20% | idle 80% | cpu000 w 00 | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 1% | user 0% | irq 16% | idle 83% | cpu0030w 01 | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 1% | user 0% | irq 3% | idle 96% | cpu001 w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | CPL | avg1 0.35 | avg5 0.11 | | avg15 0.03 | | csw 162555 | intr 10329 | | | numcpu 4 | MEM | tot 5.8G | free 4.6G | cache 467.7M | dirty 0.0M | buff 314.9M | slab 226.3M | | | | | SWP | tot 11.7G | free 11.7G | | | | | | | vmcom 274.8M | vmlim 14.6G | NET | transport | tcpi 0 | tcpo 0 | udpi 13 | udpo 8 | tcpao 0 | tcppo 0 | tcprs 0 | tcpie 0 | udpip 0 | NET | network | ipi 93756 | ipo 31144 | ipfrw 31136 | deliv 13 | | | | icmpi 0 | icmpo 0 | NET | eth3 154% | pcki 151462 | pcko 30166 | si 1544 Mbps | so 292 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | eth2 118% | pcki 33495 | pcko 118932 | si 297 Mbps | so 1181 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | vlan10 78% | pcki 77244 | pcko 14863 | si 784 Mbps | so 144 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | vlan9 59% | pcki 16514 | pcko 59779 | si 145 Mbps | so 597 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | PID PPID RUID RGID EUID EGID SUID SGID FSUID FSGID STDATE STTIME ENDATE ENTIME ST EXC S CPU CMD 1/1 8 2 root root root root root root root root 2012/02/19 06:28:00 active active -- - R 100% ksoftirqd/2 10 2 root root root root root root root root 2012/02/19 06:28:00 active active -- - S 2% ksoftirqd/3 13392 13309 root root root root root root root root 2012/02/27 23:53:07 active active -- - R 1% atop 6 2 root root root root root root root root 2012/02/19 06:28:00 active active -- - S 1% ksoftirqd/1 Где и что произошло, понятно. А вот что явилось инициатором, не пойму.. Правда, где-то секунд за 30 "до того как" замечена повышенная активность snmpd и куча непонятных процессов без PID. По snmp к роутеру ходит cacti и дополнительно php скриптом снимает кол-во conntrack с NAT-а. Но всё это крутится постоянно, раз в минуту, не вызывая проблем. PID PPID RUID RGID EUID EGID SUID SGID FSUID FSGID STDATE STTIME ENDATE ENTIME ST EXC S CPU CMD 1/2 9660 1 root root root root root root root root 2012/02/25 22:39:58 active active -- - S 24% snmpd 8 2 root root root root root root root root 2012/02/19 06:28:00 active active -- - S 2% ksoftirqd/2 ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 255 E 2% <sshd> 13392 13309 root root root root root root root root 2012/02/27 23:53:07 active active -- - R 1% atop 4 2 root root root root root root root root 2012/02/19 06:28:00 active active -- - S 1% ksoftirqd/0 4105 2 root root root root root root root root 2012/02/19 06:29:11 active active -- - S 1% kipmi0 ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 1 E 1% <modprobe> 4222 1 root root root root root root root root 2012/02/19 06:29:14 active active -- - S 0% sshd ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <khelper> ? sshd sshd - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <sshd> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <dircolors> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 1 E 0% <grep> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 1 E 0% <grep> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <id> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <grep> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <grep> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <consoletype> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <pkg-config> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <bash> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 1 E 0% <grep> ? root root - - - - - - 2012/02/28 04:25:05 2012/02/28 04:25:05 NE 0 E 0% <id> Попробую проверить кактусовые скрипты и конфиг самого snmpd. На одном из NAS-ов экспериментировал с прикручиванием "своего" OID для получения данных с ng интерфейсов. Может там где-то накосячил.. Изменено 28 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 28 февраля, 2012 · Жалоба ну SNMP может оказаться пострадавшим. Типа такая реакция на что то еще, что он там мониторит. процессы без ID, скорее всего скрипт какой то работал, что то делал процессы быстро рождались и умирали, атоп не успел PIDы снять,. судя по наличию в тоже время sshd, зашло чтото по ssh, чтото сделало и отвалило.. 4.25 никакие ночные работы не зашедулены в это время там у Вас ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 28 февраля, 2012 (изменено) · Жалоба ну SNMP может оказаться пострадавшим. Типа такая реакция на что то еще, что он там мониторит. процессы без ID, скорее всего скрипт какой то работал, что то делал процессы быстро рождались и умирали, атоп не успел PIDы снять,. судя по наличию в тоже время sshd, зашло чтото по ssh, чтото сделало и отвалило.. Да, скорее всего snmpd и sshd здесь не при делах. 4.25 никакие ночные работы не зашедулены в это время там у Вас ? Нет, на роутере вообще нет никаких "личных" расписаний, только стандартные системные. Да и время проблемы всегда разное - может быть и днём и вечером и ночью, и вообще раза три за сутки. А вот продолжительность, что интересно, практически всегда около 3 мин.. Обратил внимание вот еще на что - собственно проблема начинается с "выброса" трафика на vlan10 (на нем NAT IP, 3шт.) ATOP - bras 2012/02/28 04:25:34 ------ 1s elapsed PRC | sys 1.06s | user 0.00s | #proc 122 | #trun 3 |2#tslpi 133 | #tslpu 0 | #zombie 0 | clones 0 | | #exit 0 | CPU | sys 62 | user 1% | irq 141% | idle 253% | wait 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 100% | idle 0% | cpu003 w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 5% | user 0% | irq 20% | idle 75% | cpu0010w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 18% | idle 82% | cpu000 w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 1% | user 1% | irq 6% | idle 93% | cpu0022w 0% | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | CPL | avg1 0.10 | avg5 0.05 | | avg15 0.01 | | csw 489544 | intr 10381 | | | numcpu 4 | MEM | tot 5.8G | free 4.6G | cache 467.6M | dirty 0.1M | buff 314.9M | slab 226.5M | | | | | SWP | tot 11.7G | free 11.7G | | | | | | | vmcom 274.8M | vmlim 14.6G | NET | transport | tcpi 0 | tcpo 0 | udpi 8 | udpo 8 | tcpao 0 | tcppo 0 | tcprs 0 | tcpie 0 | udpip 0 | NET | network | ipi 87874 | ipo 32779 | ipfrw 32771 | deliv 8 | | | | icmpi 0 | icmpo 0 | NET | vlan10 70% | pcki 71124 | pcko 15230 | si 705 Mbps | so 133 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | eth3 65% | pcki 80270 | pcko 36844 | si 654 Mbps | so 323 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | vlan9 58% | pcki 16752 | pcko 59301 | si 134 Mbps | so 586 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | eth2 56% | pcki 41399 | pcko 68040 | si 328 Mbps | so 560 Mbps | coll 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | PID SYSCPU USRCPU VGROW RGROW RUID EUID THR ST EXC S CPU CMD 1/1 10 0.98s 0.00s 0K 0K root root 1 -- - R 96% ksoftirqd/3 6 0.08s 0.00s 0K 0K root root 1 -- - R 8% ksoftirqd/1 14347 0.00s 0.00s 0K 0K root root 1 -- - S 0% httpd 13392 0.00s 0.00s 0K 0K root root 1 -- - R 0% atop 4677 0.00s 0.00s 0K 0K root root 1 -- - S 0% upsd 4105 0.00s 0.00s 0K 0K root root 1 -- - S 0% kipmi0 Ну а дальше по нарастающей. Есть подозрение, что возникает петля на этих IP. Дело в том, что провом нам выделена /30 "опорная подсеть" и /23 маршрутизируемая подсеть. Последняя порезана на несколько более мелких подсетей. /24 - для пользователей (выдается /32 по PPTP) и вторая /24 порезана на 4 части, в одну из которых и входят 3 NAT IP, назначенные на vlan10. /30 назначена на vlan9. Все IP из /23 выпускаем через шлюз на /30 (vlan9). Т.е. default gateway на роутере - IP прова из "опорной" подсети. На роутере крутится quagga (zebra и ripd), "собирающая" маршруты с NAS-ов. Может здесь что-то "закольцовывается"? P.S. Наверное все же придётся анализировать трафик, чтобы понять, что, откуда и куда ломится. Буду запускать сбор netflow на роутере. Изменено 28 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 2 марта, 2012 · Жалоба Поигрался с прерываниями (вот тут).. Сутки прошли спокойно, при макс. загрузке (~ 550Мбит/65Kpps) проц(Ы) выше 60% (одна пара ядер) не перескакивали. И вот... Сегодня снова посреди ночи вылезло... :( Установил сбор netflow - ipt_netflow(сенсор)+flow-tools(коллектор), файлики пишутся, обрабатываю их в формате "unix_secs|doctets|srcaddr|dstaddr|srcport|dstport|prot" . Выглядит вот так #:unix_secs,doctets,srcaddr,dstaddr,srcport,dstport,prot 1330672576,557,94.100.178.238,172.18.17.79,2041,1445,6 1330672576,93,172.18.13.253,46.237.39.71,40686,25161,17 1330672576,129,95.188.68.76,217.150.45.209,40254,35691,17 1330672576,120,195.191.79.13,172.18.10.237,61425,2389,6 1330672576,882,109.64.228.112,172.17.7.221,16178,62343,17 Теперь вопрос - вот ОНО случилось и... Как из нужного блока (выбираем по времени проблемы) вытащить мерзавца? Ведь даже за 3-5 мин. при трафике в 500М эта табличка будет весьма солидного размера. И в ней вместе с "генератором проблемы" будет присутствовать и "легальный" трафик. Как логичнее зацепиться за нужное? Группировать по srcaddr/doctets и смотреть по большому doctets за единицу времени? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 2 марта, 2012 · Жалоба наверное суммировать вторую колонку по 3 и 4. и найти top этого хитпарада ? . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 2 марта, 2012 · Жалоба Судя по man flow-tools, выловить IP с топовой загрузкой можно с помощью flow-report. Но в нем столько опций... Хватит выкуривать на неделю.. :( Может есть у кого готовый примерчик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redhat.ua Опубликовано 5 марта, 2012 (изменено) · Жалоба На всякий случай проверьтесь http://www.howtoforge.com/sophos-linux-rst-b-backdoor-detection-tool-debian-etch Изменено 5 марта, 2012 пользователем redhat.ua Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 5 марта, 2012 · Жалоба На всякий случай проверьтесь http://www.howtoforge.com/sophos-linux-rst-b-backdoor-detection-tool-debian-etch #chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found ........ Checking `OSX_RSPLUG'... not infected Скорее всего проблема либо в железе, либо (что наиболее вероятно) в кривых ручонках.. И как это не прискорбно, в моих, горячо любимых. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 14 марта, 2012 · Жалоба # iptables -I OUTPUT -o eth0 -m state --state NEW -j LOG С роутера не должно устанавливаться много соединений во внешний мир, легко будет засечь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 15 марта, 2012 · Жалоба Да уже засёк.. Вычислить удалось только машину источник и IP получателя. Полтора Гб udp за 3-5 мин. "Спамит" мой же сервак.. :( А вот чтО конкретно запускает этот "генератор", вычислить пока не могу. На машине два сайта, почта и несколько закрытых в Мир локальных гейм-серверов. Более подозреваю все же web, т.к. в январе этого года из-за "дыры" в коде, на один из сайтов залили нехилый эксплойт, который по утверждению Cyveillance SecFraud, ломился на один из банков ЮАР. Ну и в atop-е во время "слива" вверху висит httpd. Левый код, который был явно виден, я удалил, "дыру" убрал, но возможно все же что-то осталось. Что примечательно - слив идет только по udp и адреса получателей между перерывами разные. Т.е. например, два дня подряд льется на один IP, далее пауза два-три дня, в следующий раз другой IP. Пока тупо удалил этот сайт, "сторожа" оставил, жду результатов.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 15 марта, 2012 · Жалоба Ос на вебе какая ? Зарежте фаерволом пользователю от которого ходит httpd udp совсем, если оно умеет по пользователям. ну и искать запросы сразу ПЕРЕД началом проблемы в логах. Пускач должен же быть... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...