-----Original Message-----
From: Ron DuFresne [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 22, 2001 14:48
To: Noonan, Wesley
Cc: Jaime Rita; [EMAIL PROTECTED]
Subject: RE: Permiting X through a PIX
On Fri, 19 Jan 2001, Noonan, Wesley wrote:
<snip>
> > We have students who work from home as well as from in
> > classrooms that need to access 2 Unix servers. They need to be able to
> > telnet, ftp, nfs and use X. They need to do this whether they are from
the
> > internet or from the classroom. In short, regardless of any security
> > concerns, in this case, the need of these students to be able to do
their
> > work out weighs the security risk.
> >
>
> So much for the 'private network', so much for folks not being able to
> get to the DMZ from the outside.
>
> Pray tell, how does one then provide access to resources from the
internet?
resources from the internet or resources to the internet? I think there
is a difference, though one might well impliment access in a similiar
manner for both, depends upon the issues you face and the policy you are
enforcing. Hopfully, in as secure a fashoin as one can would be as
generic an answer as is possible without detail of policy and design.
Resources from the Internet. For example, inbound email relays. It is my
understanding that the preferred location for bastion hosts is on a DMZ
where a firewall can provide the maximum amount of security, relative to the
fact that external users must be able to access certain systems in certain
ways (in our case, they must be able to telnet to the box). We placed these
servers on 1 DMZ so that they would only have the "run" of that DMZ if the
systems were hacked in some way. We then provide very specific access to
other "networks", a second DMZ and the inside network. In the case of the
inside network, there is no conduit permitting any traffic from the 2 Unix
servers onto the production network. It is my understanding that by
implementing the system in such a fashion, that we have balanced the need
for access, vs. the security we want on the resources we want secured. In
short, I think we are meeting the most secure fashion possible, given the
access requirements we have.
>
> Your weakest point are those 'from home'
> connetions. Those are the sesions to be hijacked, giving me full run of
> both DMZ's
>
> Which is an acceptable risk in our case. There is nothing of even a
remotely
> secure nature on either network. In short, this is by design. I believe
they
> are called "bastion hosts" in the security vernacular. We harden those
> systems we want to protect, and ghost those (in the event they are hacked)
> that we don't need to protect. And, in fact, many of the systems on the
> classroom network can't access the internet anyway, providing even more
> preventative medicine.
I'm sorry, I assumned of course, that since the pix was placed into
production there was something worth protecting. Perhaps the pix is
simply a fancy toy for the 'programmers to get the hang of playing about.
We do have something worth protecting, and the systems that are exposed are
completely prevented from accessing it by the PIX as well as physical
segmentation. This is why we have 2 "DMZs" and then the Inside network. For
example, there is no way for someone can access the classroom network other
than X from the DMZ. IOW, someone from the Internet would have to telnet to
the Unix server on the DMZ, then use X to access a machine on the student
network. This would entail them taking an educated guess as to what that
target machines IP address is, and whether it is even on. While this does
present a security risk, it is a required one based on the business needs.
In addition, the impact would be minimal, if not nonexistent, in terms of
risk.
<snip>
> > This is not the case with the administration machines however, which are
> > completely inaccessible from the classrooms, or from the 2 servers in
> > question. In that case, security is a major issue, and in fact out
weighs
> > the need to access.
>
> Cool, at least those 'in the know' are want to protect grades and the
> financials they gleen from the students and alumni...
>
> Like I said, we didn't go into this blindly. I also never said we were a
> .edu. Is it common for a security professional to make such bold
> assumptions? I would expect that tends to lead to over reaction and
> incorrect implementations, especially in light to how you have handled our
> discussion.
>
The details you proivided were fairly lacking, so yes, I assumed rather
then telling you to provide some details for a responce. My error, please
ignore.
I wasn't really interested in giving out the great details of our network
design for a question that was simply "what conduit statements are required
to permit X through the PIX". Unfortunately, the thread devolved pretty
quickly :). Hopefully it is providing a good learning lesson for some folks
around here (including myself).
> >
> > I guess the point I am trying to make here is that, much like "higher
ups
> do
> > not really buy into security", it seems many "Security experts" "do not
> buy
> > into business needs". Case in point is what I asked here. No one really
> said
> > whether the conduits would work. In short, the business need was never
> > really addressed. What was addressed is that SSH should be used instead.
> > This even after I stated that (a) we do not have SSH installed on the
> > servers or clients and (b) we can not change the classes in the middle -
> > even if we do go SSH, we can't do that until the next class.
> >
>
> Business can't b done in a compromised enviroment. If it's not secure,
> nothing in the environment can be taken for face value. Ths would lead me
> to feel that once into your .edu network, I'd most likely have little
> trouble getting into those administrative machines...being the mindset
> there is what it is...
>
> I seriously doubt you could, and even if you could would expect that we
> would catch you in the daily audits, as that would entail taking down the
> firewall to do so. As I have said, there is no connectivity allowed there.
>
> Not having ssh installed is not an excuse. Get up, grab the source and
> install it. .edu sites can get it for free or there near to, even from
> the commercial folks.
>
> Only a fool "gets up, grabs the source and installs it". Good policy is
> planned then implemented. Not the other way around.
>
agreed. Still, your statement reeked of apathy on this end, Stating that
it has always been so, why rush to change it now seems apathetic on this
end, perhaps I misread you.
Sorry. I am not a status quo, or apathetic, person. The classes are designed
a certain way. Changing the configuration to use SSH might require a
redesign of the classes as they are taught - I couldn't say, I'm not a
programmer. What I can say is that if changes are deemed necessary, it will
be planned then implemented. We loose business when our instructors look
like fools because the environment doesn't work like it is "supposed" to.
<snip>
>
> Use ssh to encrypt the sessin traffic to help guard against hijack issues.
> REgardless of recent announcments that mitm attacks can be waged against
> ssh sessions, it's not an easy feat,, so, why not take at least a minimal
> precaution?
>
> I never said we wouldn't. I said we wouldn't now. Plus, if the only people
> who could hijack the session are the same people we allow to use SSH,
where
> is the security benefit?
Since security here seems to be a second thought in your design, perhaps
ease of use might be more of an eye catcher? Let the ssh client handle
setting up DISPLAY propreties, let it handle the behind the sceens
negociations...Nevermind my motto of "encrypt it all and sort it at the
endpoints", maverik that I tend to be...
It isn't second thought in the design. It is second thought in this case. I
am still not so sure I am sold on the exact benefit SSH provides. In all
seriousness, so what if someone can hijack the session in this case? We
aren't talking about Internet hackers being able to do it. We are talking
about people who already have SSH access (should we implement it). IOW, why
would they hijack the session, if they have the permissions to create the
session in the first place? And even then, so what if they do? What is the
risk? If there isn't a risk, then what is the security need?
<snip>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
