alt.certification.cisco - Blocking Windows messenger while allowing legit traffic through

Author

Blocking Windows messenger while allowing legit traffic through

Robert Bowen

2002-12-27, 8:24 pm

We are experiencing the same problem many organizations that are connected
to the internet are experiencing. We were receiving Windows messenger
popups (an example of the ones we have received are on the bottom of this
web page http://www.stopmessengerspam.com/.)

We can block these at our gateway to the internet. We wish to block them
between networks within our network without blocking legitimate traffic. I
can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but then
our Windows users cannot login to our domain controllers.

I see that Cisco supports(ed) a Netbios ACL that could filter on the type of
NetBios traffic. Has anyone ever experimented with such an ACL?

Other than that does anyone know of a way to filter just the messenger
messages, and not the the "good" NetBios traffic?

Thanks,
Robert
bowenr@baldwin.k12.ny.us

Hansang Bae

2002-12-27, 9:24 pm

In article <yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net>,
bowenr@baldwin.k12.ny.us says...
> We are experiencing the same problem many organizations that are connected
> to the internet are experiencing. We were receiving Windows messenger
> popups (an example of the ones we have received are on the bottom of this
> web page http://www.stopmessengerspam.com/.)
> We can block these at our gateway to the internet. We wish to block them
> between networks within our network without blocking legitimate traffic. I
> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but then
> our Windows users cannot login to our domain controllers.
> I see that Cisco supports(ed) a Netbios ACL that could filter on the type of
> NetBios traffic. Has anyone ever experimented with such an ACL?

It filters NetBIOS traffic. Not NetBIOS over TCP (aka rfc NetBIOS or
NBT in Microsoftese). And it only kicks in if you're bridging (as I
recall).

> Other than that does anyone know of a way to filter just the messenger
> messages, and not the the "good" NetBios traffic?

I take it you can't turn off the service (as in you use print alerting?)

--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********

Bernie

2002-12-27, 10:24 pm

On Sat, 28 Dec 2002 01:56:46 GMT, "Robert Bowen"
<bowenr@baldwin.k12.ny.us> wrote:

>We are experiencing the same problem many organizations that are connected
>to the internet are experiencing. We were receiving Windows messenger
>popups (an example of the ones we have received are on the bottom of this
>web page http://www.stopmessengerspam.com/.)
>
>We can block these at our gateway to the internet. We wish to block them
>between networks within our network without blocking legitimate traffic. I
>can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but then
>our Windows users cannot login to our domain controllers.
>
>I see that Cisco supports(ed) a Netbios ACL that could filter on the type of
>NetBios traffic. Has anyone ever experimented with such an ACL?
>
>Other than that does anyone know of a way to filter just the messenger
>messages, and not the the "good" NetBios traffic?

As with so many things from MS, you pretty much have to do some
detective work. It is hard to find that level of documentation unless
you work there or just happen to run across someone that has
previously done the investigative work themselves.

I'd suggest using a sniffer and try to manually duplicate the type of
messages you are wanting to block. See if they use the same port
numbers that you have already identified above. If so, then you
probably cannot block them at the network level. If it turns out they
use unique port numbers then experiment with blocking them (in a lab
environment of course) to see if any other vital services depend on
those ports.

If not, then experiment with blocking them at the system level. I
believe I remember that you can turn some of that off in the registry.
When I was a sysadmin, I loved it when I could find settings in the
registry as that meant I could easily control them from my desktop. I
used the replication service (NT4) to copy the netlogon share to all
domain controllers and then I put policy files in the share. I
manually created policy templates to control the specific settings I
needed to control and used those templates to create the policy files.

So step one, try to figure out if the message service uses a unique
port. If not, step two is to see if you can find a registry setting
that you can manipulate.

That registry is a vast landscape of settings. Believe me, I'm sure
it is there...just a matter of finding it. I used to work at MS, and
I had to discover various registry settings through trial and error
myself. Even internally the lack of documentation is astounding.

--Bernie

Jeff C

2002-12-27, 11:24 pm

"Bernie" <Bernie@weekend.com> wrote in message
news:FB5EEAED3007B4BF.A2DDE4DCB5F6114F.D1B50F6912D68B85@lp.airnews.net...
> On Sat, 28 Dec 2002 01:56:46 GMT, "Robert Bowen"
> <bowenr@baldwin.k12.ny.us> wrote:
>
> >We were receiving Windows messenger popups (an example of
> >the ones we have received are on the bottom of this web page
> >http://www.stopmessengerspam.com/.)
> >
> >I can implement an ACL that blocks TCP ports 135-139 and UDP 135-139
> >but then our Windows users cannot login to our domain controllers.
> >
>
> As with so many things from MS, you pretty much have to do some
> detective work. It is hard to find that level of documentation unless
> you work there or just happen to run across someone that has
> previously done the investigative work themselves.

I've found that UDP port 135 seems to be the key. IIRC from the run
prompt type in "netsend IPaddress MESSAGE" (NT kernal) and you
can send a message to yourself or your buddies. When we were getting
hit with this we already had TCP blocks for the ports you mentioned I
added the UDP blocks and found that the 135 port had a hugh number
of hits in a very short amount of time.

I only block this to and from the big bad world of the Internet. So that
we can continue to log into our domain controllers and file shares. If you
are allowing users to log into your domain from across the Internet without
some type of VPN I'd be afraid.

-Jeff

Leonid Rosenboim

2002-12-28, 3:24 am

This is a tough one -
basically, if you block port 135, which the messanger uses, you will
thereby block a whole lot of other "legit" services, because this is the
RPC service which is used throughout the Windows network service.

But at a second thought, there is a more substantial change you might
want to consider -
If you clearly define the role of each computer on your network, some will
be defined as servers, others - clients, and the servers will have
particular
roles assigned to them, so you will end up with a graph depicting which
clients
need to access which servers and so on.

Then you could augment the network into segments, which parallel workgroups,
connect workgroup servers to their assigned subnet (could be implemented
with
VLANs), and have the servers allowed to communicate between eachother,
but never ever allow PCs assigned client role to communicate directly
between
eachother, or with servers in other workgroups.

Among other benefits, you will have the popups limitted within the
workgroups.

-- Happy New Year!
-----------------------------------------------------------------------
Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
Consultant Email: my first name at consultant dot com

"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
> We are experiencing the same problem many organizations that are connected
> to the internet are experiencing. We were receiving Windows messenger
> popups (an example of the ones we have received are on the bottom of this
> web page http://www.stopmessengerspam.com/.)
>
> We can block these at our gateway to the internet. We wish to block them
> between networks within our network without blocking legitimate traffic.
I
> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
then
> our Windows users cannot login to our domain controllers.
>
> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
of
> NetBios traffic. Has anyone ever experimented with such an ACL?
>
> Other than that does anyone know of a way to filter just the messenger
> messages, and not the the "good" NetBios traffic?
>
> Thanks,
> Robert
> bowenr@baldwin.k12.ny.us
>
>
>
>

Bernie

2002-12-28, 11:24 am

On Sat, 28 Dec 2002 10:59:04 +0200, "Leonid Rosenboim"
<My_1st_name@Consultant.Com> wrote:

>This is a tough one -
>basically, if you block port 135, which the messanger uses, you will
>thereby block a whole lot of other "legit" services, because this is the
>RPC service which is used throughout the Windows network service.
>
>But at a second thought, there is a more substantial change you might
>want to consider -
>If you clearly define the role of each computer on your network, some will
>be defined as servers, others - clients, and the servers will have
>particular
>roles assigned to them, so you will end up with a graph depicting which
>clients
>need to access which servers and so on.
>
>Then you could augment the network into segments, which parallel workgroups,
>connect workgroup servers to their assigned subnet (could be implemented
>with
>VLANs), and have the servers allowed to communicate between eachother,
>but never ever allow PCs assigned client role to communicate directly
>between
>eachother, or with servers in other workgroups.
>
>Among other benefits, you will have the popups limitted within the
>workgroups.

But if you route between workgroups (which I would imagine you would
do) then popup messages likewise get routed between workgroups. Am I
missing something in your description?

>-- Happy New Year!
>-----------------------------------------------------------------------
> Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
> Consultant Email: my first name at consultant dot com
>
>
>"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
>news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
>> We are experiencing the same problem many organizations that are connected
>> to the internet are experiencing. We were receiving Windows messenger
>> popups (an example of the ones we have received are on the bottom of this
>> web page http://www.stopmessengerspam.com/.)
>>
>> We can block these at our gateway to the internet. We wish to block them
>> between networks within our network without blocking legitimate traffic.
>I
>> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
>then
>> our Windows users cannot login to our domain controllers.
>>
>> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
>of
>> NetBios traffic. Has anyone ever experimented with such an ACL?
>>
>> Other than that does anyone know of a way to filter just the messenger
>> messages, and not the the "good" NetBios traffic?
>>
>> Thanks,
>> Robert
>> bowenr@baldwin.k12.ny.us
>>
>>
>>
>>
>

--Bernie

AEM Networking

2002-12-28, 11:24 am

If you want to block MSN Messenger, which can now be tunnelled via HTTP with
MSN 5.0, block all of MSN's Messenger Servers with an ACL at your internet
connection.

Otherwise, remove it from all users PC's and remove their rights to install
software...It is always good to find a compromise with users so that you
don't have to battle them in the future.

www.aemnetworking.com

"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
> We are experiencing the same problem many organizations that are connected
> to the internet are experiencing. We were receiving Windows messenger
> popups (an example of the ones we have received are on the bottom of this
> web page http://www.stopmessengerspam.com/.)
>
> We can block these at our gateway to the internet. We wish to block them
> between networks within our network without blocking legitimate traffic.
I
> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
then
> our Windows users cannot login to our domain controllers.
>
> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
of
> NetBios traffic. Has anyone ever experimented with such an ACL?
>
> Other than that does anyone know of a way to filter just the messenger
> messages, and not the the "good" NetBios traffic?
>
> Thanks,
> Robert
> bowenr@baldwin.k12.ny.us
>
>
>
>

Bernie

2002-12-28, 12:24 pm

On Sat, 28 Dec 2002 16:56:51 GMT, "AEM Networking"
<aemnetworking@aemnetworking.com> wrote:

>If you want to block MSN Messenger, which can now be tunnelled via HTTP with
>MSN 5.0, block all of MSN's Messenger Servers with an ACL at your internet
>connection.

He is not talking about MSN messaging. He is talking about the
functionality of the NT OS to send popup messages to other NT
machines.

>Otherwise, remove it from all users PC's and remove their rights to install
>software...It is always good to find a compromise with users so that you
>don't have to battle them in the future.
>
>www.aemnetworking.com
>
>
>"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
>news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
>> We are experiencing the same problem many organizations that are connected
>> to the internet are experiencing. We were receiving Windows messenger
>> popups (an example of the ones we have received are on the bottom of this
>> web page http://www.stopmessengerspam.com/.)
>>
>> We can block these at our gateway to the internet. We wish to block them
>> between networks within our network without blocking legitimate traffic.
>I
>> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
>then
>> our Windows users cannot login to our domain controllers.
>>
>> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
>of
>> NetBios traffic. Has anyone ever experimented with such an ACL?
>>
>> Other than that does anyone know of a way to filter just the messenger
>> messages, and not the the "good" NetBios traffic?
>>
>> Thanks,
>> Robert
>> bowenr@baldwin.k12.ny.us
>>
>>
>>
>>
>

--Bernie

emailNOSPAM@sover.net

2002-12-28, 6:24 pm

See text

______________________________
______
Talk is cheap. Supply exceeds Demand.

On Sat, 28 Dec 2002, Bernie wrote:

>
>
> On Sat, 28 Dec 2002 10:59:04 +0200, "Leonid Rosenboim"
> <My_1st_name@Consultant.Com> wrote:
>
> >This is a tough one -
> >basically, if you block port 135, which the messanger uses, you will
> >thereby block a whole lot of other "legit" services, because this is the
> >RPC service which is used throughout the Windows network service.
> >
> >But at a second thought, there is a more substantial change you might
> >want to consider -
> >If you clearly define the role of each computer on your network, some will
> >be defined as servers, others - clients, and the servers will have
> >particular
> >roles assigned to them, so you will end up with a graph depicting which
> >clients
> >need to access which servers and so on.
> >
> >Then you could augment the network into segments, which parallel workgroups,
> >connect workgroup servers to their assigned subnet (could be implemented
> >with
> >VLANs), and have the servers allowed to communicate between eachother,
> >but never ever allow PCs assigned client role to communicate directly
> >between
> >eachother, or with servers in other workgroups.
> >
> >Among other benefits, you will have the popups limitted within the
> >workgroups.
>
> But if you route between workgroups (which I would imagine you would
> do) then popup messages likewise get routed between workgroups. Am I
> missing something in your description?

No, that is the point. Workgroups do not need to communicate with each
other if you have a central login server. All you need to do is allow
everyone to communicate with login server (and any other legitimate
servers that use port 135). Any other communication should be explicitly
blocked. The login server must also be allowed to freely communicate with
all of the hosts of course. Here is an example of what I am talking
about :

On each Ethernet port on the router you should try an ACL similar to this
(check syntax):

access-group 110 in
access-group 111 out
access-list 110 allow udp any host 192.168.10.10 eq 135
access-list 110 deny udp any any eq 135
access-list 111 allow udp host 192.168.10.10 any eq 135
access-list 111 deny udp any any eq 135

This should allow every machine to communicate with 192.168.10.10 (NT
domain server) and stop all other communications across different
networks. There is no other good way to stop the communication within a
subnet though (layer 4 switching I suppose).

Of course if you do not have a central domain controller or login server
and are still using work groups there may be no way to stop it.

>
> >-- Happy New Year!
> >-----------------------------------------------------------------------
> > Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
> > Consultant Email: my first name at consultant dot com
> >
> >
> >"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
> >news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
> >> We are experiencing the same problem many organizations that are connected
> >> to the internet are experiencing. We were receiving Windows messenger
> >> popups (an example of the ones we have received are on the bottom of this
> >> web page http://www.stopmessengerspam.com/.)
> >>
> >> We can block these at our gateway to the internet. We wish to block them
> >> between networks within our network without blocking legitimate traffic.
> >I
> >> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
> >then
> >> our Windows users cannot login to our domain controllers.
> >>
> >> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
> >of
> >> NetBios traffic. Has anyone ever experimented with such an ACL?
> >>
> >> Other than that does anyone know of a way to filter just the messenger
> >> messages, and not the the "good" NetBios traffic?
> >>
> >> Thanks,
> >> Robert
> >> bowenr@baldwin.k12.ny.us
> >>
> >>
> >>
> >>
> >
>
>
> --Bernie
>

Bernie

2002-12-28, 6:24 pm

On Sat, 28 Dec 2002 18:26:41 -0500, emailNOSPAM@sover.net wrote:

>No, that is the point. Workgroups do not need to communicate with each
>other if you have a central login server. All you need to do is allow
>everyone to communicate with login server (and any other legitimate
>servers that use port 135). Any other communication should be explicitly
>blocked. The login server must also be allowed to freely communicate with
>all of the hosts of course. Here is an example of what I am talking
>about :
>
>On each Ethernet port on the router you should try an ACL similar to this
>(check syntax):
>
>access-group 110 in
>access-group 111 out
>access-list 110 allow udp any host 192.168.10.10 eq 135
>access-list 110 deny udp any any eq 135
>access-list 111 allow udp host 192.168.10.10 any eq 135
>access-list 111 deny udp any any eq 135
>
>This should allow every machine to communicate with 192.168.10.10 (NT
>domain server) and stop all other communications across different
>networks. There is no other good way to stop the communication within a
>subnet though (layer 4 switching I suppose).
>
>Of course if you do not have a central domain controller or login server
>and are still using work groups there may be no way to stop it.

Personally, I am not a big believer in this philosophy, i.e. the
philosophy of the zealously locking down everything. I say philosophy
because it generally mirrors the attitude of the particular company.
If from the top down, the CEO breeds an attitude of distrust and
paranoia, then the network will be run that way too. I am not saying
that is *your* attitude per se; I am speaking in general terms.

I don't believe in locking things down to that degree from a
philosophical point of view, but that is just my opinion. I believe
giving an element of freedom to employees is a better way to go. If
they want to share files, I don't want to prevent them. Sure they can
abuse it, but also I can abuse my authority as network administrator
in the over-secure environment. If you force users to work around
your policies then next thing you know, they bring in a small hub and
start directly connecting workstations together in order to get their
jobs done and share files. Then if you have a flat network and
spanning tree turned off on user ports you now have loops and network
problems. Sometimes you create bigger problems by locking everything
down, and that is partly why I don't believe in it. The other reason
is that I believe in giving people as many freedoms as is reasonable
to give and handle abuses on a case by case basis.

But if the only goal is to prevent popup NT messages, then yes problem
solved!!!

--Bernie

Bernie

2002-12-28, 7:24 pm

On Sat, 28 Dec 2002 18:23:27 -0600, Bernie <Bernie@weekend.com> wrote:

I should qualify this by saying that I am assuming that some
functionality is lost between workstations. Now this may not be the
case, and my assumption wrong. It probably doesn't break file
sharing, but something might be broken. So I'd rather go after the
individual who is causing the problem than breaking functionality that
might otherwise be useful.

>Personally, I am not a big believer in this philosophy, i.e. the
>philosophy of the zealously locking down everything. I say philosophy
>because it generally mirrors the attitude of the particular company.
>If from the top down, the CEO breeds an attitude of distrust and
>paranoia, then the network will be run that way too. I am not saying
>that is *your* attitude per se; I am speaking in general terms.
>
>I don't believe in locking things down to that degree from a
>philosophical point of view, but that is just my opinion. I believe
>giving an element of freedom to employees is a better way to go. If
>they want to share files, I don't want to prevent them. Sure they can
>abuse it, but also I can abuse my authority as network administrator
>in the over-secure environment. If you force users to work around
>your policies then next thing you know, they bring in a small hub and
>start directly connecting workstations together in order to get their
>jobs done and share files. Then if you have a flat network and
>spanning tree turned off on user ports you now have loops and network
>problems. Sometimes you create bigger problems by locking everything
>down, and that is partly why I don't believe in it. The other reason
>is that I believe in giving people as many freedoms as is reasonable
>to give and handle abuses on a case by case basis.
>
>But if the only goal is to prevent popup NT messages, then yes problem
>solved!!!
>
>--Bernie

--Bernie

Philip D'Ath

2002-12-28, 7:24 pm

Depending on what equipment you have, you have be able to designate
workstation ports as private VLAN edges, so they can't talk to each otehr at
all.
You might be able to NBAR on a router to stop the MSN traffic as well.
NBAR is able to look into packets, and offer greater control that pure
access lists.

"Robert Bowen" <bowenr@baldwin.k12.ny.us> wrote in message
news:yx7P9.176140$a8.123076@news4.srv.hcvlny.cv.net...
> We are experiencing the same problem many organizations that are connected
> to the internet are experiencing. We were receiving Windows messenger
> popups (an example of the ones we have received are on the bottom of this
> web page http://www.stopmessengerspam.com/.)
>
> We can block these at our gateway to the internet. We wish to block them
> between networks within our network without blocking legitimate traffic.
I
> can implement an ACL that blocks TCP ports 135-139 and UDP 135-139 but
then
> our Windows users cannot login to our domain controllers.
>
> I see that Cisco supports(ed) a Netbios ACL that could filter on the type
of
> NetBios traffic. Has anyone ever experimented with such an ACL?
>
> Other than that does anyone know of a way to filter just the messenger
> messages, and not the the "good" NetBios traffic?
>
> Thanks,
> Robert
> bowenr@baldwin.k12.ny.us
>
>
>
>

Leonid Rosenboim

2002-12-29, 2:24 am

"Bernie" <Bernie@weekend.com> wrote in message
news:395C3BA7A6B64C0B.72DBE8B3A82F44DE.1D511F7EDE05FA41@lp.airnews.net...
[snip]
> Personally, I am not a big believer in this philosophy, i.e. the
> philosophy of the zealously locking down everything. I say philosophy
> because it generally mirrors the attitude of the particular company.
> If from the top down, the CEO breeds an attitude of distrust and
> paranoia, then the network will be run that way too. I am not saying
> that is *your* attitude per se; I am speaking in general terms.
>
> I don't believe in locking things down to that degree from a
> philosophical point of view, but that is just my opinion. I believe
> giving an element of freedom to employees is a better way to go. If
> they want to share files, I don't want to prevent them. Sure they can
> abuse it, but also I can abuse my authority as network administrator
> in the over-secure environment. If you force users to work around
> your policies then next thing you know, they bring in a small hub and
> start directly connecting workstations together in order to get their
> jobs done and share files. Then if you have a flat network and
> spanning tree turned off on user ports you now have loops and network
> problems. Sometimes you create bigger problems by locking everything
> down, and that is partly why I don't believe in it. The other reason
> is that I believe in giving people as many freedoms as is reasonable
> to give and handle abuses on a case by case basis.
>
> But if the only goal is to prevent popup NT messages, then yes problem
> solved!!!
>
> --Bernie

The issue here is not distrust in the employees, but distrust of the
software
running on their computers. Please note that if users can e-mail a file to
one
another, this should be a sufficient (albeit rudimentary) means of sharing
information within the company, and information sharing should be encouraged
by all means.

Another means to share files is through a server shared by the two users,
and if is quite possible to have all domain servers accesible to all users,
if policy allows.

It is the operating systems that I think should not be trusted, and by using
this
"divide and concour" approach, problems can be effectively isolated into
subnebts,
and indeed, popup messanger is by far not the worst case scenarion, but it
works well to demonstrate the Windows network architecture, which does
not allow one to control specific services, and letds itself easily to all
sorts of
dangerous abose.

- Leonid

Bernie

2002-12-29, 1:24 pm

On Sun, 29 Dec 2002 09:50:57 +0200, "Leonid Rosenboim"
<My_1st_name@Consultant.Com> wrote:

>The issue here is not distrust in the employees, but distrust of the
>software
>running on their computers.

Understood, but I was under the impression that the goal was to
eliminate the abuse of popups. I don't deal with NOS's anymore, but
back when I did, I never had a problem with popups that were not
related to individuals using them. So there is a user behind such
abuses, not software doing these things by themselves. Blocking them
from outside the company makes sense, but within the company, I'd
prefer to deal with the abusers directly. And that is where I
acknowledge that this may simply be a philosophical difference people
have.

>Please note that if users can e-mail a file to
>one
>another, this should be a sufficient (albeit rudimentary) means of sharing
>information within the company, and information sharing should be encouraged
>by all means.

I was using that as an example. But even so, there are issues with
using email of file servers. With email, there is usually a size
limit imposed on sending or storing things in your inbox. I have to
regularly work around these limits at my work. With central file
servers, users put files out there and then leave them until eternity.
So then you have to manage the space on the back end, a task I grew to
loathe. I'd rather them share directly, but that is my opinion shaped
by past experiences. Anyway, this detracts from the greater issue of
lost functionality, which was my real point (file sharing is just a
simple example).

>Another means to share files is through a server shared by the two users,
>and if is quite possible to have all domain servers accesible to all users,
>if policy allows.
>
>It is the operating systems that I think should not be trusted, and by using
>this
>"divide and concour" approach, problems can be effectively isolated into
>subnebts,
>and indeed, popup messanger is by far not the worst case scenarion, but it
>works well to demonstrate the Windows network architecture, which does
>not allow one to control specific services, and letds itself easily to all
>sorts of
>dangerous abose.

Sure. I agree MS puts neat functionality over security. But I feel
that within a company environment that abusers should be dealt with as
a result of their actions, not prevented from trying. IOW, I believe
in trust (with verification) not mistrust (with prevention). While I
understand the point about not trusting the software, I also think
that in most cases there is also a user involved. Even most MS
software doesn't go about doing malicious things all by themselves
(excluding bugs, which all software has).

--Bernie

Leonid Rosenboim

2002-12-29, 2:24 pm

Bernie,

If all causes of abuse where by humans, I would agree, and in fact I used to
think along the same lines you do, but nower days, malware is everywhere,
and in a big corporation with critical resources, I would not necesarily
trust the anti-virus as my only line of defense against all sorts of worms
trojans and the like.
Therefore, structuring your network such as to allow information to flow
only where it is supposed to, damage by either human or malware abuser can
be isolated in to a single area of the network, limitting the overal damage,
and easying the solution (it is easier to scan 20 PCs when you know which
workgroup has a problem, then to scan a couple of thosands if all you got is
a flat network).

Besides, there are parts of the network you would definitely not trust
anyone with,. the finance department would be a good example. How else do
you avoid disgrunted employees peeking into their peer's or manager's salary
?

Yes, I do remember this was all about annoying popup's, but I have
intentionally generalized this discussion, only to illistrage the basis for
my original recommendation.

--
-----------------------------------------------------------------------
Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
Consultant Email: my first name at consultant dot com

"Bernie" <Bernie@weekend.com> wrote in message
news:13F7BD1A81650587.BE65C77B018204F9.1E26D93832F5F1A7@lp.airnews.net...
> On Sun, 29 Dec 2002 09:50:57 +0200, "Leonid Rosenboim"
> <My_1st_name@Consultant.Com> wrote:
>
>
> >The issue here is not distrust in the employees, but distrust of the
> >software
> >running on their computers.
>
> Understood, but I was under the impression that the goal was to
> eliminate the abuse of popups. I don't deal with NOS's anymore, but
> back when I did, I never had a problem with popups that were not
> related to individuals using them. So there is a user behind such
> abuses, not software doing these things by themselves. Blocking them
> from outside the company makes sense, but within the company, I'd
> prefer to deal with the abusers directly. And that is where I
> acknowledge that this may simply be a philosophical difference people
> have.
>
> >Please note that if users can e-mail a file to
> >one
> >another, this should be a sufficient (albeit rudimentary) means of
sharing
> >information within the company, and information sharing should be
encouraged
> >by all means.
>
> I was using that as an example. But even so, there are issues with
> using email of file servers. With email, there is usually a size
> limit imposed on sending or storing things in your inbox. I have to
> regularly work around these limits at my work. With central file
> servers, users put files out there and then leave them until eternity.
> So then you have to manage the space on the back end, a task I grew to
> loathe. I'd rather them share directly, but that is my opinion shaped
> by past experiences. Anyway, this detracts from the greater issue of
> lost functionality, which was my real point (file sharing is just a
> simple example).
>
> >Another means to share files is through a server shared by the two users,
> >and if is quite possible to have all domain servers accesible to all
users,
> >if policy allows.
> >
> >It is the operating systems that I think should not be trusted, and by
using

> >this
> >"divide and concour" approach, problems can be effectively isolated into
> >subnebts,
> >and indeed, popup messanger is by far not the worst case scenarion, but
it
> >works well to demonstrate the Windows network architecture, which does
> >not allow one to control specific services, and letds itself easily to
all
> >sorts of
> >dangerous abose.
>
> Sure. I agree MS puts neat functionality over security. But I feel
> that within a company environment that abusers should be dealt with as
> a result of their actions, not prevented from trying. IOW, I believe
> in trust (with verification) not mistrust (with prevention). While I
> understand the point about not trusting the software, I also think
> that in most cases there is also a user involved. Even most MS
> software doesn't go about doing malicious things all by themselves
> (excluding bugs, which all software has).
>
> --Bernie

Sypher

2003-03-21, 2:09 am

A Simple HOW TO
Wndows XP
1. Click on the Start button and open the control panel.
2. Open the Performance and Maintenance control panel and go to Administrative Tools.
3. Now double-click on Services, then scroll to Messenger.
4. Double-click Messenger and click Stop to stop the service.
5. Change the startup type to Disable and click Apply at the bottom.
6. Click OK to exit window.

Windows 2000
1. Click on the Start button -> Settings -> Control Panel.
2. Double click on Administrative Tools.
3. Now double-click on Services, then scroll to Messenger.
4. Double-click Messenger and click Stop to stop the service.
5. Change the startup type to Disable and click Apply at the bottom.
6. Click OK to exit window.

O_- Now why did you all go to school for these things?

Bernie

2003-03-21, 10:24 am

On Fri, 21 Mar 2003 03:09:22 -0500, Sypher
<Sypher.kmtoc@mail.examnotes.net> wrote:

Obviously. But this wasn't the question that was asked. A more
difficult task (yet still manageable) is how do you do this on all you
PCs on the network without having to go to every office?

But the real issue here was how to block messenger traffic coming in
from outside you network while still maintaining the internal ability
to use the messenger service (I believe it has *some* usefulness).

>A Simple HOW TO
>Wndows XP
>1. Click on the Start button and open the control panel.
>2. Open the Performance and Maintenance control panel and go to
>Administrative Tools.
>3. Now double-click on Services, then scroll to Messenger.
>4. Double-click Messenger and click Stop to stop the service.
>5. Change the startup type to Disable and click Apply at the bottom.
>6. Click OK to exit window.
>
>
>Windows 2000
>1. Click on the Start button -> Settings -> Control Panel.
>2. Double click on Administrative Tools.
>3. Now double-click on Services, then scroll to Messenger.
>4. Double-click Messenger and click Stop to stop the service.
>5. Change the startup type to Disable and click Apply at the bottom.
>6. Click OK to exit window.
>
>O_- Now why did you all go to school for these things?
>
>---
>View this thread: http://www.examnotes.net/article87984.html
>Sypher------------------------------------------------------------------------
>Sypher's Profile: http://www.examnotes.net/forums/mem...o&userid=174000

--Bernie

DJPsymiley

2003-03-23, 9:23 pm

> Obviously. But this wasn't the question that was asked. A more
> difficult task (yet still manageable) is how do you do this on all you
> PCs on the network without having to go to every office?
>
> But the real issue here was how to block messenger traffic coming in
> from outside you network while still maintaining the internal ability
> to use the messenger service (I believe it has *some* usefulness).

You cant keep messenger to use internally as every instance requires need to
log to MS servers.

You can block messenger by blocking the servers used and/or ports.

Sorry, i dont have servers/ports to hand, but the net may have them or a
net-traffic analyser should show up info.

Dan.

|{evin

2003-03-23, 10:23 pm

On Mon, 24 Mar 2003 03:03:50 -0000, "DJPsymiley"
<amplitude@MAPSSPAMkoloth.co.uk> wrote:

>> Obviously. But this wasn't the question that was asked. A more
>> difficult task (yet still manageable) is how do you do this on all you
>> PCs on the network without having to go to every office?
>>
>> But the real issue here was how to block messenger traffic coming in
>> from outside you network while still maintaining the internal ability
>> to use the messenger service (I believe it has *some* usefulness).
>
>You cant keep messenger to use internally as every instance requires need to
>log to MS servers.
>
>You can block messenger by blocking the servers used and/or ports.
>
>Sorry, i dont have servers/ports to hand, but the net may have them or a
>net-traffic analyser should show up info.
>
>Dan.
>

MSN messenger or the Messenger service? If the messenger service,
block incoming netbios traffic.

Bernie

2003-03-23, 10:23 pm

On Mon, 24 Mar 2003 03:26:52 GMT, "|{evin" <You@dont.need> wrote:

>On Mon, 24 Mar 2003 03:03:50 -0000, "DJPsymiley"
><amplitude@MAPSSPAMkoloth.co.uk> wrote:
>
>>> Obviously. But this wasn't the question that was asked. A more
>>> difficult task (yet still manageable) is how do you do this on all you
>>> PCs on the network without having to go to every office?
>>>
>>> But the real issue here was how to block messenger traffic coming in
>>> from outside you network while still maintaining the internal ability
>>> to use the messenger service (I believe it has *some* usefulness).
>>
>>You cant keep messenger to use internally as every instance requires need to
>>log to MS servers.
>>
>>You can block messenger by blocking the servers used and/or ports.
>>
>>Sorry, i dont have servers/ports to hand, but the net may have them or a
>>net-traffic analyser should show up info.
>>
>>Dan.
>>
>
>MSN messenger or the Messenger service? If the messenger service,
>block incoming netbios traffic.

This is an old thread. Summary was that someone wanted to block the
Windows messenger popup messages, not the MSN messenger traffic. It
was discussed at length different approaches to filtering the traffic
in question.

This thread was resurrected when someone recently stated to simply
turn off the messenger service on every PC. If you want to see the
discussion, look it up on google...there isn't much use in rehashing
this all over again. There isn't much more to add to it.

--Bernie

Ash Brown

2003-03-25, 10:24 am

This doesnt stop windows messenger. It even says it in the service
description if you took the time to look.... This is a simple messenging
service within the windows platform for the "netsend" command.

"Transmits net send and Alerter service messages between clients and
servers. This service is not related to Windows Messenger. If this service
is stopped, Alerter messages will not be transmitted. If this service is
disabled, any services that explicitly depend on it will fail to start."

O_- Now why did you all go to school for these things? <==perhaps you should
go back to school?

"Sypher" <Sypher.kmtoc@mail.examnotes.net> wrote in message
news:Sypher.kmtoc@mail.examnotes.net...
>
> A Simple HOW TO
> Wndows XP
> 1. Click on the Start button and open the control panel.
> 2. Open the Performance and Maintenance control panel and go to
> Administrative Tools.
> 3. Now double-click on Services, then scroll to Messenger.
> 4. Double-click Messenger and click Stop to stop the service.
> 5. Change the startup type to Disable and click Apply at the bottom.
> 6. Click OK to exit window.
>
>
> Windows 2000
> 1. Click on the Start button -> Settings -> Control Panel.
> 2. Double click on Administrative Tools.
> 3. Now double-click on Services, then scroll to Messenger.
> 4. Double-click Messenger and click Stop to stop the service.
> 5. Change the startup type to Disable and click Apply at the bottom.
> 6. Click OK to exit window.
>
> O_- Now why did you all go to school for these things?
>
> ---
> View this thread: http://www.examnotes.net/article87984.html
>
Sypher----------------------------------------------------------------------
--
> Sypher's Profile:
http://www.examnotes.net/forums/mem...o&userid=174000
>

Sponsored Links