OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: securing X.25 connection

Re: securing X.25 connection


Neil Williams (neil.williamsunisys.com)
Tue, 01 Sep 1998 09:18:14 -0300


1998-07-30-11:24:13 g:
> I have a requirement to connect our internal system (IP based) to a data
> feed through a X.25 connection. Any advise on how to secure this X.25
> connection?

I've dealt with a couple of these. In each case, the workstation on _our_ end
of the link had to run proprietary software from the provider, whose security
couldn't be audited (and in general it stank on ice). So we just treated that
machine as part of their security infrastructure, and kept it outside our
perimeter. This is a terrific place for one of the truly trivial high-security
firewalls: a router configured to do NAT (makes it easy to make the IP addr of
the outside box be whatever the provider likes), and block all traffic except
outbound ssh. Run an sshd on the terminal host, configured to only allow in
RSA authentication connections, and set up those users who need to use the box
to be able to ssh out. If you need to run any batch transfers, do 'em with
dropoff directories and a script run out of cron that copies 'em over ssh. If
you need to print on the remote box to printers in your net, rig lpd so it
just leaves 'em in the queue (queueing enabled, printing disabled) and have an
ssh cron job move 'em from that queue into the one[s] you want on an inside
print server.

A Cisco 2501 does a perfectly fine job of this firewalling. If Cisco sold
a suitable interface card, a 2500-series could easily handle several dozen
clients, each on a separate 10baseT drop. But they don't, so you have to go
with lots of boxes, or higher-end boxes, to do a lot of these.

-Bennett



This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:46 CDT