Linux-сервер отвечает на ARP за неизвестный IP

У меня дома есть сервер Linux (OL 6.6, fwiw), на котором запущены некоторые внутренние службы. Сегодня утром я заметил, что он отвечает на запросы ARP для адреса, записи которого я не вижу.

IP-адрес не настроен ни в одном /etc/sysconfig/network-scriptsфайле и не отображается в ip addr show.

С моей рабочей станции:

macbook:~ elliott$ arping -c1 192.168.50.108
ARPING 192.168.50.108
60 bytes from 00:24:81:05:c0:cb (192.168.50.108): index=0 time=1.854 msec

--- 192.168.50.108 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 1.854/1.854/1.854/0.000 ms
macbook:~ elliott$ 

На сервере:

[elliott@server ~]$ ifconfig | grep -i 00:24:81:05:C0:CB
br0       Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
br0:1     Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
eth0      Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
[elliott@server ~]$ 
[elliott@server ~]$ ip addr | grep 192.168.50.108
[elliott@server ~]$ 

Этот IP-адрес находится в диапазоне DHCP на моем маршрутизаторе, fwiw, и не отвечает на эхо-запросы или любые запросы TCP в обычных диапазонах портов ( nmap -T4 -Pn 192.168.50.108).

Я пробовал:

1. Завершение работы сервера для подтверждения остановки ответов ARP
2. Завершение работы служб по одному и уничтожение всех ненужных процессов - IP-адрес не перестает отвечать до тех пор, пока я не выключу компьютер (это также один из первых IP-адресов, которые появляются при включении)
3. Изменение шлюза по умолчанию, чтобы он указывал на поле Raspberry Pi и захватывал любой сетевой трафик с этим IP - я не видел ни одного

Итак, мои вопросы: а) насколько я должен волноваться? и б) что я могу / должен сделать, чтобы отследить это?

Спасибо за любую помощь!

Техника, которую вы описываете, называется arp-прокси . Он заключается в наличии интерфейса (NIC1), отвечающего на запросы arp вместо другого интерфейса (NIC2), который не находится в той же физической сети. Компьютер, на котором находится NIC1, позаботится о правильной маршрутизации пакетов, предназначенных для NIC2.

В некотором смысле, это обратная сторона спуфинга ARP: при спуфинге ARP компьютер с другим MAC-адресом делает вид, что имеет чужой IP-адрес, например шлюз, для перехвата и анализа всего сетевого трафика. Здесь вместо этого компьютер с заданным IP-адресом делает вид, что у него есть чужой MAC-адрес.

Arp-прокси используется главным образом для подключения виртуальных машин, когда мостовое соединение невозможно, или для подключения физических устройств к другому проводу и / или точке доступа; на самом деле, с ip_forwarding = 1в sysctl.confвы допускаете экспедиторская только OSI Layer 3 пакетов, в то время как абсолютно необходим трафик ARP принадлежит OSI Layer 2. Вы сами когда - нибудь настроить что - нибудь в этом роде, ВМ или DMZ? Если нет, то вы можете начать беспокоиться.

Что вы можете сделать, чтобы изучить проблему дальше:

1. проверьте, на каких интерфейсах включена поддержка arp-прокси; если вы найдете только один br0, вы должны установить, к которому подключен сетевой адаптер 192.168.50.108;

2. изучите таблицу маршрутизации, чтобы увидеть, был ли установлен где-нибудь альтернативный маршрут до 192.168.50.108;

3. изучить системные интерфейсы, псевдонимы или виртуальные, чтобы увидеть, был ли добавлен новый интерфейс;

4. изучить запущенные процессы, чтобы увидеть, работает ли гипервизор (Xen, KVM, VMWare, VirtualBox, ....); если адрес принадлежит виртуальной машине , вам не нужно видеть другие виртуальные сетевые карты в вашей системе, некоторые из них (VirtualBox) часто скрывают их без каких-либо вредных причин;

5. проверьте, открыто ли какое-либо соединение обратного туннеля / VPN с вашего сервера по какому-либо локальному или (скорее всего) удаленному адресу;

6. попытайтесь установить, есть ли у вас руткит на вашем сервере. rkhunter и chkrootkit являются широко доступными пакетами, которые делают это достойно. Не ожидайте, что они найдут руткиты уровня АНБ, но тогда вы не террорист, верно?

Вполне вероятно, что, если вы имеете дело с вторжением, человек был достаточно мудр, чтобы настроить брандмауэр для отбрасывания всех пакетов (включая ICMP), которые не принадлежат к УСТАНОВЛЕННОМУ, СВЯЗАННОМУ соединению, таким образом, существует небольшая вероятность того, что вы можете обнаружить его .... Но вы можете обнаружить некоторые из его крошек, если таковые имеются: поиск необычных правил iptables или ebtables (на самом деле, скорее всего, вам вообще не нужно настраивать ebtables, поэтому обнаружите, что ebtables работают на вашем компьютере). сервер, в одиночку, мог бы сильно рухнуть). Правило, которое вы должны искать, это переписывание источника и / или места назначения пакетов, но в целом все, что вы не поместили, может быть разумным источником беспокойства.

Вероятно, хорошим шагом будет включение беспарольного входа в систему через ssh, отключение парольного входа на ваш сервер и любого другого источника доступа к серверу (кроме ssh, конечно), а затем перезагрузка сервера без подключения кабеля, чтобы убедиться, что Вы выгнали злоумышленника. Вход в систему без пароля не может быть легко обойден, даже не зная общедоступного аналога вашего криптографического ключа.