The request is forwarded if it can't be handled internally, the answer is returned. The tunneling works.
You don't need to leave it.
Which is usually the case.
Your restrictions aren't applicable in most cases.
Hint: There are much more clever ways to tunnel than a simple HTTP CONNECT. We're talking about IP over HTTP or DNS.
| Connecting to | SGVsbG8gd29ybGQsIGhvdyBhcmUgeW91Pw==.somesite.invalid:80... | | Connected. | > GET /index.phtml?sid=VHVubmVsaW5nIGlzIHNvIGVhc3ku | > Host: VGhlcmUncyBzbyBtdWNoIHNwYWNlIGZvciB0dW5uZWxpbmc= | > User-Agent: dHVubmVsaW5nIGlzIGZ1bg== | > Referer: ZXZlbiBtb3JlIHVuc3VzcGljaW91cyBkYXRh | > X-T0ssIHNpbXBsZSBiYXNlNjQgZW5jb2Rpbmc=:aXMgc3RpbGwgZWFzeSB0byBkZXRlY3Q=
It cannot. There is no "connect" command you'll need for every tunnel or something like that.
The protocol depends on what tunneling encoding is used. And there is no limit (but with bandwith) how this will be done.
Yours, VB.
Believe me, it ain't happening in our networks, people try, we pay for testing, you just don't have any exposure to real firewall solutions if you think you can always tunnel out of a network.
Well, Charles Newman thought he could get past any firewall so people could watch the Olympics from work.... and he could not.
Hoover was paranoid about security, monitored everything, tracked down threats, etc...
I guess I would have no problems being related to Hoover - since it works and you can't get around it.
Maybe just your logical thinking is broken. Hey, you didn't even try to understand the concept of DNS tunneling...
Maybe you didn't understand that you can't tunnel OUT of something you can't reach.
DNS is usually always reachable. Your point being?
If you understood networking you would know that workstations can't use DNS outbound in a properly setup network, the can only reach the server INSIDE the network, so you can't use DNS to tunnel out from a workstation.
And if the DNS server INSIDE the network can't handle the request because he doesn't know the answer, he will
( ) send a request to the OUTSIDE and forward the answer to the INSIDE ( ) do nothing and render the network pretty unusable :-)
Forget it.
"Leythos" will explain you, that your Internet connection will be secure, when you have no Internet connection any more.
Yours, VB.
The server will reply with the address that IT resolves for the request, but only the server can resolve DNS outside the network. The workstation can NOT tunnel out using DNS as it doesn't have permission to leave the network.
Additionally, the firewall will block DNS requests to sites that are not approved.
So, do you see now that YOUR WORKSTATION can't reach outside to do tunneling.
If you're so sure I'm wrong, then explain how I'm wrong - which should be good since you cant.
If his workstation can only reach approved sites then he can't tunnel out to someplace he wants to go.
The request and the answer IS the tunnel. Right through the internal DNS server!
Besides that you're obviously too dumb to do the DNS whitelisting at the DNS server level rather than at the firewall, this is about how practical?
By the way, what do you want to do against timing attacks?
Sebastian Gottschalk wrote: [Leythos]
He even will not understand the idea. Forget that.
Yours, VB.
Don't permit DNS traffic to anything except the recommended DNS server then. Why would you anyway?
Some firewalls can block cached content search engines categorically, including the one at google.com.
-Russ.
This will not help. Please have a look on how DNS works.
Yes. And you'll have the black list problem again, say: you'll need to know _every_ proxy and caching possibility in the complete Internet, if you want to be secure.
This will not work.
Yours, VB.
As long as root-only delegation is in place, this could work. Usually that's not the case. What about zone updates?
Because people want to surf the web? Hint: This discussion is about _practical_ corporate networks and also _home users_, e.g. teh kids.
Fine, you want to block Google?
Sorry, it's not going to work - the firewall blocks returning DNS information to the server, except for the error, which then returns the error to the client.
What does this have to do with the fact that the tunnel will not be made, that the OP won't be able to get out.
WTF, your firewall setup allows the DNS server to send DNS requests to the outside, but blocks the answers?
And still the question: How practical is that, especially for home users?
It disproves your so-called fact trivially. A tunnel based on timing measures of an intermediate network device (usually the firewall itself) doesn't need any target destination nor any data transfer.
So Volker made the right prediction 21 minutes ago :-)
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.