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