>
> 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.
That's exactly what I tried to do today. I thought about doing Ray's
suggestion with tcpdump, but ran out of time. Saturday I need to do
something, or call the provider back in Monday morning to put stuff back the
way it was before we broke the existing tangle of VPNs. I thought all of them
could go away, but apparently not (which is why I'm having to allow external
access again).
> unencrypted telnet = bad. Sticking core infrastructure like an AS400
> outside of a firewall = bad.
Believe it or not, a local provider had the AS/400 effectively outside of the
firewall for 5 years already. Putting it out there again for another 4 months
(the box is going away at the end of the year) isn't going to matter much at
this point.
> 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.
That I planned to do already.
-- Joey Kelly < Minister of the Gospel | Linux Consultant > http://joeykelly.net "I may have invented it, but Bill made it famous." --- David Bradley, the IBM employee that invented CTRL-ALT-DEL ___________________ Nolug mailing list nolug@nolug.orgReceived on 08/06/04
This archive was generated by hypermail 2.2.0 : 12/19/08 EST