Изпечатай

[mrowcp]

Малко по-надолу имам 3,4 теми които се оказа, че се свеждат до един и същ проблем ( едната е тази за дропенето на ssh-a ).
Не знам до колко е вярно това което си мисля, за това реших да питам тук.
Мисля си, че имам няколко машини които по някакъв начин се опитват да са с ИП-то на гейта ми.Тъй като физически е трудно да достъпя машините ( а и не е хич желателно да ги разкачам ) за това искам ако е възможно отдалечено да разбера какво става.
Ето как седят нещата:

Gateway  - 192.168.80.1 Има 3 лан карти le0, le1 и le2
Като:

le0 IP: 192.168.15.1 00:50:56:9a:29:a6 - ISP SPNET
le1 IP: 192.168.80.1 00:50:56:9a:75:9f - LAN
le2 IP: 172.16.252.9 00:50:56:9a:68:6c - ISP BTK

Когато онзи ден сканирах мрежата с един софт за arp spoof се каза, че според сканера МАК 00:50:56:9a:75:9f се опитва да бъде 192.168.80.1 ( а той си е и така трябва да бъде ).Но в началото на реда имаше изписан друг МАК, който според сканера е 192.168.80.1 в момента.
Пуснах arping от машина вътре в мрежата:

# arping 192.168.80.1
ARPING 192.168.80.1
60 bytes from 00:d0:89:02:63:78 (192.168.80.1): index=0 time=13.956 msec
60 bytes from 00:d0:89:03:b0:80 (192.168.80.1): index=1 time=15.965 msec
60 bytes from 00:d0:89:03:b0:08 (192.168.80.1): index=2 time=17.971 msec
60 bytes from 00:d0:89:03:93:bc (192.168.80.1): index=3 time=19.981 msec
60 bytes from 00:d0:89:02:63:48 (192.168.80.1): index=4 time=21.988 msec
60 bytes from 00:d0:89:02:63:7c (192.168.80.1): index=5 time=23.995 msec
60 bytes from 00:d0:89:02:62:aa (192.168.80.1): index=6 time=26.003 msec
60 bytes from 00:50:56:9a:75:9f (192.168.80.1): index=7 time=28.013 msec
60 bytes from 00:d0:89:03:b0:08 (192.168.80.1): index=8 time=13.992 msec
60 bytes from 00:d0:89:03:b0:80 (192.168.80.1): index=9 time=16.002 msec
60 bytes from 00:d0:89:03:93:bc (192.168.80.1): index=10 time=18.013 msec
60 bytes from 00:d0:89:02:63:78 (192.168.80.1): index=11 time=20.018 msec
60 bytes from 00:d0:89:02:63:7c (192.168.80.1): index=12 time=22.025 msec
60 bytes from 00:d0:89:02:63:48 (192.168.80.1): index=13 time=24.034 msec
60 bytes from 00:d0:89:02:62:aa (192.168.80.1): index=14 time=26.042 msec
60 bytes from 00:50:56:9a:75:9f (192.168.80.1): index=15 time=28.052 msec
60 bytes from 00:d0:89:02:63:48 (192.168.80.1): index=17 time=16.004 msec
60 bytes from 00:d0:89:02:62:aa (192.168.80.1): index=20 time=22.029 msec
60 bytes from 00:d0:89:03:93:bc (192.168.80.1): index=21 time=24.037 msec
60 bytes from 00:d0:89:02:63:7c (192.168.80.1): index=22 time=26.044 msec
60 bytes from 00:50:56:9a:75:9f (192.168.80.1): index=23 time=28.052 msec
60 bytes from 00:d0:89:03:b0:08 (192.168.80.1): index=24 time=13.994 msec
60 bytes from 00:d0:89:03:b0:80 (192.168.80.1): index=26 time=18.012 msec
60 bytes from 00:d0:89:02:62:aa (192.168.80.1): index=27 time=20.018 msec
60 bytes from 00:d0:89:02:63:7c (192.168.80.1): index=28 time=22.026 msec
60 bytes from 00:d0:89:02:63:48 (192.168.80.1): index=29 time=24.035 msec
60 bytes from 00:d0:89:02:63:78 (192.168.80.1): index=30 time=26.041 msec
60 bytes from 00:50:56:9a:75:9f (192.168.80.1): index=31 time=28.054 msec
60 bytes from 00:d0:89:03:93:bc (192.168.80.1): index=33 time=16.004 msec
60 bytes from 00:d0:89:02:63:48 (192.168.80.1): index=36 time=22.027 msec

