0

Hypothetically speaking - if my web server gets an http request for a given file, say default.html, and let's say the requesting IP address has been spoofed, what happens when my server responds to the request? Would it send the file to the (fake) IP address? Would the outbound data be dropped somewhere along the way? Would my server get any feedback that the destination IP doesn't want the data or there never really was any open connection to the destination IP?

To extend this a little further, let's say the file is really large, say 5 or 50 mb. If my server reports (in the logs) that the number of bytes transferred to the requesting IP is indeed 5 or 50 mb, and that the transfer happened without error, then can I conclude that the requesting IP wasn't spoofed and it was legit?

I will note that some (or most) aspects of my question seem to have been addressed in this thread:

Is it possible to send HTTP packet via spoofed IP?

But there seems to be conflicting information in that thread. Some people say no, you can't spoof an http request, while others say "If you can fit the request in a single TCP packet, you can."

The last comment in that thread says flat-out, "It's possible to spoof the destination IP, so when the server sends the TCP/IP payload, it goes to the SPOOF IP, and not your computer".

So it's not clear to me if the spoofed IP address would be exposed to any traffic (or at minimum a syn-ack response) as a result of the fake/spoofed http request to my server. And again, if my server logs indicate that 100% of the requested file was transferred without error, even if were a large file - could that happen only if the requesting IP was legit (not spoofed)?

==============

The proposed answer (Is it possible to pass TCP handshake with spoofed IP address?) answers the question with both a yes and a no. Specifically, here is the part of that answer that seems to say "yes it can be done, for a short transaction at least":

============

Unless source routing or access to a router in the network path is available, this is not a sustainable setup. The client may be able to guess the ISN, but later sequence numbers are incremented by the size of the packets being sent, which the attacker won't see and can't reliably predict. So they should be able to get at least one packet in after the three-way handshake, but not a conversation. And sometimes one packet is enough.

=============

I just want to know if it's possible that my server would answer the http request to a spoofed IP by sending the requested file and logging the request has having been performed with no errors. Under the conditions that none of my network gear (modem, router, etc) is compromised and the requested file is small (under 10kb) and there are no further requests or transactions as part of the session. If the answer is probabilistic (ie - it can happen but there is some chance element to it) then I will go further and ask if there is a way it can happen every time it is attempted (but with the spoofed IP changing between attempts).

schroeder
  • 123,438
  • 55
  • 284
  • 319
Peggy Schafer
  • 1
  • 2
  • 1
    Please read all the answers carefully. The one which first seem to suggest "If you can fit the request in a single TCP packet, you can" explains later that more than one TCP packet is needed to establish a connection and that spoofing is thus impossible. In other words: all answers agree that this is impossible. – Steffen Ullrich Jan 29 '18 at 14:58
  • 1
    Possible duplicate of [Is it possible to pass TCP handshake with spoofed IP address?](https://security.stackexchange.com/questions/37481/is-it-possible-to-pass-tcp-handshake-with-spoofed-ip-address) and [Is it possible to send HTTP packet via spoofed IP?](https://security.stackexchange.com/questions/124184/is-it-possible-to-send-http-packet-via-spoofed-ip). – Steffen Ullrich Jan 29 '18 at 14:58
  • @SteffenUllrich both original posts [seem to be rather outdated](http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/). – ximaera Jan 29 '18 at 15:12
  • 1
    @ximaera: thanks for the feedback. I've included it in my answer. – Steffen Ullrich Jan 29 '18 at 16:36
  • @SteffenUllrich maybe it's also a good idea to update some answers in previous posts you've linked to. Or not, I'm not sure about the rules. – ximaera Jan 29 '18 at 16:45

1 Answers1

1

It is usually very hard to spoof TCP, which is the underlying protocol of HTTP (when ignoring QUIC, which has its own spoofing protection). But it is not impossible and it might be easier in some setups: see this link about quick blind TCP connection spoofing provided by ximaera for more information.

But, in case the attacker manages to successfully established a TCP connection with a spoofed source IP, the server will send its response to the claimed (spoofed) source of the connection. Since there is no matching association at the claimed target the packets sent by the server will either result in a RST from the spoofed target or will simply be lost. Since TCP relies on ACK from the peer (i.e. HTTP client in this case) to signal that it received some data and this ACK is not sent the server will realize that the connection is broken. And while QUIC is a different protocol than TCP the results will be similar.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • And, the HTTP request at application layer won't even reach your server in the first place, so no files are being sent anywhere. – multithr3at3d Jan 29 '18 at 16:26
  • @multithr3at3d: With blind TCP connection spoofing (see the link in my answer) it is actually possible to deliver a HTTP request, at least with plain HTTP. It will not be possible to do this with HTTPS though. – Steffen Ullrich Jan 29 '18 at 16:35
  • My question does indeed pertain to http (not https), with the presumed spoofer being on the WAN (internet) side of my local LAN. – Peggy Schafer Jan 29 '18 at 16:48