Text 9437, 87 rader
Skriven 2007-02-14 01:34:10 av Maurice Kinal (1:140/13)
   Kommentar till text 9435 av Paul Rogers (1:105/360.0)
Ärende: It's been a good week
=============================
Hey Paul!

Feb 13 17:15 07, Paul Rogers wrote to Maurice Kinal:

 PR> Oops, but I fixed it in another message.

I saw that.

 MK>> I think there is a "listen" command that causes sshd to only accept
 MK>> traffic  on the interface in question.  I forget if there is

 PR> Well, what systems run more than one?  A firewall/gateway/router,
 PR> and possibly a bastion host.  In my case, eth0 connects me to my
 PR> LAN, and the router which would allow attackers in, if it weren't
 PR> for the firewall.  Put a ssh daemon there?  I don't think so!

No.  Put it on a capable server on the same network that your eth0 is on.  It
could service many networks but only listen and serve X on the desired LAN. 
You could even make it a Gbit only network if speed is a desirable thing and
all other networks shouldn't even see it.  To test that run nmap on a different
network to that machine and it shouldn't show up at all although other services
open on that particular network should.

Best example I have is currently I have a secure ftp running on my gateway with
no ssl on eth1 which is my trusted LAN.  Also on there is the static internet
IP address on eth0.  If you scan ports on that address you should see no open
ports but if I scan it's private ip address on eth1 then lo and behold there it
is (21/tcp open  ftp)!  For you to gain access to it you'd need to be on the
same network and have an account on there.  The wireless network has access to
there (my neighbour Paul) via my workstation that has the private ip wired
network on it's eth0 and the wireless on ra0.  That is accomplished by my
workstation masquerading for his particular wireless interface to my particular
private ip on the LAN as well as having created an account for him on the
little guy that runs the internet connection here.

Does that make sense?  If not then check your favourite search engine with;

    "chroot jail" & sshd

and you should get a whole mess of hits that will explain it better then I can
given that I don't use X locally or networked nevermind sshd.  It isn't an
issue with me but if it were then that looks to be an interesting way to
accomplish it.

 PR> Yes, one can restrict the keys.

That too.  Where that might be interesting is to serve up specifics to that
user based on the user's preferences and needs.

 PR> Well, yes.  MAC address matching is very restrictive.  But
 PR> in the case of ssh tunneling, everything is encapsulated and
 PR> transmitted through port 22.

Not necessarily.  Ports as well as interfaces can be changed.  If you change
the port then choose one that won't interfere with a port normally used by a
different service and that will help with security issues.

 PR> an offset, usually 10.  But that isn't in /etc/services, and
 PR> not accepted by iptables, yet it works.

Of course.  Only dumb downed services expect you to follow the so-called rules.

 PR> it at the server.  Secure?  Sure.  But a PITA.

Yes.

 PR> I dunno, maybe the system configs could allow passwording,
 PR> then users could scp their public keys to the server with a
 PR> supplied password, add them to ~/.ssh/authorized_keys, and
 PR> then edit their ~/.ssh/config on the workstation to disallow
 PR> further passwords.

Something like that should work.

 PR>> P4's I think.
 MK>> Whoa!  That would be interesting to see in action.

 PR> Kinda hard to demo--where are you gonna find a workload
 PR> that exercises them?  Cute for a Beowulf cluster though.

No doubt.

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: Coffin Point BBS (1:140/13)