True that. Limiting the length might be
a solution, but txt records are used for SPF so tricky on provider
level. Bind is like a dns server swiss knife. Although, I haven't
come across many deployments using bind as LAN dns server?
On 14/10/2012 17:23, Benjamin Tayehanpour wrote:
A very easy way of blocking DNS tunnelling (given a
forced local DNS server in your control) would be to block all TXT
replies, or even to limit the length of a query so the
base32-encoded data simply will not fit. None of these measures
would hamper ordinary usage, and both of these are standard
configuration options in BIND, and, I'm sure, in many other DNS
daemons, so blocking it is quite trivial.
But it probably will go unnoticed for quite some time, unless you
use disruptive amounts of resources.
ICMP can be blocked, hence its boring. Look at DNS
tunnelling and you will quickly realise where the real
hammer is. Ok, for speed reasons an openvpn tunnel on udp
port 53 might be an alternative if outgoing DNS traffic is
not blocked. DNS tunnelling uses the internal DNS servers
to relay traffic, which is difficult to block. So, with
all outbound traffic blocked and with only access to
internal resources it is still possible to go to Facebook
with the help of an internal DNS server ;-) That can only
be mitigated on the DNS server itself and there are not so
many options yet. Snort might be able to tell the
difference (if listening on LAN).
Same principles work with local provider's Hotspot -
"please load more credit" sites. Or, for the tech novices,
just look up WiFree. It uses all mentioned methods (udp,
tcp, icmp, dns) seemingly together.
However, most ops have probably not even
heard about ICMP tunnelling. Even if this one has,
examining the contents of the ICMP Echo payload will
probably not be the first thing an ordinary op does.
She will probably think you are ICMP flooding the
target, though, and that is probably a graver offence
than a little tunnelling.
If it's a public hotspot you probably have nothing
much to fear, though, as you are anonymous and
practically impossible to trace.
>The ICMP tunnelling trick was quite nifty. It will light most pieces of network
monitoring softwares up like Christmas trees, though, but chances are public
hotspot providers do not monitor traffic that closely.
My man is working with just a Linksys wireless router <cough> </cough>
If i was one of his stress boys, and my casual reconn indicated that
the Linksys was his strongest weapon; I wouldn't put much effort to it
(it would be over kill).
But if the wireless router is loaded with ddwrt, i would tread more
carefully -- the network admin may not be the ordinary nice guy. He
may have a few surprises up his sleeve (e.g dumping logs from the
Linksys to some remote server for ana
lysis).
In such a situation,
going with ICMP/DNS tunneling is like carrying a knife to a gun fight.
The above comments and data are owned by whoever posted them
(including attachments if any). The mailing list host is not
responsible for them in any way.
