I've been in some doubt about the mechanism by which DNS
requests too big for UDP will fall back onto TCP. Jeff, if
I understand you correctly, the server returns a truncated
UDP response to the client, and it's up to the client to then
initiate a TCP connection if it needs the complete result.
So that's how the client learns that the result requires TCP;
without this mechanism, only the server knows that a TCP
connection will be needed to deliver the response.
So it is sufficient to allow clients to make outbound TCP
connections to port 53, and inbound connections can be disallowed.
That crucial bit of understanding will allow me to tighten my
firewall rules, which is a Good Thing.
But folks, that wasn't really the brunt of my questions,
which were essentially:
(a) Are other people seeing similar rashes of compromise?
The oldest instance here seems to date back to the weekend.
(b) Does anyone have a clue how this compromise is being
effected? (One compromised NTW box turned out to have 223
other viruses/malwares present, but generally the 2KPro boxes
have NAV Enterprise running and updated.)
David Gillett
-----Original Message-----
From: Jeff Kell [mailto:jeff-kell@utc.edu]
Sent: Thursday, March 17, 2005 4:07 PM
To: alexandre.skyrme@ciphersec.com.br
Cc: incidents@securityfocus.com; gillettdavid@fhda.edu
Subject: Re: Pubstro rash
Alexandre Skyrme wrote:
Greetings David,
Just a thought about your third comment...
As far as I'm concerned DNS just uses 53/TCP to do zone
transfers. In case
your workstations are on a different network than your DNS
servers it should
probably be safe to block incoming TCP connections to that
network on such
port.
Tipically zone transfers would only be used by secondary
servers to update
their own zones from its primary server.
RFC1035 allows 512 bytes for a DNS response (53) but they may now be
longer, according to RFC2671 and others. If the DNS query
fails or is
"truncated", the query may be repeated over TCP.
So, 53/tcp is NOT just for zone transfers.
Jeff
