You can use Linux iptables (standard on Redat 4.x and 5.x) to very
narrowly limit which ports are accessible to which specific hosts....
dropping connections to/from all others. With iptables you can configure
eth0 and eth1 separately for a spectrometer host.
Iptables works at the kernel level, upstream of tcpwrappers (hosts.allow &
deny) and prevents evil hosts from seeing your system. An attempted ssh
connection with just tcpwrappers results a "port 22 connection refused"
message to the perpetrator. If the connection is dropped by iptables
there is no response at all. The attempt is not even logged unless you
use a more advanced construction in /etc/sysconfig/iptables.
I'd be happy to provide an example of our configuration to anyone
interested.
--Mike
----------------------------------------------------------------------------
Michael Strain mstrain_at_uoregon.edu
desk/voice-mail: (541)-346-4605 cell: (541)-556-4077
CAMCOR NMR Spectroscopy Facility text: 5415564077_at_vtext.com
Klamath Hall - Chemistry
http://nmr.uoregon.edu
University of Oregon, Eugene, OR 97403-1253
----------------------------------------------------------------------------
On Sun, 10 Jul 2011, 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 Mon Jul 11 2011 - 10:06:24 MST