forum.opennet.ru - "левые айпи в arp" (10)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"левые айпи в arp"

Форумы OpenNET: Виртуальная конференция (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"левые айпи в arp"		+/–
Сообщение от romeo (ok) on 05-Авг-09, 23:26
Доброго времени суток! есть шлюз на OpenSUSE 11.0 который раздает инет на 20 человек и вот периодически когда просматриваю arp вижу следующее: 10.25.122.235 (incomplete) eth1 10.44.78.116 (incomplete) eth1 10.0.0.2 ether 00:11:22:33:44:55 C eth1 10.71.51.240 (incomplete) eth1 10.62.77.244 (incomplete) eth1 10.22.248.249 (incomplete) eth1 10.42.38.45 (incomplete) eth1 10.0.0.10 ether 11:22:33:44:55:66 C eth1 10.62.51.34 (incomplete) eth1 10.44.36.249 (incomplete) eth1 10.44.44.238 (incomplete) eth1 10.0.0.3 ether 22:33:44:55:66:77 C eth1 10.23.19.105 (incomplete) eth1 10.62.14.252 (incomplete) eth1 10.23.8.242 (incomplete) eth1 10.44.46.197 (incomplete) eth1 10.71.15.21 (incomplete) eth1 10.24.44.251 (incomplete) eth1 10.71.61.55 (incomplete) eth1 10.71.92.58 (incomplete) eth1 10.44.41.223 (incomplete) eth1 10.44.46.230 (incomplete) eth1 10.0.0.5 ether 88:99:00:11:22:33 C eth1 10.62.44.15 (incomplete) eth1 10.44.8.36 (incomplete) eth1 10.23.77.251 (incomplete) eth1 10.26.30.196 (incomplete) eth1 10.44.46.235 (incomplete) eth1 10.0.0.7 ether 99:00:11:22:33:44 C eth1 10.26.50.116 (incomplete) eth1 10.23.48.194 (incomplete) eth1 10.24.41.247 (incomplete) eth1 10.24.203.234 (incomplete) eth1 10.71.18.232 (incomplete) eth1 10.44.79.232 (incomplete) eth1 10.22.185.169 (incomplete) eth1 10.71.40.13 (incomplete) eth1 10.22.172.242 (incomplete) eth1 10.61.12.11 (incomplete) eth1 10.21.154.241 (incomplete) eth1 10.71.43.20 (incomplete) eth1 10.26.60.245 (incomplete) eth1 10.25.36.252 (incomplete) eth1 10.21.91.254 (incomplete) eth1 10.0.0.3 ether 33:44:55:66:77:88 C eth1 10.71.51.250 (incomplete) eth1 10.62.3.223 (incomplete) eth1 10.25.146.247 (incomplete) eth1 10.24.70.240 (incomplete) eth1 10.62.7.35 (incomplete) eth1 10.0.0.12 ether 44:55:66:77:88:99 C eth1 10.0.0.14 ether 55:66:77:88:99:00 C eth1 10.23.49.151 (incomplete) eth1 10.21.138.241 (incomplete) eth1 10.51.19.253 (incomplete) eth1 10.24.91.254 (incomplete) eth1 10.24.65.250 (incomplete) eth1 10.0.0.20 ether 66:77:88:99:00:11 C eth1 10.22.41.236 (incomplete) eth1 10.21.92.252 (incomplete) eth1 10.62.44.247 (incomplete) eth1 10.0.0.6 ether 77:88:99:00:11:22 C eth1 реальные айпи и маки есть, но что значат вот этот список непонятных айпи, которые в сети не используются...? подскажите: как можно выловить что это и как с этим бороться?
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

левые айпи в arp, ze6ra, 14:26 , 06-Авг-09, (1)

левые айпи в arp, romeo, 12:46 , 10-Авг-09, (2)

левые айпи в arp, ze6ra, 13:17 , 10-Авг-09, (3)

левые айпи в arp, romeo, 13:25 , 10-Авг-09, (4)

левые айпи в arp, ze6ra, 13:55 , 10-Авг-09, (5)

левые айпи в arp, romeo, 00:18 , 11-Авг-09, (6)

левые айпи в arp, ze6ra, 10:11 , 11-Авг-09, (7)

левые айпи в arp, romeo, 12:25 , 11-Авг-09, (8)

левые айпи в arp, ze6ra, 13:21 , 11-Авг-09, (9)

левые айпи в arp, romeo, 13:41 , 11-Авг-09, (10)

Сообщения по теме [Сортировка по времени | RSS]

1. "левые айпи в arp" +/–

Сообщение от ze6ra (ok) on 06-Авг-09, 14:26

>Доброго времени суток!
>
>есть шлюз на OpenSUSE 11.0 который раздает инет на 20 человек
>
>реальные айпи и маки есть, но что значат вот этот список непонятных
>айпи, которые в сети не используются...?
>
>
>подскажите: как можно выловить что это и как с этим бороться?
incomplit значит был поллан arp запрос но ответ пока не получен.
это либо локальные процессы пытались обращаться по эти ip ну или кто то из клиентов если их маска подсети короче маски шлюза.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "левые айпи в arp" +/–

Сообщение от romeo (ok) on 10-Авг-09, 12:46

>incomplit значит был поллан arp запрос но ответ пока не получен.
>
>это либо локальные процессы пытались обращаться по эти ip ну или кто
>то из клиентов если их маска подсети короче маски шлюза.
может быть такой вариант, что у кого-то троян какой-то завелся или еще какая-нибудь гадость? которая сканит сеть?
потому как такой диапазон айпи у меня никогда не использовался
и хотелось бы отловить по чьей вине постоянно такое количество арп-запросов валится

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "левые айпи в arp" +/–

Сообщение от ze6ra (ok) on 10-Авг-09, 13:17

>>incomplit значит был поллан arp запрос но ответ пока не получен.
>>
>>это либо локальные процессы пытались обращаться по эти ip ну или кто
>>то из клиентов если их маска подсети короче маски шлюза.
>
>может быть такой вариант, что у кого-то троян какой-то завелся или еще
>какая-нибудь гадость? которая сканит сеть?
да троянов особо не надо скрипт на пару строк, да и  утилит полно что сканируют по диапазону IP. Наверное кто-то весьма любопытен.
>
>потому как такой диапазон айпи у меня никогда не использовался
>и хотелось бы отловить по чьей вине постоянно такое количество арп-запросов валится
>
tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и  какие пакеты на эти IP.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "левые айпи в arp" +/–

Сообщение от romeo (ok) on 10-Авг-09, 13:25

>tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и
>какие пакеты на эти IP.
попробую наверное wireshark
потому как по выводу tcpdumpa так и не понял кто генерит столько запросов

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "левые айпи в arp" +/–

Сообщение от ze6ra (ok) on 10-Авг-09, 13:55

>>tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и
>>какие пакеты на эти IP.
>
>попробую наверное wireshark
>потому как по выводу tcpdumpa так и не понял кто генерит столько
>запросов
arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным IP. (IP источника пославшего пакет).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "левые айпи в arp" +/–

Сообщение от romeo (ok) on 11-Авг-09, 00:18

>arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным
>IP. (IP источника пославшего пакет).
вот то что выловил через ethereal:
10.0.0.1 - айпи сервера
10.0.1.21 - айпи клиента
все остальные айпи левые
получается что все запросы в 3х пакетах были от одного и того же клиента? 10.0.1.21 ?
если я правильно понял вывод... осталось только выяснить что стоит у клиента и лупит столько запросов
No.     Time        Source                Destination           Protocol Info
   4562 4.414954    10.0.1.21             10.44.64.211          TCP      ssslic-mgr > 59574 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
Frame 4562 (62 bytes on wire, 62 bytes captured)
    Arrival Time: Aug 10, 2009 23:08:07.916380000
    [Time delta from previous captured frame: 0.001161000 seconds]
    [Time delta from previous displayed frame: 0.011635000 seconds]
    [Time since reference or first frame: 4.414954000 seconds]
    Frame Number: 4562
    Frame Length: 62 bytes
    Capture Length: 62 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp]
