Messenger spam sneaks thru firewall - how?? What additional ports do we block?

We've been getting some windows messenger spam - it's breaking thru our firewall to attack one of machines with a public IP.  

We are blocking ports 135-139 tcp and udp.  we are also blocking 1025-1029 udp.

what additional ports should we block?  

It looks like the messenger spammers have found and are using another porthole.

Note: Disabling window messenger is not an option.
Who is Participating?
sr1xxonConnect With a Mentor Commented:

 that's a lot of back-and-forth on this forum to have solved the problem on your own.
 To the messanger,  maybe you could not block the spams thru blocking special ports. as you know, the message is pass thru the port which messanger us, or, in some way, your messanger will get the information on it's own from the messanger server. so if you permit the messanger to pass thru firewall from inside to outside, the spam will come out with the messanger server's permition.
  To block the spam just like the messanger server delivered. I think maybe to change the msn messanger will give you some help.

TKS & Best Wishes
grant-ellsworthAuthor Commented:
I am referring exclusively to inbound message sent via the Netbios windows messenger from outside our LAN.  We are not sending any messages using the windows messenger to places outside our LAN.  

What additional ports (see first post) do I need to make sure are blocked to block the spam.  
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

I confused.  SPAM to be generally means e-mail.  Not messgages sent using the "NET SEND" command.

As far you your firewall configuration is concerned, block ALL ports that you do not need.  

NET SEND uses port 138 UDP.

also set the following setting which will disable broadcasts on UDP1900 - messenger uses this in conjunction with SSDP.
Key: Software\Microsoft\DirectPlayNATHelp\DPNHUPnP
Name: UPnPMode
Value: 2 disabled

next, run a trace util on your server - ethereal will give you a dump of what ports are being used and abused.. but before you go that route, try sysinternals tdimon.exe will also do a packet capture and save to log-- this will show you what ports are being used.
really you should consider implementing IPSEC for this server - you know what services you need.. only allow them and reject all others.
start by implement an IPSEC policy for windows messenger that only allows communication from port 135 to internal addresses - reject packets to port 135 from external sources.. tdimon will let you know what is redirecting to windows messenger, so perhaps block that too if you can't lock it down from the tdimon dump..

personally on a server in a DMZ, the first thing I would do is disable netbios from within the NIC IPconfig.

how did you prove that it broke through your firewall?

> What additional ports (see first post) do I need to make sure are blocked to block the spam.  
close *all* ports, then only allow those which you need and which you know what they are for.
You should also block 445/tcp - Netbios over TCP
grant-ellsworthAuthor Commented:
Wow!  Thankyou to prueconsulting and sr1xxon and their useful suggestions - will follow up.  

These recent comments do beg some additional comments/questions.

For giltjr - see and related for some discussion of what I called "Messenger Spam" - maybe describing it as "winpopup" spam would have been more precise.

For sr1xxon - How do I run a trace/what is ethereal - where do i find it?  The victim machine is a windows xp, not a windows server - where do I get info on setting up ipsec as you describe? I read that Messenger Service uses other ports besides UDP 135  (136 - 139) (all were already blocked).  What do I do to block Netbios in IPConfig where/how?  Is that port 445?

For ahoffmann - to prove - No machine on my network sent the Messenger Service message that alerted us to the problem.  I think there are some ports I don't know about - because, for example, when I block all tcp/udp ports >= 1024, Google won't work.

For Prueconsulting - looks like this (445) is one port I did not have blocked - will try that to see if that works?
I think that you really need to get somebody to look at your firewall.  You are supposed to permit the ports you need to work and deny all others, not permit all and deny what may be causing you problems.

What part of google does not work when you block ports above 1024?  We block all ports above 1024 and I can go to googles web site without any problems.

Based on what little I've seen here you have a very unsecure network.  Again, this is only based on what I see here.
You could also consider disabling the messenger service on your machines unless you use it.

Disabling Messenger and firewall settings:

Sorry, just reread your question about disabling messenger not an option :)
> I think there are ..
thinking is not enough here, you need to be 100% sure, anything else is guessing
grant-ellsworthAuthor Commented:
For ahoffman - When I use the firewall's setting to block all ports except a few specific ports I have allowed >= 1024, google will not return page with search results; it just hangs.  When I change the setting to block all ports >= 1029, google will return search results pages.  Now that you call my attention to these ports, I noticed that my firewall will block identified tcp ports even when there is an established connection - unless I specify otherwise - one port at a time.  So I wouldn't regard my network as particularly insecure.  GRC's ShieldsUp test says all ports thru 1056 on my network are "stealth" unless I have explicitly opened them.

