http://www.cert.org/advisories/CA-2003-19.html
Would blocking port 135 at the network edge be a prudent preventative
measure?
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
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
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.
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
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
its far less stinky than the chicken option though, you must admit that.
Bob German wrote:
Absolutely. All of the NetBIOS ports: 135, 137, 138, 139, 445.
And filtering 445 in the outbound direction to prevent attacks from the inside out is probably prudent as well.
I also would recommend blocking these outbound, if they are not.
Especially 137, it's so useful in finding Windows machines on other
networks.
Date sent: Fri, 1 Aug 2003 14:09:52 -0500 (CDT)
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:
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.
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).
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.
-Jack
as opposed to core level filtering which somehow doesn't break things?
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.
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.
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
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..
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
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.