Ethernet II, Src: Foxconn_e6:81:78 (00:01:6c:e6:81:78), Dst: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
    Destination: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Foxconn_e6:81:78 (00:01:6c:e6:81:78)
        Address: Foxconn_e6:81:78 (00:01:6c:e6:81:78)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 10.0.1.21 (10.0.1.21), Dst: 10.44.64.211 (10.44.64.211)
Transmission Control Protocol, Src Port: ssslic-mgr (1203), Dst Port: 59574 (59574), Seq: 0, Len: 0
No.     Time        Source                Destination           Protocol Info
   4563 4.415064    EdimaxTe_b9:b1:32     Broadcast             ARP      Who has 10.44.64.211?  Tell 10.0.0.1
Frame 4563 (42 bytes on wire, 42 bytes captured)
    Arrival Time: Aug 10, 2009 23:08:07.916490000
    [Time delta from previous captured frame: 0.000110000 seconds]
    [Time delta from previous displayed frame: 0.011745000 seconds]
    [Time since reference or first frame: 4.415064000 seconds]
    Frame Number: 4563
    Frame Length: 42 bytes
    Capture Length: 42 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:arp]
    [Coloring Rule Name: ARP]
    [Coloring Rule String: arp]
Ethernet II, Src: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: ARP (0x0806)
Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    Sender MAC address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
    Sender IP address: 10.0.0.1 (10.0.0.1)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 10.44.64.211 (10.44.64.211)
