AlKov Опубликовано 4 ноября, 2009 (изменено) · Жалоба Есть сеть из порядка 1300 юзеров, состоящая из 3-х сегментов. Самый крупный - около 1200 юзеров находится за DOCSIS CMTS (в режиме рутера), "остатки" разбросаны частично через WI-FI и частично ethernet. Все подсети (IP диапазоны не пересекаются) сходятся в софтовый рутер на Linux. На нем же DHCP, DNS, Border. Суть проблемы: периодически наблюдаю на рутере ситуацию, схожую с arp spoofing. Выглядит это следующим образом - начинается сканирование всех подсетей последовательным перебором IP. arp -an в это время сообщает: ? (10.0.193.89) at <incomplete> on vlan101 ? (10.0.193.12) at <incomplete> on vlan101 ? (10.0.193.102) at <incomplete> on vlan101 ? (10.0.192.202) at <incomplete> on vlan101 ? (10.0.193.59) at <incomplete> on vlan101 ? (10.0.192.133) at <incomplete> on vlan101 ? (10.0.193.93) at <incomplete> on vlan101 ? (10.0.192.63) at <incomplete> on vlan101 ? (10.0.193.40) at <incomplete> on vlan101 ? (10.0.193.104) at <incomplete> on vlan101 ? (10.0.145.166) at <incomplete> on eth6 ? (10.0.145.175) at <incomplete> on eth6 ? (10.0.145.180) at <incomplete> on eth6 ? (10.0.193.43) at <incomplete> on vlan101 ? (10.0.193.146) at <incomplete> on vlan101 ? (10.0.193.205) at <incomplete> on vlan101 ? (10.0.192.166) at <incomplete> on vlan101 ? (10.0.192.139) at <incomplete> on vlan101 ? (10.0.193.190) at <incomplete> on vlan101 ? (10.0.193.96) at <incomplete> on vlan101 ? (10.0.145.132) at <incomplete> on eth6 ? (10.0.192.124) at <incomplete> on vlan101 ? (10.0.193.36) at <incomplete> on vlan101 ? (10.0.193.113) at <incomplete> on vlan101 Смотрю tcpdump-ом интерфейс, на котором подняты сканируемые vlan-ы 12:31:29.359331 arp who-has 10.0.193.215 tell 10.0.192.1 12:31:29.359348 arp who-has 10.0.193.217 tell 10.0.192.1 12:31:29.359356 arp who-has 10.0.193.219 tell 10.0.192.1 12:31:29.859316 arp who-has 10.0.193.218 tell 10.0.192.1 12:31:29.859327 arp who-has 10.0.193.220 tell 10.0.192.1 12:31:29.863307 arp who-has 10.0.193.216 tell 10.0.192.1 12:31:30.359352 arp who-has 10.0.193.217 tell 10.0.192.1 12:31:30.359362 arp who-has 10.0.193.219 tell 10.0.192.1 12:31:30.359371 arp who-has 10.0.193.221 tell 10.0.192.1 12:31:30.859335 arp who-has 10.0.193.218 tell 10.0.192.1 12:31:30.859346 arp who-has 10.0.193.220 tell 10.0.192.1 12:31:30.859352 arp who-has 10.0.193.222 tell 10.0.192.1 12:31:31.359386 arp who-has 10.0.193.219 tell 10.0.192.1 12:31:31.359400 arp who-has 10.0.193.221 tell 10.0.192.1 12:31:31.359409 arp who-has 10.0.193.223 tell 10.0.192.1 Сей процесс "поддерживается" со стороны docsis сегмента (физическое отключение "шнурка" с CMTS процесс останавливает). Что примечательно, в это время на фейсе, смотрящем в сторону CMTS, arp активности не наблюдается и запущенная arpwatch никак не реагирует на это безобразие.. Вопрос - что это может быть и, самое главное, как вычислить "автора"? P.S. Есть подозрение на вирь arp8023.sys, но поведение как-то не очень похоже на него.. Второе подозрение пало на собственные "кривые ручки" в плане ошибки конфигурации DHCP. P.P.S. И еще раз самое непонятное - не могу определиться с методом поиска гаденыша.. Что и где смотреть/слушать, или хотя-бы, как блокировать? Изменено 4 ноября, 2009 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 4 ноября, 2009 · Жалоба имхо банальный скан сети, а не спуф Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
networks Опубликовано 4 ноября, 2009 · Жалоба Вирус kido может такое давать. Он же conficker. Зараженные машины сканят свою подсетку по порядочку арпами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 4 ноября, 2009 · Жалоба +1 за обычный скан сети. А рассылающий ARP 10.0.192.1 - это кто? Если кто-то неизвестный, найти его (можно попробовать по MAC'у). Если твой же сервер - шлюз для абонентов, то кто-то сканирует через него соседние подсети - посмотреть трафик на несуществующие ип. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 5 ноября, 2009 · Жалоба nmap -sP 10.0.193.1-254 + tcpdump будет аналогичная картина Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 7 ноября, 2009 (изменено) · Жалоба Провел "дополнительное следствие" - действительно, это скан. По всей сети бродят пинги на несуществующие IP. Но сканер явно вирь, т.к. валится сиё дерьмо одновременно не от одного десятка юзеров.. 16:46:50.948720 IP 10.0.132.87 > XXX.YYY.51.18: ICMP echo request, id 512, seq 51459, length 44 16:46:52.454140 IP 10.0.132.87 > XXX.YYY.51.19: ICMP echo request, id 512, seq 51971, length 44 16:46:53.951441 IP 10.0.132.87 > XXX.YYY.51.20: ICMP echo request, id 512, seq 52483, length 44 16:46:55.449614 IP 10.0.132.87 > XXX.YYY.51.21: ICMP echo request, id 512, seq 52995, length 44 16:46:56.955408 IP 10.0.132.87 > XXX.YYY.51.22: ICMP echo request, id 512, seq 53507, length 44 16:46:58.455832 IP 10.0.132.87 > XXX.YYY.51.23: ICMP echo request, id 512, seq 54019, length 44 Практически в то же самое время... 16:47:16.197304 IP 10.0.129.245 > XXX.YYY.63.14: ICMP echo request, id 512, seq 62728, length 44 16:47:17.692355 IP 10.0.129.245 > XXX.YYY.63.15: ICMP echo request, id 512, seq 63240, length 44 16:47:19.194653 IP 10.0.129.245 > XXX.YYY.63.16: ICMP echo request, id 512, seq 63752, length 44 16:47:20.807514 IP 10.0.129.245 > XXX.YYY.63.17: ICMP echo request, id 512, seq 64264, length 44 16:47:22.199496 IP 10.0.129.245 > XXX.YYY.63.18: ICMP echo request, id 512, seq 64776, length 44 16:47:23.706666 IP 10.0.129.245 > XXX.YYY.63.19: ICMP echo request, id 512, seq 65288, length 44 16:47:25.225829 IP 10.0.129.245 > XXX.YYY.63.20: ICMP echo request, id 512, seq 265, length 44 16:47:26.713884 IP 10.0.129.245 > XXX.YYY.63.21: ICMP echo request, id 512, seq 777, length 44 Что интересно, в то время когда один зас..нец сканит одну часть блока IP, другой сканит следующую.. И еще один не совсем понятный момент - если за сканируемый диапазон отвечает мой рутер, то он (рутер) почему-то овечает на "левый" запрос, несмотря на то, что icmp на рутере закрыт в iptables для этих подсетей политикой по умолчанию "DROP" цепочки "FORWARD" 19:49:10.777913 IP 10.0.132.147 > 10.0.194.121: ICMP echo request, id 512, seq 6254, length 44 19:49:10.788152 IP 10.255.255.254 > 10.0.132.147: ICMP host 10.0.194.119 unreachable, length 72 19:49:11.306745 IP 10.0.132.147 > AAA.BBB.107.122: ICMP echo request, id 512, seq 6510, length 44 19:49:12.280189 IP 10.255.255.254 > 10.0.132.147: ICMP host 10.0.194.120 unreachable, length 72 19:49:12.294827 IP 10.0.132.147 > 10.0.194.122: ICMP echo request, id 512, seq 6766, length 44 19:49:12.907739 IP 10.0.132.147 > AAA.BBB.107.123: ICMP echo request, id 512, seq 7022, length 44 19:49:13.779510 IP 10.0.132.147 > 10.0.194.123: ICMP echo request, id 512, seq 7278, length 44 10.255.255.254 - это рутер, ХХХ.YYY - префикс моей "белой" /23 подсети (63 - уже не моё), ААА.ВВВ - преф. подсети провайдера (у меня /30 из нее). Пробовал смакетировать ситуацию - "прикидывался" членом сети 10.0.132.0/22 и запускал ping -t 10.0.194.200..... - результат нулевой! Не реагирует рутер на меня, т.е. исправно дропает кривые пинги.. Вопрос, как всегда банальный - кто виноват и что делать?? Что это за вирь такой может быть и как с ним возможно побороться? Изменено 7 ноября, 2009 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...