full-disclosure - SQL Slammer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: niels=netsys at bakker.net (Niels Bakker)
Subject: SQL Slammer - lessons learned

> On Wed, 2003-02-05 at 06:55, John.Airey@...b.org.uk wrote:
>> Sure, you can block 1434 udp inbound, but what if your DNS server (that
>> doesn't run SQL server) picks that port randomly for incoming data from
>> other DNS servers? You'll get failures when you shouldn't.

* pauls@...allas.edu (Paul Schmehl) [Wed 05 Feb 2003, 16:57 CET]:
> No, you wouldn't, because DNS servers talk on port 53, and they wouldn't
> negotiate port 1434 because it's reserved for SQL.

Please learn how the Internet works.  BIND8 and up don't use 53 as
source for outgoing queries anymore by default; you can override this in
named.conf with

---
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	// query-source address * port 53;
---

So, given (1434 - 1023 - 1) other applications that use UDP active, or
that many outstanding queries, BIND may very well end up using UDP port
1434 for a query packet.

There is nothing in any application that keeps it from using 1434/udp,
except it being in use already by another application.  Apart from the
ludicrous idea that UDP ports are `negotiated' in any way.

	-- Niels.

--