No.     Time        Source                Destination           Protocol Info
   4564 4.415104    10.0.1.21             10.41.3.227           TCP      ssslog-mgr > 59039 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
Frame 4564 (62 bytes on wire, 62 bytes captured)
    Arrival Time: Aug 10, 2009 23:08:07.916530000
    [Time delta from previous captured frame: 0.000040000 seconds]
    [Time delta from previous displayed frame: 0.000040000 seconds]
    [Time since reference or first frame: 4.415104000 seconds]
    Frame Number: 4564
    Frame Length: 62 bytes
    Capture Length: 62 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp]
Ethernet II, Src: Foxconn_e6:81:78 (00:01:6c:e6:81:78), Dst: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
    Destination: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Foxconn_e6:81:78 (00:01:6c:e6:81:78)
        Address: Foxconn_e6:81:78 (00:01:6c:e6:81:78)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 10.0.1.21 (10.0.1.21), Dst: 10.41.3.227 (10.41.3.227)
Transmission Control Protocol, Src Port: ssslog-mgr (1204), Dst Port: 59039 (59039), Seq: 0, Len: 0

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "левые айпи в arp" +/–

Сообщение от ze6ra (ok) on 11-Авг-09, 10:11

>>arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным
>>IP. (IP источника пославшего пакет).
>
>вот то что выловил через ethereal:
>10.0.0.1 - айпи сервера
>10.0.1.21 - айпи клиента
>все остальные айпи левые
>получается что все запросы в 3х пакетах были от одного и того
>же клиента? 10.0.1.21 ?
Вообще-то только в двух arp запрос пошёл от вашего сервера
>если я правильно понял вывод... осталось только выяснить что стоит у клиента
>и лупит столько запросов
Да стоит глянуть машину клиента, чтото там не чисто.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "левые айпи в arp" +/–

Сообщение от romeo (ok) on 11-Авг-09, 12:25

