Why not just have SSH forward the ports you need - a lot less messing
around and the pop etc will be encrypted. For extra security use RSA keys
with ssh. All that said SSH is not free for non unix clients.
John
At 09:06 AM 6/22/99 +0000, Bryan Andersen wrote:
> > I have small network protected by firewall and now have a few people that
> > need to use internal services (e.g. POP3, SMTP) via dialup from various
> > other cities. Since they're using dialup, I can't just open up a hole in
> > my network for their IP. What I'm looking for is some kind of thin client
> > app that sits on their machine and after they dial up, they start this
> > client which authenticates them and then tells the firewall (a Linux
> > ipfwadm box) to allow their current IP to connect through.
>
> > Does such a freeware beast exist? I've never used SecuRemote for FW-1,
> > but this is what I imagine it does.
>
>If the firewall is Linux or {Free,Net,Open}BSD box, this
>would be simple.
>
>Without buying anything, I'd have them ssh (secure shell)
>into a special account (one per user). Then have them run
>a script that opens their IP up till they logout of the ssh
>session. Have ssh port open to all IPs, while everything
>else locked down. Then when one of the people logs in with
>ssh, then grab the host/ip they come in from and open the
>required ports to them while they are logged in. If you
>assign csh as the shell they log in to, then you can use the
>.login and .logout call scripts to do the work. For security,
>I'd make the login accounts have no abilities.
>
>Now for those who hate setuid scripts which the above needs...
>
>My preferred approach would be to make a small app to serve
>as the login shell. It would make the required kernel calls
>for opening up to the IP, wait around till connection
>termination, then cleanup. Place the ap as the login shell.
>As for terminal input to the ap, I'd do single character
>reads till I see a control-D, then cleanup and exit. I'd
>also make the accounts run in a sterile chroot environment.
>Make sure your ap properly cleans up on logout. Set some sort
>of internal time outs and the proper interrupt handlers. As a
>secondary security procedure, I'd write to a log file the
>date, time, userid, process id (of the ap), and the remote IP
>address to a log file, then have that log files scanned
>hourly to see if the pid is still there, if so, do nothing,
>else make sure the IP closed off.
>
>Both these approaches have the problem of having a login to
>the firewall machine. One could use a machine behind the wall
>as the target for the ssh logins, but that means you need a
>network app to tell the firewall to open up. Better then to
>write an app to run on the users machine. Unfortunatly this
>means coming up with a protocal, etc. Making sure it's secure,
>etc. My thoughts is to piggyback on a known checked out protocal,
>ie. secure shell. If needed one could also use one time passwords.
>OpenBSD makes this easy to implement.
>
>--
>| Bryan Andersen | [EMAIL PROTECTED] | http://softail.visi.com |
>| Buzzwords are like annoying little flies that deserve to be swatted. |
>| -Bryan Andersen |
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
