mailing list archives
Re: The Outgoing Traffic Problem --
From: "R. DuFresne" <dufresne () sysinfo com>
Date: Fri, 21 Jul 2006 15:05:31 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 17 Jul 2006, Paul D. Robertson wrote:
On Tue, 11 Jul 2006, Marcus J. Ranum wrote:
"After the State Department break-ins, many employees were instructed to
change their passwords. The department also temporarily disabled a
technology known as secure sockets layer, used to transmit encrypted
information over the Internet. Hackers can exploit weaknesses in this
technology to break into computers, and they can use the same technology
to transmit stolen information covertly off a victim's network.
It'd be interesting to know if it was protective or reactive blocking --
it may just be that the IPS couldn't deal with that traffic so they
decided to punt it, or it may be they finally have the authority to block
something they've wanted to block-- we used to have a state.gov poster, if
he's still around it'd be nice to know if we're at the event horizon
The vast majority of your state governments are not this sophisticated to
understand the ramifications here, and certainly not to have dug out the
info that Marcus did from this advisory. To be quite blunt, in most cases
your state institutions do not have or wish to allocate the funds to
actually hire folks with clues and/or experience to do security postureing
for their environs. Cool thing is that what is happening for one state
often spreads up and down and around to many as they tend to clump into
working coordiation efforts. In our case, likely spans the whole East
Uderstand for state governments, it's a pervasive issue whence all state
agencies have their very own little fifedoms and there is no master contra
mechanics to push from top down any fundamental process or proceedure in
anything, let alone IT. Even though the org I work for is legislatively
commanded to exist, and works directly under the govenor and legislature,
they have not found a way to consilidate the various agencies into any
I figger here, the state is about 10-15 years behind the rest of the ITS
industry. We still have the router boys doing firewalls, which have rule
disasters on a bi-weekly basis, now further complicated by active IPS
systems they don't realy understand...so many terabytes of logs, so few
resources to parse em, meaningless bit and bytes....
Many diplomats were unable to access their online bank accounts using
government computers because most financial institutions require the
security technology to be turned on."
So, reading between the lines, it would appear that the bad guys were
using SSL egress as a conduit. Some of us (me, Paul, Fred..) were
predicting back in the mid-1990's that this would eventually be a problem.
I hate it when we're right...
So perhaps a bit of this message is "I told you so!" but it does raise an
interesting question. Once you've got a user base that is accustomed
be being able to send arbitrary encrypted streams out through your firewall,
what ARE you going to do when the bad guys start tunnelling in with your
IDS! No IPS! No SSL Firewalls!!!!!
We're way beyond the generic protection mechanism stage, simply because
HTTP tunnels have driven us there. SSL tunnels won't change that, so
here's your next big great market opportunity...
In Marcus-land, it seems an act of insanity to allow
(anyone inside) -> (anyplace outside)
SSL connectivity. For exactly the reasons that State appears to be
in the process of discovering.
What are most organizations doing about this?? Do most security
managers have their heads still firmly in the sand on this topic?
I trust that everyone realizes that it's going to get worse, not better,
Most security managers have their heads firmly planted somewhere- normally
it's in a vendor's sandpile ;)
No different here for state management of ITS resources.
As far as I can see, the endgame is going to be one of two
- Organizations are going to try to add signature-style
controls to SSL transactions and are going to rely on "man
in the middle" style interception tricks and (call 'em what
you want) signatures to detect malicious traffic
- Organizations are going to have to positively identify
sites with which it is necessary/appropriate to do SSL
I don't see a lot of future in EITHER of those options. The first
one falls apart really fast if anyone ever fixes SSL's certificate
trust model (not highly likely) but since it's signature-based
it'll fail when the hackers add superencryption to their command
streams. The second option would have worked if it had been
approached 10 years ago but ironically there's finally enough
SSL being used that it's probably too late. And reining it in
would be bad, anyhow. So what happens? Is the long term
prognosis as bad as I think it is? I'm just afraid that the
hackers, malcode-writers, and botnetters of the world are going
to have an impact on the entire Internet that is comparable to
the impact that the spammers have had on Email systems:
namely, they have degraded the value and raised the costs
of the system to the point where it's worth 1/100th of what it
should be. As many of you have noticed, this boils my
Someone, please - tell me I am wrong and that somehow
it'll get fixed soon.
I dunno- wanna form a software start-up? I've got a couple of ideas. Our
motto could be "We sell you expensive stuff because your were too stupid
to listen to us when it was a cheap problem to fix."
It's all okay though, those of us with a clue here understannd not to do
our taxes online, the data is not secure if one does, and as long as the
tax dollars roll in we get our paychecks and skip along the bumps and
craigs, dare not try and push a clue upstream outside the minor realm one
is pushed into, they shoot the messangers!
admin & senior security consultant: sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
-----END PGP SIGNATURE-----
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com