The good old days (was Re: M$SQL cleanup incentives)
On Sat, 22 Feb 2003, William Allen Simpson wrote: I see. So you're still filtering port 25 from the Morris sendmail worm. Funny thing, I was a researcher visiting at Cornell, and had just left in the car for the 9.5 hour drive home when it struck. I've often wished I'd stuck around for a few more hours for the excitement. Anyway, we didn't need to put in a long term block, as everyone took down their systems and cleaned them. I didn't even find out about the problem until over a day later, by which time it was long gone. Ah, the days when we all cooperated In 1988 we had ad-hoc responses, with people posting to various USENET newsgroups or some mailing lists still working, about what they were seeing and how to fix it. There was no CERT, BBN (and others) disconnected from the net (and took many people downstream with them), even though most people knew each other they didn't all have alternate contact information, and most of the methods the Morris worm used in 1988 are still being used *effectively* today. 1) Backdoor in SENDMAIL 2) Buffer overflow in Fingerd 3) Password guessing in Rsh/Rexec Some people blocked the ports used. Some people still block ports such as Finger (79) and rsh/rexec (513/514). But generally ports were blocked by the local institution, not on the ARPANET. The version numbers change, the executables change, but the basic problems haven't changed in 30 years. We still have backdoors, buffer overflows and pasword guessing. We still have ad-hoc response by people sharing solutions on mailing lists. The people who cut themselves off from the open process are still slower to get stuff fixed. And we still have weak methods for contacting people through alternate methods. I wish it was as easy as paying a managed security company to watch out for me. But unfortunately, paying several thousand dollars for the privilege of getting confidential alerts which look amazingly similar to what I wrote on a public mailing list a few hours earlier is a bit silly.
Re: The good old days (was Re: M$SQL cleanup incentives)
Sean, Plus ca change, plus c'est le meme chose. Of course the past is with us: look at Bob Metcalfe's RFC 602 (1973). Have we fixed anything over the nearly 30 years? How recently have you seen a password on a Post-It? How many folks have their spouse's/significant other's/ offspring's name as a password? How many uninstalled fixes can dance on a port? Peter
Re: M$SQL cleanup incentives
I'll bite.. - Original Message - From: William Allen Simpson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 21, 2003 2:25 PM Subject: Re: M$SQL cleanup incentives [snip] I'm of the technical opinion that everyone will need to filter outgoing 1434 udp forever. [snip] Iljitsch van Beijnum wrote: Maybe the best approach is to try and deliberately infect the entire local net every few minutes or so to detect new vulnerable systems while the people installing them are still on the premises. Gosh, should we do that for every known virus/worm/vulnerability? Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? You lambast him for attempting a solution that is foolish to apply for every known possible problem where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms. Have fun filtering. Or maybe you don't actually own and/or have legal and financial accountability for your own network? Or maybe he likes having a network his customers can actually use. --Doug
Re: M$SQL cleanup incentives
Doug Clements wrote: Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us. You lambast him for attempting a solution that is foolish to apply for every known possible problem You bet I do! where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms. In one part of your response, you note I don't advocate a 1-size-fits- all solution, and then the second part, assume 1-size-fits-all. That's inconsistent logic in your argument. Have fun filtering. Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.) Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together If you didn't filter, you're actually depending on the good graces of the rest of us that did! Should we start using more loaded words, like parasite? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: [Re: [Re: M$SQL cleanup incentives]]
BB DNS clients will eventually timeout and fall back to another BB server, so any problems would be transient, but the packets BB were legit, right? Stateful packet filters are nice. Properly written, they protect both inbound and outbound traffic and need to track very little state. Stateful packet filtering by C sitting between A and B is fallacy since in order for C to make an intelligent decision it may need to know the details of every possible communication protocol used by A and B. Alex
Re: M$SQL cleanup incentives
On Sat, Feb 22, 2003 at 09:25:24AM -0500, William Allen Simpson wrote: Doug Clements wrote: Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us. I see. So you're still filtering port 25 from the Morris sendmail worm. The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.) The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit. If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm. Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together If you didn't filter, you're actually depending on the good graces of the rest of us that did! If you didn't filter or don't filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore. The correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed. I'm sorry, but I'm not seeing your case for implementing permament filters for this or anything else. --Doug
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Doug Clements wrote: The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Unlikely in this case. A reasonably fast system infected with slammer is capable of generating enough traffic to make the Cisco 2900XL switch its plugged into incapable of passing normal traffic. All it takes is one infected customer's system to really foul up the network it's attached to. The only plus side is, this is perfect justification to management for replacing any switches customers connect to with newer ones that (at least claim to) do per-port rate limiting. If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. I setup inbound 1434/udp filters the 3rd time we had a customer (different ones each time) get (re-?)infected weeks after the initial outbreak. Sure, some DNS replies and assorted other packets will get dropped, but AFAIK, nobody has complained or even noticed...and we've had no more re-infections since the filters were put in place. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
Thus spake [EMAIL PROTECTED] If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally safe to block on public networks, but its speed can be easily applied to other protocols we can't afford to block. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: M$SQL cleanup incentives
Doug Clements wrote: I see. So you're still filtering port 25 from the Morris sendmail worm. Funny thing, I was a researcher visiting at Cornell, and had just left in the car for the 9.5 hour drive home when it struck. I've often wished I'd stuck around for a few more hours for the excitement. Anyway, we didn't need to put in a long term block, as everyone took down their systems and cleaned them. I didn't even find out about the problem until over a day later, by which time it was long gone. Ah, the days when we all cooperated Well, of course, there were fewer systems involved. ;-) Then again, there were fewer people to fix them, too. The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Sure. I'll be happy to modify that *forever* to when all M$ systems have been cleaned and updated. Let us all know when that happens, will you? The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit. For some silly reason, not all operators are notifying their own customers, even when reported. Anyway, we passed the detection phase long ago, and the second step in eradication is quarantine. That's what I'm talking about! If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm. Fascinating. I'm sure his legal department will have an opinion on that. However, we could help protect him from legal issues by adopting self-help as a Best Current Practice. Are you ready and willing to write up the internet-draft? If you didn't filter or don't filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore. The reason is that many of us are _still_ filtering. Some who removed filters put them back. correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed. Unfortunately, I haven't seen a lot of investigation. Perhaps you can explain why the infection rate is still the same after 3 weeks? Anyway, I'll chalk you in the column for removing all filters, and hoping for the best. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Stephen Sprunk wrote: As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact. Whether or not the traffic is billable is irrelevant if your network is effectively down. One infected host connected to a 2900XL effectively kills the switch. I was fortunate enough to be on vacation and not even have net access when the initial slammer wave hit. But when I was back and on-call, we had a single customer get (re-?)infected, killing the switch they were on and noticably slowing down the network for the whole POP. What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally Be screwed unless we've completed planned upgrades. But in this case, I can filter until we've upgraded our network to hardware that's better able to deal with such traffic. Just because filtering might not always work doesn't mean it shouldn't be done when it does work. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [Re: M$SQL cleanup incentives]
On Thu, 20 Feb 2003, Joshua Smith wrote: Only if people didn't fix their servers. And if they didn't, this reverse denial of service attack is a good reminder. what was that one worm from a year or two ago that was eliminated from the net, oh yeah, code red..if they didn't fix themselves the first round, what makes you think they will fix it the second time, or the third... Their link to the net is unusable if they're infected so not doing anything is not an option. If a box is going to be infected, we want it to happen immediately upon installation. Friday night late is no fun... (Un)fortunately, the number of worm packets still coming in is too low for this (about 1 per second for a /19, so it takes a few hours on average for an IP address to be hit.) Also unfortunate is the fact that the worm has shown it can bypass many filters. It's not clear how exactly, but I guess it has something to do with broadcasts or multicasts. So depending on a filter to protect vulnerable boxes isn't an entirely safe approach, especially if there is a lot of infrastructure between the filter and the box. Maybe the best approach is to try and deliberately infect the entire local net every few minutes or so to detect new vulnerable systems while the people installing them are still on the premises.
Re: [Re: [Re: M$SQL cleanup incentives]]
it isn't legit for what i have in my network though :-) Gary E. Miller [EMAIL PROTECTED] wrote: Yo Joshua! On Thu, 20 Feb 2003, Joshua Smith wrote: i still get 8K plus hits against my acls per day for udp/1434...(75 in the time it took to write this email) You are probably doing as much damage as good. udp/1434 is not a reserved port. A lot of what you are blocking is legit traffic that picked a random port to use for an ad-hoc use. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: [Re: [Re: M$SQL cleanup incentives]]
I think the bigger issue for all of the M$SQL customers will be the new licensing fees they get stuck with... http://www.theregister.co.uk/content/53/29419.html -David Barak fully RFC 1925 compliant --- Joshua Smith [EMAIL PROTECTED] wrote: it isn't legit for what i have in my network though :-) __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: [Re: [Re: M$SQL cleanup incentives]]
Date: Fri, 21 Feb 2003 09:53:59 -0800 (PST) From: David Barak [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I think the bigger issue for all of the M$SQL customers will be the new licensing fees they get stuck with... http://www.theregister.co.uk/content/53/29419.html It could be a huge problem for some companies, but appears to have no impact on most M$SQL server users. Just companies that base products on the server. Let's not start a panic. On the other hand, Timeline's case is YEARS old and they are going after treble damages from companies who just took Microsoft's word that there was nothing to worry about. Some people should be VERY nervous, indeed. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: [Re: [Re: M$SQL cleanup incentives]]
On the other hand, Timeline's case is YEARS old and they are going after treble damages from companies who just took Microsoft's word that there was nothing to worry about. Some people should be VERY nervous, indeed. Thats the part that worries me greatly. This general idea may apply to a lot of other cases. The way I read the news story, you can not rely on your vendor to provide you with legally licensed software. Do you have to check for each software (firmware?) component you buy? How do you ever find out which licensed components are included? -- [EMAIL PROTECTED] Collaborative Intrusion Detection join http://www.dshield.org
Re: [Re: [Re: M$SQL cleanup incentives]]
Date: Fri, 21 Feb 2003 14:02:09 -0500 From: Johannes Ullrich [EMAIL PROTECTED] On the other hand, Timeline's case is YEARS old and they are going after treble damages from companies who just took Microsoft's word that there was nothing to worry about. Some people should be VERY nervous, indeed. Thats the part that worries me greatly. This general idea may apply to a lot of other cases. The way I read the news story, you can not rely on your vendor to provide you with legally licensed software. Do you have to check for each software (firmware?) component you buy? How do you ever find out which licensed components are included? This is slightly different in that the case was public fairly well known. Microsoft was asked explicitly by several customers if there was an issue and were assured that there were none. The fact that a company asked Microsoft when the KNEW that the license was at issue implies that they should have asked a lawyer about it and knowingly ignored the patent. That is the cause for treble (punitive) damages. Any company that is can substantiate that they had no reason to suspect a possible problem is probably safe from more than direct damages which will amount to back royalties. (Not that this is insignificant.) Oh, by the way, IANAL, so don't take this as having any actual basis in case law. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: [Re: [Re: M$SQL cleanup incentives]]
udp/1434 is not a reserved port. [...] legit traffic that picked a random port to use for an ad-hoc use. it isn't legit for what i have in my network though :-) Really? So you're blocking udp/1434 both in and out? Got any DNS servers on your network? Any of your desktop clients use DNS? Recent versions of un*x BIND will pick a random port above 1024 for udp conversations. It can and has picked 1434. DNS clients will eventually timeout and fall back to another server, so any problems would be transient, but the packets were legit, right? -bryan bradsby Texas State Government Net
Re: [Re: [Re: [Re: M$SQL cleanup incentives]]]
Bryan Bradsby [EMAIL PROTECTED] wrote:
udp/1434 is not a reserved port. [...] legit
traffic that picked a random port to use for an ad-hoc use.
it isn't legit for what i have in my network though :-)
i should clarify this - my data center has www/dns/ftp servers and a bunch
of voip gateways (mostly cisco), so they all talk on the same udp ports
(most of which are greater than 3)
my corporate lan does have a ms sql server or two (running on nt4), but
there is no reason that those servers should be talking to anything
outside of my network (or outside of their vlan)
Really? So you're blocking udp/1434 both in and out?
yep
Got any DNS servers on your network? Any of your desktop clients use DNS?
options {
query-source * port 53
};
Recent versions of un*x BIND will pick a random port above 1024 for udp
conversations. It can and has picked 1434.
destination port will be 53, i suppose it is possible that the client
could pick 1434 for a source.
DNS clients will eventually timeout and fall back to another server, so
any problems would be transient, but the packets were legit, right?
on the off chance that someone's windows desktop picked 1434 for a source.
those packets however will not be leaving my network.
it may not be the best way to do all of it, but it keeps my network from
being killed (it also helps that the lan admin keeps all the servers
well patched)
-bryan bradsby
Texas State Government Net
joshua
(the grouchy ip/security/*nix guy sitting alone in the dark corner of the
office)
Walk with me through the Universe,
And along the way see how all of us are Connected.
Feast the eyes of your Soul,
On the Love that abounds.
In all places at once, seemingly endless,
Like your own existence.
- Stephen Hawking -
Re: M$SQL cleanup incentives
I've been pretty disappointed with some of the responses on this issue. Yes, we filter both incoming and outgoing 1434 udp. No, we cannot keep doing that forever, the router CPU utilization is pretty high. We only logged for a couple of hours before turning that off (weeks ago) I'm of the technical opinion that everyone will need to filter outgoing 1434 udp forever. Yet, since we are (currently) free of infection, that's the direction we don't _need_ to filter. Now, some folks have expressed the opinion we should just all drop filters and let the infected machines DoS our networks, hoping against experience that the miscreant customers will notice their bad machines and fix them promptly. That's technically incompetent! For one thing, experience shows that the miscreant won't notice they're infected for DAYS! Why do you think there are 20K+ still infected? For another thing, I'm happy for all those of you that have such huge resources to overspecify your networks and equipment. The rest of us were swamped. We don't have any (that's right: zero zip nil) M$ machines in the operational network (only Linux, *BSD, Macs), and we still lost all accounting, network management, and basic services, until the border filters were in place. Iljitsch van Beijnum wrote: Maybe the best approach is to try and deliberately infect the entire local net every few minutes or so to detect new vulnerable systems while the people installing them are still on the premises. Gosh, should we do that for every known virus/worm/vulnerability? Or maybe you don't actually own and/or have legal and financial accountability for your own network? Is there anybody around here serious about actually cleaning up the mess, and thinking of network operational mechanisms to prevent such things in the future? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: M$SQL cleanup incentives
On Fri, 21 Feb 2003 17:25:46 -0500 William Allen Simpson [EMAIL PROTECTED] wrote: I've been pretty disappointed with some of the responses on this issue. Maybe you won't like this one either, but here goes. I'd be very interested in hearing how opeators feel about 'pushback'. It may make more sense near ingress edges or where there is limited aggregate capacity on the egress (a bottleneck), but debating that point is probably secondary. You can refer to some of the material, particularly by Bellovin, Floyd and others here: http://www.icir.org/pushback/ In the simplest scenario, pushback could be similarly deployed to the way RED is deployed (if you consider that easy or useful or not, I'm not sure). Signals do not even necessarily need to propagate to upstream routers, rather anomalous traffic (based on a simple, hopefully, policy) could be dropped more aggressively. This response could be automatic or require intervention. I think there are a number interesting properties to this approach, especially since if it behaves similar as one might hope, it could still allow some valid traffic through. Hint: think about what will happen if a Slammer/Sapphire-like worm hits port 25/53/80 and cannot be easily filtered without affecting all traffic on those ports. Coming up with a policy that determines what is anomalous is one of the hard parts. Vendor implementation being another, but you can kind of do this sort of thing already if you're so inclined. Thoughts? John
Re: M$SQL cleanup incentives
I'd be very interested in hearing how opeators feel about 'pushback'. the only interesting thing i have seen in this space randy
Re: M$SQL cleanup incentives
On Fri, 21 Feb 2003, William Allen Simpson wrote: I've been pretty disappointed with some of the responses on this issue. :-) I'm of the technical opinion that everyone will need to filter outgoing 1434 udp forever. Forget it. That's a port used for legitimate traffic. Besides, filtering on port numbers is a flawed proposition to begin with. The fact that it more or less works is just luck. Too bad we can't filter on competence. Now, some folks have expressed the opinion we should just all drop filters and let the infected machines DoS our networks, hoping against experience that the miscreant customers will notice their bad machines and fix them promptly. That's technically incompetent! Thank you. I agree that at this time it is often not feasible to simply not filter. But that's certainly the place I want to be in the future. If a customer wants to spew out 50 Mbps worth of UDP I don't want that to influence my network. So either I forward the traffic and the customer pays for the bandwidth or I rate limit it and they live with the packet loss. For one thing, experience shows that the miscreant won't notice they're infected for DAYS! Why do you think there are 20K+ still infected? Most of those are dial-up so their traffic isn't all that much and they're hard to track down. Depending on how the OS works, such a host may not even experience a very significant slowdown. For another thing, I'm happy for all those of you that have such huge resources to overspecify your networks and equipment. The rest of us were swamped. We don't have any (that's right: zero zip nil) M$ machines in the operational network (only Linux, *BSD, Macs), and we still lost all accounting, network management, and basic services, until the border filters were in place. Strange. By the way: I manage ~ 4 networks. One just upgraded to huge resources and they didn't feel the extra 100 Mbps traffic from two infected customer boxes (I filtered it anyway, good netizen as I am). Another has more or less adequate resources; one router also had 2 infected boxes on the local network but this one could handle it. The next router (behind a 1:3 funnel) had a meltdown even though the hardware is identical. Always use CEF, kids. Two other networks are more or less underpowered, but no real trouble (one also with two infected boxes).
Re: [Re: [Re: M$SQL cleanup incentives]]
On Sat, 22 Feb 2003, E.B. Dreger wrote: BB Recent versions of un*x BIND will pick a random port above BB 1024 for udp conversations. It can and has picked 1434. Standard socket(2) behavior. BIND [hopefully] runs chown(2)ed, so the source port number must be = 1024. At startup, named bind(2)'s a UDP port to send queries from, and get the answers back on. In the absence of a query-source option that specifies otherwise, this will be a random ephemeral port, however that's defined on the system. TCP queries follow standard behavior, binding a random ephemeral port for each query. Pardon the pedantry, but since this is an often misundertood topic, I thought it might help to lay out the facts. HTH, Doug -- The last time France wanted more evidence, it rolled right through Paris with a German flag. - David Letterman
Re: M$SQL cleanup incentives
On Thu, 20 Feb 2003, William Allen Simpson wrote: Worse, it only takes 1 infected host to re-infect the entire net in about 10 minutes. So, the entire 'net has to cooperate, or we'll see continual re-infection. Only if people didn't fix their servers. And if they didn't, this reverse denial of service attack is a good reminder. Unfortunately, this is a cost that prevents pain to others, rather than self-inflicted pain. Another pollution of the commons issue. Seems to me that filtering is no longer necessary unless you have reason to believe your customers are going to install new vulnerable boxes or vulnerable software on existing boxes AND their pipe to you is so big the excess traffic is going to hurt you more than them.
Re: [Re: M$SQL cleanup incentives]
Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On Thu, 20 Feb 2003, William Allen Simpson wrote: Worse, it only takes 1 infected host to re-infect the entire net in about 10 minutes. So, the entire 'net has to cooperate, or we'll see continual re-infection. Only if people didn't fix their servers. And if they didn't, this reverse denial of service attack is a good reminder. what was that one worm from a year or two ago that was eliminated from the net, oh yeah, code red..if they didn't fix themselves the first round, what makes you think they will fix it the second time, or the third... Unfortunately, this is a cost that prevents pain to others, rather than self-inflicted pain. Another pollution of the commons issue. Seems to me that filtering is no longer necessary unless you have reason to believe your customers are going to install new vulnerable boxes or vulnerable software on existing boxes AND their pipe to you is so big the excess traffic is going to hurt you more than them. the reason is that ms sql and msde are vulnerable out of the box, and since ms is such a popular o/s, you can be reasonably certain that new vulnerable boxes are installed everyday. and while a vulnerable box on a small pipe may slow the initial growth, how long would it take to find another vulnerable box on a big pipe? i still get 8K plus hits against my acls per day for udp/1434...(75 in the time it took to write this email) joshua Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: M$SQL cleanup incentives
On Thu, 20 Feb 2003 22:11:06 +0100, Iljitsch van Beijnum said: Seems to me that filtering is no longer necessary unless you have reason to believe your customers are going to install new vulnerable boxes or vulnerable software on existing boxes AND their pipe to you is so big new vulnerable boxes has to be assumed as the default state for any new installs, until such time as the vulnerability is patched in the base install, and has been out for so long that installing the unpatched version will inspire ewww that's old comments... msg09208/pgp0.pgp Description: PGP signature
Re: [Re: M$SQL cleanup incentives]
Yo Joshua! On Thu, 20 Feb 2003, Joshua Smith wrote: i still get 8K plus hits against my acls per day for udp/1434...(75 in the time it took to write this email) You are probably doing as much damage as good. udp/1434 is not a reserved port. A lot of what you are blocking is legit traffic that picked a random port to use for an ad-hoc use. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
