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: [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: [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: [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: [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
