Re: [Nolug] networking question

From: Scott Harney <scotth_at_scottharney.com>
Date: Fri, 06 Aug 2004 15:00:26 -0500
Message-ID: <4113E35A.6070906@scottharney.com>

Scott Harney wrote:
> Joey Kelly wrote:
>
>>
>> Nope, it's not possible to do that. The server resides in on location,
>> and another location needs to access it. It's an AS/400, so while I've
>> tried to forward telnet to the box, apparently it needs more than just
>> that for everything to work correctly. While forwarding selected ports
>> is what I'd rather do, it's going to be simpler to just stick the box
>> on the net, having it appear to be on a real IP, while remaining on a
>> private IP so the host location can continue to access it. I'm going
>> to effectively forward all possible ports to the box.
>>
>>
>
>
> I would think long and hard about the security implications of what
> you're doing.
>
>

Free advice:
If the problem you're trying to solve is that some users need to telnet
to the AS400 from the outside world, you'd be far better off giving them
shells on the firewall (or another box behind it via port forwarding)
and forcing^H^H^Hteaching them to use putty to ssh to that box and then
telnet to the AS400 behind the firewall. you can make the users' shells
something like pdmenu ( http://kitenet.net/programs/pdmenu/ ) and they
just select the telnet session to the AS400 from a menu without having
to deal with the *nix CLI.

unencrypted telnet = bad. Sticking core infrastructure like an AS400
outside of a firewall = bad. The above idea mitigates both issues. If
you know where the user's will be originating ssh sessions from then you
can use the firewall or tcp-wrappers to tighten things up further.

-- 
Scott Harney <scotth@scottharney.com>
"Asking the wrong questions is the leading cause of wrong answers"
gpg key fingerprint=7125 0BD3 8EC4 08D7 321D CEE9 F024 7DA6 0BC7 94E5
___________________
Nolug mailing list
nolug@nolug.org
Received on 08/06/04

This archive was generated by hypermail 2.2.0 : 12/19/08 EST