[unisog] Lifting backbone port 1434/udp blocks

Michael Sinatra michael at rancid.berkeley.edu
Tue Jan 28 20:16:29 GMT 2003



On Tue, 28 Jan 2003, Glenn Forbes Fleming Larratt wrote:

> How does 'forever' grab you?
>
> We made the decision long ago (January 2001, after some initial TCP
> 1433 portscans) that MS-SQL servers were campus-only resources, and
> there was no justification for allowing unfettered access thereto to
> the entire Internet. Lucky for us...because SQLSnake hit in May.
>
> We made the decision more recently (November 28th, after some initial
> UDP 1434 portscans) that if we were going to block MS-SQL, we should
> do it across the board, and block TCP and UDP 1433 and 1434. Lucky for
> us, again...as this past weekend shows.

How are you dealing with the fact that 1433 and 1434 are unprivileged
ports?  We've aready seen legitimate DNS traffic blocked by our udp/1434
filter on the outbound side.  In this case because 1434 is an unpriviliged
port, a DNS query is free to take udp/1434 as its source port.  When the
response comes back from an offsite DNS server, 1434 becomes the
destination and the packet is dropped.  If you're also blocking tcp/1434,
I would guess that you're using the 'established' keyword in a cisco ACL
or some similar stateful mechanism.  Otherwise, it would be even worse
because you would be blocking random web, SMTP, etc. that happened to use
1434 as its source port and all of the resulting ACKs were blocked.

Our problem is that we have a lot of asymmetric traffic across our border,
as we have two sets of border connections.  And I don't see any reasonable
way that a cisco ACL can deal with the UDP side.  I know IPFILTER can
maintain "state" on UDP, but that's usually deployed on a much smaller
scale, with symmetry of traffic.

The udp problem gets ugly with BIND 9, which settles on a source port on
startup and sticks with that same port for all recursive queries.  I had a
case where a university was blocking some unprivileged UDP port in both
directions and one of our entire nameservers couldn't see anything within
that university and our users complained.  Once I contacted that
university, they understood the problem and modified the ACL.  But even if
your ACL is inbound only (as ours is), you can still block legitimate
traffic (as ours has) and that could create the kinds of intermittent
problems that drive helpdesks crazy.

michael



More information about the unisog mailing list