Re: Protecting EPICS IOCs on ethernet

[Alan K Biocca <AKBiocca@LBL.gov>]

At the Advanced Light Source (ALS) we have done several things:

1) put accelerator (core system) controls on a separate (private)
subnet, and each sector of the beamline area on its own subnet.

2) setup the router with filters so only ALS subnets can talk to the
control net, with a few special exceptions to reach necessary and
trusted local laboratory services like dns. consider replicating
services more locally to reduce these.

3) do not install default routes in the production vxworks/epics
processors. install only trusted net routes and necessary and trusted
host routes (that aren't covered by the net routes). the crates cannot
respond to or connect to remote hosts unless the route is known to
vxworks. responses for a destination not routed to are discarded.

4) avoid placing production vxworks/epics systems in dns. many attackers
get lists of targets from dns. use local host tables instead. regular
clients use broadcasts to connect to channel access and don't need to
know hostnames.

5) have a security policy and plan so implementations can be evaluated
and progress measured.

6) development machines are on a separate development network that is
allowed to talk to the outside world and to the control net. beamlines
are similar.

7) the greatest weakness is security management on the workstations and
pc's. keep abreast of security recommendations and configurations.
breakins always come via workstations and pc's. this is where the
problem begins.

8) have a plan for disconnecting from the internet in an emergency. we
have used this once. pulling the net connections from the router to the
site core effectively isolates the facility as an island and allows it
to continue operating. insure enough services are available in this
configuration to make operations useful.

9) use tcp-wrappers on hosts to further limit access.

10) use secure shell and secure copy.

10a) consider 'pulling' software distributions into the core from the
external development systems rather than 'pushing' into the production
servers, as this allows enhanced security.

11) use ethernet switch technology so sniffers don't get much.

12) monitor hosts binary configurations with checksums like tripwire.

    etc etc etc.



-- Alan K Biocca
ALS Controls


"John A. Priller" wrote:
> 
> All;
> 
> We're about 6 months away from starting up a production EPICS system, and
> I'm wondering about how to best protect our IOCs from malicious intent
> coming at them over the ethernet.
> 
> I'd originally planned to set them up on a private network and multi-home
> the workstations on both it and our lab's ethernet, but that involves a lot
> of extra ethernet cards and running a lot of extra cable.
> 
> Our Ethernet Gurus suggest that a router/firewall combo between the IOCs and
> our building ethernet would be far easier to implement, and I'm wondering
> what other EPICS sites have tried doing and what seems to work.  I find the
> router/firewall idea appealing (from the less-work-for-me standpoint, if
> nothing else), but I'm uncertain how secure it can be configured and still
> allow EPICS to work fairly seamlessly throughout our lab (i.e, channel
> access broadcasts, beacons, log messages, what-have-you, can still pass to
> and from the IOCs and trusted workstations on the other side).
> 
> I'd be very interested in hearing what other sites have done to solve this
> sort of problem.  And if you've gone with a router and/or a firewall, any
> hints as to how you've configured the thing would be most welcome!
> 
> Thanks,
> JP
> 
> --
> John A. Priller            | Phone : (517) 333-6375
> MSU Cyclotron Laboratory   | Fax   : (517) 353-5967
> South Shaw Lane            | Email : priller@nscl.msu.edu
> East Lansing, MI 48824     | Web   : http://prille.nscl.msu.edu/jp.html