Linux-сервер отвечает на ARP для неизвестного IP

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

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

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

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

1. проверьте, какие интерфейсы имеют ARP-proxying включен; если вы найдете только один за br0, вы установили на какой NIC 192.168.50.108 подключается;

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

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

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

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

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

вполне вероятно, что, если вы имеете дело с вторжение, человек был достаточно мудр, чтобы настроить брандмауэр, чтобы удалить все пакеты (в том числе ICMP), которые не принадлежат к установленному, связанному соединению, таким образом, существует мало или нет шансов, что вы можете обнаружить его.... Но, вы можете обнаружить некоторые из его крошится, если таковые имеются: поиск необычных iptables или ebtables правил (на самом деле, скорее всего, вы не должны иметь ebtables настроен на всех, так что найти у вас есть ebtables работает на вашем сервере, в одиночку, будет могучий большой рухнуть). Правило вы должны искать те, кто переписывает источник и / или назначение пакетов, но в целом все, что вы не разместили, может быть разумным источником беспокойства.

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