СТА 3/2018

T OFINO M ODBUS TCP E NFORCER LSM Модуль Modbus TCP Enforcer позво- ляет осуществить анализ трафика Modbus TCP на достаточно глубоком уровне – уровне регистров передаваемых данных. Необходимость подобной про- верки связана с тем, что Modbus, навер- но, самый «хороший» пример по уязви- мости именно промышленных протоко- лов. Это связано с тем, что протокол Modbus, который применяется на огром- ном количестве предприятий, известен ещё с 70-х годов прошлого века. Впервые спецификация была опубликована ком- панией Modicon в 1979 году, сейчас эта компания называется Schneider Electric. Иначиная с момента публикации специ- фикации, этот протокол набирал по- пулярность и проник практически во все сферы промышленности. Можно ска- зать, что сейчас Modbus – это стандарт де-факто среди промышленных прото- колов. При этом протокол достаточно простой и лёгкий в реализации. Огром- ное количество производителей ПЛК и оконечных устройств используют его (Schneider Elecric, Advantech, ABB, FASTWEL, Emerson, WAGO и т.д.). При этом Modbus настолько популярен, что многие noname-производители имеют поддержку именно Modbus. И было бы всё хорошо, но в те далёкие годы, когда спецификация протокола была разрабо- тана, никто в принципе не думал о без- опасности. В качестве линии для переда- чи данных использовались RS-232/485, всё было изолировано внутри промыш- ленного объекта либо цеха. В результате увеличения скоростей пе- редачи данных и доли интеллектуальных устройств Modbus решили перевести на стек TCP, и в результате этого в XXI веке Modbus представлен в виде протокола Modbus TCP. Но что изменилось? Да в принципе изменений совсем немного. Modbus TCP – это по-прежнему прото- кол типа «запрос-ответ», на установку со- единения в нём ничего не завязано. В спецификации, конечно, есть пункт про установку соединения и дальнейшую его поддержку, где указано, что не следу- ет разрывать его после каждого ответа, но это рекомендуется делать только для оп- тимизации, чтобы избежать «торможе- ния». Если заглянуть внутрь пакета, то существенные значения: идентификатор устройства, код операции и данные (за- висят от операции) – остались без изме- нения. И вроде бы поле «идентификатор устройства» логически должно отвечать за базовуюбезопасность, но, увы, оно ис- пользуется не для защиты, а лишь толь- ко для адресации. Это поле используется и в протоколе Modbus RTU, и в Modbus TCP. В случае с TCP-версией оно либо игнорируется при непосредственном подключении, либо в дальнейшем ис- пользуется шлюзом для маршрутизации. Относительно поля «код операции» мож- но сказать, что в TCP-версии при ответе устройства в нём может содержаться код ошибки, либо может быть полное дубли- рование отправленной информации, что наиболее вероятно. Получается, что при переходе к TCP-версии протокол факти- чески не изменился. Modbus-данные упаковываются в Ethernet-пакет, и ис- пользуется порт 502. Все плюсы и мину- сы, присущие изначальной версии про- токола, остались неизменными.Шифро- вание, аутентификация, авторизация – это всё не про Modbus. Но есть один мо- мент с безопасностью, который всё-таки прописан в спецификации: указано, что на критически важных объектах связы- вающиеся узлы должны проверять друг друга по IP-адресу. Если рассмотреть функциональность Modbus, то можно выделить три большие группы функций, которые позволяют нам узнать про устройство: стандартные (прописаны в спецификации), зарезер- вированные и пользовательские, послед- ние вендор использует по своему усмот- рению. В разрезе безопасности и защиты протокола стоит рассматривать лишь первый тип. К нему относится доступ к данным – чтение/запись из регистров. Также стандартно доступен достаточно большой список диагностических функ- ций, который различен для разных кана- лов связи. Для TCP-версии наиболее ин- тересна функция device identification, то есть система присвоения уникального идентификатора устройству. В стандарте прописано, что устройство должно со- общить о себе ряд обязательных (vendor name, product code, MajorMinorRevision) и необязательных данных (vendorUrl, ProductName, ModelName, UserApplica- tionName). Но стандарты зачастуюне со- блюдаются. Кто-то из производителей передаёт их, кто-то не передаёт, а кто-то передаёт, но другими способами. Например, используяПОModbus Device Identificator, можно просканировать всю сеть и определить абсолютно все Mod- bus-устройства, которые там исполь- зуются. При этом подобных утилит очень много: пара приложений ModSim/Mod- Scan, fuzzing-утилиты для поиска уязви- мостей и ряд других, не стоит забывать про всем известные Wireshark и Python. Последняя позволяет очень просто соз- дать скрипт (листинг 1), передающий Modbus-данные в Ethernet-сеть. В итоге можно сделать вывод, что, имея доступ к Ethernet-сети без каких- либо дополнительных уровней защиты, можно довольно просто просканиро- вать все Modbus-устройства и, напри- мер, обнулить все регистры, либо то- чечно передать ложные данные. Ситуацию может спасти DPI-провер- ка данных. Но и тут не всё так однознач- но, простота и удобство Modbus-прото- кола несут определённые сложности в реализации его защиты. Важно пони- мать, что для TCP протокол Modbus – это конвейер данных, информация пере- даётся байт за байтом. И устройство, вы- ОБ ЗОР / П РОМЫШЛ Е ННЫЕ С Е Т И СТА 3/2018 26 www.cta.ru Листинг 1. Пример скрипта для передачи информации по протоколу Modbus TCP # скрипт, позволяющий передать ложные данные from pyModbusTCP.client import ModbusClient import time c = ModbusClient() c.host("192.168.1.1") c.port(502) c.open() while True: address = 12288 while 1 < 2: c.write_single_coil(address,0) c.write_single_register(12293,0) c.write_single_register(12291,100) regs=c.read_input_registers(12291,4) if regs is not None: print(regs) else: print("Fail!") time.sleep(1)