Re: ubuntu-devel Digest, Vol 23, Issue 16

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Nathan Sutton
> On 7/4/06, Scott James Remnant <[hidden email]> wrote:
> > > There should be no exception: there should be no open ports by default.
> > >
> > This isn't actually entirely true; we currently have two open ports by
> > default:
> >
> > If you're on a network with DHCP, the DHCP client listens on UDP port 68
> > to receive responses from the DHCP server.
> >
> > And every time you make a DNS query, a UDP port is opened to receive the
> > response from the DNS server.
>
> Both of these are examples of getting replies to queries sent out by the
> system, so they don't count, really.
> - Dan

Ahh, but UDP doesn't maintain state, except at higher levels in the
OSI model.  This can be exploited for ARP poisoning attacks and DoS,
so these examples do count.

Nate

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Dan Kegel-2
On 7/4/06, Nathan Sutton <[hidden email]> wrote:

> > > If you're on a network with DHCP, the DHCP client listens on UDP port 68
> > > to receive responses from the DHCP server.
> > >
> > > And every time you make a DNS query, a UDP port is opened to receive the
> > > response from the DNS server.
> >
> > Both of these are examples of getting replies to queries sent out by the
> > system, so they don't count, really.
>
> Ahh, but UDP doesn't maintain state, except at higher levels in the
> OSI model.  This can be exploited for ARP poisoning attacks and DoS,
> so these examples do count.

strace seems to show that by default, the DNS port is only open
until the response is received.  So it looks like there's only one
open UDP port,  not two.  netstat -lu confirms this on my
dapper box:

dapper:~$ netstat -lu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 *:bootpc                *:*

I had a quick look at
http://www.ietf.org/rfc/rfc2131.txt
and didn't see anything that would require the dhcp client to
keep the port open.  Maybe this is a bug... can somebody who
really understands dhcp comment?
- Dan

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Scott James Remnant-2
On Tue, 2006-07-04 at 15:38 -0700, Dan Kegel wrote:

