On Fri, Aug 31, 2007 at 07:07:40PM +0100, Gregory Stark wrote:
> >
> > It shouldn't be easy. Ident uses TCP, which is rather harder to
> > spoof.
>
> Say what? It's actually quite easy to spoof TCP. There are even command-line
> tools to do it available in most Unix distributions.
Sorry, I should have been more precise. It's hard to spoof TCP
easily and usefully. It's trivial to spoof a TCP packet and send it,
but because TCP depends on the handshake, there's a bunch of
additional overhead that make the whole thing fragile: intermediate
firewalls and such like tend to detect these things and prevent their
continued use. (This is all in comparison with UDP, which is
completely trivial to spoof. In the absence of BCP38, it's also
almost impossible to detect, which is why the DNS is so vulnerable
these days.)
> > If someone can originate spoofed TCP packets from 127.0.0.1, you
> > gots bigger problems than them being able to lie about the
> > identity of a user.
>
> Well yes, there are other insecure services which look at the
> originating ip address.
I was thinking that, if your operating system is accepting packets
from 127.0.0.1 on an external interface, you're already in a world of
hurt. And if someone is able to fiddle with the packets on your own
box, then they have root anyway; they can do anything they want. If
you haven't set up your systems so that this kind of attack is
impossible from localhost, well, I don't think that anything at the
application's level of security is going to do you any good at all.
Indeed, I would argue that, for industrial-class data centre use, if
you can't use ident between machines, your network security is in
very bad shape. (That isn't to say I think it's a good idea; but
rather, that I hope the network is well enough run that, even if you
did run it, it would not represent a real risk.)
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
