OT Säkerhet

Modbus

Ett seriekommunikationsprotokoll från 1979 som blev den dominerande standarden för industriell enhetskommunikation och fortfarande är brett utbrett trots att det saknar inbyggd autentisering och kryptering.

Var du ser detta: Relevant i industriella miljöer, kritisk infrastruktur och överallt där IT-nätverk ansluter till operationsteknologisystem.

Vad det är

Modbus är ett kommunikationsprotokoll som utvecklades av Modicon 1979 för användning med deras programmerbara logikkontrollers. Det definierar hur enheter utbyter data över serielinjer eller, i sin TCP-variant, över vanliga Ethernetverk. Protokollet använder en förfrågan/svar-modell där en masterenhet skickar en förfrågan innehållande en enhetsadress, en funktionskod som specificerar operationen, en dataadress och eventuell relevant data. Slavenheten på den adressen behandlar förfrågan och returnerar ett svar. Protokollet är avsiktligt minimalistiskt, vilket är varför det blev en öppen standard som tillverkare i hela branschen adopterade utan licensavgifter.

Nyckelpunkter
  • Master/slav-arkitektur där en master pollar en eller flera slavar för data eller skickar kommandon.
  • Tre huvudvarianter: Modbus RTU och ASCII för serielänkar, Modbus TCP för Ethernetverk.
  • Kommunicerar med funktionskoder som definierar läs-, skriv- och diagnostikoperationer.
  • Ingen autentisering, ingen kryptering och ingen meddelandeintegritetskontroll i basprotokollet.
  • Finns fortfarande i nästan varje industrisektor, från energi och vatten till tillverkning och fastighetsautomation.

Hur det fungerar i stora drag

  1. Mastern initierar all kommunikation genom att skicka en förfrågningsram. Slavenheter talar aldrig utan att bli tillfrågade. Det innebär att nätverkstrafik från en legitim master följer förutsägbara mönster som kan användas som baslinje.
  2. Varje förfrågan innehåller en enhetsadress som identifierar målslavens enhet, en funktionskod som specificerar operationen exempelvis läsning av hållregister eller skrivning av enskild spole, en dataadress som specificerar vilket register eller spole som ska nås, och eventuell data som operationen kräver.
  3. I Modbus RTU överförs data som råbinär data över RS-232 eller RS-485-serielänkar. I Modbus ASCII kodas data som ASCII-tecken. Modbus TCP omsluter samma protokolldataenhet i ett TCP-segment och lägger till ett litet applikationsdataenhetshuvud som ersätter enhetsadressen med en enhetsidentifierare.
  4. Modbus organiserar enhetsminne i fyra datatabeller: spoler för diskreta utgångar, diskreta ingångar för lässhyddade binära ingångar, hållregister för 16-bitars läs/skrivvärden och ingångsregister för 16-bitars skrivskyddade värden. Funktionskoder mappar direkt till operationer på dessa tabeller.
  5. Modbus TCP använder port 502 som standard. En masterenhet öppnar en TCP-anslutning till slaven och skickar förfrågningar via den anslutningen. Transaktionsidentifieraren i applikationsdataenhetshuvudet gör det möjligt att matcha svar mot förfrågningar.

Konkret exempel

En naturgaskompressorstation använder Modbus RTU över RS-485 för att ansluta en PLC till ett batteri av trycksändare och ventilstyrenheter. En ingenjör installerade också en serie-till-Ethernet-omvandlare för att möjliggöra fjärrövervakning via anläggningsnätverket. Eftersom omvandlaren helt enkelt bryggar seriell Modbus till Modbus TCP utan autentisering kan nu vilken enhet som helst i anläggningsnätverket utfärda skrivkommandon till ventilstyrenheterna, inklusive kommandon för att öppna eller stänga ventiler oberoende av PLC:ns styrlogik. Fjärrövervakningsmöjligheten lade till uppkoppling utan att lägga till någon åtkomstkontroll.

Varför det är viktigt

Modbus finns bokstavligen överallt i OT-miljöer. Äldre seriella installationer och moderna Modbus TCP-driftsättningar delar samma totala avsaknad av autentisering och kryptering, vilket gör det till ett prioriterat ämne i alla ICS-säkerhetsbedömningar.

Säkerhetsperspektiv

  • Modbus saknar autentisering. Vilken enhet som helst som kan skicka en korrekt formaterad ram till en lyssnande slav kan utfärda kommandon.
  • Alla registervärden, spolstatus och kommandodata skickas i klartext. En angripare med nätverksåtkomst kan läsa all processdata och övervaka alla kommandon i realtid.
  • Modbus saknar meddelandeintegritetsskydd utöver CRC i RTU-läge. En man-i-mitten-angripare kan modifiera ramar utan att det upptäcks.
  • Angripare kan räkna upp all enhetsdata systematiskt och sedan skriva till hållregister och spoler för att ändra börvärden eller tvinga utgångar.
  • Det primära försvaret är nätverkssegmentering. Modbus-enheter ska bara vara nåbara från auktoriserade masters, och Modbus TCP på port 502 ska aldrig vara tillgänglig från företagsnätverk.

Vanliga fallgropar

  • Att anta att Modbus TCP är säkert för att det körs över standard-Ethernet. Transportlagret ändrades men protokollets totala avsaknad av säkerhetsmekanismer gjorde det inte.
  • Att förbise seriell Modbus RTU i granskningar för att det inte finns på nätverket. Serielänkar kan nås via felaktigt säkrade serie-till-Ethernet-omvandlare eller fysisk åtkomst.
  • Att behandla all Modbus-trafik som säker bara för att den verkar komma från en känd master-IP. IP-adresser kan förfalskas, och en kompromissad enhet kan skicka godtyckliga kommandon.
  • Att inte inventera vilka register som innehåller börvärden med säkerhetsimplikationer kontra skrivskyddade diagnostikvärden. En skrivning till fel register kan ge omedelbara fysiska konsekvenser.

FÖRDJUPNING

Protokollmekanik: ramar, funktionskoder och datatabeller

Varje Modbus-transaktion följer samma struktur. Mastern skickar en protokolldataenhet innehållande en funktionskod och data. Slaven svarar med antingen den begärda datan eller en undantagskod som anger varför förfrågan misslyckades. I RTU-läge föregås protokolldataenheten av en slavadress och följs av en CRC-kontrollsumma. I TCP-läge föregås den av ett sex byte långt applikationsdataenhetshuvud som innehåller en transaktionsidentifierare, en protokollidentifierare satt till noll och ett längdfält, med enhetsidentifieraren i stället för slavadressing.

Funktionskoder är Modbus-vokabulär. De vanligaste är FC01 för läsning av spoler, FC02 för läsning av diskreta ingångar, FC03 för läsning av hållregister, FC04 för läsning av ingångsregister, FC05 för skrivning av enskild spole, FC06 för skrivning av enskilt hållregister, FC15 för skrivning av flera spoler och FC16 för skrivning av flera hållregister. Varje funktionskod mappar till en specifik typ av dataåtkomst. Att känna till vilka funktionskoder som är legitima för en given enhet och vilka som inte är det är grunden för Modbus-övervakning och avvikelsedetektering.

Datamodellen delar in enhetsminnet i fyra tabeller som motsvarar olika fysiska storheter. Spoler är ettbitsvärden som typiskt representerar diskreta utgångar som relästatus. Diskreta ingångar är ettbits skrivskyddade värden från fysiska ingångar. Hållregister är 16-bitars läs/skrivvärden som används för börvärden, parametrar och utgångsvärden. Ingångsregister är 16-bitars skrivskyddade värden från sensorer och mätningar. Den här organiseringen är en konvention snarare än en strikt hårdvarumappning, och olika leverantörer implementerar den på olika sätt, vilket är varför det är nödvändigt att läsa enhetsdokumentation innan man tolkar infångad Modbus-trafik.

Seriell Modbus RTU jämfört med Modbus TCP

Distinktionen mellan Modbus RTU och Modbus TCP är viktig för både driftsförståelse och säkerhetsgranskning. Modbus RTU designades för seriekommunikation, typiskt över RS-485-flerpunktsbussar där en master kommunicerar med upp till 247 adresserade slavar på en enda fysisk kabel. Seriemediet ger en viss grad av fysisk åtkomstkontroll: en angripare måste vara på kabeln eller ansluten till en enhet på kabeln för att interagera med bussen. Det är ingen stark säkerhetskontroll, men det är en verklig sådan som försvinner när protokollet bryggs till Ethernet.

Modbus TCP, standardiserat 1999, tar samma protokolldataenhet och transporterar den över TCP-anslutningar, typiskt till port 502. Övergången till TCP tar med sig all räckvidd som Ethernet och IP-routing medger. En Modbus RTU-enhet som var fysiskt isolerad på en seriebuss blir en Modbus TCP-enhet som kan vara nåbar från var som helst i anläggningsnätverket, från anslutna företagsnätverk och potentiellt från internet om nätverksgränser inte hanteras noggrant. Många serie-till-Ethernet-omvandlare finns just för att brygga äldre seriella Modbus-enheter till moderna nätverksarkitekturer, och de introducerar ofta uppkoppling utan att introducera någon åtkomstkontroll.

Ur en angripares perspektiv är Modbus TCP väsentligt mer lättillgängligt än Modbus RTU eftersom det kan nås på distans utan fysisk åtkomst till en seriekabel. Att söka efter port 502 i nåbara nätverk är trivialt, och verktyg för att interagera med Modbus TCP finns brett tillgängliga. Vid granskning av en OT-miljö bör Modbus TCP-exponering på port 502 behandlas med hög prioritet, och all exponering utanför styrnätverkszonen bör betraktas som ett kritiskt fynd.

Vad en angripare kan göra med Modbus-åtkomst