> On 7/4/06, Nathan Sutton <[hidden email]> wrote:
> > > > If you're on a network with DHCP, the DHCP client listens on UDP port 68
> > > > to receive responses from the DHCP server.
> > > >
> > > > And every time you make a DNS query, a UDP port is opened to receive the
> > > > response from the DNS server.
> > >
> > > Both of these are examples of getting replies to queries sent out by the
> > > system, so they don't count, really.
> >
> > Ahh, but UDP doesn't maintain state, except at higher levels in the
> > OSI model.  This can be exploited for ARP poisoning attacks and DoS,
> > so these examples do count.
>
> strace seems to show that by default, the DNS port is only open
> until the response is received.  So it looks like there's only one
> open UDP port,  not two.
>
No, it's still an open port.  UDP lacks any form of checking that things
received are the expected responses, and while the port is open for the
response anything can be sent to it (this is safe-guarded with TCP,
which is why TCP connections aren't considered "open ports").

This means it's up to the application to ensure that while its UDP port
is open, it discards any unexpected responses.

So it's effectively an open port.

Scott
--
Scott James Remnant
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Dan Kegel-2
On 7/4/06, Scott James Remnant <[hidden email]> wrote:
> > strace seems to show that by default, the DNS port is only open
> > until the response is received.  So it looks like there's only one
> > open UDP port,  not two.
>
> No, it's still an open port.  UDP lacks any form of checking that things
> received are the expected responses, and while the port is open for the
> response anything can be sent to it (this is safe-guarded with TCP,
> which is why TCP connections aren't considered "open ports").

Good point.  (The window during which the port is open is pretty short,
which lessens the chance of an attack succeeding, but doesn't make it zero.)
I wonder how practical it would be to get glibc to use tcp for
DNS requests... a friend of mine is about to open a can of whoop-ass
on nscd, maybe I'll ask him to look into that.   (Not that ubuntu uses nscd
by default, but nevermind that...)

There remains the dhcp open port.  I'm still curious why that needs to be there
while the client is in bound state.   (Even if we get rid of that, there will
still be a window during system startup when it's vulnerable to attack,
but that's by design; dhcp is inherently promiscuous.   I have to hope that
networks managed by DHCP also filter out bogus DHCP packets from outside.)
- Dan

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Ivan Krstić-3
Dan Kegel wrote:
> I wonder how practical it would be to get glibc to use tcp for
> DNS requests...

Not an option; many sites only allow AXFRs via TCP/53.

--
Ivan Krstic <[hidden email]> | GPG: 0x147C722D

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: UDP open ports [was: ubuntu-devel Digest, Vol 23, Issue 16]

Matthew Palmer-2
On Tue, Jul 04, 2006 at 08:55:54PM -0400, Ivan Krstic wrote:
> Dan Kegel wrote:
> > I wonder how practical it would be to get glibc to use tcp for
> > DNS requests...
>
> Not an option; many sites only allow AXFRs via TCP/53.

Then those sites are broken.  A DNS server must allow TCP/53 for responses
which are larger than a single UDP packet.

- Matt

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Daniel Pittman
In reply to this post by Dan Kegel-2
"Dan Kegel" <[hidden email]> writes:

> On 7/4/06, Scott James Remnant <[hidden email]> wrote:
>> > strace seems to show that by default, the DNS port is only open
>> > until the response is received.  So it looks like there's only one
>> > open UDP port,  not two.
>>
>> No, it's still an open port.  UDP lacks any form of checking that things
>> received are the expected responses, and while the port is open for the
>> response anything can be sent to it (this is safe-guarded with TCP,
>> which is why TCP connections aren't considered "open ports").
>
> Good point.  (The window during which the port is open is pretty short,
> which lessens the chance of an attack succeeding, but doesn't make it zero.)
> I wonder how practical it would be to get glibc to use tcp for
> DNS requests...

That would make you extremely unpopular in a wide range of ISP
environments, as you just radically increased the load on their DNS
servers.  The rest of the Internet infrastructure might well want a work
also...

Not to mention the much lower performance for DNS lookups from your new
TCP-only client, especially on loaded links, and the much higher
probability of triggering bugs by using a much less tested code path in
the various DNS serves out there.

[...]

> There remains the dhcp open port.  I'm still curious why that needs to
> be there while the client is in bound state.  

Because DHCP requires address renewal, which requires communication with
the DHCP server.  The client, at least in sane cases, drops away from
root (which can open raw sockets) to mitigate security risks.

So, you either run your DHCP client as root full time, or you keep the
socket open.

Regards,
        Daniel
--
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: [hidden email]
http://digital-infrastructure.com.au/


--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: UDP open ports [was: ubuntu-devel Digest, Vol 23, Issue 16]

Scott James Remnant-2
In reply to this post by Matthew Palmer-2
On Wed, 2006-07-05 at 11:40 +1000, Matthew Palmer wrote:

> On Tue, Jul 04, 2006 at 08:55:54PM -0400, Ivan Krstic wrote:
> > Dan Kegel wrote:
> > > I wonder how practical it would be to get glibc to use tcp for
> > > DNS requests...
> >
> > Not an option; many sites only allow AXFRs via TCP/53.
>
> Then those sites are broken.  A DNS server must allow TCP/53 for responses
> which are larger than a single UDP packet.
>
But I do not believe they must allow TCP/53 for responses that are
SMALLER than a single UDP packet.

Scott
--
Scott James Remnant
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UDP open ports [was: ubuntu-devel Digest, Vol 23, Issue 16]

Matthew Palmer-2
On Wed, Jul 05, 2006 at 03:08:07AM +0100, Scott James Remnant wrote:

> On Wed, 2006-07-05 at 11:40 +1000, Matthew Palmer wrote:
>
> > On Tue, Jul 04, 2006 at 08:55:54PM -0400, Ivan Krstic wrote:
> > > Dan Kegel wrote:
> > > > I wonder how practical it would be to get glibc to use tcp for
> > > > DNS requests...
> > >
> > > Not an option; many sites only allow AXFRs via TCP/53.
> >
> > Then those sites are broken.  A DNS server must allow TCP/53 for responses
> > which are larger than a single UDP packet.
> >
> But I do not believe they must allow TCP/53 for responses that are
> SMALLER than a single UDP packet.

I'd love to see the firewall rules on *that* one... <grin>  Does BIND have a
"reject unsolicited TCP DNS requests" option?  I've certainly never seen one
(although that's not definitive; I tend to find options by grep rather than
by an exhaustive reading of named.conf(5)).

- Matt

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Dan Kegel-2
In reply to this post by Daniel Pittman
On 7/4/06, Daniel Pittman <[hidden email]> wrote:
> > I wonder how practical it would be to get glibc to use tcp for
> > DNS requests...
>
> That would make you extremely unpopular in a wide range of ISP
> environments, as you just radically increased the load on their DNS
> servers.

Yeah, I guess it's not too practical.  While we're on the subject of
security and overhead, may as well mention dnssec, too.
(How the heck would the keys get distributed in the real world?)
Anyway, the no-open-port policy probably says "but DNS is ok",
or should.

> > There remains the dhcp open port.  I'm still curious why that needs to
> > be there while the client is in bound state.
>
> Because DHCP requires address renewal, which requires communication with
> the DHCP server.  The client, at least in sane cases, drops away from
> root (which can open raw sockets) to mitigate security risks.

Sounds like a perfect use for CAP_NET_BIND_SERVICE.
The client could keep the one capability it needs, but
drop the rest of root.  (I haven't looked at the code, but I
wouldn't be surprised if it's already in there...)
- Dan

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: ubuntu-devel Digest, Vol 23, Issue 16

Micah Cowan
In reply to this post by Dan Kegel-2
On Tue, Jul 04, 2006 at 05:10:12PM -0700, Dan Kegel wrote:

> On 7/4/06, Scott James Remnant <[hidden email]> wrote:
> > > strace seems to show that by default, the DNS port is only open
> > > until the response is received.  So it looks like there's only one
> > > open UDP port,  not two.
> >
> > No, it's still an open port.  UDP lacks any form of checking that things
> > received are the expected responses, and while the port is open for the
> > response anything can be sent to it (this is safe-guarded with TCP,
> > which is why TCP connections aren't considered "open ports").
>
> Good point.  (The window during which the port is open is pretty short,
> which lessens the chance of an attack succeeding, but doesn't make it zero.)

I think such things are a necessary evil... Perhaps "no open ports"
should be ammended to mean "...except for specifically-limited uses for
a small window of time"?

A potentially bigger exception is the fact that, if a user opens a
non-passive FTP connection and fetches a file, they will implicitly open
a TCP port (which isn't explicitly safe-guarded, I believe, since it's
for an  "incoming" connection).

It might be worthwhile to be as conscious as possible about such things,
and manually verify that all code that we allow to do this explicitly
checks that the sender IP address is as expected... I doubt we could
realistically do a 100% job of that, though (trying to track every
program that can do FTP would be a feat).

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: UDP open ports [was: ubuntu-devel Digest, Vol 23, Issue 16]

Ian Jackson
In reply to this post by Scott James Remnant-2
Scott James Remnant writes ("Re: UDP open ports [was: ubuntu-devel Digest, Vol 23, Issue 16]"):
> But I do not believe [nameservers] must allow TCP/53 for responses
> that are SMALLER than a single UDP packet.

RFC1123 `Requirements for Internet Hosts - Application and Support'
aka STD-3:

         6.1.3.2  Transport Protocols

            DNS resolvers and recursive servers MUST support UDP, and
            SHOULD support TCP, for sending (non-zone-transfer) queries.
            Specifically, a DNS resolver or server that is sending a
            non-zone-transfer query MUST send a UDP query first.  If the
            Answer section of the response is truncated and if the
            requester supports TCP, it SHOULD try the query again using
            TCP.

            DNS servers MUST be able to service UDP queries and SHOULD
            be able to service TCP queries.  A name server MAY limit the
            resources it devotes to TCP queries, but it SHOULD NOT
            refuse to service a TCP query just because it would have
            succeeded with UDP.

Ian.

--
ubuntu-devel mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel