> While I do not want to get into a religious war here, let me provide a
> little bit of insight for us, and our situation, for the benefit of the
> discussion.
>
> We are not the EPA. Or the GAO. Or a corporation. We are an educational
> institution.
Just on my account, I'm willing to bet there has not been a quarter in the
last two years, perhaps three to four, that I have not helped a .edu admin
'discover' that at least one system of their network had been compromised
and used to assualt others on the internet. Requiring them to at the
least, re-evaluate their security measures and re-installl the servers
from scratch. Others on the list will prolly have similiar stories, if
not more grandious ones...
> 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?
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.
and if there are any trust relationships from there to the
inside, full rull of the whole .edu network.
Only a moron would have that situation. As I have already stated, we
explicitly prevent that from occurring. Plus, we are physically separated
from the rest of the campus. We didn't go into this blindly.
Your at home users burrowing in from the internet are no different then
the hijacked X sessions the GAO grabbed from the EPA and, as was not
mentioned lockheed who manages the EPA networks.
Actually, now that I am thinking of it, while telnet is permitted from the
internet, X is not.
> 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.
>
> 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.
> Now perhaps this is an uneducated question, but I will pose it anyway. Why
> use SSH? I mean technically. Not because "X is bad", but a firm technical
> reason. We have machines on 2 networks that are behind a firewall, being
> NAT'ed, using private (non routable) addresses. At no point does the X
> traffic actually cross the internet. I don't see a security risk here,
> outside of the students, and that is a risk that comes with providing
access
> to them. That risk was there before the PIX. If I am "uneducated" in
> security here, rather than flaming me, educate me. If I have missed
> something, please point it out. I just don't see what SSH brings to the
> table in this particular case.
>
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?
Your attitude reeks of the same apathy that made the GAO audit of the EPA
a reality. And apathy seems to run rampant in gov and edu administrative
sites. A variation on the " it was broked before I got here, why should I
fix it, even if I have half a clue ".
There is no apathy on my part. I do feel though that there is a bit of
contrived arrogance on yours. There is a difference between doing nothing,
and doing something when the time presents itself. As I have said,
repeatedly now, SSH is something that we will surely look into (though
again, I fail to see the benefit since the only people who could hijack the
session will be permitted to use SSH as well). It is imprudent to rush such
a change without considering what changes will need to be made to the
curriculum, classroom setups and instruction. I guess that is why good
security people are rarely good business people. This is also why good
security people are seldom informed of business decisions till after the
fact - people don't like putting up with belittling attitudes. It is
unfortunate, as this tends to make security professionals cautions a self
fulfilling prophecy.
> Let me also pose the alternative (which was what happened before we
> implemented the PIX). The Unix servers are multi-homed, and have direct,
> unprotected, Internet connections. They are also directly connected to the
> classroom network. We then had MS Proxy server protecting the inside
> network. To me, what we have done by implementing the PIX is provide (a)
> better performance (b) more security to the inside network (c) more
security
> to the Unix servers, and that DMZ (d) a systematic solution of bastion
hosts
> with a minimum required risk (the Unix servers and the SMTP relay, which
is
> also on the same DMZ) for the required access (those systems HAVE to be
> accessible and must be able to access the classrooms.
>
> I guess my (overly long) point is, security isn't the only issue that must
> be weighed. In a perfect world, sure, but this isn't that world. Blanket
> security policies (those that cover all circumstances) can be as bad, if
not
> worse, than no security. Like Jaime said, one must weight the business
need
> against the security risk, and try to determine an acceptable compromise.
>
Lucky thing none of you certifications has a security bent to it, or I'd
advise you contact the certifying authority of your failing a real-life
situation and thus being compelled to return said certification.
It is unfortunate that you are unable to conduct a professional discussion
without resorting to personal snipes and diatribes.
It takes away from any validity to your argument.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
