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