[Dshield] Secure computing (was: Port 135)

Bob Savage bsavage at rnr-inc.com
Mon Oct 28 16:41:30 GMT 2002

I know this discussion is way over my head, but I don't understand the
resistance here to using a firewall of some kind as part of the program.
I must be missing a basic concept.  Why would this be looked at
differently in an educational institution?  Isn't it just common sense
to put a lock on the door even in a school?

Bob Savage

-----Original Message-----
From: Jan Johansson [mailto:janj at wenf.org]
Sent: Monday, October 28, 2002 9:35 AM
To: list at dshield.org
Subject: Re: [Dshield] Secure computing (was: Port 135)

On Sun, Oct 27, 2002 at 11:30:59PM -0500, David Kennedy CISSP wrote:
>At 11:51 PM 10/26/02 +0200, Jan Johansson wrote:
>>I will try to respond on all the comments that have been made.
><lots of stuff about AFS (good), Kerberos (good), and SSH (good)
>You didn't really respond to comments regarding this from your
>earlier post:
>At 05:58 PM 10/25/02 +0200, Jan Johansson wrote:
>>On Wed, Oct 16, 2002 at 10:17:05AM -0700, John Hardin wrote:
>>>If they're accessing this through your firewall, your firewall is
>>>misconfigured. I think that could be an effective argument against
>>What firewall? And where should I point it with 10 000 students.
>>Protect the Internet from me or me from the Internet. It is as
>>much harm on either side anyway which makes it useless.
>I for one would not object to your using a firewall to protect the
>rest of us on the Internet from your university and it's students,
>faculty and staff.  

As of today I have still to see why this would be needed. We are
not a .edu (wrong side of the pond).

This year we have had 19 complaints about abuse. 16 of them came
from central NOC that had noticed unusual traffic (they null
route and send mail for explanation).

DShield has our 3 C-nets as:
Source: 21
Destination: 73
Reports: 681

Looking at the sources I can rule out some. For example our AFS
servers has never been used to attack anyone. However AFS uses
callbacks to tell the client that files have changed. This can be
done several hours after the client fetch the file at which time
many statful packet filters will have timed out.

On the other hand I also see that other departments seems to be
far worse than us.

>>>135:139 SHOULD NOT be permitted in from or out to the Internet.
>>How should my students then be able to access their files from
>>home? Mapping shares over the Internet works and is easy to
>>use for the computer illiterate.
>This part really got my attention and you have not addressed it. 
>Using all those technologies I've snipped from your message are good.
> If you now want to dig yourself out of the hole you're in by saying
>you do it by AFS, SSH or a Kerberized solution, simply explain why
>did you respond in that way to John's "135:139" line?  

Frustration over that people try to solve every computer problem
with firewalls and laws. In this case (spam by windows message
server) I see that the source of the problem as (yet again) bad
implementation from Microsoft. So why is noone complaining? Fix
the real problem don't make a workaround. (Or rather make them
fix the problem).

>>month we had zero(0) logins to our samba server from outside
>>campus network[3]. The goal is to turn of all SMB services within
>>six(6) months.
>is your only windows-ish file sharing, that's not 10 000 students
>accessing their files from home; so why did you respond to John as
>you did?

This says that of 1200 students 0 has choosen to use the samba
server from home. In other words they use AFS and Kerberos FTP.

>You make no mention of how you enforce any policies about
>Windows drive sharing.

Computer policies make it impossible for Joe User to share a
drive. We also audit our network for shares on user maintained
machines. When found we educate the user on howto do without it.

>And with no firewall, no mention by you of default-deny router
>ACLing, the mention by you of 75 Unix boxes without mentioning
>the gratuitous services many default installations represent,
>the inference left is the weak security many of us have come to
>accept and expect from the EDU community (granted an
>over-simplification, but there you are).  

We don't accept default installation. Using the Solaris Jumpstart
it is very easy to remove unwanted services.

>Were it not for the dramatic increase of malicious traffic from worms
>and East Asia, the EDU's would still be at or near the top of TLD's
>originating attack traffic.  The US President's Advisor for cyber
>security has warned the EDU community here to act to secure their
>systems and networks.  Network managers (outside the EDU's) have
>learned how to deny AS or IP blocks belonging to China and Korea to
>cut the attack traffic from those countries.  It won't be a stretch
>to create an analogous list of AS's representing EDU's placing
>priorities on academic freedom and money too far above
>responsibilities to be good netizens.  

We seem to be in a quiet corner of the Internet as we do not see
the need for this. It might also be that we do not care about
portscans and CodeRed attacks. We trust that our machines are
patched and as secure as we can make them (but still

>>My solution to the Windows Messenger problem is to turn of the
>You're doing this on your 300 Windows workstations, without
>blocking 135:139, how?  And the clients your 10 000 students
>use, how?  If there's a way to do this that scales, I'd be
>interested to hear about it.  

We have not gotten to this stage yet as the SPAM is not a large
problem for us yet. The solution we are looking at is turning off
the "Messenger" service. That would be done in the Ghost image
and then the clients would be reinstalled.

Our next incarnation of Windows will use Active Directory so this
type of thing should be even simpler in the future.

If turning of the service is not an option one can always try a
host based packet filter or in worst case filtering in the border

I hope this answers your questions.

Dshield mailing list
Dshield at dshield.org
To change your subscription options (or unsubscribe), see:

More information about the list mailing list