Re: AMMRL: Network security practices

From: <holger_at_uwm.edu>
Date: Tue, 12 Jul 2011 16:21:06 -0500

In addition, it pays to run the ssh on a non standard port, i.e. not port 22 but a different port.
In my case that cut down dramatically on the number of attempted connections from the
outside. That is in particular helpful if you want to access your server from a non local
network while travelling, and thus don't want to restrict ssh with a host allow/deny policy. It
does require that your users know how to specify a specific port in their sftp software, and
that they know what that port is.
Holger
On 10 Jul 2011 at 12:11, Bill Gurley wrote:

> Alex:
>
> I am not our NMR director, but do work with him on IT matters. We have
> a similar situation: a 400 MHz Bruker NMR with imaging accessory, also
> with a RHEL 4 linux computer, and also including Paravision. And of
> course we also ran into Bruker's not wanting us to change the OS.
>
> My solution, for security purposes, was this: We set up an old, cheap
> Linksys 4-port router (no wireless, just a router). The "internet" side
> of the router was registered on our campus network with the IP
> name/number that the NMR computer previously had. In other words, when
> you sftp to that NMR computer, you are actually connecting to this
> router. The router was then configured to only allow SSH, port 22. SSH
> services on the router were configured to redirect to the local IP
> address of the linux computer, which is connected to one of the four
> ports on the router. (Look for "Port Forwarding" in your router config.)
>
> In this manner, all network ports on the linux computer are blocked,
> except for port 22. Users MUST use one of the free sftp clients to get
> data, since ftp is not allowed.
>
> In addition, we implement "TCP_wrappers" on the linux computer. (Google
> this if you're unfamiliar.) The file /etc/hosts.allow limits
> connections from our campus network and local home ISP domains. Even
> though the linux computer is behind the router, tcp_wrappers still works.
>
> We also have this setup on a Solaris computer on our 600 MHz Varian
> instrument.
>
> I have used a similar approach in our mass spec lab, where we have
> several old Windows NT computers. In that case, I use an old PC running
> linux, which has two network adapters. The linux PC is acting as a
> gateway to our mass spec lab, where all computers are connected to
> network hubs behind that linux gateway PC. This is really the same
> thing as using the linksys router, but gives you an added option of
> putting a large shared backup disk in the linux gateway PC, that is
> accessible inside the private network, and also from the internet.
>
> As for cleaning and verifying your linux computer after the compromise,
> I'm afraid I can't be of much help. Here at UT, there are people in our
> OIT security group that are linux experts, and I would rely on them to
> scan the machine and see if they can clean it up.
>
> Good luck.
>
>
> On 07/06/2011 04:01 PM, Alex Waters wrote:
> > AMMRL,
> >
> > I work in a small animal imaging facility with two Bruker MRI systems
> > that are operated by workstations running Red Hat Enterprise Linux 4.
> > The MRIs do not have an option of running Windows workstations.
> > Because ParaVision (which runs on top of TopSpin) is very fragile,
> > Bruker will not permit us to install any system updates. Naturally,
> > one of our workstations was hacked and used to send out spam. The IT
> > department was unimpressed and shut off our ethernet port. After a
> > lot of time fixing the network settings, the scanner is operational
> > again, but completely offline. Our second workstation is similarly
> > vulnerable. I got a few suggestions from our NMR colleagues, but
> > would appreciate your input as well.
> >
> > Questions:
> > 1) What strategies do you use to prevent this sort of thing from
> > happening, but still enable users to access data?
> > Keep workstations on the network and lock down as many ports as
> > possible? Does anybody know which ports/services must remain open
> > (such as flexlm and the CORBA naming service) and which can be closed?
> > Hide them behind a router/gateway computer? How does your IT
> > department feel about that? (Routers are banned here, but we could
> > maybe argue for a special exemption).
> >
> > 2) What steps do we need to take to fix the compromised workstation so
> > we can get our port back? IT said (in so many words) that they'd
> > prefer we just incinerate it. Are we going to have to wipe the disk
> > and reinstall everything?... : (
> >
> > While I do not fear linux and know how to use google, I have no
> > sysadmin/networking background and no IT support, so detail is muchly
> > appreciated. Security has been discussed in the past on this forum,
> > but not in the last several years, so I am hoping for an updated
> > conversation.
> >
> > Thank you very much!
> > Alex Waters
> >
> >
>
>
> --
> -Bill-
>
> ---------------------------------------------
> Bill Gurley, Technical Director
> Department of Chemistry
> Univ. of Tennessee, Knoxville
> ---------------------------------------------
>
Received on Tue Jul 12 2011 - 11:22:30 MST

This archive was generated by hypermail 2.4.0 : Sat Jun 17 2023 - 15:29:23 MST