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)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор