Application Security Concerns: How easy is it to fake an IP-Address?

Question

I am dealing with an application that is protected by a firewall and only allows access from certain IP-Addresses (which are application webservers).

Its a bit delicate and it would be much hassle to introduce another authentication/protection layer.

My understanding of networking is not great because its not my subject, but in my Head I made up the following scenario:

• Someone knows the IP-Address of one of our application servers and wants to fake it to get access to the other application which he knows the listening socket and protocol of.

• So he alters the Header of his IP packets to have the Webserver IP as transmitter.

What happens next?

• A: His ISP rejects the packet and says "Hey, that is not the IP address you were assigned from me." - Problema Solved

• B: The ISP passes the packet on to the next level (his up-link...)

Lets assume the ISP has been compromised or the packet is passed on without inspection (I don't know whether that's the case)

What happens next?

• A: The carrier rejects the Packet and says "Hey, that IP is not in the range of IP we agreed you are operating on!" - Now if my webserver isnt operated by the same ISP that my attacker compromised - Problema solved

• B: The ISP doesn't inspect the packet or is compromised and forwards it to his up-link.

Now I am quite sure that IP addresses ARE inspected and filtered when passing a router. Otherwise it would be total anarchy.

So to put this straight: An Attacker that wants to fake my IP-Address needs to compromise the VERY same ISP that is in charge of the IP-Range my Webserver operates in - or this ISP does not do packet inspection.

• Is this correct?

Okay now I imagine my server is located in an office and its ISP is a regional cable company.

What would be the steps necessary to send packets from my IP address to another internet IP?

(Of course I am only asking to get aware of the risks and choose proper protection!)

I imagine locating the routing station which is often in some small container at the side of the street that is only protected by a lock. Going in there. Swapping cables or plugging yourself into.

Will this most likely work if you know what you are doing or is there some encrypted handshake with keys stored on the real offices modem that is required to built an authenticated connection?

I am talking about today's standards in cable internet.

Last thought: So if my origin server is not some household ISP that has its stations vulnerable on the street i should be pretty safe, right?

I remember that NFS servers relies on IP authentication ONLY as a default. Because this is pretty common - are there any examples where NFS servers got hacked by faking IP addresses?

I realise that this question is put very very vagly. This is because I am not sure about anything I am saying here. I just wanted to give some input where I think the cave-eats could be, so they can be confirmed or eliminated.

Overall I am grateful for any comment and your personal thoughts about that subject!

Nobell

Answer 1

Now I am quite sure that IP addresses ARE inspected and filtered when passing a router.

This assumption is incorrect, despite your level of sureness. "Egress filtering", which is the name of this, is generally not done.

The major protection against widespread spoofing of IP addresses is that the attacker would not recieve any response packets - they would all be routed back to the host that is legitmately using the IP address being spoofed. This kind of attack is known as "blind spoofing", because the attacker is working blind.

In order to send data on a TCP connection, you must be able to finish the TCP "three-way handshake". This requires knowing the initial sequence number used by the opposite end - and since TCP initial sequence numbers are chosen reasonably randomly¹, this prevents a blind spoofing attack from being able to do this. (Note also that this does not apply to UDP - without some kind of application layer preventative, UDP is at significant risk from blind spoofing).

If the attacker can see the replies coming back (say, because he is sniffing the uplink or the local network of your server), then this also doesn't apply - spoofing TCP connections in this case is not just possible but trivial.

---

^{1. These days, anyway - this wasn't always the case.}

Faeroese

it's clear enough to me that you know what you are talking about. It's amazing how much rubbish you get on google about IP spoofing over TCP. Thanks – Layer

@wlf: Yes, it is overwhelmingly likely that the address in your logs corresponds to the actual machine that was making the connnections - that said, that machine could have been a third party machine that was compromised by the attacker and used to launch the attack. – Faeroese

Answer 2

Inside a LAN it depends on how your routers/switches/hubs are configured. But I think spoofing should be possible quite often.

---

I don't think the IP address is inspected. Thus you can send UDP packets with forged sender IP. But you won't receive the answer since the server will send it to the real owner of that IP.

This means you can't simply fake an IP in TCP since establishing the connection needs a handshake.

---

You can forge the IP of somebody if the response will go through your router. So a network admin can fake all IPs inside his LAN, an ISP all IPs inside his net, and a carrier can fake IPs on many international connections, provided they get routed through him.

---

Finally there is the possibility of abusing BGP to modify the routes for that IP to go through your computer. But not everybody has access to BGP, you probably need to become an ISP to get it. And then the manipulation will probably be detected because BGP route changes are monitored.

Selfesteem

that is all very interesting. so bottom line the vulnerability is a man in the middle attack. which, when in place, would render for example basic http authentication invalid as well. so i can rely on ip authentication so far, but if i want to bring it a step further i need to implement encryption whith a shared secret or asynchron with a confirmed public key. do you agree? – Nobell

If the IP is shared(NAT,Proxy,...) between several persons that don't trust each other(but trust the router/proxy) then IP authentication fails but the attacker still can't intercept a TCP connection. – Selfesteem

I'd simply use https with known public key. That helps in public/untrusted WLANs too, and that's a relatively common scenario. – Selfesteem