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
it isn't legit for what i have in my network though :-) "Gary E. Miller" <gem@rellim.com> wrote: 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 gem@rellim.com 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 -
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 <joshua.ej.smith@usa.net> 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/
Date: Fri, 21 Feb 2003 09:53:59 -0800 (PST) From: David Barak <thegameiam@yahoo.com> Sender: owner-nanog@merit.edu
I think the bigger issue for all of the M$SQL customers will be the new licensing fees they get stuck with...
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: oberman@es.net Phone: +1 510 486-8634
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? -- -------------------------------------------------------------------- jullrich@euclidian.com Collaborative Intrusion Detection join http://www.dshield.org
Date: Fri, 21 Feb 2003 14:02:09 -0500 From: "Johannes Ullrich" <jullrich@euclidian.com>
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: oberman@es.net Phone: +1 510 486-8634
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
BB> Date: Fri, 21 Feb 2003 14:08:46 -0600 (CST) BB> From: Bryan Bradsby JS> it isn't legit for what i have in my network though :-) BB> Really? So you're blocking udp/1434 both in and out? BB> BB> Got any DNS servers on your network? Any of your desktop BB> clients use DNS? s/DNS/UDP-based servers/ 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. 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. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
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
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
participants (8)
-
alex＠yuriev.com -
Bryan Bradsby -
David Barak -
Doug Barton -
E.B. Dreger -
Johannes Ullrich -
Joshua Smith -
Kevin Oberman