requests from fake IPs

[lucy24]

This is a “how does this work?” question, not a “how do I solve this problem I’m currently having?” question. (Is this even the right place to ask? I dunno.)

Say a malign actor sends in a request from a fake IP address, meaning that they don’t actually want the material, they just want to make trouble for you and/or for the real owner of the address. Your server unsuspectingly sends out the file ...

... and then what? Where does it go? Does it matter if the receiving IP actually belongs to anyone?

My usual analogy for the fake-IP-request involves ordering something by mail and having it sent to someone else’s address without their knowledge or consent. But analogies can only go so far.

:: looking vaguely in phranque’s direction ::

[phranque]

how do you identify a "fake IP address"?

afaik, the server won't see an HTTP request until the TCP handshake has been completed successfully.

[lammert]

Are you talking http(s)? IP spoofing shouldn't be able over TCP because of the handshake which takes place before the payload is sent. Both HTTP 1.1 and HTTP/2 are TCP based. HTTP/3 (forrmely QUIC, or Quick UDP Internet Connections) is a whole different story because it relies on UDP.

For other protocols over UDP like NTP and DNS, IP spoofing with payload amplification (small request, big answer) is a well-known way to DDOS third party IP addresses. I guess Google build in precautions to prevent IP spoofing in the QUIC protocol though.

[lucy24]

how do you identify a "fake IP address"?

I don't: in fact that's what I'm asking. Since the server--assuming vanilla http--can't tell whether the IP address given in the request is the IP address the request actually comes from, and just sends the requested content to the named address, where does it go? I mean, physically, what happens to it if there's nobody at the other end waiting to receive it?

IP spoofing shouldn't be able over TCP because of the handshake which takes place

Well, that's nice to know. And it's certainly an argument in favor of https for large sites. (I can't imagine being personally targeted for DDOS, unless it should randomly happen that I'm sharing a server with someone else who has done something to make the robots mad!)

As I said, this is a theoretical rather than a practical question. All sites I control have now gone HTTPS, though there are a few categories of content that can--by necessity--go out over HTTP.

[lammert]

The destination of packets is determined by routing tables. Your server has probably a fixed routing table with only one upstream router in it for all traffic outside the local subnet.

That upstream router (or a router a few hops further in the line) will use a dynamic routing table which is updated constantly using the BGP protocol. This protocol continuously updates the digital roadmap of where all IP addresses in the world can be found, and which paths are available to reach them. If an IP address is fake/non-existent, the first BGP aware router won't be able to determine how to reach the destination and will either discard the packet, or send an ICMP type 3 "Destination unreachable" message back to your server.