Re: Default DENY with ipchains
On Mon, Oct 23, 2000 at 12:06:57AM -0400, James Antill wrote:
> Steve Bowman <sbowman@frostwork.net> writes:
>
> > I think we're talking apples and oranges here. Let me clarify. Because
> > S. Sehic used the phrase "ordinary users", I responded with comments
> > pertaining to opening ports locally, e.g., with bind(). My comments
> > involving ftp, etc., reflect that because I was talking about client-side
> > connections rather than a root-owned service. In that case, the change
> > to PROT_SOCK would prevent "ordinary users" from opening those sockets.
>
> This is what I was talking about, denying users from using the
> bind() function. What may have confused you is that I started talking
> about connect() because connect() does an implicit bind(). For
Looking back, it seems clear enough that you were talking about
incoming connections. I'm not sure what got me thinking otherwise....
Tired maybe.
> instance run the following /bin/sh script under potato...
>
> #! /bin/sh
>
> while :; do
> telnet localhost 1200;
> done
>
> ...after a while it will stop saying
> "telnet: Unable to connect to remote host: Connection refused" and
> anything you type will then be repeated back to you when you press
> return (or after every character if you turn telnet into character
> mode). This is because the connect() to port 1200 by chance connect'd
> to the port that had been implicitly bound by the connect() before it
> happened (connect() is guaranteed to have this bahaviour) -- if you
> follow that.
If I understand you correctly, you're saying that the incoming connection
will fail because the outgoing connection already bound 1200 and because
the outgoing connection binds first.... Something doesn't sound quite
right with that so maybe I misunderstand.
On my box, it will fail because nothing is listening at 1200. However, if
something were to be listening at 1200, an attempt to bind it explicitly
would fail because the port's in use (IIRC). A connect with a * port
would simply get a different port.
>
> This is the only problem I could see with changing PROT_SOCK, as I
> haven't done a (and am unlikley to do a) test to see if connect() will
> still work (Ie. if the implicit bind() will succeed), because I'm
> almost positive that it'll never have a port < 1024 from an implicit
> bind().
> So if you test it and it doesn't work for normal users then you'll
> have to hack the functions I ponted out in my last email to the list.
>
> > However, after rereading the original post and Mr. Antill's reply, I
> > realize you are both speaking of users owning the port on the remote side.
> > It is _not possible_ to determine that the user associated with a remote
> > connection until _after_ a connection is made.
>
> This isn't what I was saying at all, I'm sorry for any confusion I
> may have caused.
ACK. No problem. I was writing more for the original poster than for
you anyway.
> It's impossible to know who the user on the other end is (ident
Agreed! That was the whole point I was trying to make clear.
> etc. only help the remote admin, it's no use to you as it can be
> easily faked and isn't always available).
Umm, yes, ident is totally useless in this context. Use authentication
protocols.
Steve
--
Steve Bowman <sbowman@frostwork.net> (preferred)
Buckeye, AZ <sbowman@goodnet.com> <bowmanc@acm.org>
<http://www.goodnet.com/~sbowman/>
Powered by Debian GNU/Linux and GNU/Hurd <http://www.debian.org>
Reply to: