From: Julio Sanchez <jsanchez @
gmv .
es>
>
>> From: Doug Hughes <Doug .
Hughes @
Eng .
Auburn .
EDU>
>> Date: Wed, 31 Jan 1996 08:29:39 -0600
>> Cc: firewalls @
greatcircle .
com
>>
>> I think you are confusing our firewall with our external router. As this
>> wasn't made clear in the original post, that is a natural mistake. My point
>> was that the University as a whole has an external router that has a block
>> as opposed to allow strategy by necessity. There are several protocols that
>> we can all agree deserve blocking (RPC, NFS, rexec, etc). However, making
>> an allow list would be huge and unwieldy (while blocking all else).
>> Our firewall is actually part of the engineering network and does serve
>> to protect us from other depts outside of engineering in a limited fashion.
>> I wouldn't call it a real firewall as it uses tcp_wrappers, some scanner
>> detection, and other IDS type tools, but it serves its purpose admirably.
>
>Good, so you already have one or more internal firewalls. That was
>actually the point I was making, that a firewall protecting a
>University network from the Internet is silly most of the time.
>
>But the point being made in the thread by others is that RPC, etc. are
>not really securable.
>
Hmm, I didn't hear that point, and I disagree. RPC and NIS are securable
if you know what you are doing and you take the appropriate steps. I've
outlined this before, and it's available on my WWW page, so I won't belabor
the point here again. (Note: Secureable from outside attack, but less so
from inside attack - an important distinction)
>And then my other implicit point was that the University network at
>large is not protected very strongly. This is actually very common in
>Universities and is not necessarily wrong in itself. Only that
>everyone must be aware of this and no unwarranted expectations should
>be raised by anyone. You cannot be very open (like your departments
>require) and very protected at the same time.
>
agreed.
>> The ruleset on the external router is quite small, unfortunately, and
>> necessitates a block vs. allow strategy.
>
>That, as you probably know, requires you to know what is dangerous and
>we don't really know that. At most, we think we know what things don't
>seem to be dangerous. And some people in the list will immediately
>point out that I am being too optimistic :-)
>
The list of services that are known to be not used are blocked.
(tcpmux, link, supdup, stuff like that). The list of known to be
dangerous are blocked (NFS, RPC).
Anything can be used dangerously. Somebody could setup a server on
any port. Since arbitrary servers cannot be denied by fiat, this is
one of those things we must live with and accept.
>> The actual firewall machines are under our direct control and are
>> self-consistent and wholly configured by us.
>> We do not rely upon the external router to be a panacea, but just to do the
>> little things that an External router can be good at:
>> 1) preventing external TCP/IP spoofing attacks
>
>Good, but in an open environment as yours it is probably very easy to
>get to some internal machine maybe even through approved means
>(accounts for research partners, student accounts whose passwords
>circulate around, etc.) and as soon as they've got a stronghold
>inside, the router (or a more restrictive firewall for that matter) is
>going to be of little help.
>
We have been trying to implement a one-time password or token based
authentication mechanism for outsiders, but either the expense, or the
hassle has made it impractical up till now. It's a matter that is constantly
being revisited. If I had my druthers we would have secure telnet clients
for access and one time passwords (not necessarily in combination, but
possibly). Finding a multi-platform free secure telnet is an ongoing
project. :) (STILL waiting on STel). tripwire, tcp_wrappers, rpcbind,
modified logins, extensive logging, and a GUI IDS help us detect who's
been 'bad or good'. We also watch patterns of students/profs logging in
from external sites. I have an pseudo-AI perl tool that scans the wrappers
logs and detects unusual patterns of user activity. It logs any connections
outside the US, connections from multiple domains, and connections where
RFC931 style identification does not match local ID, as well as users logging
into a machine that they don't normally use. We've caught quite a few
people doing password sharing this way. They don't do it again if they
want to continue using their accounts. ;)
>
>So, your network at large is not really very secure and cannot
>probably be secured without major rethinking/restructuring and a lot
>of consensus.
>
It depends on what you refer to the network at large. The University
(except possibly COE and some other small pockets) network is largely
unsecured except for router filters. Yes, this is an undesirable truth.
The COE network has much more security. It has a fair balance of usability
vs. security. I am constantly trying to make it more secure without making
it less usable. That secure telnet client would go a long way to helping
here.
>At least you already have some networks more protected so it seems you
>are more aware of the issues that I had thought at first (so I
>apologize for jumping so fast). The Spanish University I mentioned did
>not seem to be, so the depth of the damage is unknown. No one knows
>how deep they got, but the fact that disguised sniffers were found is
>not comforting. Since all I know about this intrusion is second hand
>and off-the-record, it might be pure invention. So those considering
>asking (some already have), please refrain, I cannot tell who they are
>unless they come forward. But it is worth some thinking even if it
>just were an hypothetical case (similar cases have been reported
>before anyway).
>
Luckily, with our current setup, it is easy to boot net - install workstations
should a population of them become corrupted. The installation software is
protected. (It also helps to have fast 8mm tape drives in emergencies - luckily
we haven't had one in 2-3 years)
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug @
eng .
auburn .
edu
Pro is to Con as progress is to congress
References:
|
|
