Blocking port 135?
http://www.cert.org/advisories/CA-2003-19.html Would blocking port 135 at the network edge be a prudent preventative measure?
Absolutely. All of the NetBIOS ports: 135, 137, 138, 139, 445. Bob -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adi Linden Sent: Friday, August 01, 2003 2:37 PM To: nanog@merit.edu Subject: Blocking port 135? http://www.cert.org/advisories/CA-2003-19.html Would blocking port 135 at the network edge be a prudent preventative measure?
I also would recommend blocking these outbound, if they are not. Especially 137, it's so useful in finding Windows machines on other networks. On 1 Aug 2003 at 14:09, Adi Linden wrote: Date sent: Fri, 1 Aug 2003 14:09:52 -0500 (CDT) From: Adi Linden <adil@adis.on.ca> To: Bob German <bobgerman@irides.com> Copies to: nanog@merit.edu Subject: RE: Blocking port 135?
Absolutely. All of the NetBIOS ports: 135, 137, 138, 139, 445.
Ports 137, 138, 139, 445 have been blocked for a long time. But port 135 wasn't until today...
Thanks! Adi
On Fri, 1 Aug 2003, Bruce Pinsky wrote:
And filtering 445 in the outbound direction to prevent attacks from the inside out is probably prudent as well.
Unfortunatly I've ran into at least 1 rather big example of a company using 445 for SSL since they wanted to put more then 1 cert on a machine. In this case it was a check clearing house, and a bank couldn't reach them because their ISP was filtering their T1. Jason -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
None of the exceptions mentioned means you can't filter. We practice a policy of informed filtering. We filter by default, and if the customer requests unfiltered and understands the risks involved, we add an exception for their connection. By default, we filter all of the usual Windows ports, plus a few other known-sketchy ports and port combinations. -----Original Message----- From: Jason Slagle [mailto:raistlin@tacorp.net] Sent: Saturday, August 02, 2003 10:12 AM To: Bruce Pinsky Cc: Bob German; nanog@merit.edu Subject: Re: Blocking port 135? On Fri, 1 Aug 2003, Bruce Pinsky wrote:
And filtering 445 in the outbound direction to prevent attacks from the inside out is probably prudent as well.
Unfortunatly I've ran into at least 1 rather big example of a company using 445 for SSL since they wanted to put more then 1 cert on a machine. In this case it was a check clearing house, and a bank couldn't reach them because their ISP was filtering their T1. Jason -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
Bob German wrote:
Absolutely. All of the NetBIOS ports: 135, 137, 138, 139, 445.
Although the public exploits floating around (at the moment) attack 135/tcp, 135/udp is also vulnerable... And for this crowd, I should point out that blocking 135/udp blocks DCE-RPC which is used rather heavily by HP OpenView by default. You may hear some shrieks of pain should you chose to block 135/udp. Oh, and according to the guys who broke the story in the first place, http://www.securityfocus.com/archive/1/329918 Port 593/tcp is also potentially problematic.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adi Linden Sent: Friday, August 01, 2003 2:37 PM To: nanog@merit.edu Subject: Blocking port 135?
http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative measure?
-- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Fri, 1 Aug 2003, Crist Clark wrote:
And for this crowd, I should point out that blocking 135/udp blocks DCE-RPC which is used rather heavily by HP OpenView by default.
You may hear some shrieks of pain should you chose to block 135/udp.
I bidirectionally blocked all NetBIOS ports (tcp and udp) a long time back and have yet to have any problems. In fact I have blocked every single port that's unique to a Microsoft product including the MS SQL ports. I haven't seen any downside to doing that. I also block all Apple AFP ports for the same reasons. For that matter SunRPC is also blocked. Basically I weeded out all the ports that have major security issues and no valid use for my users. Now I'm not a backbone provider but for my many users we have experienced no problems and have avoided numerous security issues because of it. A little preventative maintenance can go a long way. My $.02 Justin
On Fri, Aug 01, 2003 at 01:37:21PM -0500, Adi Linden wrote:
http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative measure?
I've blocked these ports on my home network for some time, just for insurance reasons to make sure that I don't accidentally have something "bad" happen. I don't think you will see providers doing widescale filtering ala the ms-sql slammer situation though. I've actually been considering the ethics of sending winpopup "spam" to send people to the windows update website. I think that the most important thing to do is to remind users to (and how to) download all the latest patches for their system. And that it's worth the download time and effort. This is something that the lurking reporters can do for the good of the internet, encourage your readers to visit windowsupdate.microsoft.com. If your website does pop-up ads, consider windowsupdate.microsoft.com in your rotation :) - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Fri, 1 Aug 2003, Adi Linden wrote:
http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative measure?
It depends. Do you have a network edge? Do you have the resources to block it? Do you need it for anything else? Have you left other holes open? In reality blocking port 135 is almost never sufficient. Its slightly better than waving a dead chicken over your PC.
On Fri, 1 Aug 2003, Sean Donelan wrote:
In reality blocking port 135 is almost never sufficient. Its slightly better than waving a dead chicken over your PC.
its far less stinky than the chicken option though, you must admit that.
only if you thaw before use... http://home.xnet.com/~warinner/chickens.html --bill
So, you don't like the smell of fried chicken ? We keep an old overclocked 486-33, with a quadrupler around, making it run at about 100mhz.. for just this purpose... Complete the Chicken ritual, at Midnight, of course. Unprotect port 25, let alt.freak know... Route all mail to /dev/null.... Whip the chicken on to the old processor, and wait till the spam hits.... Fried chicken in 5 minutes or less. Mmmmmmm. :D Christopher L. Morrow wrote:
On Fri, 1 Aug 2003, Sean Donelan wrote:
In reality blocking port 135 is almost never sufficient. Its slightly better than waving a dead chicken over your PC.
its far less stinky than the chicken option though, you must admit that.
On Fri, 1 Aug 2003, Christopher L. Morrow wrote:
On Fri, 1 Aug 2003, Sean Donelan wrote:
In reality blocking port 135 is almost never sufficient. Its slightly better than waving a dead chicken over your PC.
its far less stinky than the chicken option though, you must admit that.
yep. If you want to be in loco parentis for users, most residential users should block *ALL* inbound connections using a statefull firewall. Most residential users do not intend to run Internet servers. Blocking port 135 is not sufficient to "protect" Microsoft software. There are lots of other holes. Practically, the best place to make this decision is as close to the user as possible. The ISP doesn't "know" what the user intended to do. Mind-reading customer care hasn't worked out as well as we thought. There are cheap hardware firewalls and free/cheap software firewalls that are easy and effective to use. Most places that sell PC's also sell personal firewalls, anti-virus, and even backup systems. Your own personal firewall can block everything out of the box, and can be changed locally (you don't need to wait for the ISP).
On Fri, 1 Aug 2003, Jack Bates wrote:
Sean Donelan wrote:
free/cheap software firewalls that are easy and effective to use.
And breaks all kinds of nifty things which ISP has to pay for via helpdesk support.
as opposed to core level filtering which somehow doesn't break things?
Thus spake "Adi Linden" <adil@adis.on.ca>
http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative measure?
If you see your job as protecting users from their own ignorance, blocking 135-139 both tcp and udp has been prudent for nearly a decade. However, not all providers share that view. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
IMHO, If it's for my own network, yes. Block it. If you are ISP'ing for it, you shouldn't need netbios related stuff on your own servers and they should be protected anyway. However, it should be passed along to your customers in case they are foolish enough to have to expose MS related services anyway. Chris Johnston 714-306-5746 949-653-8819 (fax) Cannot find REALITY.SYS. Universe halted. ------------------------------------------------------------------- -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adi Linden Sent: Friday, August 01, 2003 11:37 AM To: nanog@merit.edu Subject: Blocking port 135? http://www.cert.org/advisories/CA-2003-19.html Would blocking port 135 at the network edge be a prudent preventative measure?
Subject: Blocking port 135? Date: Fri, Aug 01, 2003 at 01:37:21PM -0500 Quoting Adi Linden (adil@adis.on.ca):
http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative measure?
As most have said, no. * It does not cover all possible attacks. * It may block legitime traffic. * If you block and interfere, you are responsible for what your customer does. You Do Not Want That. * If my home ISP tried this on me, I'd take them to the consumer protection authority and have them explain why they are calling their filtered service "Internet access". Instead, I'd suggest this: - Have the customer responsible for all things on their own machine. In writing if necessary. - Inform them that "real Internet" is a Good Thing, but emphasize that it takes some care and feeding of connected devices. - Tell them where to get free or cheap protection software. - Inform them that devices found to be broken into will be sent to null0 until proof of cleanliness has been obtained. - If they have a larger net (corporate customers) tell them you *will* take their CPE interface down if they are visibly broken into and fail to respond. Works for us. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE I fill MY industrial waste containers with old copies of the "WATCHTOWER" and then add HAWAIIAN PUNCH to the top ... They look NICE in the yard ...
Mans Nilsson wrote:
* If you block and interfere, you are responsible for what your customer does. You Do Not Want That.
Depends on why you block and interfere. Intention plays a large part according to law. In this case, it's to protect the network infrastructure from a high probability outage and overall security of the customer's box is inconsequential. Some other things following this intent; filtering of problem networks during attacks, executable stripping or virus scanning (we don't warrant you won't get a virus, but minimize the overall virus throughput in our network to maintain operational mail servers), and suspension of insecure systems or spammers (primary goal is to keep the entire network from being blacklisted publicly or privately, secondary goal is good neighbor policy).
* If my home ISP tried this on me, I'd take them to the consumer protection authority and have them explain why they are calling their filtered service "Internet access".
Many AUP/TOS aggreements have interesting no-server clauses. Blocking 135 inbound to those systems would not breach "Internet access" as the customer shouldn't have a server running on that port. The lack of <1024 filtering on such AUP/TOS services is courtesy really. If it's not a problem to the network, the ISP generally doesn't care.
Instead, I'd suggest this:
You fogot to mention: - Setup detection systems and perform immediate contact on accounts that trigger the system to determine if it's legitimate or not. If not, bye bye. Of course, this only stops outbound issues. It does nothing to prevent inbound, and in the event of a worm, you'd better make sure you have double and triple methodologies in place to stabalize your network. I received a lot of reports on the issues people had with Saphire. What took me less than a few minutes took some hours just to access their equipment. Suggestion? Prewrite the lists and have them in place and know ahead of time how you'll activate them when the network is under extreme load. -Jack
Subject: Re: Blocking port 135? Date: Sat, Aug 02, 2003 at 08:09:47AM -0500 Quoting Jack Bates (jbates@brightok.net):
Depends on why you block and interfere. Intention plays a large part according to law.
If people can sue McDonalds for hot coffee, everything is possible. I'm European, so this does not apply, but I'd try to be very careful in .us.
Many AUP/TOS aggreements have interesting no-server clauses.
Not mine. And, I generally think that with such AUPen, one gets something one step better than Minitel or I-Mode, which is not Internet. Yes, I'm one of those loud end-to-end guys.
- Setup detection systems and perform immediate contact on accounts that trigger the system to determine if it's legitimate or not. If not, bye bye.
That is wiretapping in Sweden, and illegal without a court order. I believe. Nobody has gone even close to taking it to court, and I stay far away from it.
Of course, this only stops outbound issues. It does nothing to prevent inbound, and in the event of a worm, you'd better make sure you have double and triple methodologies in place to stabalize your network.
Some of our thinner access lines were up to 50% full when the Slammer hit. If there comes a much more evil worm than so, we do have OOB access to the entire core.. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE CHUBBY CHECKER just had a CHICKEN SANDWICH in downtown DULUTH!
On Sat, 2 Aug 2003, Jack Bates wrote:
Many AUP/TOS aggreements have interesting no-server clauses. Blocking 135 inbound to those systems would not breach "Internet access" as the customer shouldn't have a server running on that port. The lack of <1024 filtering on such AUP/TOS services is courtesy really. If it's not a problem to the network, the ISP generally doesn't care.
The Slammer worm was > 1024. As someone else pointed out, if you want the ISP to provide you with a completely "safe" network you will end up with something like Minitel. ISPs do not control what Microsoft puts in its operating systems, bugs, features or other things. ISPs also did not control the introduction of NCSA Mosaic, Real Streaming, IRC Chat or most of the other things. Services which require the ISP to "update" their network are always at a disadvantage, such as Multicast or IPv6.
On Sat, 2 Aug 2003, Sean Donelan wrote:
On Sat, 2 Aug 2003, Jack Bates wrote:
Many AUP/TOS aggreements have interesting no-server clauses. Blocking 135 inbound to those systems would not breach "Internet access" as the customer shouldn't have a server running on that port. The lack of <1024 filtering on such AUP/TOS services is courtesy really. If it's not a problem to the network, the ISP generally doesn't care.
The Slammer worm was > 1024.
As someone else pointed out, if you want the ISP to provide you with a completely "safe" network you will end up with something like Minitel.
On a per-customer basis most ISP's will provide managed security services, Firewall/Authentication-services... Certainly, if the customer is interested in this service its very doable and managable. I'm not sure that the overwhelming number of customers are interested in it though. Security is still a 'only after I get screwed' thought for most customers. Slammer brought alot of attention onto security from a customer perspective (which is a good thing) and perhaps this new possible worm will do the same :) The more people have to think about it they more they will realize, as another poster posted, 'security is a lifestyle'.
ISPs do not control what Microsoft puts in its operating systems, bugs, features or other things. ISPs also did not control the introduction of NCSA Mosaic, Real Streaming, IRC Chat or most of the other things.
The gov'ts need to realize this fact, there are times that an ISP might be able to step in and help, those times HAVE TO BE minimalized and for very short durations. No ISP's network is designed to drop traffic, all of them are designed to forward on to the end destination as quickly and faithfully as possible. Depending or requiring ISP's to massivly block traffic in order to 'save the internet' due to software vendor issues is not scalable nor operationally feasible. Amazingly enough there are people that WANT to share files over the internet using standard Microsoft tools....
On Sat, 02 Aug 2003 10:46:54 +0200, Mans Nilsson said:
- Inform them that devices found to be broken into will be sent to null0 until proof of cleanliness has been obtained.
And then they download the patches how? (This is particularly a problem if the customer is using a NAT to obfuscate the IP addresses, leaving you with only one address to null0...)
participants (17)
-
Adi Linden -
bmanning＠karoshi.com -
Bob German -
Bruce Pinsky -
Chris Johnston -
Christopher L. Morrow -
Crist Clark -
Jack Bates -
Jared Mauch -
Jason Robertson -
Jason Slagle -
Justin Shore -
Mans Nilsson -
Richard Irving -
Sean Donelan -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu