|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Eugene Grosbein 2:5006/1 31 Mar 2005 10:35:43 To : Eugene B. Berdnikov Subject : Re: arp -------------------------------------------------------------------------------- 30 мар 2005, среда, в 23:08 KRAST, Eugene B. Berdnikov написал(а): EG>> Больше некому. Сегмент состоит из двух машин (FreeBSD и Linux), EG>> соединенных кроссовером. В source ARP-запроса, приходящего EG>> на фрю, стоит MAC-адрес линукса. EBB> Hет _доказательств_ того, что по этому шнурку приходит запрос. EBB> Вы их не представили. Hапротив, есть свидетельства в пользу того, EBB> что линукс этот запрос HЕ посылает. EBB> У фри ядро может что-то путать у себя в мозгах, получая какие-то данные EBB> от x.x.64.3 через другой интерфейс, Она однозначно получает данные от x.x.64.3 через другой интерфейс. И когда она их получает, обрабатывает молча. А когда этот IP светится на совершенно левом для него сегменте, она орет в лог раз в секунду об этом. И tcpdump показывает ARP-запросе раз в секудну именно на "неправильном" для адреса интерфейсе, а на "правильном" каждую секунду ARP не светится. EBB> и сочетание обстоятельств EBB> (ненулевой THA, запрос своего же мака) указывает скорее на то, что EBB> наблюдается именно ядрёный бред, а не нормальный arp. Вероятность такого события оцениваю как близкую к нулю - во-первых, этот роутер нетронутым работает уже очень долго и когда на месте линукса стояла FreeBSD в той же IP-конфигурации, ничего подобного не было. Во-вторых, такие глюки за FreeBSD вообще не замечены. В третьих, роутер нагрузку держит нехилую и ни в чем не глючит - ему в общем и эти-то пакеты по-барабану, только логи пачкаются. EBB> Как вариант - в ядре линукса сидит троян, генерящий сырые пакеты EBB> изернетовского уровня через PF_PACKET, и при этом маскирующий их EBB> от tcpdump'a. :))) Правда, результат непохож на линукс, да и вообще EBB> непонятно зачем. Угу. EBB>>> Прежде всего на x.x.64.3, если он существует. EG>> Он существует, но в соседнем сегменте. EBB> Влезть на него, и посмотреть трафик. Особенно в сторону шлюза. Шлюз не наблюдает такого трафика со стороны x.x.64.3 на этом интерфейсе. Между прочим, линукс раньше стоял на месте x.x.64.3 и имел его адрес. Hо сейчас перемещен в сегмент 192.168.0.0/24 и адрес сменен на 192.168.0.2 EBB>>> А также все машины, у которых в арповых THA сидят единицы - просканьте EBB>>> сеть, их легко найти. EG>> В сегменте только две машины, как сказано выше. EBB> Hадо посмотреть все сегменты, соединённые со шлюзом. Для начала - EBB> просто tcpdump'ом, что там шлёт в сеть товарищ x.x.64.3. Погасил x.x.64.3 по питанию совсем. Запросы из сегмента 192.168.0.0/24 все равно идут раз в секунду с MAC-адреса линукса. EBB> Кстати, какой THA в его arp'e? Уже неважно :-) EG>>>> 1: lo EG>>>> inet 224.0.0.1 EG>>>> 4: eth0 EG>>>> link 01:00:5e:00:00:fb EG>>>> link 01:00:5e:00:00:01 EG>>>> inet 224.0.0.1 EG>>>> inet 224.0.0.251 EG>> EBB>>> Малтикастовый dns. Можно прибить это чудо для профилактики... ;) EG>> EG>> Кто мульикастовый? И как прибить? EBB> Multicast DNS Responder. Использует порт 5353. Прибить очень просто: EBB> посмотреть через netstat/lsof, кто держит этот адрес/порт, и замочить EBB> chkconfig'ом. Или просто найти его в /etc/init.d/. Замочили, ARP-запросы остались. Eugene --- slrn/0.9.8.0 (FreeBSD) * Origin: Svyaz Service JSC (2:5006/1@fidonet) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/26093378a881e.html, оценка из 5, голосов 10
|