Selective SMB firewallin

Archived from groups: comp.security.firewalls (More info?)

On 21 Apr 2004 11:00:31 -0400, Gary Algier spoketh

>
>Does any know how to write a "proper" set of rules that will
>allow the laptop to act as a client, but not as a server on
>the kitchen-sink services on ports 137-139 and 445?

Disable the "Server" service on the laptops, and they won't be sharing
anything anywhere.


Lars M. Hansen
www.hansenonline.net
Remove "bad" from my e-mail address to contact me.
"If you try to fail, and succeed, which have you done?"

Archived from groups: comp.security.firewalls (More info?)

Lars M. Hansen <badnews@hansenonline.net> writes:

> On 21 Apr 2004 11:00:31 -0400, Gary Algier spoketh
>
> >
> >Does any know how to write a "proper" set of rules that will
> >allow the laptop to act as a client, but not as a server on
> >the kitchen-sink services on ports 137-139 and 445?
>
> Disable the "Server" service on the laptops, and they won't be sharing
> anything anywhere.
>
>
> Lars M. Hansen
> www.hansenonline.net
> Remove "bad" from my e-mail address to contact me.
> "If you try to fail, and succeed, which have you done?"

I tried that, with no firewall and I can print. I modified
the firewall to allow inbound to ports 137-139 & 445 but
without that service and I can still print. This is
just what I need (assuming no bugs in M$Windows...).

One little problem:
How do I keep them from reenabling it? Perhaps we can
remove some files associated with the service? I checked
and the "services.exe" file is used by 16 different services.
Now if they had just separated out the server code from the
client code, I could remove the server code.

The Symantic Firewall has the ability to block to given
executable files, but not to given services. I created
a rule to block to the services.exe file and that broke
it.

Thanks for the help, we are getting a bit closer...

--
Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758
Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033

Nielsen's First Law of Computer Manuals:
People don't read documentation voluntarily.

Archived from groups: comp.security.firewalls (More info?)

On 21 Apr 2004 13:44:37 -0400, Gary Algier spoketh


>
>I tried that, with no firewall and I can print. I modified
>the firewall to allow inbound to ports 137-139 & 445 but
>without that service and I can still print. This is
>just what I need (assuming no bugs in M$Windows...).
>
>One little problem:
>How do I keep them from reenabling it? Perhaps we can
>remove some files associated with the service? I checked
>and the "services.exe" file is used by 16 different services.
>Now if they had just separated out the server code from the
>client code, I could remove the server code.
>
>The Symantic Firewall has the ability to block to given
>executable files, but not to given services. I created
>a rule to block to the services.exe file and that broke
>it.
>
>Thanks for the help, we are getting a bit closer...


Non-administrators should not have local admin rights on their
computers. Only admins can re-enable a disabled service.

Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

Archived from groups: comp.security.firewalls (More info?)

Gary Algier wrote:
> I have been struggling with how to protect company laptops while not
> in the office, yet allow access to resources when here. The biggest
> problem is the whole "file sharing" boondoggle.
>
> Here's the situation:
>
> When in the office, I at least want to be able to allow my users
> to access the company file and print servers (which run Samba). They
> do not need to share files the other way (the laptop need not be
> a server) as they can always put files they want to share on
> a server.
>

<BIG SNIP>

It sounds like you are trying to control behavior of intelligent
users with dumb machines and software. It might work with some
users, some of the time, but it will never work with all the
users, all the time.

A half-way smart, half-way computer savvy user will be able to
break whatever you come up with, on any computer he physically
controls. Removing the CD and floppy drives, and protecting the
BIOS with a password would add some barriers . . . but it still
won't stop anyone who's determined.

And, if they've got a knowledgeable computer-savvy friend,
forget about it! I don't know of a way you can protect a Windows
system from someone with physical access, a Knoppix CD, and
another CD of DOS & Windows tools readily available on the
Internet. (For that matter, Linux systems can't be protected
in that situation, either: Linux was not designed to be secure
against someone with physical access.)

It's amazing how many posts you can find on Google from corp
laptop users trying to figure out how to break the controls or
limits on their systems, so they can browse porn at home, or
do personal work, and so on. You'd probably be dismayed to see
how much useful aid they get, toward those ends.

To make matters worse, you are chained (as are most of us) to a
Windows OS that has always been designed to make it easier and
easier for computer novices to 'do stuff', and that doesn't
make it very easy to setup users as "Power Users" with no other
privileges.

I'm guessing that your closest approach to what you want would
be achieved with a combination of a clear use policy; a punitive,
but reasonable, violation policy; a fair, but effective return
scan policy (scans before re-entry to the network, for both
policy violations and for malware); AND effective,
well-presented training explaining it all.

That's a pain, of course.

Archived from groups: comp.security.firewalls (More info?)

Lars M. Hansen <badnews@hansenonline.net> writes:

> On 21 Apr 2004 13:44:37 -0400, Gary Algier spoketh
[...]
>
> Non-administrators should not have local admin rights on their
> computers. Only admins can re-enable a disabled service.
>
Oh, did I forget to mention: everyone seems to think they
need admin rights... to install s/w, to change networking
params so they can use it at home,... Management gives in
so we need a technical solution. I came up with one:
I deleted the registry entries associated with the services
in question so they don't even show.

--
Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758
Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033

Nielsen's First Law of Computer Manuals:
People don't read documentation voluntarily.