Техника, которую вы описываете, называется 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? Если нет, то вы можете начать беспокоиться.
Что вы можете сделать, чтобы изучить проблему дальше:
проверьте, на каких интерфейсах включена поддержка arp-прокси; если вы найдете только один за пределами br0 , вы будете устанавливать, к которому подключается сетевой адаптер 192.168.50.108;
изучите таблицу маршрутизации, чтобы узнать, был ли установлен где-нибудь альтернативный маршрут до 192.168.50.108;
изучить системные интерфейсы, псевдонимы или виртуальные, чтобы увидеть, был ли добавлен новый интерфейс;
изучить запущенные процессы, чтобы увидеть, работает ли гипервизор (Xen, KVM, VMWare, VirtualBox, ....); если адрес принадлежит виртуальной машине, вам не нужно видеть другие виртуальные сетевые карты в вашей системе, некоторые из них (VirtualBox) часто скрывают их без каких-либо вредных причин;
проверьте, открыто ли какое-либо соединение обратного туннеля /VPN с вашего сервера по какому-либо локальному или (скорее всего) удаленному адресу;
попытайтесь установить, есть ли у вас руткит на вашем сервере. rkhunter и chkrootkit являются широко доступными пакетами, которые делают это достойно. Не ожидайте, что они найдут руткиты уровня АНБ, но тогда вы не террорист, верно?
Представляется вероятным, что, если вы имеете дело с вторжением, человек был достаточно мудр, чтобы настроить брандмауэр для отбрасывания всех пакетов (включая ICMP), которые не принадлежат к УСТАНОВЛЕННОМУ, СВЯЗАННОМУ соединению, таким образом, существует небольшая вероятность того, что Вы можете обнаружить его .... Но вы можете обнаружить некоторые из его крошек, если таковые имеются: поиск необычных правил iptables или ebtables (на самом деле, скорее всего, вам вообще не нужно настраивать ebtables, так что обнаружение, что у вас есть ebtables, работающие на вашем сервере, в одиночку, было бы могучим большая крошка). Правило, которое вы должны искать, это переписывание источника и / или места назначения пакетов, но в целом все, что вы не поместили, может быть разумным источником беспокойства.
Вероятно, хорошим шагом будет включение беспарольного входа в систему через ssh, отключение парольного входа на ваш сервер и любого другого источника доступа к серверу (кроме ssh, конечно), а затем перезагрузка сервера без подключения кабеля, чтобы убедиться, что Вы выгнали злоумышленника. Вход в систему без пароля не может быть легко обойден, даже не зная общедоступного аналога вашего криптографического ключа.
