Ah, I need to start using this. Work's firewall is completely bonkers, and they just removed access to webchat.freenode.net, so I need to find a way to punch thru... You can't even ssh out, or use websockets etc...
Why not just use your smartphone or something instead? As an infosec guy, I try to maintain the customer service-oriented attitude of "Oh, you snuck something past me? Nice one! Don't do it again. Here's why..." Then again, I am fortunate enough to work in a semi-open academic/clinical/research environment, where if you cross-your-heart-and-hope-to-die promise me that you won't misuse BitTorrent for warez or porn and that you truly have a business need for it, I'll entertain your request for a firewall/QoS exception. But if you work at the kind of place that is manned by totally bonkers jackbooted thugs, they won't be so lenient. When they find you, you could lose your job or worse. It sucks, but the network's not yours to hack around even if you really do know better than the people operating it (and you probably do).
(signed, a former firewall piercer extraordinaire)
((I got so fed up with one customer's stupid firewall rules that I bought a dial-up subscription to Earthlink and an adapter that would let me hook my modem up to the handset of their digital phone.))
(((Holy shit! Earthlink still has dialup service!)))
Circumventing your companies firewall is not a great idea in the first place.
Additionally, if they have aggressive egress filtering, its likely that the only DNS communication will be via an internal resolver which is going to be monitored - iodine is going to leave a LOT of shit in those logs.
> Circumventing your companies firewall is not a great idea in the first place.
Neither is putting in place a firewall that makes people need to circumvent it to get their jobs done. If you work at the NSA, sure, it makes sense that all access is heavily restricted. (Though if you work at the NSA, please reconsider what you're doing with your life.) But if you work at an ordinary company, and doing your job (note: not goofing off, but actually doing your job) requires you to work around the corporate firewall, that's a serious policy problem. And the answer isn't to sit on your hands until IT fixes the firewall, because IT departments invariably seem to have far too many people in them that forget that you can't create security by preventing work. A system encased in concrete is secure, but not useful.
I'm a security guy so I obviously have a differing viewpoint, but when it comes to ensuring what data comes in and leaves your environment there's little choice. The ability to analyse outgoing traffic is really a requirement for being able to effectively detect and respond to incidents.
If your job involves idling on Freenode maybe take it up with management?
It's still a bit silly, I can plug my smartphone in the same PC and have a completely un-monitored network link.. So instead of having /some/ sort of control on traffic if their firewall was not rendering the link useless for a lot of case, they get people (I see them) doing just that.
It's not security, it's security-by-the-checkbox, that doesn't prevent them having the whole intranet on a single shared drive, use outlook, flash, java etc etc. Oh, and such a braindead password policy (like, 6 of them) that everyone has to keep them on postits anyway.
First, security is never a goal in itself; the goal is to get some job done, which involves having something to protect, and security's job is to protect it.
Second, even when your metric is security, creating a policy that people have to circumvent to get their job done seems likely to reduce security.
> when it comes to ensuring what data comes in and leaves your environment there's little choice
The concept of your environment having an "inside" and an "outside" is dangerous. Better to assume that "inside" is just as hostile as "outside", and avoid having any insecure internal services or resources. Use TLS/HTTPS everywhere internally, require authentication for internal services, and otherwise make sure that an attacker gains nothing by compromising an end-user system except what's on that end-user system.
> If your job involves idling on Freenode
Forget "idling"; participating effectively in many Open Source projects (whether developing them or getting support for them) requires the ability to get on IRC.
> maybe take it up with management
Short of C-level executives, management rarely has the ability to change IT policy.
I guess the goal of Security is to not become the next OPM or Hacking Team.
I agree with what you say regarding perimeter security, a concept quickly decreasing in relevance in today's environments. Unfortunately, when you have thousands of people working for you that don't know how to computer, you have to take steps to ensure that the data and functionality that they're handling remains protected.
Additionally, a large amount of attack surface exists on the client side, and with these two factors at play you're dealing with a lot of non-trivial trust relationships within your organisation.
Yes, ideally every system would be an island, and everyone who was supposed to operate it could do so securely and competently enough that they'd realise if something was wrong.
Until then, corporate workstations live in a locked down world where all external access is monitored and scrutinised.
If getting the job done requires exceptional access outside what is allowed by the firewall, a formal exception should be sought. Perhaps there is a solution to put a workstation separate from the corporate network? Maybe it's time to take up the management banner charge up the ranks to have C-level visibility? Someone needs to be the hero. :P
Continuing to circumvent the corporate controls puts your job and possibly your career in jeopardy. Likely you will impact your colleagues as well with even more onerous restrictions.
Well I hope they don't proxy the DNS -- it's quite costly to do so, if they don't it'll be fine. If they do, well, I'll have to find another way using 'long' http transactions and such...
I had used it once. But the speed it gave to me is too slow. I could not even open a basic site without waiting for 10-15 seconds. Had I done something wrong or is this speed same to you?
From reading the article, it looks like in the most restrictive environment, the "malware" (dnscat2) behind the firewall passes data out by resolving lots and lots of unique subhosts at the controlled DNS server, e.g. many queries of hosts like: 19c301abcddeadbeef.malware.com.
It seems like this pattern could be recognized behind the firewall. How often would a real Internet client resolve hundreds or thousands of sub-hosts in a short timeframe?
It loads <some random subdomain>.cloudfront.net - and it changes every reload for me. For instance, d262ilb51hltx0.cloudfront.net, dnqgz544uhbo8.cloudfront.net, d262ilb51hltx0.cloudfront.net.
That seems a bit different. A unique subdomain for each web page load might be common, but from my reading of the article, it looks like every packet of the tunneled conversation gets a unique domain. So for transferring any amount of data, I'd expect to see hundreds (thousands?) of subdomain resolution queries in a few minutes. That could raise a red flag.
I suppose if the malware wanted to be more stealthy, it could slow transfers way down, intermix unrelated queries and spread the tunnel across multiple unrelated controlled domains.
You can bypass essentially all paywalls using DNS tunnelling. The connection you get has _terrible_ bandwidth and latency characteristics, which is why nobody does it.
This doesn't work for many hotel paywalls, because they would have a catch-all rule for all DNS A queries (resolving to a local IP of authenticating proxy) and block everything else. And the reason is exactly because of the DNS tunneling, which was making rounds in p2p circles as far back as 2005 if not earlier.
Doesn't this cause issues with cached bogus A records once the user pays and is granted access? I suppose you could return really short TTLs, but there would still be a delay of at least a few seconds.
(I'm not doubting they do this, just saying it seems very hacky...)
Yes, it does, and of course fails if the site called is https. AFAIK some implementations work as a proxy after successful authentication to reduce that problem.
Other solutions use proxy configuration detection to redirect people to a proxy that first asks for authentication/payment. (wpad file)
Both solutions are kind of hacky, but they work for more or less all devices.
Yea, it was pretty bad for me. I did manage to establish an ssh connection over that, but it would get dropped pretty fast. I'd setup L2TP on the host if you want to browse the web, it might just about work.
The connection itself is not that bad, I actually paid for it eventually and it was okayish. I'm pretty sure with a bunch of adjustments you could get it to a point where you can use some IM comfortably.
I was tinkering with DNS tunneling for free mobile internet, and found that TCP port 53 was apparently unfettered. (Other traffic I tried was firewalled, and HTTP was captured and redirected to a page prompting to buy a data plan.) I guess the intention was for DNS over TCP, but I was able to ssh over that port and got decent speeds and no apparent tampering of the traffic.
