On Wed, 31 May 2000, Graham Wheeler wrote:
> > > > Or, you could just encap the same data in say, five, DNS requests during
> > > > each 24 hour period..
> > >
> > > If all you're doing is stealing the bandwidth of 5 DNS requests in a
> > > day, tunnel away!
> >
> > If you think bandwidth is the biggest risk of tunneling, you should
>
> Not the biggest risk, but I'm basing this on what our clients usually
> want to deploy firewalls for in the first place. And bandwidth control
> (and being able to split the costs amongst departments) is right up
> there in their requirements.
Firewalls aren't the optimum solution for bandwidth control, and it's
fairly easy to do QoS to a gateway using internal network equipment, or
pacing using older multiplexing technologies. Using a firewall to
artificially limit bandwidth is an interesting application of a firewall,
but it's not really the best way to do it. In fact, it's a lot easier to
rip into something like IPFilter and add latency, or do policy based
routing under Linux than it is to reliably count on most firewalls[1] to
do bandwidth management.
> > probably spend some time doing practical security somewhere, or spend more
> > time talking strategy with folks who do. Unlike a lot of industries, the
> > information security industry has a high number of in-the-field
> > practicioners who are aware of and in many cases ahead of vendor
> > solutions.
>
> I think I'm pretty well informed, even if you don't think I am.
I can only go on your recent posts to this list as evidence. That's ok
though, you're probably convinced my posts aren't worth what you pay for
them ;)
> > I disagree. Most corporations I've worked with aren't worried about the
> > bandwidth issues, especially for penthouse.com, it's liability and
> > security issues. Bandwith users are trivial to track down and stop.
>
> Well, you've clearly worked with different ones to me. But then you
> probably live in the first world, where the cost of Internet
> connectivity is negligible (I assume). That isn't the case in much of
> the third world, which is where I happen to be. For anyone other than a
> medium to large size corporation, Internet connectivity can be a
> significant cost. And that's just for a 64kbs leased line. If that's all
> you have, and its costing you a fair whack of money every month,
> controlling the use of that limited bandwidth is a big issue. And
> splitting the cost of that bandwidth can be a major requirement too.
> I realise this probably sounds weird to people in the USA.
Not too weird, the issues are the same once you start hitting scale points
in the thousands of users category, even if the toys are larger.
> > That requires a targeted network. Tunnels can be the conduit provided to
> > and from malicious code (such as worns and viruses) to provide significant
> > vectors into and out of networks- both by genuine bad people and
> > potentially malicious employees. The ability to timebomb systems is
> > nothing new, and while it's generally not newsworthy that doesn't mean it
> > doesn't happen. Tunnels give the same sort of person the oppertunity to
> > surrepticiously access systems after they've been terminated and their
> > access credentials revoked.
>
> I guess I phrased myself badly. It's not that I don't think that
> tunneling is not an issue. Although I admit that's what I literally
> said, it's not what I meant). What I meant was that there are easier
> ways than tunneling 5 DNS packets a day, or using steganography and
> jpegs (which, incidentally, could be somewhat countered by putting
> severe restrictions on the size of downloadable image files). SMTP
> combined with procmail or a hacked majordomo comes to mind, in terms of
> tunneling. If there is a malicious party on the inside, then anythings
> possible.
Right, what most people who dismiss the tunneling risk seem to miss is
that "malicious party" could potentially include "innocent" users, which
I'd expect to be an even bigger problem in 3rd world countries where there
hasn't been a history of computers in schools for at least a decade. I
don't have enough data to back that up though, it's just conjecture.
> As for timebombs - well, you're not talking about that - you're talking
> about someone using a tunnel to trigger a bomb. A timebomb shouldn't
No, I'm equating the use of timebombs (which was something we worried
about back in the "mainframe days") to the use of tunnels today.
> even need that; it just needs to sleep until the right time. What it
> needs is a malicious party on the inside. And once you have that, all
> the firewalls and bullet-proof glass and CCTV in the world may not be
> able to help you.
The point isn't about the culpability of the target, it's about the use of
the technology to break a trust boundary and the fact that it should be on
firewall designers and security administrator's radar.
> Ultimately, I'm just arguing that even though it can be argued that
> tunneling exploits render firewalls useless, I still think firewalls are
> a Good Thing (I should do, as a principal architect, otherwise I'm just
> wasting my time, and should be writing tunneling programs instead).
> Tunneling exploits seem to me like shovelling coal one piece at a time,
> when in fact there is usually a choice of shovels, if not bulldozers,
> available.
Yet if firewall architects add and enhance trending and analyis tools the
good thing could get better, no?
> And I also think that a lot of tunneling can be rendered ineffective.
> The DNS example is easily countered, with some intelligent proxying.
> Images can be stripped or size restricted or modified on the fly to
> counter steganography. Enforcing strong user authentication for access
> to services can help to track things down, especially if the
> authentication requires interactivity that can't be easily automated.
> That's not to say that current products do these things. But as the
> attacks evolve and become more commonplace, so will the defenses.
If we're constantly playing catch-up as an industry it's a bad thing[tm].
> > Trending and analysis can gain precursors to mass tunneling or heavy
> > abuse, but don't count on it 100%.
>
> You can't count on anything 100% (except death and taxes).
Sure you can, you can count on flames on Firewalls :)
Paul
[1] Specific products can do it, but it's not a general application of
firewalling technology.
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
