Here is my setup: I will create two REST services that are run on Server B and should only be called from Server A. Both servers are on the same network and I am not able to configure a firewall to enforce this. There are several clients that share the same (internal) network the servers are on. Because of this I will configure Server B to only allow incoming connections from Server A's IP address. (technical detail: this will perhaps be a Tomcat behind Apache httpd)

  • REST service 1 which is located on https://server_b/getValue?id=1234 will return the value that is stored for the id 1234.
  • REST service 2 which is located on https://server_b/setValue?id=1234&value=foo will set a value of foo for id 1234

(remarks: I know this is not REST as they teach it in the books, this is just an example ;-) And no: unfortunately I will not be able to use basic authentication or the like)

What will happen now if someone spoofes the IP address and pretends to be Server A ? When calling REST service 1 nothing will be conveyed to the forger because the answer will be send to the "real" Server A. Is this correct ?

Calling service 2 will be worse because the get method becomes effective immediately. Is this assumption correct ?

I read information about IP spoofing, for example IP forgery (theories are fine) but was not able to answer my specific questions by using that information.


As you have said other, presumably untrusted, computers are on the same network, your concerns are justified. Any of the other machines on the same network could set their IP address to that of server_a and send a request to server_b.

I would suggest using client certificates and server certificates within your ssl configuration see https://www.scriptjunkie.us/2013/11/adding-easy-ssl-client-authentication-to-any-webapp/ for some started tips on why and how to use client certificates. Note some of the aforementioned article does not apply as you are authenticating servers not client to server.


On a normal Ethernet network there are a couple of ways an attacker with full control of a machine on the network could take control of an IP address.

Firstly they could spoof the MAC address. Due to the way Ethernet switches work once the attacker sends packets from a MAC addres they will also receive replies to that MAC address. The downside of this approach is that they will likely "fight" with the legitimate owner of the MAC address leading to unreliable delivery of replies for both the attacker and the legitimate client.

Secondly they could forge ARP packets to convince your server that their MAC address is the legitimate MAC address for the IP address. The great thing about this method is they can then forward the packets they aren't interested in to the legitimate client. So they are more likely to go unnoticed.


Active TCP spoofing is normally only viable if you are on the same network as the person you are hijacking, so it's not likely to affect you at all. However, as you are using ssl, have you considered using client certificate validation to ensure only legitimate connections can be made?

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.