it isn't legit for what i have in my network though 
Yo Joshua!
> 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
  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
> 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
Date: Fri, 21 Feb 2003 14:08:46 -0600 (CST)
From: Bryan Bradsby
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?
s/DNS/UDP-based servers/
Recent versions of un*x BIND will pick a random port above
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.
DNS clients will eventually timeout and fall back to another
server, so any problems would be transient, but the packets
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
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
> DNS clients will eventually timeout and fall back to another
> server, so any problems would be transient, but the packets
> 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