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

Report this post to a moderator

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.
******************************
******************************
********

Report this post to a moderator

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

Report this post to a moderator

"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

Report this post to a moderator

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
>
>
>
>

Report this post to a moderator

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

Report this post to a moderator

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
>
>
>
>

Report this post to a moderator

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

Report this post to a moderator

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
>

Report this post to a moderator

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

Report this post to a moderator