I did not have port 445 blocked.  I have now blocked 445.  I have seen no further winpopup/messenger spam for a while.  If this holds for another 24 hrs, I would regard closing 445 as the solution.
> .. block .. >=1024 .. it just hangs.  
you should use a statefull firewall which knows automatically which related ports are allowed.

> When I change the setting to block all ports >= 1029,
then you'll have problems with other services next time.

As said above: close *all* ports unless your're 101% sure you know what they are doing. If you firewall cannot do that, replace it with a reliable one.

grant-ellsworth, no offence, just technical information ;-)
grant-ellsworthAuthor Commented:
My ***@#$%!!! firefwall is not an explicitly statefull firewall - i gotta know the relatives.  You may have identified the other piece of my problems - thanks.  Otherwise,, my firewall closes all ports as specified - closes them tight.
If possible what firewall are you using?  I have used non-statefull firewalls and they normally are setup so that you have to specifically define port, protocol, and direction.  

I have yet to use any firewall that does not have either a predefined rule for web browsing or examples of how to set it up.
grant-ellsworthAuthor Commented:
This firewall is the built-in firewall on a netopia 4657 dsl router.  The firewall port settings allow us to specify forward TCP ports only when there is an established connection

apols for the delay in replying..

ethereal is a packet analyzer.. it's opensource and works on both linux and windows. It's good for diagnosing all sorts of problems, but probably isn't what you want to get into immediately - you need a very good knowledge of the OSI model in order to use it effectively.
it will look inside each packet sent and give you <loads> of information about your network traffic.

TCPVIEW gives realtime thread information for each executing app.. including local and dest ports, and also channel status (established, ended, error etc..) run as admin.

TDIMON gives you information about each application's network activities. this is much easier to follow than ethereal for the first time user. it's a single exe - run it (with an admin account) on the system which you think has been compromised. you will see the source app, local and destination port and

best practice, as suggested by several other posters, is to block all incoming traffic and allow only certain ports on your firewall.
eg.. allow in port 80 - ONLY to your webserver
      allow in port 25 ONLY to your DMZ-hosted email bastion
      block all others in.

to block netbios in you IP configuration,
open network connections - (NIC PROPERTIES) - TCP/IP - advanced button -  WINS Tab - radio button 'disable netbios over TCP/IP.

As I said, I would do this for hosts in DMZ's.. for client pc's in a lan, it's a different story. if you are using WINS, then this will break the WINS service on the PC.

you might be getting errors with blocking all above port 1024 if you are using port 8080 with your proxy.. that would defo cause google/internet to fail.

there is heaps of information available on setting up IPSEC - and useful as this is, be certain of what you are going to allow because you can stop a system pretty easily unless you know what you are doing.

something else you might not have considered is content scanning for your internet connections and IDS.. several have application filters which will kill unwanted stuff like winpopups over the internet.
check out these
(free) with copfilter and BOT
(pay) - not and IDS, but it is an effective web/mail filter

I could not find a the model 4657 on Netopia's support site, so I am not sure what functions this device/firewall has.

Unless yoy are hosting servers behind this box, most DSL routers/firewalls allow for outbound Internet access out of the box with no really configuration needed at the tcp/udp port level.
at its most basic settings, netopia have a default configuration which should block most inbound traffic - log onto the firewall console, click the firewall tab, and ensure that the firewall is set to MEDIUM, click save. the router will prompt to restart.. see if the problem persists.

grant-ellsworthAuthor Commented:
To Giltjr - I erred.  My router is a Netopia 4652.  
To sr1xxon - router does not have a web interface - it's all done thru telnet.  as delivered from COVAD, there was no firewall set up.  Over time, I have needed to open several ports for several different applications and functions.  I have multiple machines, some servers, some workstations/desktops. including web/secure web, mail, rdp, specialized apps, vpn, etc..  I have had NO problems except for this recent invasion of winpopups to one machine I had added to the public IP set.  I had some winpopup issues when they first showed up a couple years ago - and I quickly shut down the upd/tcp ports 135-139 and had no issues till now.  

Questions for sr1xxon:
1.  What ports get closed to block netbios over tcp/ip in the firewall?  (Not at nic/ws level where I may / do need it)
2.  where are tdimon, tcpview, and ethreal found - I'll "google" for them, but do they have an "official source?"

The Netopia 4652 has 2 firewall filter sets - one was delivered empty, the other had some very very basic openings - did not include web, mail, vpn, etc.. I don't have the original out of the box settings.  I opened ports as needed.  Closed them when obsolete.  I found that if I totally locked down the higher range ports (>=1024) except for known planned exceptions - e.g. 3389 for RDP, there were websites that didn't work.  Problem was that the total lockdown blocked TCP traffic including traffic from connections established thru already opened ports.  I had to figure out which ranges to open - which I did.

