3

I have a Linux server at home (OL 6.6, fwiw) running some internal services. I noticed this morning that it is responding to ARP requests for an address I see no record of.

The IP is not configured in any /etc/sysconfig/network-scripts files, and does not show up in ip addr show.

From my workstation:

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$ 

On the server:

[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 ~]$ 

This IP is in the DHCP range on my router, fwiw, and does not respond to pings or any TCP requests in the normal port ranges (nmap -T4 -Pn 192.168.50.108).

I've tried:

  1. Shutting down the server to confirm the ARP replies stop
  2. Shutting down services one by one and killing all unnecessary processes -- the IP does not stop responding until I shut down the computer (it is also one of the first IPs to come up when powered on)
  3. Changing the default gateway to point to a raspberry pi box and capture any network traffic with that IP -- I have not seen any

So my questions are a) how worried should I be? and b) what can/should I do to try to track this down?

Thanks for any help!

1 Answer 1

1

The technique you describe is called arp-proxying. It consists in having an interface (NIC1) replying to arp queries in lieu of another interface (NIC2), which is not on the same physical network. The computer on which NIC1 resides will take care of routing correctly packets destined to NIC2.

It is, in a way, the reverse of ARP spoofing: in ARP spoofing, a pc with a different MAC address pretends to have someone else's IP address, for instance the gateway's, in order to intercept and analyze all network traffic. Here instead a pc with a given IP address pretends it has someone else's MAC address.

Arp-proxying is used mostly to connect VMs when bridging is impossible, or to connect physical pcs on a different wire and/or AP; in fact, with ip_forwarding = 1 in sysctl.conf you are allowing forwarding only of OSI Layer 3 packets, while the absolutely essential ARP traffic belongs to OSI Layer 2. Did you yourself ever configure anything of this sort, a VM or a DMZ? If not, then you may start to worry.

What you can do to explore the issue further is:

  1. check which interfaces have arp-proxying enabled; if you find just one beyond br0, you will have established on which NIC 192.168.50.108 connects;

  2. study the routing table, to see whether an alternative route to 192.168.50.108 has been established anywhere;

  3. study the system interfaces, aliases or virtual, to see whether a new interface has been added;

  4. study the running processes, to see whether an hypervisor is running (Xen, KVM, VMWare, VirtualBox,....); should the address belong to a VM, you need not see other virtual NICs on you system, some of them (VirtualBox) often hide them for no mischievious reasons whatsoever;

  5. check whether any reverse-tunnel/VPN connection is open from your server to some local or (most likely) remote address;

  6. try to establish whether you have a rootkit on your server. rkhunter and chkrootkit are widely available packages doing a decent job of it. Do not expect them to find NSA-grade rootkits, but then you are not a terrorist, right?

It seems likely that, if you are dealing with an intrusion, the person has been wise enough to setup a firewall to drop all packets (including ICMP) which do not belong to an ESTABLISHED,RELATED connection, thus there is little or no chance that you can detect him.... But, you may detect some of his crumbles, if any: search for unusual iptables or ebtables rules (actually, most likely you should not have ebtables configured at all, so finding you have ebtables working on your server, alone, would be a mighty large crumble). The kind of rule you should be looking for are those re-writing source and/or destination of packets, but in general anything you have not placed there might be a reasonable source of worry.

Probably a good move would be to enable passwordless login via ssh, disabling password login to your server, and any other source of access to the server (apart from ssh, of course), then rebooting the server without any cable connected, to make sure you have kicked out the intruder. Passwordless login cannot easily be circumvented, not even knowing the public counterpart of your cryptographic key.

6
  • Isn't ARP proxying usually used to "cross" network segments, e.g. in a NAT/routed situation? In this case the ARP reply is for an IP on the same network the box's main IP is on.
    – ebarrere
    Jan 25, 2016 at 16:32
  • I did have KVM running on here at one point, but none of the VMs are running anymore (sudo virsh list), and the box still replies even when all libvirt services are stopped -- is that normal?
    – ebarrere
    Jan 25, 2016 at 16:33
  • @ebarrere Question 1. Arp-proxy is used whenever you wish to have two distinct network segments within the same broadcast range. For instance, if your pc is acting as an AP and it is connected to a router via ethernet, and you want both the ethernet-connected and the wifi-connected segments to belong to the same broadcast address. Question 2: an incomplete uninstall might very well do that. Follow the suggestions I gave you in my reply. Jan 25, 2016 at 17:09
  • Thx @MariusMatutiae, unfortunately I haven't found much after following your suggestions. Proxy ARP doesn't seem to be enabled on any interfaces (cat /proc/sys/net/ipv4/conf/*/proxy_arp shows only 0s), no routes have been added, and no new interfaces. I did have a hypervisor running (libvirtd --daemon), but I've stopped it and I still see the ARP replies. No VPNs or anything that I can see in process list or netstat.
    – ebarrere
    Jan 25, 2016 at 18:00
  • As for rootkits, it's a headless server & I don't have a monitor on it so it will be a little tricky to start it w/out networking, but I'll see what I can do. From what I understand though I shouldn't hold my breath expecting to actually find much -- the consensus seems to be that if you expect you've been hacked it's best to just rebuild..?
    – ebarrere
    Jan 25, 2016 at 18:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .