North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: "top secret" security does require blocking SSH

  • From: Stephen Sprunk
  • Date: Mon Jul 10 01:50:05 2000

Thus spake "Greg A. Woods" <[email protected]>
> If the primary concern of a security policy is that covert channels
> must be prevented then it is absolutely mandatory that port-22 be
> blocked since it is by definition a covert channel.

Blocking that specific port won't prevent covert communication; it just
makes it harder to discover.  I'd rather let the "hackers" self-identify
so I know who to watch.

It is common practice to use SSH on port 23 to bypass typical corporate
firewalls or port 443 (with appropriate scripts) for the more thorough
ones.  Other methods are commonly discussed on SSH users' mailing lists;
intentionally defeating typical corporate security (from the inside) is
frighteningly easy.

More esoteric methods require tunneling of IP packets via ICMP errors,
lone fragments, DNS requests/reponses, and the padding at the end of
legitimate HTTP TCP segments.  If you look hard enough, you can find
people doing it.

> However having any kind of Internet connection, proxied or not, into a
> site where sensitive information must not be allowed to be leaked is
> in effect a violation of the policy.

Most of the "secure" sites I'm aware of require physical separation of
"secure" and "insecure" networks.  Even email requires SneakerNet.

> A paper given at last year's ACM New Security Paradigms Workshop
> by Dean Povey ("Optomistic Security: A New Access Control Paradigm")
> suggests that it might be better to adopt the view that security
> officers should "Make the users ask forgivness not permission."
> Whether this paradigm can successfully be delployed in top secret (or
> higher) environments or not is yet to be discussed.  I suspect it can
but
> then I'm not an expert in traditional forms of high security.

We have enough preventable leaks as it is; letting well-intentioned but
naive users devise their own policies doesn't give me a warm fuzzy
feeling.

Any system, no matter how "secure", can be broken into with sufficient
determination and resources; the sensitivity of a break-in usually
determines how difficult one can afford to make that task.  I'd be happy
if the folks in the "security industry" would recognize that principle,
as most I've met are under the impression they can mandate perfect
security.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, HCOE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: [email protected]