I know Samy well. Probably more than 10 years.
He's one of the best of the best. I'd hire him in a second if he'd let me.
NAT-to-NAT direct connections with no proxy/STUN needed
31–37 of 37 posts
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#32Earlier quoted context omitted.
Yeah, it's not for corporate networks. But, for example, corporate network (and security) could benefit from this, too. Virtual P2P meetings could be done this way without a third party central server or the need to install a special server software. The meeting initiator can send an email with an URI and everyone else just clicks on it running the relevant client software. Much better security-wise than most scenari…
> Much better security-wise than most scenarios nowadays. Can you elaborate on this?
Note I'm kind of thinking out loud, and in this idea was about P2P conferencing, so it's not for local network or well connected offices. More like a very typical scenario of several people connecting from different locations (e.g. working from home plus remote offices.)
Using a VPN (centralized) adds a lot of latency and degrades the experience. Using a third party service (MS, WebEx, Lotus) often adds trusting them with your dearest corporate secrets and allows them (and the authorities on their respective countries) to spy on the conference or even simply detect your users's IPs to direct attacks to their more vulnerable home computers full of interesting data.
With some service set up like this the users can just have an "initiator" "server", who's software just checks its NAT external IP (thousands of existing free services and web pages give you this) and creates a meeting URI. They send it by some secure channel (e.g. email over vpn) to the other parties. The rest conenct to the initiator "server" and discover each other's IP. If the protocol is carefully designed the clients and server can have a shared secret on the URI to avoid Man-in-the-middle. Voilà!
This can easily be an open source product with zero server costs (unlike WebEx, Skype, MS.) Of course, this works only for clients with NAT access and others should connect in other ways (e.g. HTTPS and/or UPnP.)
My point was that even the corporate network and security teams can benefit from this in some way. It's not just to set up quake servers on college networks.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#33how exactly is this different than netcat -u ?
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#34We're experimenting with this technique in our peer-to-peer software. Unfortunately we probably won't have data on what percentage of the time it works for a few weeks. Provided everything goes okay, I'll try to post our data as a follow up.
Sorry for being lazy. Does it need root rights to forge ICMP?
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#35Earlier quoted context omitted.
they're dropping everything but DNS and HTTP from a proxy That won't help them either anymore: Weaponizing dnscat with shellcode and Metasploit http://news.ycombinator.com/item?id=1204931
(a) My point isn't that enterprises can solve the (fundamentally intractable) covert channel problem. It's that this NAT tunnelling code won't work on corporate networks. (b) DNS tunneling is also clever, but it's loud, easily detected, easily defeated, and extremely likely to get you fired.
Thank you for the followup! A quick question: after reading over "Detecting and preventing the use of DNScat" on this page:
http://tadek.pietraszek.org/projects/DNScat/ ,
it seems as if uncovering small amounts of data sent this way might be difficult. Here are the detection techniques mentioned:
detecting unusual and malformed DNS packets (DNScat will evade this)
detecting high number of unusual types of DNS queries (e.g. TXT) (DNScat will also evade this)
Anomaly detection: DNS query and response length
Anomaly detection: profiling the amount of traffic per client source IP address
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#36Is there a possible segfault at line 108 in udpclient.c? pport is a junk pointer at this line: sprintf(pport, "2222");
In v0.2-beta, the line reads `sprintf(pport_s, "2222");'.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#37Earlier quoted context omitted.
You're right. It's a big deal. It's just not a big deal for corporate networks.
Yeah, it's not for corporate networks. But, for example, corporate network (and security) could benefit from this, too. Virtual P2P meetings could be done this way without a third party central server or the need to install a special server software. The meeting initiator can send an email with an URI and everyone else just clicks on it running the relevant client software. Much better security-wise than most scenari…
basically you are trying to hack a solution for one thing that can be solved with your wallet.
And i dont mean to pay for the most expensive option becausw that's what you isp wants.
I'm talking about hiring a smaller isp that does not goes extra lengths to block your connections