0

I have a Debian server (Stretch 9.9) that I recently noticed some odd behavior on; the default Ethernet interface (the only one aside from loopback) seems to be attempting to grab every available IP address with DHCP and keeping them all assigned as secondary addresses. I have not made any special configurations to DHCP on the machine, and the /etc/network/interfaces file is, from what I understand, nothing special:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Executing ip a spits out a wall of assigned addresses:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 18:03:73:50:a7:5a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.190/24 brd 192.168.1.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.191/24 brd 192.168.1.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.192/24 brd 192.168.1.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.193/24 brd 192.168.1.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.194/24 brd 192.168.1.255 scope global secondary eth0

Where the initial 192.168.1.111 is one that I have configured with a reservation for this device on the DHCP server, and the following addresses (just a few were included in the excerpt) span the rest of the available DHCP range.

I would prefer to manage IP allocation via reservations at the router hosting the DHCP server, rather than with static configuration, but this server effectively running a DHCP starvation puts a bit of a damper on that. Despite much googling I haven't been able to find anyone with a similar issue, so any input is greatly appreciated.

  • 1
    If someone has not forgotten there some tool running, your server is hacked. That is known behaviour – Rui F Ribeiro Jul 30 at 19:29
  • 1
    Auditing with Lynis and scanning the full filesystem with ClamAV shows everything clean, if this is known behavior would you be able to specify what it's a known behavior of? – Kevin Jul 30 at 21:26
  • 1
    Clamav/Lynis only provide a false sense of security. Known of malware alternating between several IPs to evade firewall/spam list limitations/backlisting/throthling. Seen it before. Although with private IP addresses, alternating between IP addresses is less useful. I would see if the corresponding public IP address(es) are in SPAM blacklists, for starters. – Rui F Ribeiro Jul 31 at 4:39
  • 1
    uninstall "dhcpig" "dhcpstarv" etc. – Jasen Jul 31 at 5:31
  • I've confirmed with ultratools, mxtoolbox, and a couple others that the public IP doesn't appear on any blacklists, and apt removeing dhcpig and dhcpstarv just confirms that neither package was installed in the first place. If ClamAV/Lynis are no good, could anyone recommend a reliable way to clean the machine? – Kevin Jul 31 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.