i have grown increasingly nervous about going with modbus TCP in our control systems. I find it scary that modbus TCP is an open protocol, inviting the world to hack. Right now the PLC and HMI speak to each other using this protocol. traditionally, our company does not protect vital registers from modification. The switch is behind a cabinet that is locked. I am curious what sort of protection can be provided, if any, to prevent intrusion or denial of service attack on the system. I also fear of liability issues involved in this sort of scenario. Do most people monitor UI modifications to system registers via a log? Do BMS systems assume the responsibility to stay away from mapped areas that are not theirs? the volume of data to protect is large and the resources for programming protection is too small to justify a change in the future. I am curious if there are switches that can filter based on mac address to only modify specific modbus TCP registers.
Try openwrt, you can program any security scenario.
Openwrt is avaiable for most routers.
Assume you use Modbus TCP communication only within a private subnet.
Then the ModbusTCP server could check the IP address of the client and only allow a connection from a know IP address.
Unfortunately this is not implemented on most gateways but you can implement this if you have a software-modbusTCP/RS485-gateway on standard PC hardware.
On Linux and Windows the solution could be a IPSEC filter.
Being an open standard i would say is a plus here as this allows you as a end user to understand the possibilities in the protocol. Other systems like Siemens (which i am particularly aware of) also have a default non configurable everything open policy. And for modbus, many devices have proprietary extensions that allow for instance downloading new code
I think the necessary measure should be (in most cases) to separate the modbus traffic network from office traffic with a firewall and control access. Physical protection of switches and cabling should also be considered.
An easy approach would be to keep a no entrance policy on the control net, having services exporting data to outside machines from within the network.
Virtual lans may be a useful tool to separate traffic when dedicated cabling is not feasible
What i am describing is not a hacker proof system, but rather what can be done easily to good effect
I doubt any 'switch' can do this. There are many boxes which can enable/block basic traffic based on MAC, but I doubt most can work down to protocol bytes within Modbus. The real high-end ($20,000?) security boxes probably could be scripted to do it.
There is a Linux Modbus 'firewall' which can do this, but you'd require a 2-port Linux box. ( http://modbusfw.sourceforge.net/ )
Alternatively you could completely hide the PLC behind some form of programmable gateway where you define a reduced register set and control access by MAC, which would block any random Modbus access merely because most registers are unaccessable. It would be a lot of work, so you'd become addicted to having a programmer on staff.
You can use a managed switch like our MSM-508. This will allow you to restrict access based on IP address.
> You can use a managed switch like our MSM-508. This will allow you to
> restrict access based on IP address.
That is not what this user wants.
They want Modbus packet 'introspection' to enable/disable access via the type of function *AND* the data range, so that a particular Master can only read certain Modbus data and so on. Yes, an IP might be involved, but they want to (for example) say "SCADA can only read PLC registers 4x00100 to 4x00189 and cannot issue any writes". Simple IP-filtering won't do this.
Seems like an odd place to apply that sort of rule set to me. Anyway - I think you could implement it with a cheap PC with 2 NICs running Snort in "Network Intrusion Detection" mode. You would simply build a rule that drops traffic based on your source and Modbus address range. It can be a bit pesky if you're not comfortable with Linux. You might get someone who is to give you a hand with the initial setup.
"Design Simplicity Cures Engineered Complexity"
What if you put another PLC or a PC between the network and the PLC's as a bridge? It accepts and replies to client commands, and issues commands and accepts responses from the PLC's. You could either do it on a one-to-one transaction basis, or build a data table in your gateway/bridge and run the outside and inside parts asynchronously and buffer the data.
Requests that are out of bounds for a given client could either be ignored or you could return a Modbus exception response.
Seems like a device that's programmable to the level of a PC or PLC would have an easier time of this than a product we'd normally think of as a bridge or gateway.
If someone is able to work with MAC and IP addresses and make some kind of filter, the Hirschmann switches can be the solution.
I have used these switches and work very well with Siemens PLCs (although we haven't used its filter to MAC/IP addresses yet). I think the MACH1000 Fast Ethernet switches can do part of what you want to.
Of course and as Lynn August wrote, these devices can't block/allow specific registers from PLC, they block/allow the communication to/from PLC, it's all or nothing.
I hope it helps!
Saludos desde Venezuela
Gustavo A. Valero P.
I did find this device, Tofino, that does provide modbus filtering over IP...I am looking into it and it looks promising. It can only segregate 2 portions of the modbus map, but this is at least a start. It has a high $ though