I understand that if I tell my computer to send TCP packets from a fake ip address - say 128.5.32.3 - then my computer will happily send the packets out but not receive them in response.
But why is no response received? At which point in the chain is the return packet dropped?
Or, to give the same question asked another way - if my internet provider assigns me some arbitrary IP address, why can't my computer tell the internet provider to give me a different, arbitrary, IP address?
It's like sending a letter with a return address in it that is invalid. The mail will still get there, but if they send it back the postman (router) will at best be able to deliver it to a fake return address.
Your internet provider gives you an address on internet that isn't arbitrary rather one of it's internet addresses it has allocated. You can't 'move house' by wishing it.
If you do move house by getting another valid address you still need to receive a response using address supplied.
The postmen (routers) are incorruptible AFAIK :)
To start with your question about why no response is received, it is because the response goes to the person whose IP you spoofed. This can be abused, and an example if this is a "smurf attack". You would need to control the spoofed IP in order to receive the response, and there would be no point to spoofing if you had this control.
As for your question about why you cannot make your ISP assign you an IP is because, firstly, your ISP has control of a range of IPs and cannot assign IPs out of its permitted range. Secondly, most ISPs won't take into account the IP that your device wants. It has full control and will control your IP how it wants, so you cannot change your external IP at will.
There are many reasons why an ISP will not give an 'arbitrary' IP address. These include
They themselves only have a block of IP addresses they are allowed to allocate to users, if the IP address you want to use is not in this block there's nothing they can do (even if they want to, which they probably don't)
You are mostly likely being assigned an IP through DHCP (unless your provider is very generous or you are paying for a static IP). This also means that your IP is frequently changing.
The reason you receive no response is, as you put it, because the spoofed address is not your IP address. You are in essence telling the receiver of the TCP packets to respond to a different user (e.g., you send a packet, and they respond to some random stranger).
Related
Can you send data to a UDP receiver without your IP address or location visible to the receiver?
Yes. It's possible to create and send UDP packets with a spoofed IP address using a raw socket.
Raw sockets allow applications to create their own IP headers including the source address fields. Look around for examples in whatever language you write in.
However, creating and sending such a packet doesn't mean that the networks along the way to the recipient will actually deliver it. Some networks employ defensed like Reverse path forwarding to protect against IP spoofing. There's CAIDA a research project that tests for IP spoofing in networks around the world, you can find an up to date report here.
Here is what I think.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
The question is , I heard that there's a subnet mask and I know what It does. Why do I need NETWORK ID at all? I read somewhere that it's used so that response could find the network from where request was done, but in above scenario, there's no network needed as web server knows router's ip address and gives it response.
Why do I need(does router need) NetworkId and HostId to know specifically?
There seems to be a lot of confusion here. Your router does not need a network ID, and, in this context, I do not understand what you mean by a host ID.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
Eh, no. That is not how it works. When your computer makes a request to a website your computer will first think about what to do with the request.
Is the target directly connected? That means, if I AND the ip address with the netmask, is it the same as my own ip address ANDed with the netmask?
Do I have a specific route for this ip address?
otherwise, send it to the default gateway.
BTW: my own ip address ANDed with the netmask is my network. So a router may store this if it does not want to perform the calculation every time.
Your router will forward the packet to the destination. It does not make a request to the Internet. In the case of a home-NAT-router, it will modify some fields in the protocol header, but it will not make a request of its own.
What I need is quite the same asked here, I don't understand the answer too well, because of my knowledge, so maybe someone could help me.
What I'd like to do is using the connected user's IP address (Client IP) to make the server-side HttpWebRequest, so I would grab the user's IP and make the call with it.
What I'd like to obtain is that every connected user makes HttpWebRequests with their IP.
Is it possible?
If it is, how should I edit that code to do this?
Thanks.
This is impossible. My answer to the other question was about selecting which IP Address (read: network adapter) to use for a request. However, you cannot invent IP Addresses out of thin air, nor use IP Addresses that are not yours (in a physical, attached-to-this-computer sense).
Now, technically, using Raw Sockets, you can spoof another IP Address in your packets. However, the problem with that is that the return traffic will go to the IP Address you specify, not the one you actually have!
So, my advice is to not pursue this line of thought any further, and find another way to do whatever it is that you are trying to do.
You may only make outbound connections from your server using an IP that is assigned to the server. If you tried to use a client's IP, it would fail.
Even if it did not fail, it would be a form of spoofing and would fail pretty qucikly anyway- the handshake that occurs using tcpip would case the remote connection to send an acknowledge packet back to the source ip (in your case, the client ip) which would result in an error.
If you are using UDP, it actually is possible to do this, but that is a different subject.
I need to make a request with a spoofed IP address for testing purposes. What's the easiest way to do this?
For my own purposes, changing the HTTP header was enough, via the following:
curl --header "X-Forwarded-For: 1.2.3.4" "http://www.foobar.com"
You can't.
In general, spoofing IP addresses for TCP is remarkably difficult. Unless you have control of a router quite near your target or near the IP you're spoofing, consider it impossible.
The reply packets need a path back to you in order to complete even the three-way handshake. The most reliable way to do this is to have control over a router in the most common pathway between your target and your spoofed IP address: this would let you capture packets between the target and the spoofed address and forward them on to you.
You could also try injecting bogus BGP route advertisements, but doing so would doubtless be noticed and cost you dearly when your peers drop you completely.
Can I make libcurl fake or hide my real IP address?
No. libcurl operates on a higher level. Besides, faking IP address
would imply sending IP packet with a made-up source address, and then
you normally get a problem with receiving the packet sent back as they
would then not be routed to you!
If you use a proxy to access remote sites, the sites will not see your
local IP address but instead the address of the proxy.
Also note that on many networks NATs or other IP-munging techniques
are used that makes you see and use a different IP address locally
than what the remote server will see you coming from.
Imagine the following:
User goes to script (http://sample.org/test.php),
Script sends an HTTP request to some other page (http://google.com/). For this example, we'll say using curl.
The script sets the IP address of the request to the user's IP, via CURLOPT_INTERFACE.
I know already that the requesting script will not receive the response, as the remote-host will send any responses to the IP address given in the request.
What I am wondering is what happens to this response? Assuming the client is on a LAN that has one external address and that all traffic sent to that IP is handled by a router acting as a DHCP server, will the response even get back to the user's machine? If it did, would there be any way to ensure that it was handled by the user's browser? And if so, how would the browser handle this, typically? Would it open a new window with Google in it?
I definitely have a follow up to this question, but I am very curious what goes on at this level, before I experiment further.
The script sets the IP address of the request to the user's IP, via CURLOPT_INTERFACE.
Usually, this won't work. Your ISP knows which IP address you are supposed to have and will not forward traffic coming from "fake" IP addresses.
In particular, since you can only communicate one-way with a fake IP (since the answer won't reach you), you would not be able to establish a working TCP connection, since TCP requires a three-way handshake. Thus, you wouldn't be able to submit your web request.
What I am wondering is what happens to this response? Assuming the client is on a LAN that has one external address and that all traffic sent to that IP is handled by a router acting as a DHCP server, will the response even get back to the user's machine?
If the user's PC has an internal IP address and uses NAT, the router will not know which LAN machine to forward the packet to (since it did not see any outgoing request to which it could match that response). Therefore, the answer would be dropped.
Even if you could get the response to reach the client:
If it did, would there be any way to ensure that it was handled by the user's browser?
No. As stated above, a TCP request consists of a three-way handshake. This handshake has not been completed, so the operating system would just drop the packet.
CURLOPT_INTERFACE is for use on computers that have multiple IP addresses assigned to them, to specify which of those addresses should be used as the source IP for the connection. You can't use it to spoof some other computer's IP address. Most likely you'll either get an error, or the option will be ignored and the OS will choose a source interface automatically (the default behavior).
The response will be returned on the same TCP connection as the request.