Re: [PLUG] network/ssh question

[gabriel rosenkoetter <gr@eclipsed.net>]

On Wed, Apr 03, 2002 at 12:16:25PM -0500, eric@lucii.org wrote:
> Thanks Neighbor! (I'm on Dartmouth Ave. in Swarthmore)

So happens I do still live in the neighborhood, though I'm not a
student at Swarthmore College these days. (I live behind--not above,
behind--the flower shop over on Chester by the train station.)

> ok, I have heard of this before.  If I open ports >1024 do we have to
> forward all those ports to the server in question?  I guess yes.

Um... sure, I suppose. This is one-to-many NAT, I take it? (Also
called masquerading, though that term properly means something
else.)

> If we do that, does that make our server more vulnerable to attack and
> or compromise?  I guess yes... although it's a SuSE 7.3 pro system and
> we try to keep it updated.  That is, I guess, the risk we take.

Only if you've got daemons that contain buffer overflows listening
on those ports. If you're running xdm, it's liable to be listening
on 6000. Use lsof | egrep 'TCP|UDP' to find out on what ports you
have daemons listening. (If you don't have lsof, your distro surely
has a package for it.)

Thing is, if a daemon's bound to a port, the forked sshds will never
also be on that port. So for things like X that use well-known
ports, you can simply avoid forwarding *those* ports and be safe.
(Things like NFS will also grab high-ports, but they'll be using
them for communication not for listening. Sure, it'd theoretically
be possible from outside your network to spoof the IP address that
one of these forked daemons was looking for and then connect to
the daemon before the rightful client did, but that's a *really*
hard race condition to exploit.)

> I'm also guessing that the same process of using higher number ports 
> is true for mysql and http as well?  

Dunno about mysql, but any httpd that handles parallelizes responses
(Apache and most others do) does.

> Whoa yeah!  No kidding!  Sounds like a good open-source project for 
> the paranoid :-D  Our connection is via Comcast cable so we are 
> justifiably paranoid.... hummmmm.

Yeah, but it's less cool than another hack of ssh I'd like to do to
keep a carrier stream of data. See, it's theoretically possible,
even with SSH-2, to watch the data stream of a connection that's
just doing terminal stuff and record the data that goes past for
later cracking. With SSH-1, it's even pretty easy to automatically
notice when something that's liable to be "su" goes past, then grab
the next forty or so bytes and just crack that. But if my connection
to my server is always running at exactly 2 kb/sec (or something
appropriate to your connection) and only periodically peaking above
that, there's no way you can get any useful data even if you are a
MITM.

> Is there a "range" that sshd likes?  For example, I know that the game
> "Age of Empires" uses ports 47634 and ports 2300-2400.  

Dunno. Check the source. :^>

Actually, looking at the output from fstat (NetBSD's in-tree utility
that does the same thing as lsof), I see this:

root     sshd       29627    4* internet stream tcp c0c2f870 127.0.0.1:6010
root     sshd       29627    5* internet stream tcp c0c2f9a4 66.92.234.100:22 <-> 207.103.86.77:58859
root     sshd       29627    7* internet stream tcp c0c2f608 127.0.0.1:6010 <-> 127.0.0.1:61059
root     sshd         251    3* internet6 stream tcp c0bede70 *:22
root     sshd         251    4* internet stream tcp c0c2f004 *:22

pid 251 (pid's are in the third column) is the listening daemon...
seems that the forked daemon is also attached to port 22 on the
server (server IP addr is listed first, client second). The
localhost:6010 stuff is for X forwarding.

This means that OpenSSH, at least, doesn't fork and move to another
port, but rather has the main daemon do a select on incoming
datagrams on the port and, if they're attached to an related to an
established connection, pass them off to the appropriate daemon.

Which means that this is, perhaps, not your problem after all.

In light of that, I would think it was more likely that your firewall
is not properly rewriting the source address on the servers
replies... except that a telnet to port 22 does get the version
string back.

Hrm.

Have you checked the DNS resolution suggestion that was already
made? That may well be the solution...

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpSyoMRKQmHK.pgp
Description: PGP signature