I have been reading about TURN and STUN servers because I would like to develop a browser-to-browser application so that BrowserA (behind a NAT) could communicate with BrowserB (behind a NAT). In this case, I think I should use TURN protocol.
My question: is there any other solution that does NOT require an external phisical server? A just-software solution would be simply perfect.
THANKS
Answer is no.
Explanation: NAT stands for Network Address Translation. It means translation of the 'private' IP of your device which is valid only on the LAN (Local Area Network) into a 'public' IP address which valid on the WAN (i.e., the wild wild part of the Internet that is on the other side of your NAT).
The problem is that the translated address is only visible from outside your LAN. Hence, you need a reachable device out there to read it and sent it back to you (or other peers).
You will always need a server/central peer to help establishing a connection between two peers located behind different NATs when they both have a private IP addresses.
http://samy.pl/pwnat/ works without an intermediary but also moving this question to serverfault might help :)
Thanks. Let's imagine that BrowserA (the one who starts the communication) knows the public IP of BrowserB, but not the other way round. It is the same answer for this question?
Related
Ok. I am creating a teamviewer like app. And p2p connection is the best route based on my research on p2p. I want to know weather teamviewer works fully on p2p, and is it possible to create such an app without using any dedicated server and a static public ip address. I mean i do know all nodes in a p2p n/w act equal, but then how will these maintain a connection having dynamic ip addresses. Hoping someone can explain how p2p establishes this.
They do not need a static IP. But in absence of a static IP you need some discovery / address exchange mechanism that allows nodes to find each other.
Overlay networks like DHTs/gossip protocols/supernodes are generally used for such a thing, but it could be as simple as a user manually entering the current IP address.
In practice reachability is a much bigger concern. NATs and Firewalls may prevent incoming connections. If both nodes cannot accept incoming connections then neither can connect to the other.
I have created an P2P application which is FULLY decentralized and is using a Kademlia algorithm to make it so. This has been tested on the local network and it completely successful.
I heard about UDP Hole Punching, however hole punching requires the peer to know about the clients IP and vice versa, however as said due to design it is impossible. As it would require each peer to keep on asking the supernode\server for new arrivals and keep them assigned and so naturally it is not too dependable especially if the supernode is down.
Due to the design of the algorithm 1 peer does not know the other peers IP address so I need 1 peer to completely open a port up for PUBLIC to be able to connect to, how can I do this, in Windows? could someone perhaps also give me suitable links that might give me a direction?
It would be preferable (but not absolute) if they use c++\c as example
I think you will have to change your architecture a little. There is no other way for NAT traversal unless you configure your NAT for port forwarding (I think you don't want this). You might need to implement three layers:
Lower layer 1: it knows about IP addresses and ports and can solve problems like hole punching or dealing with servers (which could be down but first you have no choice and second you can add alternatives for connectivity).
Layer 2: implements special naming, addressing and location services for your solution (instead of using IP addresses).
Upper layer 3: implements your p2p solution using lower layer naming and location services.
First of all, you need to examine your design. If it needs 100% connectivity between all nodes (without relays) it's probably going to fail under IPv4 since not all NATs are traversable. And possibly under IPv6 due to stateful firewalls.
Now, for the nat traversal: A solution for DHT-assisted NAT traversal is for NATed nodes to have a rendezvous node.
To keep the UDP NAT mappings open it has to regularly ping that rendezvous node.
Additionally it has to announce the address of the rendezvous point on the DHT, e.g. under hash("rendezvous" + node ID) or simply on its reachable neighbor nodes.
The rendezvous node can then act as coordination point for hole punching.
This does not require any special "supernode", just other (possibly multiple, thus eliminating the SPOF) nodes in the network that are not NATed and can assist.
Additional mechanisms such as UPnP IGP, NAT-PMP, PCP and ultimately instructing users to forward the needed ports can also help to reduce the need for nat traversal.
Due to the design of the algorithm 1 peer does not know the other peers IP address so I need 1 peer to completely open a port up for PUBLIC to be able to connect to
First of all this will only work for Full cone NAT. For other types of NAT that public IP:Port you open will only work for specific destination. In your case you don't know the destination so it's impossible.
In case of full cone NAT, you send a packet to a random address with low TTL value so that the packet drops in the middle and doesn't reach that address. If it reaches than that address's NAT might block you. If you do this then a port will be opened for anybody to send you a packet. You need to keep sending packets after some short interval for that port to be remained open. Here is a problem that you can't choose which port to open in the NAT. The NAT will assign you a free port on its own.
Finally I don't see any point doing any of the above if peers can't exchange their IP information with each other. You should use a signalling protocol like SIP or XMPP to exchange IP information between peers.
To learn more about NATs please read this answer.
It is very interesting that I can actually make a mVoIP service from the scratch. I finally could make a call using OpenSIPs source through SIP protocol. I used external STUN server that helps me to find users' private IP address behind NAT firewalls.
However, the free external STUN server cannot find user's IP address to make a call when a smartphone is on 3G or 4G network. As a programmer, I won't give up to make a mVoIP service. However, I need a help at this time from you guys.
Is there a good way to solve this problem? Thank you.
There can be two problems here:
-you can't find the correct external address behind all kind of NAT. This depends on the NAT type only
-some mobile operators blocks STUN. You can add some modified stun or a simple encryption as a workaround
I actually could find IP address using external STUN server, however it failed to connect media session on 3G/4G network. So, I decided to use RTP proxy to make a SIP call.
OpenSIPs provides RTP proxy module, and it helps to make a call without NAT issue.
I am dealing with an application that is protected by a firewall and only allows access from certain IP-Addresses (which are application webservers).
Its a bit delicate and it would be much hassle to introduce another authentication/protection layer.
My understanding of networking is not great because its not my subject, but in my Head I made up the following scenario:
Someone knows the IP-Address of one of our application servers and wants to fake it to get access to the other application which he knows the listening socket and protocol of.
So he alters the Header of his IP packets to have the Webserver IP as transmitter.
What happens next?
A: His ISP rejects the packet and says "Hey, that is not the IP address you were assigned from me." - Problema Solved
B: The ISP passes the packet on to the next level (his up-link...)
Lets assume the ISP has been compromised or the packet is passed on without inspection (I don't know whether that's the case)
What happens next?
A: The carrier rejects the Packet and says "Hey, that IP is not in the range of IP we agreed you are operating on!" - Now if my webserver isnt operated by the same ISP that my attacker compromised - Problema solved
B: The ISP doesn't inspect the packet or is compromised and forwards it to his up-link.
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router. Otherwise it would be total anarchy.
So to put this straight: An Attacker that wants to fake my IP-Address needs to compromise the VERY same ISP that is in charge of the IP-Range my Webserver operates in - or this ISP does not do packet inspection.
Is this correct?
Okay now I imagine my server is located in an office and its ISP is a regional cable company.
What would be the steps necessary to send packets from my IP address to another internet IP?
(Of course I am only asking to get aware of the risks and choose proper protection!)
I imagine locating the routing station which is often in some small container at the side of the street that is only protected by a lock. Going in there. Swapping cables or plugging yourself into.
Will this most likely work if you know what you are doing or is there some encrypted handshake with keys stored on the real offices modem that is required to built an authenticated connection?
I am talking about today's standards in cable internet.
Last thought: So if my origin server is not some household ISP that has its stations vulnerable on the street i should be pretty safe, right?
I remember that NFS servers relies on IP authentication ONLY as a default. Because this is pretty common - are there any examples where NFS servers got hacked by faking IP addresses?
I realise that this question is put very very vagly. This is because I am not sure about anything I am saying here. I just wanted to give some input where I think the cave-eats could be, so they can be confirmed or eliminated.
Overall I am grateful for any comment and your personal thoughts about that subject!
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router.
This assumption is incorrect, despite your level of sureness. "Egress filtering", which is the name of this, is generally not done.
The major protection against widespread spoofing of IP addresses is that the attacker would not recieve any response packets - they would all be routed back to the host that is legitmately using the IP address being spoofed. This kind of attack is known as "blind spoofing", because the attacker is working blind.
In order to send data on a TCP connection, you must be able to finish the TCP "three-way handshake". This requires knowing the initial sequence number used by the opposite end - and since TCP initial sequence numbers are chosen reasonably randomly1, this prevents a blind spoofing attack from being able to do this. (Note also that this does not apply to UDP - without some kind of application layer preventative, UDP is at significant risk from blind spoofing).
If the attacker can see the replies coming back (say, because he is sniffing the uplink or the local network of your server), then this also doesn't apply - spoofing TCP connections in this case is not just possible but trivial.
1. These days, anyway - this wasn't always the case.
Inside a LAN it depends on how your routers/switches/hubs are configured. But I think spoofing should be possible quite often.
I don't think the IP address is inspected. Thus you can send UDP packets with forged sender IP. But you won't receive the answer since the server will send it to the real owner of that IP.
This means you can't simply fake an IP in TCP since establishing the connection needs a handshake.
You can forge the IP of somebody if the response will go through your router. So a network admin can fake all IPs inside his LAN, an ISP all IPs inside his net, and a carrier can fake IPs on many international connections, provided they get routed through him.
Finally there is the possibility of abusing BGP to modify the routes for that IP to go through your computer. But not everybody has access to BGP, you probably need to become an ISP to get it. And then the manipulation will probably be detected because BGP route changes are monitored.
I need to put together a small brief about the weaknesses behind limiting content to specific countries based on IP address.
Besides using proxy server located in another country, can you think of another way to circumvent such a system?
Basically, any solution that uses an intermediary is a proxy. Period.
All the "surf anonymously" sites are proxies, even if they use their own software.
You can use SSH and tunneling, but that is, in effect, a proxy as well, just a tunneled one. Same with VPN.
The only thing that doesn't require a proxy is source address spoofing, and that only works with one-way attacks, because no return data will be able to get to you.
Also, consider that Geo-Locating is not 100% accurate. I have IP addresses in Canada that show up as US addresses, and I've had US addresses that show up as Canada. I'm sure this is more common in other parts of the world.
You could buy that software that prevents you from broadcasting your IP address. I'm sure it works, I see it advertised in banner ads all over the place :)
On a more serious note, one way of bypassing this would be by using a caching server (google cache, wayback machine).
I don't think you can. The machine you're talking to has to know where to send it's reply to; that's your IP address. The only way to hide that is to have it reply to someone that's not you who passes it on to you - ie. a proxy.
Tor is a good way of achieving anonymity in general, although it's not appropriate for circumventing the type of system you're talking about.
Since your IP address is in each IP packet that goes over the network, and it is required for you to get the response back, you cannot prevent your real IP address from being detected at the server (other than by putting a proxy in between).
Some links that may be of interest to you:
Conflict between Sweden and Norway about surveillance (Sweden cannot reliably identify Norway IP traffic and exclude it from surveillance)
Herdict.com (which we built, I am happy to report)
It depends on what level of the IP stack you are checking the IP, but on higher levels, you wouldn't need to even have a proxy server to have a different IP address show up. For example, modifying the TCP header would do it if that is what you are checking against.
Here's a link discussing spoofing: http://www.securityfocus.com/infocus/1674
If the service is using a web based Geo IP lookup, then a successful MITM attack could trick the service into thinking that the IP address is valid. Of course this is much more involved, but definitely doable.
Don't forget VPNs (and, admittedly, NAT). I guess that could be classed as a proxy, too. It also requires having access to a suitable machine in another country.