IP forgery (theories are fine)

Full IP spoofing is hard for the commoners.

Everything in IP is made of packets. Each packet has a source address and a destination address. IP spoofing is about sending packets with a wrong source address. Sending such a packet is simple enough with a few lines of code (it tends to require local Administrator / root rights; on Linux, this is a matter of a socket() system call with the SOCK_RAW parameter).

Making the packet reach its destination might be a bit problematic. Normally, packets hop from router to router, and routers only look at the destination address (they are interested in where the packet should go, not from where it comes). However, some routers enforce anti-spoofing mechanisms: the routers "know" what IP addresses are behind it, and will see that the spoofed packet is not "possible" (its source address is not one of the source addresses which are normally behind the router). Such routers react by dropping the offending packet. Some ISP employ such routers, because they do not want to be seen as lax ISP who let their customers engage in network practices of questionable morality and legality.

Assuming that your ISP is lax and lets the spoofed packets transit, you reach the other problem known as "TCP sequence numbers". A Web server does not expect lone packets, but a TCP connection. The TCP connection begins with the "three-way handshake":

• Client sends a first packet containing the SYN flag.
• Server responds to that packet with a packet containing the SYN and ACK flag.
• Client responds to that packet with a packet containing the ACK flag.

Each packet with SYN contains the initial sequence number (a 32-bit value) for the data stream originating from the same machine. Indeed, each data byte will be "numbered" and the counter starts at a value that the sender chooses. These values are used in the TCP control flow; client and server use them to tell to the other machine which bytes have been received (the "acknowledge"). In particular, the third packet for the three-way handshake (the ACK from the client) MUST contain the sequence number that the server sent in its SYN+ACK packet.

But a spoofing client never gets that SYN+ACK packet. Indeed, the server sends its SYN+ACK to the alleged client address, which is the source address in the SYN packet. By definition, the spoofing client used a fake source address. So the SYN+ACK went to that fake address, not to the client. Not having received the SYN+ACK, the client has no way of guessing the sequence number which the server put in its SYN+ACK. Therefore, the client cannot send a valid ACK. The server will thus never consider the three-way-handshake as completed. No handshake, no data. No data, no HTTP request or response. The attempt at connecting with a fake source address will simply not work.

Guessing the server's sequence number is hard if the server uses a decent random number generator. The TCP sequence prediction attack is about first opening some connections to the target server, to get a few fresh "random" sequence numbers. Then, the attacker tries to work out the internal state of the Random Number Generator used by the server's operating system to produce the sequence numbers. If the RNG is of cryptographic quality (as it should be in any decent operating system), such prediction is not feasible, and the attacker has to rely on luck. Since sequence numbers are over 32 bits, the attacker has one chance in about four billions to get it right. That's not good odds for the attacker...

To be able to finish the three-way-handshake, the attacker must thus, practically, "see" the SYN+ACK packet, even though it is sent to the fake address. This requires the attacker to be "close" to the target server, on the same LAN or maybe one or two routers away, at most. This explains why I said that full IP spoofing is hard for the commoners: as a basic ISP customer, you do not have the physical access to the wires required to make a full TCP spoofing on a generic Web server. Of course, employees at the facilities where the server is hosted can do a lot more things...

And the answer ? Even if you succeed in making the three-way-handshake and sending the HTTP request, the server will send the HTTP response to the fake address, not to you. There again, you need extensive wire-level accesses to get the response. Otherwise, you could, at best, send "blind" request but not witness their result. This might be enough for an attack, or not, depending on what the server does and why you try to contact it under a fake address.

Short version - Yes it's possible to make it appear from another address, it's unfortunately extremely hard to get a full session with a fake IP though.

Example - I could DoS someone and put a fake IP address (your 225.225.225.225) in the source address and as far as you see you're getting attacked from that address (there are ways to trace this outside the scope of the question).

DoS is easy however because I don't care what you say back - I'm just trying to flood you with packets. When I actually want to listen / interact with you you need to know where to send the data back. If I'm putting fake data in the source field, you're going to send the return data to this address meaning I, at whatever my real address is, never recieve it.