Is it possible to spoof the source IP if I'm behind a router that is using NAT?
If not, how do botnet programmers manage to make a SYN flood from their slaves? Don't most home/business networks use NAT?
In short, No unless you have a leak in the protocol.
A botnet can still "do a SYN flood" but, in case where a NAT function delineates the corporate LAN from the Internet, it is the router that will get flooded.
Of course, the actual situation is more complicated than that but I won't get into fully describing it here.
Related
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
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'm writing a P2P application. Peers regularly ping a main server to update their current IP/port, so when a peer wants to reach another one it can ask the server for that information. For now peers use UPnP to configure the NAT (for classic home setups) to be accessible from outside.
So everything works, except when a peer's client tries to reach another (or the same) peer's server and both are behind the same NAT. Since in that case the client is trying to reach its own "external" (public) IP address from behind the NAT, the NAT doesn't do the port forwarding and is unable to route the IP packet.
For now I'm thinking of two solutions:
query the NAT with UPnP to see to which local IP the port is forwarded
store on the main server the internal IPs of the peers
Can you think of other solutions? What strategies do mainstream P2P applications implement to solve this problem?
Since in that case the client is trying to reach its own "external"
(public) IP address from behind the NAT, the NAT doesn't do the port
forwarding and is unable to route the IP packet.
This is known as the hairpin condition. Not all router/NAT solve this properly. The solutions are:
a) Check whether your router/NAT can be configured to enable 'hairpining'. This solution works iff you control all router/NATs in your deployment.
b) Buy another router/node allowing this. Just like a), it works iff your control all router/NATs in your deployment.
c) If you can get obtain the port information for from UPnP, this is a solution too, but not all Router/NAT know or support UPnP. It does not cover for all cases in large deployment.
d) Using multicasting to 'discover' other nodes on the LAN and even communicate with them is a common solution to this problem. You need to agree on an IP address and have peers listen to it.
e) Storing the private IP address on the server is a solution too, but it requires more storage capacity on the server than solution d. There is a timeout (i.e., expiration of data validity) to handle too.
f) Use a TURN like communication between peers (i.e., communication between nodes pass through central server). This solution is rock solid, but not the most efficient in terms of bandwidth consumption.
Hope this helps.
Interactive Connectivity Establishment (ICE) was specifically developed for solving that type of NAT problems. It uses STUN and TURN to achieve the result and is used in modern p2p applications. (e.g. Voicechat)
The PJNATH library has a document explaining
unlike standalone STUN solution, it (ICE) solves the hairpinning issue, since it also offers host candidates.
Is it safe to restrict access to a site by IP?
I know there is something called "IP spoofing" - does this mean that (under some conditions) IP restriction is not accurate?
If a client forges its source IP address, it will be very difficult to establish a TCP connection, because as #cdhowie noted in a comment below, the client would need to ACK the server's SYN + ACK back, which it will never receive.
Spoofed IP addresses are mostly dangerous for denial of service attacks, as the attacker would not care about receiving responses to the attack packets, and they would be much more difficult to filter since each spoofed packet appears to come from a different address.
Not really. First, you would need to restrict all proxies, too, to be effective. More importantly, you may block legitimate users like this. It can be a quick-fix for some chronic issues, but in general it's not as effective as it seems.
IP Spoofing is mostly possible on LAN. In my opinion it is not possible to restrict access to site per IP. I would rather consider applying some certificates/auth methods.
Here is an example. Read some theory here
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.