Which Microsoft protocols should ISP's break today? Microsoft Exchange?
Microsoft file sharing? Microsoft Plug & Play? Microsoft SQL/MSDE?
Microsoft IIS?
It would be so much easier if worm writers followed the RFC's and set
the Evil Bit.
China has firewalled the entire country, and they have more infected
computers than the US.
"The problem isn't Microsoft's products or the knowledge
of the consumer. The problem lies in the ISPs' unwillingness
to make this issue disappear or at least reduce it
dramatically," said Cooper.
This is a disturbing viewpoint. Next thing you know we'll be blaming
ISP's for file sharing...
-Terry
Well, when one of the largest providers of high-speed internet access is including
"download music" as a reason for wanting their service.....
Um...What exactly is wrong with that? There are lots of LEGAL ways to
download music. Apple's Music Store and several other licensed commercial
services provide music download services, as well as internet radio and
other "fair use" applications. This seems like a perfectly legitimate
reason to want internet access. As such, it seems like a perfectly reasonable
feature to advertise.
The problem _IS_ Micr0$0ft choosing to produce code with vulnerabilities
in order to increase market penetration. They have essentially built the
information superhighway equivalent of the exploding Pinto and it's high
time they got held accountable if you ask me.
I hesitate to include this here (sorry Susan), but, I'm starting to think
that all the admins and other people who are suffering impact on their
non-windows systems from these vulnerabilities generating DOS traffic
should take Micr0$0ft to small claims court. Let them defend a couple
of million tiny lawsuits all over the world. Make them play whack-a-mole
the way we've had to on patching their garbage.
Owen
And Napster can be used to download non-infringing files. Look where it got them.
Hi, NANOGers.
] > He added that ISPs have the view and ability to prevent en-masse
] > attacks. "All these attacks traverse their networks before they reach
] > you and me. If they would simply stop attack traffic that has been
] > identified and accepted as such, we'd all sleep better," Cooper said.
Oh, good gravy! I have a news flash for all of you "security experts"
out there: The Internet is not one, big, coordinated firewall with a
handy GUI, waiting for you to provide the filtering rules. How many
of you "experts" regularly sniff OC-48 and OC-192 backbones for all
those naughty packets? Do you really want ISPs to filter the mother
of all ports-of-pain, TCP 80?
Filter at the *EDGE* folks. You own your own networks; use and manage
them responsibly. If you need assistance, ASK. If you can't take on
the task, purchase bandwidth from providers who sell (yes, CHARGE YOU
MONEY) a filtering service.
Thanks,
Rob.
North Texas charges students $30 if their computer is infected, and needs
to be cleaned.
http://www.ntdaily.com/vnews/display.v/ART/2003/08/29/3f4eeca4ac93d
If you don't want to download patches from Microsoft, and don't want to
pay McAfee, Symantec, etc for anti-virus software; should ISPs start
charging people clean up fees when their computers get infected?
Would you pay an extra $50/Mb a month for your ISP to operate a firewall
and scan your traffic for you?
Hey, Sean.
] North Texas charges students $30 if their computer is infected, and needs
] to be cleaned.
I think this is very reasonable, and a great idea.
] Would you pay an extra $50/Mb a month for your ISP to operate a firewall
] and scan your traffic for you?
No, but I have been sorely tempted to offer up [coffee|beer|cash]
to have ISPs manage the network security of their other customers. 
Folks need to remember that even if they outsource the security
facets of their Internet-connected networks, they must still be
responsive to abuse complaints and queries. Your managed security
services provider might be excellent...or not. In the end it is
still YOUR network, and any "CNN moments" will be all YOURS as well.
Keep those abuse@ aliases pointed at helpful and clueful folks, and
respond as quickly as you would have others respond.
Of course if you aren't responsive, you just might end up as an
example in my next presentation. 
Thanks,
Rob.
http://www.vnunet.com/Analysis/1143268
> Although companies may have the infrastructure to deal with the current
> band of worms, Trojans and viruses, there is currently a line of defence
> that is not in place. "The problem isn't Microsoft's products or the
> knowledge of the consumer. The problem lies in the ISPs' unwillingness
> to make this issue disappear or at least reduce it dramatically," said
> Cooper.
This completely overlooks the user as the ultimate infection vector.
Even if Microsoft never has another external hole users can still infect
themselves. To paraphrase badly: the most dangerous part of the computer
is the nut behind the wheel.
Moore's law in on the side of virus writers that spam their viruses to
users. As long as users only need to click on email attachments to
execute programs you can expect an increasing amount of virus spam.
> He added that ISPs have the view and ability to prevent en-masse
> attacks. "All these attacks traverse their networks before they reach
> you and me. If they would simply stop attack traffic that has been
> identified and accepted as such, we'd all sleep better," Cooper said.
Perhaps paper manufacturers should be held liable until they come out with
paper that can't be used to write down bad ideas.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
Know what *really* irks me? I order blank paper, and this damned company keeps
sending me paper that's got connect-the-dots pictures of bad ideas all over it. I'd
change vendors, but I can't find a copying machine vendor that will service my
copier if I use any other brand....
North Texas charges students $30 if their computer is infected, and needs
to be cleaned.
Excellent, perhaps they'll learn early that they have to patch often.
..... don't want to
pay McAfee, Symantec, etc for anti-virus software;
Please show me an anti-virus product for the desktop that protects against
such things, I've disinfected at least 30 machines this week that have
McAfee VirusShield or Norton Antivirus installed with automatic updates
enabled (and yes, I verified they all had the latest virus definitions),
they'll happily sit there spewing shit to the world until they're rebooted
(a few weeks later, now that windows will happily kludge along but not
completely crash) then you get a wonderful dialog that says:
'Warning $anti-virus-program has found an infected file $FOO but could
not delete it'
Why couldn't it delete it? Because the file was set read only, and the
software is too dumb to attrib -r $file
And no, $upstream should not be filtering my connection, if you see activity
circuit.
If you don't want to download patches from Microsoft, and don't want to
pay McAfee, Symantec, etc for anti-virus software; should ISPs start
charging people clean up fees when their computers get infected?
Only if it impacts the ISP, which it doesn't most of the time unless they buy an unfortunate brand of dial-up concentrators.
Would you pay an extra $50/Mb a month for your ISP to operate a firewall
and scan your traffic for you?
No way. They have no business even looking at my traffic, let alone filtering it.
What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort.
No... I have one T1 to Sprint and one T1 to AT&T, I think my AT&T bill
will be high this month so I stop sending OUT AT&T and only accept
traffic, all my traffic in that link... So now I push OUT sprint and IN
AT&T. I don't want sprint to kill my connection just because all traffic
to me is entering AT&T do I?
What would be great though is a system where there is an automatic
check to see if there is any return traffic for what a customer sends
out. If someone keeps sending traffic to the same destination without
anything coming back, 99% chance that this is a denial of service
Eh? Have you ever run a mailing list? The majority of subscribers
NEVER post. Those who do, post prior to the large quantity of traffic
originates. I suppose the latter can be accounted for using positronic
equipment instead of electronic. =) Legit mailing lists may not be
99% of total traffic, but they're sure a good chunk of legit email.
attack. If someone sends traffic to very many destinations and in more
than 50 or 75 % of the cases nothing comes back or just an ICMP port
unreachable or TCP RST, 99% chance that this is a scan of some sort.
Sure, and I scan my systems from outside all the time. I'm looking for
validation that my system has NOT started listening on ports I don't
run services on. It's called external monitoring, and is rather useful
in letting me get a good night's sleep. Could I do it locally? Sure,
but I'd still need a way to verify my sites can be reached from other
places. If you want to know how TCP is working to a destination, you
have to use TCP to test it. When I'm working a half dozen part-time
contracts, each of whom has multiple servers scattered around the
country, this traffic may well be nearly continuous. My employers
will "know" about this (it'll be in some memo that no one read), but I'm
not going to find every transit provider I cross to warn them, too much
hassle. I'm probably not even going to tell my ISP, as it's none of
their business.
Are those patterns common among DOS/DDOS? Sure. You'll need to do more
analysis than that to determine if that's, in fact, what you have. Scans
by themselves certainly aren't inherently dangerous. Heavy levels of them?
Well, who gets to define "heavy?" A cracker might need only 2 or 3 scans
to get the info needed to attack a site. I probably need a few hundred a
day to verify said cracker hasn't succeeded. A script kiddie might run
hundreds, or more, or less.
What would be great though is a system where there is an automatic
check to see if there is any return traffic for what a customer sends
out. If someone keeps sending traffic to the same destination without
anything coming back, 99% chance that this is a denial of service
Eh? Have you ever run a mailing list?
No, haven't had the pleasure.
The majority of subscribers NEVER post. Those who do, post prior to the large quantity of traffic originates.
So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no problems there.
Christopher L. Morrow's mention of asymmetric routing for multihomed customers is more to the point, but if we can solve this for all those single homed dial, cable and ADSL end-users and not for multihomed networks, I'll be very happy.
attack. If someone sends traffic to very many destinations and in more
than 50 or 75 % of the cases nothing comes back or just an ICMP port
unreachable or TCP RST, 99% chance that this is a scan of some sort.
Sure, and I scan my systems from outside all the time. I'm looking for
validation that my system has NOT started listening on ports I don't
run services on. It's called external monitoring, and is rather useful
in letting me get a good night's sleep.
So which do you prefer: nobody gets to scan your systems from the outside (including you) or everyone gets to scan your systems from the outside (including you).
but I'd still need a way to verify my sites can be reached from other
places.
They have something for that now. It's called "ping".
If you want to know how TCP is working to a destination, you
have to use TCP to test it.
As I mentioned above: this will not impact TCP at all because TCP generates return traffic. I'm sure there are one or two UDP applications out there that don't generate return traffic, but I don't know any. The only problem (except asymmetric routing when multihomed) would be tunnels, but you can simply enable RIP or something else on the tunnel to make sure it's used in both directions. Multicast doesn't generate return traffic so this would only apply to unicast destinations.
Scans by themselves certainly aren't inherently dangerous.
It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through.
So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no
problems there.
Ah, so you're only looking to stop non-TCP attacks. How long do you think
before the majority of DOS are TCP based? SYN floods result in ACKs, they
just also result in the server being useless. If an ACK is all you need,
you won't catch much of anything.
Christopher L. Morrow's mention of asymmetric routing for multihomed
customers is more to the point, but if we can solve this for all those
single homed dial, cable and ADSL end-users and not for multihomed
networks, I'll be very happy.
Yes, I'd be happy too, but your original point wasn't terribly
specific, and doesn't really address typical traffic patterns.
Now that it's clear, how about a more obvious one: Streaming services
are primarily assymetric, and plenty of them use UDP. There may be
a little return traffic, but nothing you're going to predict. I suppose
you can call for the end of UDP based streaming protocols. Good luck.
It took long enough for people to get used to moving away from NFSv2.
>>attack. If someone sends traffic to very many destinations and in more
>>than 50 or 75 % of the cases nothing comes back or just an ICMP port
>>unreachable or TCP RST, 99% chance that this is a scan of some sort.>Sure, and I scan my systems from outside all the time. I'm looking for
>validation that my system has NOT started listening on ports I don't
>run services on. It's called external monitoring, and is rather useful
>in letting me get a good night's sleep.So which do you prefer: nobody gets to scan your systems from the
outside (including you) or everyone gets to scan your systems from the
outside (including you).
So let's see, my choices are:
1) both cracker and I know if I've been cracked by cracker.
2) cracker knows I've been hacked, I have to wait until my server is now
an active participant in screwing the rest of the internet, AND I then
have to actively be inspecting the system to see where he's failed to
cover his tracks well.
Yes, the choice is wonderful. Obscurity has done so much to enhance
reliability, security, you name it.
>but I'd still need a way to verify my sites can be reached from other
>places.They have something for that now. It's called "ping".
Yes, and ICMP echos are already consistent in being blocked (not).
This line is relevant:
>If you want to know how TCP is working to a destination, you
>have to use TCP to test it.
It's an example. I need to generate traffic to the various ports. Even
if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP
or SMTP are getting through. Relying on ping to verify outside
connectivity is great for providing a ping response server, but not
many customers seem interested in paying for that.
As I mentioned above: this will not impact TCP at all because TCP
generates return traffic. I'm sure there are one or two UDP
applications out there that don't generate return traffic, but I don't
know any. The only problem (except asymmetric routing when multihomed)
UDP generates return traffic, but there's nothing to predict any degree
of symmetry. Indeed, likely different last mile, local congestion, et al
virtually guarantee that I can't predict how much return traffic there will
be. Look inside, and they all come down to 'push a bunch of UDP out. pray
very hard that enough gets to the other side. hope that other side can tell
us if not.' ICMP likewise may or may not result in return traffic.
At any level, things are almost never completely tit-for-tat.
>Scans by themselves certainly aren't inherently dangerous.
It should be possible to have a host generate special "return traffic"
that makes sure that stuff that would otherwise be blocked is allowed
through.
Sure, and spoofing the special "return traffic" will be obvious only to
the other end, not the transits in the middle.
So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no
problems there.
Ah, so you're only looking to stop non-TCP attacks. How long do you think
before the majority of DOS are TCP based? SYN floods result in ACKs, they
just also result in the server being useless. If an ACK is all you need,
you won't catch much of anything.
A SYN flood will either stay within the resource limits of the (network to the) target host, or it won't, and either the source addresses are legitimate, or they aren't. Only in one of the four combined cases there will be return traffic for most packets. So this should have beneficial effects most of the time. Also, when the target host implements filtering there won't be return traffic so then it should work even better.
Now that it's clear, how about a more obvious one: Streaming services
are primarily assymetric, and plenty of them use UDP. There may be
a little return traffic, but nothing you're going to predict.
I did a little test using Quicktime and I see 10 packets per second return traffic. But the port numbers don't match the traffic flowing in the other direction...
The amount of return traffic isn't important, as long as there is _some_.
If you want to know how TCP is working to a destination, you
have to use TCP to test it.
It's an example. I need to generate traffic to the various ports. Even
if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP
or SMTP are getting through.
So what's the problem? You open an HTTP, SSH, RTSP or SMTP session and see if you get a response. If you do, no problems. If you don't, the "suspicious traffic going on" counter increases. If you keep hammering on a non responsive server then after a while something is going to happen to your port. I think rate limiting outgoing traffic to very low levels (5 kbps or so) is probably the best automated way to handle this.
Scans by themselves certainly aren't inherently dangerous.
It should be possible to have a host generate special "return traffic"
that makes sure that stuff that would otherwise be blocked is allowed
through.
Sure, and spoofing the special "return traffic" will be obvious only to
the other end, not the transits in the middle.
Hm, good point. Maybe it's easier to set the thresholds such that some limited port scanning doesn't trigger any action. It's not like any of this is going to make targeted portscanning completely impossible anyway, it will mostly make sweeping the net for vulnerable systems too slow to be useful.
This is fine until a customers sends out legitimate multicast traffic, so any such scheme has to ignore multicast traffic. Then the worms and virus writers will just switch to using multicast as a vector.
Also this only works where routing is strictly symmetrical (e.g. edge connections, and to single homed edges at that).
It also has the problem that you have to retain some state (possibly little) for all outbound traffic until you can match it to inbound traffic. Given the paupacity of memory in most edge routers this is a problem. Even with a decent amount of memory, it would soon get overrun, even on a slowish circuit like a T1. A DSLAM with several hundred DSL lines would need lots of memory to implement this, and lots of CPU cycles to manage it.
At the layer 3 level, all TCP traffic is revertive as it has to send ACKs back so this scheme can't simply work on '"I've seen another packet in the reverse direction, so it's OK". So we have to work on byte counts and see if what goes one way is balanced by what goes another way.
Then it gets worse still, much legitimate traffic is highly asymmetric. In a POP3 session, most traffic is one way and only a small quantity of high level ACKs go the other way. Ditto SMTP and most HTTP traffic.
So, we're reached the stage that, for this to work, it has to have at least the complexity of a stateful firewall. OK, that is doable, at a cost. But in the process we seem to have lost any characteristic of asymmetry that allows us to distinguish good from bad traffic.
>He added that ISPs have the view and ability to prevent en-masse
> attacks. "All these attacks traverse their networks before they reach
> you and me. If they would simply stop attack traffic that has been
> identified and accepted as such, we'd all sleep better," Cooper said.
Frankly I dont want any of my ISP's filtering any of my traffic. I think we need (especially enterprise administrators like myself) to take some responsibility, and place our own filters. Filters not only to stop the ingress attack but to also filter our own egress traffic.
I have encountered many private administrators who have the mentality that all they need to do is filter the ingress traffic and do not place egress filters on their networks. TSK TSK TSK!!!!!
Individuals like Rob Thomas, and countless others provide frequently updated Bogon Lists, templates, etc. apply these to your edge. This is your first layer of filtering. Make sure to apply NULL routes to the BOGONS so you block these on the egress. Apply prefix list if you are a BGP speaker (keep that routing table clean), and access list at your ingress point to block any traffic from a BOGON (Bogus!!!) address. Now you are ready for your next filters.
Use a chokepoint, and filter now your TCP/UDP ports, or any other protocols you run internally (MS PORTS???). Making an all inclusive filter is the only way to go here.
Now keep yourself informed and modify your filters to mitigate attacks, etc.
This might not be the easy way (easy way would be to say...Hey ISP it's on you now...Filter this stuff!!!!) but it is the only sure way to protect that network you administrate (which is your responsibility not the ISP's).
Frankly all I want my ISP to do is to maintain my link with them, provide to me BGP routes, and accept my advertisements.
Your BOGONS are easily maintained since once again individuals like Rob Thomas update their templates accordingly (THANKS!!!!!!!), and are nice enough to also inform the list of upcoming changes.
A big letter "L" should be stamped on anyone's forehead who was allowing ingress traffic on those MS ports (and even more so if they where allowing it to egress also).
Microsoft cannot blame the ISP networks for not filtering the ports used by their proprietary protocols. Shame on them, shame on all those that left these ports open on their networks.
Even if ISP's would begin filtering (a thought that doesnt make me too happy) I would never trust their filters because I have no control over them. Yes I am that paranoid!!!!!!!
Gerardo A. Gregory
Manager Network Administration and Security
402-970-1463 (Direct)
402-850-4008 (Cell)
Hey, Chris.
] No... I have one T1 to Sprint and one T1 to AT&T, I think my AT&T bill
] will be high this month so I stop sending OUT AT&T and only accept...
Yep, this is a very common tactic, for reasons of finance, politics,
responsiveness, etc.
Thanks,
Rob.