[Dshield] should ISPs close ports (was: Windows Messenger Popup Spam on UDP Port 1026)
security at admin.fulgan.com
Tue Jun 24 09:42:28 GMT 2003
(This is going to be a long post. If you don't have time, don't bother
to read it. If it's off topic for this list, please tell me so and I'll
try to carry on by Emailing directly the intended recipient)
MT> Calm down, let me explain. If you have any questions, feel free to
MT> ask, use as many question marks as it takes.
MT> Take a look at the conversation between Ed & Johannes:
MT> Johannes: "I do not advocate blocking ports anywhere at the
MT> backbone. The filters should be applied as close to the end user
MT> as possible."
MT> Ed: "But, that is exactly where I WOULD block 135, 137-139, and
MT> 445 - at the border, where the ISP connects to the backbone."
MT> The "border" is being used in Ed's posts, as the point where
MT> filtering should occur. He defines the border at the top, at the
MT> ISPs pipe. I define it at the bottom, the IP, or range, that the
MT> ISP assigns to the customer. Johannes is objective enough not to
MT> offer a precise definition, but clearly disagrees with me, and
MT> somewhat agrees with Ed.
So it seems. Fine, you have different definition for "border"
(actually, opposite ones). But as I stated, you're mixing two
problems: the legitimacy of ISP-applied filters and the place it is
>> First, filtering port is in no way a failure to provide access to
>> Internet. If your contract doesn't specfically states that you have a
>> full, infiltered access to all of the public IP range, then it's still
>> valid. In fact, any contract that have such a close would be invalid
>> since you'll be filtered at the borders of other networks.
MT> Filtering ports is in every way failure to provide access to the
MT> Internet, thats what filtering ports does, denies access.
Once again, you'll be denied access to a variety of places without
your ISP placing these filters. Also,
MT> Internet access is not 1 single port from 1 single protocol, its
MT> all of them together. Not all of them minus one or two, ALL of
Wrong. Internet is a mesh of interconnected networks sharing using a
common protocol (TCP/IP) over a shared address space. It does also
require two infrastructures to work: DNS and EMail. That's it. Nowhere
is it specified that you must have full, unrestricted access to every
port and every address in that space to qualify and in fact, you do
NOT have access to most of that address/port space due to filtering.
Also, many ISPs have filters in place that will check what's inside
your packet and selectively drop some of them (egress filtering) which
is also some limitation on your traffic.
>> Second, defining borders might be non trivial (depending on your
>> definition of "broder" and the topology of your network), but setting
>> up such "protective port filtering" is, in effect, very easy: you
>> simply have to identify the range of IPs that must be protected
>> (should be very easy) and apply the necessary ACLs on the POPs
MT> I thought you didn't see the corelation between defining the
MT> border and filtering ports, now you're explaining it..
No, I was telling it's two completely different problems: first there
is the legitimacy of port filtering at the ISP level and second there
is the technical way to apply it. I just acknowledge that it would be
technically feasible to apply such filter where it should be applied:
right at the POP router (in order to protect the other users accessing
MT> and I even agree, its really easy to filter the ports. That
MT> doesn't make it right.
There we agree on the subject: not the technical dificulty (which is
what the "border" issue is about) but the ethic behind it. Let's focus
>> MT> If ISPs want to filter at their gateways, they need to make this
>> MT> absolutely clear to all of their clients, and they should not be
>> MT> allowed to market "Internet Access".
>> Why would they ? They are offering you a service that is defined in a
>> document called "Service agreement". If you haven't read it before you
>> signed for it, then the fault is your's. In any case, I don't think
>> you'll ever find an ISP that is foolish enough to offer you what you
>> are apparently asking for: a written contract where they guarantee you
>> a full, unfiltered access to the whole public IP range.
>> MT> Filtering a single port, or a group of them, to permanently
>> MT> address a problem is still just a workaround.
>> Now, that's partially true. The problem is: until IPv6 is in place or
>> until everyone uses IPSec for everyting, it's the only reasonable way
>> to solve the problem at hand.
MT> I disagree. I think a reasonable way to solve the problem at hand is to
MT> address it honestly.
How ? I'm telling you one thing: if you have a workable way to stop
both SPAM, intrusion and worms propagation, I'm betting you'll be a
rich and famous man (or simply famous if you do not sell the idea).
Problem is: I don't think you (or anyone) has such a solution until
we have a way to properly authentify both ends of every connections
(and I don't see that coming any time soon).
MT> The problem at hand has nothing to do with TCP/IP & the
MT> structure of the Internet, or the way ISPs offer their service.
How so ? Please explain.
MT> Yet, all of the solutions being offered here, other than Joe's
MT> instructions on how to turn off Windows Messenger, involve making
MT> changes to these things.
It is one way to solve the problem (in a broader approach, you might
say: disable the services you don't use). Another, more effective,
MT> Why isn't the Windows Messenger service
MT> being addressed as the source of the problem, and the ultimate
MT> solution? The same with NetBIOS.
You're right to say "the same" because that's the root of the problem:
NetBIOS/NetBEUI are protocol designed for the LAN only. The fact that
they have been extended to use TCP/IP as a transport mechanism is what
is causing trouble.
Now, how about fixing THAT, you say ? Well, it HAS been fixed: you can
use a feature of windows NT called "SMB packet signing" that will, in
effect, drop every SMB packet that doesn't bear the proper signature.
Problem is: it's disabled by default because it can't simply work out
of the box: you need an infrastructure to make it work (as does
MT> I'd like to think that accountability is still within reason. That
MT> being said, users of systems that are not affected by this problem
MT> should in no way be adversely affected by its solution.
Wrong: I have a motorbike that can go up to 290 kph and I'm a
qualified driver and I have quite a bit of racing experience on car.
Yet, I'm not allowed to far faster than 120 kph of the highways here
because it's a reasonable limit for the average driver (and some say
it's still to high). While comparing the risk of car accident with
popup spam isn't exactly fair, the idea behind it is the same: if it
is the most efficient way to keep the average user out of trouble,
then we should apply it even if it means that so far and apart users
find it an annoyance.
>> MT> Its like building a door in a desert without a wall. Someone can
>> MT> easily go around it.
>> Uh ?? Filtering a well known port to prevent it to be abused is a very
>> effective way to solve a category of problem. In our case, filtering
>> NetBIOS ports and several common RPC ports (The UDP 1026 that started
>> the thread) will, in effect, prevent the abuse. It doesn't prevent
>> NetBIOS traffic from being tunnelled, explicitly, by another channel
>> (VPN) but it prevent it to be used without some specific arrangement
>> between both interested parties (which is just fine).
MT> Bingo. "It doesn't prevent NetBIOS traffic from..." you said it.
Read the remaining of the sentance: " It doesn't prevent
NetBIOS traffic from being tunnelled, explicitly" meaning that is DOES
prevent NetBIOS to be used if you don't specifically encapsulate it in
another protocol that you have to agree about with the other end of
the pipe. Most corporate network works exactly this way. there is no
way in or out of the network but for a few protocols but you can
connect using VPN which will encapsulate whatever protocol you wish
in it's own channel.
MT> When both interested parties are a virus and an infected host your
MT> filtering goes out the window.
The point isn't to prevent two hostile application from communicating
but to protect a well know flaw from being exploited in a broad way.
Sometimes, filtering doesn't help at all (like in the case of virii,
browser flaw, installed trojan and spam) sometime it helps a lot and
is the only real way to prevent average users from shooting themselves
in the foot.
>> MT> That being said, ISPs that filter 1 port, will naturally filter
>> MT> more over time, making the Internet a really frustrating place to
>> MT> work & play.
>> What are you basing this affirmation on ? You really sound as if you
>> think that your ISP has any advantage at annoying you. They don't.
>> What they should be able to do, however, is protect Mr John "Clueless"
>> Doe against the basic problems linked with a connection to Internet.
MT> I have so much faith in John "Clueless" Doe. I wish more people
MT> did. Mr Clueless didn't create Code Red & Nimbda, Mr Cluefull
MT> did., when he released IIS 5.0.
Yet Mr Clueless is the one that is still propagating these over the
net by running an unpatched IIS servers and opening all attachments.
In medical therm, the vector of these worms ARE the clueless users,
not the knowledgeable ones and if you want to stop an infection, you
attempt to stop it from spreading by either elimination the vector
(something that, as a software writer, I sometime hope I could do) or
stop it from going from one host to the other. Filtering, and not only
port filtering but also virus scanning, RBL blocking, egress
filtering, etc. is about the later.
It IS an efficient tool to help solve or reduce some of these problems
and in the case of NetBIOS, it's a perfectly valid one and extremely
effective one as it doesn't prevent the power users from working
around it should they wish to do so.
>> MT> Every port, TCP, UDP, whatever, is used for valid
>> MT> purposes.
MT> Agreed, that doesn't make a whole lot of sense. My point is that the
MT> flexibility of the Internet is appreciated.
It is. But like many flexible things, it is a double-edged sword. You
have to find a balance between security for the average user and
flexibility for the power user. And guess what ? port filtering, in
some cases, offers just that.
MT> I guarantee there are people offering legitimate services on
MT> famous problem ports, tcp17300 for example, and this should be
MT> respected a million more times than the virus itself.
Not quite. First, there never was a suggestion to block a random port
number because a trojan was using it. This isn't a good use of port
filtering because it's easier to change the trojan's port than to
change all applications that are potentially using it.
NetBIOS ports, however, are a different matter: they are almost
exclusively used by a single "application" and that is the application
that we want to stop from reaching out (in fact, if you're using these
ports for anything else, you aren't following the rules as they are
registered by the IANA for NetBIOS and MS-DS).
Now, the question is more precise: should an ISP block a specific
application ? My answer is yes, they should. Why ? Because this
specific application isn't designed to cross the border of the LAN
and, therefore "bad things"(tm) happen when it is allowed to do so.
Port 1026 is another matter: it is registered by IANA but it isn't
strictly "limited" as are the low port numbers. IANA register these
ports as "a convenience to the community". It is, however, only a port
that is frequently listened to by the messenger service. It's the way
RCP works, you see (as another post explains) It might be used by any
other RPC service"and, as such, it wouldn't be as efficient to block
MT> My statement
MT> should have read "Every port on every protocol _can_ be used for
MT> valid purposes".
You've missed my point which was that the legitimacy of some kind of
traffic is not a "general" thing. It is dependant of the context. That
context is made of: actual usage, type of users on both ends of a
connection and other factors. In our specific case, NetBIOS traffic has
no belonging over Internet and the ISP should be blocking these ports.
To be honest, if you wanted to have a case, you might want to pick up
another protocol than NetBIOS. Try SMTP. That's a very different
matter: it is INTENDED to be an inter-network communication protocol
and as such, shouldn't be blocked. Yet, it is also a protocol that has
it's own internal routing infrastructure which makes it possible for
an ISP to block it for all it's internal users and still provide them
that service by way of an internal relay server.
That should allow them to severely cut down the spam coming FROM their
networks yet it's a solution that is seldom applied. Ever wondered why
? My personal be here is that it's because it isn't completely trivial
to implement and because it would piss SOME users off (with reason):
the ones that are simply using their company's mail server to route
their messages, the ones that are using other email address than the
ones provided by the providers etc.
So, it seems that the facts are against you: it would have helped many
provider to lower their costs and improve their abuse handling to
apply that filtering to SMTP while only annoying a low number of
users. Yet it seems very few ISPs apply such rule.
MT> I'm not sure how your VPNs come in to play here.
Because it's the most simple and effective way to tunnel traffic from
a user to a known and authentified host. It solves the shortcomings of
netBIOS regarding authentication and also works around the port
MT> The fact that you know how to configure a VPN makes you no less
MT> fragile than anyone else on the Internet. VPN routers are sold off
MT> the shelf, "fragile" people buy them.
So ? You can get VPN clients for free, what you don't get for free is
the access point, the receiving end of the VPN. And until every
machine on the planet has a built-in VPN client AND server and unless
these allow completely transparent and anonymous connection on both
end, authentication will require both party to agree on the connection
before being allowed: it solves the authentication issue which is
the root of the problem. After all, if the spammers had to ask for
your permission before sending you these popup adds, you'd simply say
"no thanks" as a default answer and be off with it (unless you are
actually interested in the content of the add).
>> MT> None of them should be discarded because of a single vendor or
>> MT> service causing a pile of problems (cough MS).
>> Wrong again. You might kick and scream for "a perfect world" where
>> every protocol is fully described by a RFC and where it's securely
>> supported by many different vendors on machines that are setup by
>> users that know what they are doing but it won't change the reality:
>> 90+% of the machines connected to the net are variations of Windows
>> and a good 80 to 90% of the users behind these machines have never
>> HEARD about "UDP".
MT> This is wrong? You honestly think its right that the problems of
MT> Microsoft (or anyone for that matter) land at everybody else's
You know, unlike what some politicians try to make you swallow these
days, there is something between "right" and "wrong", "good" and "bad"
and "white" and "dark". It's also a funny fact that reality usually
happen to be in between these extremes. For the specific issue at
hand, it is "wrong" to have a widely used protocol that has a security
shortage (due to the fact that it's been put to uses it wasn't
designed for) but it is what's happening. Now, you can wish this
wasn't the case or you can try to solve the problem. And unless you're
willing to pay a personal visit to each and every users of Windows out
there (or, at least, a significant portion of them) the solution isn't
in upgrading the software but in acting where you can place a
solution that restores the initial intended use of that protocol.
After all, the drawer where I put my wallet doesn't lock. I'm working
around this obvious shortcoming (which happen to be also very
practical) by locking the door of my house. (Well, to be honest, that's
most of the time only: I am lucky to live in a country where you can
leave your car open for days on a public parking lot and usually find
it just as you left it).
MT> I don't, nor do I
MT> think the solutions to these probems should effect anyone but the people
MT> exhibiting symptoms of the problem itself.
Ok, let's get short and practical for once:
1/ You shouldn't be using NetBIOS reserved ports for anything BUT
2/ NetBIOS isn't designed for inter-network communications. It's
designed for LAN.
3/ The "fix" for NetBIOS security is not deployable except in
Given that, blocking the ports used by NetBIOS does perfectly fit the
problem: it restores the initial usage conditions of the protocol, it
doesn't affect anyone BUT people affected by the problem and a few
others that are misusing the same port. It can even be worked around
(in a safe way) if you need it.
>> MT> IMO, the suck of worms & spam does not outweigh the kickass of
>> MT> freedom.
>> What kind of statement is that ? You want to make "freedom" equal
>> "unrestrained liberties". It ain't so but in an ideal world populated
>> by perfect people. On this earth, we still need rules, laws and
>> way to enforce them.
MT> Its a comparitive statement, and you addressed it completely out of context.
Because it was stated as a universal statement, not as a contextual
one. It is also a common dialectic (sp?) trick to try to use such
broad statement (with loaded words) in context of a more limited
problem. I simply used one of the common denial for that trick: show
that it isn't generally true and therefore doesn't apply to the case
MT> All I'm saying is that by chipping away at the free nature of the
MT> Internet by advocating filtering by the ISP will only make it
There, you're doing it again ;)
Let's get this straight: "freedom" isn't something you can apply to a
protocol of a network. You need someone
Ok, now that I've gotten that out, let's replace "free" by "flexible"
and you've got something that means the same, but without the
same emotional implications. The problem is, when you do that
replacement, it just turns out that the affirmation is wrong. By
blocking several ports, ISP do not "take away" the flexibility of
Internet. You still have all the tools required to do anything you
want. The only flexibility that it takes out is to use these specific
ports for that. And guess what ? Even if the filtering wasn't in place
that general statement wouldn't be true: you don't have the right to
pass anything on any port you fancy because there are rules about port
usage that you should follow.
MT> If the solution means filtering ports, by all means leave it up to
MT> the end user.
That would be only a reasonable solution if there was a 20 hours class
on TCP/IP and basic network sanitation before handing anyone a network
connection. Since there isn't such requirement, that "solution"
doesn't solve the problem.
>> MT> ::ducks and runs for cover::
MT> Next time, make sure to pull the pin.
Now I be you didn't notice the remote in my LEFT hand, did you ? ;)
P.S. Sorry for the "aggressive" tone, of the previous message. First,
I had a pretty bad day and second I've had personal (and rather
unpleasant) experience with people that tends to advocate that
ultimate liberties of doing whatever they want is a proper way to live
in society. That's just to explain why I jumped on the gun a bit fast.
More information about the list