>Вообще-то только в двух arp запрос пошёл от вашего сервера
>Да стоит глянуть машину клиента, чтото там не чисто.
от сервера? т.е. допускается вариант что и сервер сам еще сканит сеть?
если так, то что может генерить арп-запросы на сервере?
на сколько я знаю там стоит:
веб +мускл + фтп + днс + нтп + + DCHub + ntop (который только иногда я вручную запускаю посмотреть что на интерфейсах бегает) + nut (для снятия статистики с УПСа)
вот на всякий случай список процессов за исключением системных + тех которые я знаю, может здесь есть что-то подозрительное, что и генерит запросы, т.к. сервер достался от старого админа
кстати, есть какой-то процесс от ipaudit но в стартовых скриптах ничего подобного не нашел... не могу понять как он запускается и как стопается... кроме как в ручном режиме

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1433  0.0  0.1   2332  1068 ?        Ss   Apr21   4:22 /sbin/syslog-ng -a /var/lib/named/dev/log
root      1436  0.0  0.0   1800   544 ?        Ss   Apr21   0:00 /sbin/klogd -c 1 -x
100       1445  0.0  0.1   2412  1060 ?        Ss   Apr21   0:15 /bin/dbus-daemon --system
root      1455  0.0  0.0   1664   532 ?        Ss   Apr21   0:00 /sbin/acpid
root      1471  0.0  0.0   1916   672 ?        Ss   Apr21   0:00 /sbin/resmgrd
root      1503  0.0  0.2   7820  2220 ?        Ssl  Apr21   0:03 /usr/sbin/console-kit-daemon
101       1606  0.0  0.2   5736  2972 ?        Ss   Apr21   0:41 /usr/sbin/hald --daemon=yes
root      1607  0.0  0.1   3220  1072 ?        S    Apr21   0:00 hald-runner
root      1617  0.0  0.1   3332  1076 ?        S    Apr21   0:00 hald-addon-input: Listening on /dev/input/event3 /dev/input/event2 /dev/input/event1
101       1622  0.0  0.0   2204   948 ?        S    Apr21   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
postfix   1914  0.0  0.2   5996  2116 ?        S    09:54   0:00 smtp -t unix -u
bin       2706  0.0  0.0   1696   548 ?        Ss   Apr21   0:00 /sbin/portmap
root      2811  0.0  0.0  10248   688 ?        S<sl Apr21   0:02 /sbin/auditd -s disable
root      2815  0.0  0.0  10004   688 ?        S<sl Apr21   0:04 /sbin/audispd
avahi     2826  0.0  0.1   2876  1596 ?        Ss   Apr21   0:03 avahi-daemon: running [rol.local]
root      2842  0.0  0.0   1824   532 ?        Ss   Apr21   0:00 /usr/sbin/avahi-dnsconfd -D
root      2923  0.0  0.1   3424  2020 pts/1    S+   Apr21   0:00 /bin/bash
named     2956  0.0  3.6  65768 37800 ?        Ssl  Aug06   0:17 /usr/sbin/named -t /var/lib/named -u named
root      3749  0.0  0.0   2696   996 ?        S    11:16   0:00 /usr/sbin/cron
root      3871  0.0  0.2   6692  2564 ?        Ss   Apr21   0:00 /usr/sbin/cupsd
root      3949  0.0  0.1   5816  1752 ?        S    11:16   0:00 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t
root      3953  0.0  0.1   5808  1752 ?        S    11:16   0:00 /usr/sbin/postdrop -r
root      3954  0.0  0.1   6552  1764 ?        Ss   Apr21   1:05 /usr/lib/postfix/master
root      3995  0.0  0.0   2272   780 ?        Ss   Apr21   0:10 /usr/sbin/cron
root      4097  0.0  0.1   2764  1316 ?        S    11:16   0:00 /bin/sh /usr/sbin/rcntp ntptimeset
ntp       4105  0.0  0.1   4400  1620 ?        S    11:16   0:00 /usr/sbin/ntpd -g -u ntp:ntp -c /etc/ntp.conf -q
root      4228  0.0  0.0   1872   572 tty1     Ss+  Apr21   0:00 /sbin/mingetty --noclear tty1
root      9071  0.0  1.1  97412 11908 ?        Ss   Jul02   0:55 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
root     12420  0.0  0.0   3164   708 ?        Ss   Aug10   0:06 /usr/sbin/smpppd-ifcfg --up --rc -i ifcfg-dsl0
postfix  15825  0.0  0.2   6328  2744 ?        S    10:27   0:00 cleanup -z -t unix -u
root     16784  0.0  0.0   4988   712 ?        Ss   Jun29   0:46 /usr/local/bin/opendchub --help
root     16785  0.0  0.0   4988   756 ?        S    Jun29   0:44 /usr/local/bin/opendchub --help
postfix  20078  0.0  0.1   5836  1860 ?        S    10:37   0:00 pickup -l -t fifo -u
postfix  23955  0.0  0.2   5988  2068 ?        S    Aug06   0:02 qmgr -l -t fifo -u
root     29292  0.0  0.0   2692   980 ?        S    11:00   0:00 /usr/sbin/cron
ipaudit  29293  0.0  0.0      0     0 ?        Zs   11:00   0:00 [cron30min] <defunct>
ipaudit  29327  0.0  0.0   3024   476 ?        S    11:00   0:00 /bin/sh cron/cron30min
root     29328  0.0  0.2   5848  2144 ?        S    11:00   0:00 /home/ipaudit/bin/ipaudit -g /home/ipaudit/ipaudit-web.conf -o /home/ipaudit/data/30min/2009-
08-11-11:00.txt

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "левые айпи в arp" +/–