Ясно се вижда повтарянето на следните МАК адреси:

1 MAC - 00:d0:89:02:63:78
2 MAC - 00:d0:89:03:b0:80
3 MAC - 00:d0:89:03:b0:08
4 MAC - 00:d0:89:03:93:bc
5 MAC - 00:d0:89:02:63:48
6 MAC - 00:d0:89:02:63:7c
7 MAC - 00:d0:89:02:62:aa

и чак на 8ми ред е моя които трябва да е

8 MAC - 00:50:56:9a:75:9f

При проверка с nmap извади следното:

Код:

Initiating ARP Ping Scan at 09:10
Scanning 192.168.80.1 [1 port]
Completed ARP Ping Scan at 09:10, 0.20s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 09:10
Completed Parallel DNS resolution of 1 host. at 09:10, 2.51s elapsed
Initiating SYN Stealth Scan at 09:10
Scanning 192.168.80.1 [1697 ports]
Discovered open port 80/tcp on 192.168.80.1
Discovered open port 25/tcp on 192.168.80.1
Increasing send delay for 192.168.80.1 from 0 to 5 due to 78 out of 194 dropped                                                                                                  probes since last increase.
SYN Stealth Scan Timing: About 35.71% done; ETC: 09:12 (0:00:54 remaining)
Discovered open port 587/tcp on 192.168.80.1
Discovered open port 199/tcp on 192.168.80.1
Discovered open port 333/tcp on 192.168.80.1
Discovered open port 3128/tcp on 192.168.80.1
Completed SYN Stealth Scan at 09:11, 62.42s elapsed (1697 total ports)
Initiating Service scan at 09:11
Scanning 6 services on 192.168.80.1
Completed Service scan at 09:12, 11.04s elapsed (6 services on 1 host)
Initiating OS detection (try #1) against 192.168.80.1
Retrying OS detection (try #2) against 192.168.80.1
Retrying OS detection (try #3) against 192.168.80.1
Retrying OS detection (try #4) against 192.168.80.1
Retrying OS detection (try #5) against 192.168.80.1
Host 192.168.80.1 appears to be up ... good.
Interesting ports on 192.168.80.1:
Not shown: 1691 closed ports
PORT     STATE SERVICE    VERSION
25/tcp   open  smtp       Sendmail 8.14.2/8.14.2
80/tcp   open  http       Apache httpd 2.2.6 ((FreeBSD) DAV/2 PHP/5.2.5 with Suh                                                                                                 osin-Patch)
199/tcp  open  smux       Linux SNMP multiplexer
333/tcp  open  ssh        OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0)
587/tcp  open  smtp       Sendmail 8.14.2/8.14.2
3128/tcp open  http-proxy Squid webproxy
[color=red]MAC Address: 00:D0:89:03:B0:80 (Dynacolor)[/color]

Портовете и свсичко отговаря на истината, само последния адрес - МАК-а не би трябвало да е този.
Има ли начин да разбера от къде идват тези МАК адреси на Dynacolor?
И изобщо има ли нещо вярно в предположенията ми?

EDIT: Оказа се, че това са 7 DVR-a, но в настройките имат ръчно набити ИП-та...
Спрях единия и при арпинг на гейта, мак адреса го няма в списъка на тези 7 по-горе.

EDIT2: Търсих на всякъде в настройките, но няма нищо зададено което да води към 80.1 Пробвах с ИП от друга мрежа, но като пусна арпинг към 80.1, МАК-а на въпросния ДВР пак се вижда.
Някакви идеи?