Modbus-åtkomst ger en angripare ett direkt gränssnitt till processdata och styrfunktioner utan att någon autentisering krävs. Angreppsytan definieras av vad som är mappat till enhetens datatabeller. En angripare kan systematiskt läsa alla registeradresser och spoladdresser för alla giltiga slavadresser för att bygga upp en komplett bild av processtatusen: vilka utgångar som är aktiva, vad alla börvärden är, vad aktuella mätningar visar och hur systemet beter sig. Denna spaning kräver ingen specialkunskap om målenheten, bara kunskap om hur Modbus-adressering fungerar.

Skrivåtkomst är där de fysiska konsekvenserna börjar. En angripare som känner till eller kan härleda vilka register som innehåller börvärden kan ändra dem. Ett register som styr ett temperaturbövärde, en trycknivå, en hastighetssreferens eller en kemikaliedoseringstakt kan skrivas med ett nytt värde som driver den fysiska processen utanför dess avsedda driftomräde. Eftersom PLC:n eller styrenheten fortsätter att köra sin egen styrlogik normalt, och eftersom det ändrade värdet ser ut som vilken annan registerwrite som helst i avsaknad av övervakning, kan förändringen kvarstå och förvärras innan operatörer märker något fel.

Spolskrivningsfunktionen är särskilt direkt. Att skriva till en spole som representerar en fysisk diskret utgång kan tvinga den utgången till på eller av oberoende av PLC:ns logik. Det innebär att en angripare kan beordra en ventil att öppna eller stänga, en motor att starta eller stanna, eller ett relä att sluta eller öppna utan att passera genom någon styrlogik alls. Effekten är omedelbar och fysisk. Kombinerat med möjligheten att läsa processstatus i realtid har en angripare med beständig Modbus-åtkomst ett synnerligen kapabelt gränssnitt för att manipulera en fysisk process.

Övervakning och detektion i Modbus-miljöer

Eftersom Modbus-trafik från en legitim master följer förutsägbara mönster lämpar den sig väl för avvikelsedetektering. Ett produktionssystem kommunicerar typiskt med en känd uppsättning slavadresser, använder en konsekvent uppsättning funktionskoder, läser från specifika registerintervall och gör det med regelbundna pollingintervall. Varje avvikelse från dessa mönster, som läsningar från ovanliga registeradresser, skrivfunktionskoder som dyker upp när mastern normalt bara läser, eller trafik från en oväntad källadress, är en meningsfull signal värd att undersöka.

Industriella nätverksövervakningsverktyg som förstår Modbus kan tolka funktionskoder och dataadresser och generera larm baserade på policyregler. En enkel men effektiv policy är att larma vid skrivfunktionskoder som observeras i ett nätverk som bara ska ha läsåtkomst för övervakningssyften, eller att larma vid skrivoperationer till specifika högkonsekvensregisteradresser. Mer sofistikerade metoder bygger beteendebaslinjer och larmar vid statistiska avvikelser.

Detektion utan responsförmåga har begränsat värde. När en misstänkt Modbus-skrivning detekteras måste responsarbetsflödet vara definierat i förväg: vem meddelas, vilka manuella åtgärder operatörer ska vidta för att verifiera processens fysiska tillstånd och hur den drabbade enheten kan isoleras vid behov. I OT-miljöer där ett processstopp har egna konsekvenser måste responsplanen ta hänsyn till både cybersäkerhetsdimensionen och den operativa dimensionen av alla inneslutningsåtgärder.

Kompenserande kontroller för ett protokoll som inte kan åtgärdas

Modbus kan inte patchas för att lägga till autentisering eller kryptering. Protokollet är vad det är, och den installerade basen är enorm. Säkerhetsmetoden fokuserar därför helt på kompenserande kontroller: att begränsa vem som kan nå Modbus-enheter, övervaka trafiken som når dem och säkerställa att konsekvenserna av obehörig åtkomst är begränsade.

Nätverkssegmentering är den viktigaste kontrollen. Modbus-enheter bör befinna sig på ett dedikerat styrnätverkssegment som bara är tillgängligt från auktoriserade ingenjörsarbetsstationer och masterstyrenheter, med den åtkomsten genomdriven av brandväggar som utför Modbus-medveten djup paketinspektion. Industriella brandväggar kan tillämpa tillåtningslistor för funktionskoder, adressintervallsbegränsningar och hastighetsgränser på protokollnivå, vilket ger ett meningsfullt kontrollager utan att kräva ändringar i enheterna själva.

Fysisk säkerhet är fortsatt relevant för seriella Modbus RTU-driftsättningar. RS-485-bussanslutningspunkter, serie-till-Ethernet-omvandlare och serieportservrar bör finnas i låsta kapslar eller skåp. Obehörig fysisk åtkomst till dessa komponenter är likvärdigt med obehörig Modbus-åtkomst. Inventering av alla serie-till-Ethernet-omvandlingspunkter är ett nödvändigt första steg för att förstå den faktiska exponeringen av en äldre Modbus RTU-driftsättning, eftersom dessa omvandlare ofta installeras av praktiska skäl och glöms bort utan att dokumenteras i nätverksdiagram.