7

We are renting a Windows root server at Serverloft. Recently, when the server restarted after installing regular Microsoft updates, it restarted properly, but couldn't be accessed anymore, and a Linux server was answering instead!

After convincing the hotline that this was not our mistake (which took some time), they found out that some other server in the same subnet somehow (they didn't explain how) "stole" the public IP of our server (or rather "took precedence").

They disconnected the "thief", and for a short period of time we could see our server again. Then, without restart, it happened again! After another hour or so our server was back.

Question: does this make sense (we are simple developers who don't really know)? And is it possible to prevent such a scenario? Or can anyone in a typical hosting environment simply "steal" another IP, provided s/he knows how to do this?

Olaf
  • 821
  • 2
  • 10
  • 22
  • 4
    I suspect its a misconfiguration on someone's part (whether the hosting company or the other user) rather than a foul plot to take over the world by stealing IP addresses. And yes, its perfectly possible; by its very nature, TCP/IP was designed in a more trusting time so there just aren't that many security precautions against this type of thing baked into the basics of the system. – Rob Moir Feb 20 '11 at 17:59
  • Thanks - good to know. And no, I didn't want to suggest it was intentional (that's why I used quotation marks on "stealing"). – Olaf Feb 20 '11 at 18:04

5 Answers5

2

Static ARP entries in the ARP cache of the switches would help

Ask Serverloft how are configured their switches, and if something like this is scheduled.

edit:

Static arp entries in the switches would not prevent someone to "steal" the IP address if it's wanted (as MAC address can be changed), but it would prevent from beeing accidental.

The other solution I see to prevent IP stealing would be to implement 802.1x on the switches, like with wifi.

802.1x on the switch is port-based authentication. Wikipedia has a good article describing how a host talks to the switch using EAP, and the switch talks to a Radius server.

In the radius server can be set attributes for an host, and would set the client IP address in the mac address table of the switch once authenticated (eg. like a radius does w/ a LNS server).

petrus
  • 5,287
  • 25
  • 42
  • I believe they mentioned ARP, so I suspect a misconfiguration or malfunction. But thanks, yes, I will ask them. – Olaf Feb 21 '11 at 08:29
1

It's not possible to prevent IP conflicts at the server. I suspect you are at a provider that allows root or admin access to the servers (that or an incompetant managed provider). Once is a mistake, twice is unacceptable. At an ISP that does base configuration for you and manages the servers for you this doesn't happen. I would suggest changing providers. My personal suggestion is orcsweb. The most likly reason this is happening is because linux does not repond or generate gratuitous ARP requests, to help prevent IP conflicts.

Jim B
  • 23,938
  • 4
  • 35
  • 58
1

Am I missing something here? Or is everybody missing the fact that it seems you are assigning dynamic addresses (with DHCP) to servers?

In general, servers should be assigned static addresses so that situations like this don't occur.
It also helps to ensure that a server doesn't get a new address on restart, seemingly making the server disappear.

Azz
  • 320
  • 1
  • 3
  • 10
  • 1
    That is a comment, not an answer. I also don't believe DHCP is in play in this case. More likely it's nothing more than another machine configured with the same IP address. – John Gardeniers Feb 20 '11 at 21:04
  • 1
    How is this not an answer? He's suggesting (correctly) to statically assign the IP address to prevent this sort of thing from happening. – gravyface Feb 20 '11 at 21:43
  • 1
    A, How do you figure DHCP is involved and B so what? Assigning the same "stolen" IP will result in the same issue. It is a valid comment however – Jim B Feb 21 '11 at 04:32
  • There is certainly no DHCP involved, but static addresses. The problem is, from what I understand, solely that a computer can assign any IP address to itself. – Olaf Feb 21 '11 at 08:28
0

There is nothing you can do to prevent a system admin from assigning a static IP address to system that may conflict with your own. And if that machine happens to be in the same vlan as your own box then they will come into conflict (just ask a network guy who has had a user assign their machine the same IP address as the router how much fun that is).

This sounds like user error on the part of another system admin. If you are using dynamic assignments (DHCP) then permanent leases or reservations can make this less likely to happen. Your hosting provider could also implement smaller subnets or private vlans to make this less likely to happen.

Peter
  • 5,403
  • 1
  • 25
  • 32
-2

Short Answer: Change the MAC address of the machine.

Possible Explanation:

One possible scenario is when the machines are "Virtual Machines" under VMware or Hyper-V. What people usually do is that they create a Reference machine and clone it as and when people request it. So, typically all hardware settings are copied to the 'cloned' machine too.

If we go to the basics, the IP is assigned to a NIC, and the DHCP Server assigns IP's to NIC's.. and NIC's are identified by their MAC addresses..

user67714
  • 357
  • 1
  • 4
  • 12
  • 3
    How would changing the MAC address help if the required IP address has already been set on another machine? – John Gardeniers Feb 20 '11 at 21:00
  • With no knowledge of the networking in this case - finding solution can be hard. I explained one possible scenario, Though it is well known that servers should be given fixed IPs, the manner in which they are given vary. 1. The computers are themselves enter their static IP in their networking properties.. 2. The computers are assigned a fixed IP by the DHCP server, in this case, the computer is still in DHCP mode, but it always gets a fixed IP. Now, if it's case 2, changing the MAC and refreshing or restarting the rogue and real computers will get the things right. I think so. – user67714 Feb 21 '11 at 06:08