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.
Related
nmap has a decoy option that can be used to give different ip addresses as source ip.
I was wondering how this works, as what i know packets are routed based on their source and destination ip address so when we send a packet with a different ip as source how does the answer gets back to us ?
Is this option works on a single broadcast domain or can it be used across the internet too?
Any link to a document or website about how this works will be great, thanks
I was also looking for the answer to this question. I thought of leaving what I found with a quick search.
how does the answer gets back to us ?
We are not interested in getting all the SYN,ACK replies back to us. We only need that one reply that comes back to the attacker's IP to figure out that the port is open. The primary purpose of the decoy is to confuse the IDS on the target site. If there are 10 different clients sending TCP SYN to the server, it wouldn't be easy to find who is the attacker, and who are the innocent clients.
Yes, the responses will be going back to the decoy addresses. That is why the following article says to make sure the decoy addresses are also alive because if they are not, the pattern of handshake will be different for the attacker and the dead decoy addresses, which the victim may be able to figure out and pinpoint the attacker's IP.
https://nmap.org/book/man-bypass-firewalls-ids.html
Is this option works on a single broadcast domain or can it be used
across the internet too?
I don't see any reason why it should be from the same subnet. It can be any IP address(es)
I have two my own applications on C++ and Java: server and client. It both in one LAN and can transfer data via specified port. I want to make it possible, that client can find IP of server. But how to?
Enumeration of all possible IP with address mask - bad idea, it will take a lot of time. May be exists some way, where I can send broadcast to lan from client and receive it in server? Or another way... I can't find information about this, but I think that is possible, because I see it in MyPhoneExplorer on android, for example.
Why not using UDP broadcast?
the client can UDP broadcast "I am at x.x.x.x", and the server can answer (in UDP) to the client, "I am at y.y.y.y".
maybe you can use the Broadcast Address to find your server.
I am running a TURN server (http://tools.ietf.org/html/rfc5766) on a server that is behind a firewall. The machine has a public IP address where incoming and outgoing network packets are sent to/from the server's private IP address. Basically, the server cannot bind sockets to the public IP address, only the private IP address. Running ifconfig shows the network device having a private IP address.
When I run the TURN server, I have to bind to the private IP address (since the server doesn't think it is connected to the public Internet). All responses to allocation creations send back the XOR-RELAYED-ADDRESS with the private IP address. Clients receive the XOR-RELAYED-ADDRESS and send data to the server's private IP address, which clearly fails.
There are two options I am considering to overcome this:
Have my client code ignore the IP address of the XOR-RELAYED-ADDRESS and only use the port of XOR-RELAYED-ADDRESS. Clients will send all relayed messages to the TURN server's public IP (since the client already knows this value beforehand) and the XOR-RELAYED-ADDRESS port.
Alter my server to know about its public IP (even though it can't bind sockets to it), and always send back the public IP in XOR-RELAYED-ADDRESS responses.
I feel like the first method breaks the TURN RFC...even though I can't imaging a situation where the TURN server would send back the IP of XOR-RELAYED-ADDRESS as something other than the TURN server's public IP, the RFC says that the XOR-RELAYED-ADDRESS is what clients should be sending data to.
I feel like the second method breaks the RFC less...if that makes sense. Furthermore, this method doesn't force clients to do anything special, whereas the first method needs all clients to abide by the above.
What do you think about this? Has anyone experienced this, and/or have any opinion on which method breaks the RFC less, or if the RFC is even violated by either method?
I have nearly the same exact problem running my STUN server code on Amazon EC2. The origin address and the alternate address returned by the stun server to the client are NAT'd IP addresses.
Some solutions I have thought about:
Just assume clients are pre-configured to know the alternate IP address if they actually want to do the additional NAT type detection tests. This is not a bad assumption to make for STUN. After all, they are expected to know the primary IP address of the stun service.
Modify the server code to be passed it's mapped IP addresses from the command line or config file. This is equivalent to your second method described above. I could have the server self-discover it's own external IP address via a web request (or test another stun server) when it starts up to make this automatic.
Your first proposal - clients are aware of the IP mapping - is perfectly fine assuming you aren't trying to interop with other clients other than your own. But if you think you'll have a need to use someone else's client stack, then this option becomes less desirable. You could do a hybrid approach - invent a new custom attribute for TURN Allocate responses that your client understands to mean, "ignore relay IP, just assume the port is correct". This is OK, but not great.
Your second proposal is more in line with my #2 above. There's one other thing to think about. What happens if your clients are also behind the same firewall as your TURN server? Do you want the internal address or the external? Then again, if both your clients are behind the same firewall, they likely won't need TURN to communicate. The other issue is just the administration overhead of passing the right IP address to the server.
I like your second proposal.
You could consider posting a question to the BEHAVE IETF email discussion group. They are the open committee that drafted the STUN and TURN specs. I think they should be aware that servers in the cloud running behind NATs are becoming increasingly common. They may have some advice. I would be keenly interested in joint authoring this email with you. Or at least reading their response.
I would like to get the user's IP locally without any invoking any service.
Looking for a purely client side solution.
In general this problem is not solvable because the client computer might not even know its own external IP address. This happens when the client is behind a NAT or some other kind of firewall.
Note that many different client machines might share the same external IP address, and also different client machines might have the same internal IP address but different external IP addresses. Or, I can even imagine a situation where two different clients have the same internal and external IP addresses.
If you would explain why you believe you need this information, another solution to your actual problem might be possible.
Am I able to depend on a requestor's IP coming through on all web requests?
I have an asp.net application and I'd like to use the IP to identify unauthenticated visitors. I don't really care if the IP is unique as long as there is something there so that I don't get an empty value.
If not I guess I would have to handle the case where the value is empty.
Or is there a better identifier than IP?
You can get this from Request.ServerVariables["REMOTE_ADDR"].
It doesn't hurt to be defensive. If you're worried about some horrible error condition where this isn't set, check for that case and deal with it accordingly.
There could be many reasons for this value not to be useful. You may only get the address of the last hop, like a load balancer or SSL decoder on the local network. It might be an ISP proxy, or some company NAT firewall.
On that note, some proxies may provide the IP for which they're forwarding traffic in an additional HTTP header, accessible via
Request.ServerVariables["HTTP_X_FORWARDED_FOR"]. You might want to check this first, then fall back to Request.ServerVariables["REMOTE_ADDR"] or Request.UserHostAddress.
It's certainly not a bad idea to log these things for reference/auditing.
I believe that this value is set by your web sever and there is really no way to fake it as your response to there request wouldn't be able to get back to them if they set there IP to something else.
The only thing that you should worry about is proxies. Everyone from a proxy will get the same IP.
You'll always get an IP address, unless your web server is listening on some sort of network that is not an IP network. But the IP address won't necessarily be unique per user.
Well, web request is an http connection, which is a tcp connection and all tcp connections have two endpoints. So, it always exists. But that's about as much as you know about it. It's neither unique nor reliably accurate (with all the proxies and stuff).
Yes, every request must have an IP address, but as stated above, some ISP's use proxies, NAT or gateways which may not give you the individual's computer.
You can easily get this IP (in c#) with:
string IP = Context.Request.ServerVariables["REMOTE_ADDR"].ToString();
or in asp/vbscript with
IP = request.servervariables("REMOTE_ADDR")
IP address is not much use for identifying users. As mentioned already corporate proxies and other private networks can appear as a single IP address.
How are you authenticating users? Typically you would have them log in and then store that state in their session in your app.