The Netopia 4652 firewall filter setup is user-hostile and far more complex (more options to mess with) than the firewall setups in Netgear, Linksys, D-Link, XyCel/Xywall, etc..  In my opinion, only CISCO firewalls are more complex.

Just FYI - ever since I explicitly slammed the door on port TCP/UDP 445, the windows messenger spam has not recurred.  It had been coming in many times a day with the same 2 messages which I suspect had the same source.  If I see no more by Friday morning, I'll accept the port 445 closure as the main solution.

Many thanks to all of you for the info you've given.
you've already blocked tcp 445 in - :))
block tcp 135 in
block udp 137 in
block udp 138 in
block tcp 139 in

your final rule should be 'block any any' - which should disable all ports which aren't explicitly given access (in and out) by a rule above that.

finally , use a portscanner (such as NMAP) to check which ports are still open - either connect a laptop to the external interface of your router (if it's eth) or connect from a remote net - and see what other ports need to be closed.

grant-ellsworthAuthor Commented:
For sr1xxon - 135-139 have been blocked since wayback.  I'll see if I can locate the port scanner.  thanks.
Block all you want, but Messenger is worse than a virus. If it cannot get out of any of the pre-defined ports it will tunnel over http. Your regualar firewall will not do layer 7 protection for it. Checkpoint does this, and they are about the only firewall i know that does other than like ISA server. Your options cost money, a proxy server that filters your web traffic. EX Websense, bluecoat, Proxy sg/ av. These provide policy-based Web traffic control for small to large enterprises at the corporate gateway, including content filtering, IM/P2P control, and bandwidth management.

If you wanted a dedicated IM appliance you can look at CipherTrusts IronIM instant messaging security appliance they are the first and only solution that integrates policy to secure, log, monitor and encrypt enterprise IM communications.
There are similiar Instant messaging products out there, Now days stateful isnt enough. You need a L7 proxy/monitoring device to alleviate this type of attack.

grant-ellsworthAuthor Commented:
For imreble1/RDC Fishnet ...

Ai yi yi!! Are we talking about the same "Messenger" ???

You're describing what I call "Instant Messenger" - like AOL Instant Messenger or MS's "Clone" ...  bad boys indeed!

My problem concerns the MS Windows built-in Windows Messenger Service which is normally used on a LAN via the opsys' "Net Send" command.  The unwanted popup messages come from juveniles abusing that "Net send" utility.  

I should have titled my problem: "Windows Messenger winpopup 'spam' sneaks thru firewall - how??  What additional ports do we block?"
Tim HolmanCommented:
It's common, and good practise, to have your firewall block ALL incoming traffic unless you explicitly allow it.  It's unusual to come across a problem like this, as it's very rare that firewalls have been 'unconfigured' to open the stock netbios ports.
I would suggest reevaluating your firewall policy - block everything, and only allow things like 25 (mail) 80 (www) inbound and so forth.  That way, problems like this (and many others) won't affect you.
Bit more info here looked useful:

Rich RumbleSecurity SamuraiCommented:
Quite the thread, I'm just reitterating and summarizing but here it is
You do not need any incomming ports open to use the net if the firewall is stateful. If the firewall isn't stateful, turn it off and use one that is, such as XP Pro's built-in firewall, or the free firewall from ZoneAlarm (or the pay version for that matter) The messenger service being turned off would of solved the pop-ups, but not blocked the traffic per se. Shoot-the-messenger and the Dcom-bobulator are good tools to start securing M$ machines with if a firewall is cost prohibitive
Having ports 135-139 and 445 (tcp/udp) open to the outside world is an open invitation for trouble.

To me it sounds like the firewall you have is easily fooled by "spoofed" packets. Just because a packet says it's source is "" doesn't actually mean it came from ... and if your lan is using RFC 1918 subnets (10.x.x.x 192.168.x.x or 172.16.x.x) and the firewall's outside interface recieves a packet that say's it came from one of those subnets, it may actually pass it on to the internal subnet... if the firewall is THAT BAD at checking packets or has a very bad config. If possible you may need to tell your firewall to drop packets that come from an RFC 1918 address to the outside interface, it's a very old practice, but one that some still observe. RFC 1918 subnets are not publicly routable, but there are plenty of routers that don't check src ip very well still, so it's possible to still send these spoofed packets. This is a very common thing to see with linux iptables
grant-ellsworthAuthor Commented:
To Moderator - I think a refund is in order =- I solved my own problem with 2 pieces of info:

1.  Utlity to display the RPC Stack - RPCDMP - showed the snake coming in on port 031
2.  Determined that I was missing a security patch MS-03-043

Installed patch and the problemwent away
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.