Сообщение от ze6ra (ok) on 11-Авг-09, 13:21

>
>>Вообще-то только в двух arp запрос пошёл от вашего сервера
>>Да стоит глянуть машину клиента, чтото там не чисто.
>
>от сервера? т.е. допускается вариант что и сервер сам еще сканит сеть?
>
>если так, то что может генерить арп-запросы на сервере?
Клиент попросил сервер передать пакет "левому ip" сервер увидев что ip назначения в одной подсети с сервером, делает arp запрос чтоб потом передать пакет. Нормальная в общем-то работа всех протоколов. Осталось разобраться зачем клиенту понадобилось обращаться к этому ip.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "левые айпи в arp" +/–

Сообщение от romeo (ok) on 11-Авг-09, 13:41

>Клиент попросил сервер передать пакет "левому ip" сервер увидев что ip назначения
>в одной подсети с сервером, делает arp запрос чтоб потом передать
>пакет. Нормальная в общем-то работа всех протоколов. Осталось разобраться зачем клиенту
>понадобилось обращаться к этому ip.
ясно - сенкс
пойду ловить клиента и узнавать, что у него там на машине происходит...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "левые айпи в arp"		+/–
Сообщение от ze6ra (ok) on 06-Авг-09, 14:26
>Доброго времени суток! > >есть шлюз на OpenSUSE 11.0 который раздает инет на 20 человек > >реальные айпи и маки есть, но что значат вот этот список непонятных >айпи, которые в сети не используются...? > > >подскажите: как можно выловить что это и как с этим бороться? incomplit значит был поллан arp запрос но ответ пока не получен. это либо локальные процессы пытались обращаться по эти ip ну или кто то из клиентов если их маска подсети короче маски шлюза.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "левые айпи в arp"		+/–
	Сообщение от romeo (ok) on 10-Авг-09, 12:46
	>incomplit значит был поллан arp запрос но ответ пока не получен. > >это либо локальные процессы пытались обращаться по эти ip ну или кто >то из клиентов если их маска подсети короче маски шлюза. может быть такой вариант, что у кого-то троян какой-то завелся или еще какая-нибудь гадость? которая сканит сеть? потому как такой диапазон айпи у меня никогда не использовался и хотелось бы отловить по чьей вине постоянно такое количество арп-запросов валится
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "левые айпи в arp"		+/–
	Сообщение от ze6ra (ok) on 10-Авг-09, 13:17
	>>incomplit значит был поллан arp запрос но ответ пока не получен. >> >>это либо локальные процессы пытались обращаться по эти ip ну или кто >>то из клиентов если их маска подсети короче маски шлюза. > >может быть такой вариант, что у кого-то троян какой-то завелся или еще >какая-нибудь гадость? которая сканит сеть? да троянов особо не надо скрипт на пару строк, да и утилит полно что сканируют по диапазону IP. Наверное кто-то весьма любопытен. > >потому как такой диапазон айпи у меня никогда не использовался >и хотелось бы отловить по чьей вине постоянно такое количество арп-запросов валится > tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и какие пакеты на эти IP.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "левые айпи в arp"		+/–
	Сообщение от romeo (ok) on 10-Авг-09, 13:25
	>tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и >какие пакеты на эти IP. попробую наверное wireshark потому как по выводу tcpdumpa так и не понял кто генерит столько запросов
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "левые айпи в arp"		+/–
	Сообщение от ze6ra (ok) on 10-Авг-09, 13:55
	>>tcpdump или wireshark должны помочь выяснить чья станция отправляет пакеты и >>какие пакеты на эти IP. > >попробую наверное wireshark >потому как по выводу tcpdumpa так и не понял кто генерит столько >запросов arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным IP. (IP источника пославшего пакет).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "левые айпи в arp"		+/–
	Сообщение от romeo (ok) on 11-Авг-09, 00:18
	>arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным >IP. (IP источника пославшего пакет). вот то что выловил через ethereal: 10.0.0.1 - айпи сервера 10.0.1.21 - айпи клиента все остальные айпи левые получается что все запросы в 3х пакетах были от одного и того же клиента? 10.0.1.21 ? если я правильно понял вывод... осталось только выяснить что стоит у клиента и лупит столько запросов No. Time Source Destination Protocol Info 4562 4.414954 10.0.1.21 10.44.64.211 TCP ssslic-mgr > 59574 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 4562 (62 bytes on wire, 62 bytes captured) Arrival Time: Aug 10, 2009 23:08:07.916380000 [Time delta from previous captured frame: 0.001161000 seconds] [Time delta from previous displayed frame: 0.011635000 seconds] [Time since reference or first frame: 4.414954000 seconds] Frame Number: 4562 Frame Length: 62 bytes Capture Length: 62 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Foxconn_e6:81:78 (00:01:6c:e6:81:78), Dst: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Destination: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Foxconn_e6:81:78 (00:01:6c:e6:81:78) Address: Foxconn_e6:81:78 (00:01:6c:e6:81:78) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 10.0.1.21 (10.0.1.21), Dst: 10.44.64.211 (10.44.64.211) Transmission Control Protocol, Src Port: ssslic-mgr (1203), Dst Port: 59574 (59574), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 4563 4.415064 EdimaxTe_b9:b1:32 Broadcast ARP Who has 10.44.64.211? Tell 10.0.0.1 Frame 4563 (42 bytes on wire, 42 bytes captured) Arrival Time: Aug 10, 2009 23:08:07.916490000 [Time delta from previous captured frame: 0.000110000 seconds] [Time delta from previous displayed frame: 0.011745000 seconds] [Time since reference or first frame: 4.415064000 seconds] Frame Number: 4563 Frame Length: 42 bytes Capture Length: 42 bytes [Frame is marked: False] [Protocols in frame: eth:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: ARP (0x0806) Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Sender IP address: 10.0.0.1 (10.0.0.1) Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 10.44.64.211 (10.44.64.211) No. Time Source Destination Protocol Info 4564 4.415104 10.0.1.21 10.41.3.227 TCP ssslog-mgr > 59039 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 4564 (62 bytes on wire, 62 bytes captured) Arrival Time: Aug 10, 2009 23:08:07.916530000 [Time delta from previous captured frame: 0.000040000 seconds] [Time delta from previous displayed frame: 0.000040000 seconds] [Time since reference or first frame: 4.415104000 seconds] Frame Number: 4564 Frame Length: 62 bytes Capture Length: 62 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Foxconn_e6:81:78 (00:01:6c:e6:81:78), Dst: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Destination: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) Address: EdimaxTe_b9:b1:32 (00:0e:2e:b9:b1:32) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Foxconn_e6:81:78 (00:01:6c:e6:81:78) Address: Foxconn_e6:81:78 (00:01:6c:e6:81:78) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 10.0.1.21 (10.0.1.21), Dst: 10.41.3.227 (10.41.3.227) Transmission Control Protocol, Src Port: ssslog-mgr (1204), Dst Port: 59039 (59039), Seq: 0, Len: 0
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "левые айпи в arp"		+/–
	Сообщение от ze6ra (ok) on 11-Авг-09, 10:11
	>>arp запросы генерирует сам сервер. Смотреть надо кто обращается к этим нежелательным >>IP. (IP источника пославшего пакет). > >вот то что выловил через ethereal: >10.0.0.1 - айпи сервера >10.0.1.21 - айпи клиента >все остальные айпи левые >получается что все запросы в 3х пакетах были от одного и того >же клиента? 10.0.1.21 ? Вообще-то только в двух arp запрос пошёл от вашего сервера >если я правильно понял вывод... осталось только выяснить что стоит у клиента >и лупит столько запросов Да стоит глянуть машину клиента, чтото там не чисто.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "левые айпи в arp"		+/–
	Сообщение от romeo (ok) on 11-Авг-09, 12:25
	>Вообще-то только в двух arp запрос пошёл от вашего сервера >Да стоит глянуть машину клиента, чтото там не чисто. от сервера? т.е. допускается вариант что и сервер сам еще сканит сеть? если так, то что может генерить арп-запросы на сервере? на сколько я знаю там стоит: веб +мускл + фтп + днс + нтп + + DCHub + ntop (который только иногда я вручную запускаю посмотреть что на интерфейсах бегает) + nut (для снятия статистики с УПСа) вот на всякий случай список процессов за исключением системных + тех которые я знаю, может здесь есть что-то подозрительное, что и генерит запросы, т.к. сервер достался от старого админа кстати, есть какой-то процесс от ipaudit но в стартовых скриптах ничего подобного не нашел... не могу понять как он запускается и как стопается... кроме как в ручном режиме USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1433 0.0 0.1 2332 1068 ? Ss Apr21 4:22 /sbin/syslog-ng -a /var/lib/named/dev/log root 1436 0.0 0.0 1800 544 ? Ss Apr21 0:00 /sbin/klogd -c 1 -x 100 1445 0.0 0.1 2412 1060 ? Ss Apr21 0:15 /bin/dbus-daemon --system root 1455 0.0 0.0 1664 532 ? Ss Apr21 0:00 /sbin/acpid root 1471 0.0 0.0 1916 672 ? Ss Apr21 0:00 /sbin/resmgrd root 1503 0.0 0.2 7820 2220 ? Ssl Apr21 0:03 /usr/sbin/console-kit-daemon 101 1606 0.0 0.2 5736 2972 ? Ss Apr21 0:41 /usr/sbin/hald --daemon=yes root 1607 0.0 0.1 3220 1072 ? S Apr21 0:00 hald-runner root 1617 0.0 0.1 3332 1076 ? S Apr21 0:00 hald-addon-input: Listening on /dev/input/event3 /dev/input/event2 /dev/input/event1 101 1622 0.0 0.0 2204 948 ? S Apr21 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket postfix 1914 0.0 0.2 5996 2116 ? S 09:54 0:00 smtp -t unix -u bin 2706 0.0 0.0 1696 548 ? Ss Apr21 0:00 /sbin/portmap root 2811 0.0 0.0 10248 688 ? S<sl Apr21 0:02 /sbin/auditd -s disable root 2815 0.0 0.0 10004 688 ? S<sl Apr21 0:04 /sbin/audispd avahi 2826 0.0 0.1 2876 1596 ? Ss Apr21 0:03 avahi-daemon: running [rol.local] root 2842 0.0 0.0 1824 532 ? Ss Apr21 0:00 /usr/sbin/avahi-dnsconfd -D root 2923 0.0 0.1 3424 2020 pts/1 S+ Apr21 0:00 /bin/bash named 2956 0.0 3.6 65768 37800 ? Ssl Aug06 0:17 /usr/sbin/named -t /var/lib/named -u named root 3749 0.0 0.0 2696 996 ? S 11:16 0:00 /usr/sbin/cron root 3871 0.0 0.2 6692 2564 ? Ss Apr21 0:00 /usr/sbin/cupsd root 3949 0.0 0.1 5816 1752 ? S 11:16 0:00 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t root 3953 0.0 0.1 5808 1752 ? S 11:16 0:00 /usr/sbin/postdrop -r root 3954 0.0 0.1 6552 1764 ? Ss Apr21 1:05 /usr/lib/postfix/master root 3995 0.0 0.0 2272 780 ? Ss Apr21 0:10 /usr/sbin/cron root 4097 0.0 0.1 2764 1316 ? S 11:16 0:00 /bin/sh /usr/sbin/rcntp ntptimeset ntp 4105 0.0 0.1 4400 1620 ? S 11:16 0:00 /usr/sbin/ntpd -g -u ntp:ntp -c /etc/ntp.conf -q root 4228 0.0 0.0 1872 572 tty1 Ss+ Apr21 0:00 /sbin/mingetty --noclear tty1 root 9071 0.0 1.1 97412 11908 ? Ss Jul02 0:55 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf root 12420 0.0 0.0 3164 708 ? Ss Aug10 0:06 /usr/sbin/smpppd-ifcfg --up --rc -i ifcfg-dsl0 postfix 15825 0.0 0.2 6328 2744 ? S 10:27 0:00 cleanup -z -t unix -u root 16784 0.0 0.0 4988 712 ? Ss Jun29 0:46 /usr/local/bin/opendchub --help root 16785 0.0 0.0 4988 756 ? S Jun29 0:44 /usr/local/bin/opendchub --help postfix 20078 0.0 0.1 5836 1860 ? S 10:37 0:00 pickup -l -t fifo -u postfix 23955 0.0 0.2 5988 2068 ? S Aug06 0:02 qmgr -l -t fifo -u root 29292 0.0 0.0 2692 980 ? S 11:00 0:00 /usr/sbin/cron ipaudit 29293 0.0 0.0 0 0 ? Zs 11:00 0:00 [cron30min] <defunct> ipaudit 29327 0.0 0.0 3024 476 ? S 11:00 0:00 /bin/sh cron/cron30min root 29328 0.0 0.2 5848 2144 ? S 11:00 0:00 /home/ipaudit/bin/ipaudit -g /home/ipaudit/ipaudit-web.conf -o /home/ipaudit/data/30min/2009- 08-11-11:00.txt
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "левые айпи в arp"		+/–
	Сообщение от ze6ra (ok) on 11-Авг-09, 13:21
	> >>Вообще-то только в двух arp запрос пошёл от вашего сервера >>Да стоит глянуть машину клиента, чтото там не чисто. > >от сервера? т.е. допускается вариант что и сервер сам еще сканит сеть? > >если так, то что может генерить арп-запросы на сервере? Клиент попросил сервер передать пакет "левому ip" сервер увидев что ip назначения в одной подсети с сервером, делает arp запрос чтоб потом передать пакет. Нормальная в общем-то работа всех протоколов. Осталось разобраться зачем клиенту понадобилось обращаться к этому ip.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "левые айпи в arp"		+/–
	Сообщение от romeo (ok) on 11-Авг-09, 13:41
	>Клиент попросил сервер передать пакет "левому ip" сервер увидев что ip назначения >в одной подсети с сервером, делает arp запрос чтоб потом передать >пакет. Нормальная в общем-то работа всех протоколов. Осталось разобраться зачем клиенту >понадобилось обращаться к этому ip. ясно - сенкс пойду ловить клиента и узнавать, что у него там на машине происходит...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору