Verstädnisfragen zu PROFIBUS

[AlexSc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Leute,

schonmal vorweg, ich bin relativ neu in der Materie und doppeltes Sorry für den ziemlich langen Post! Im Zuge meiner Bachelorarbeit beschäftige ich mich mit Sicherheit in einem Feldbussystem. Der Fokus liegt dabei auf PROFIBUS.
Nach einiger Recherche bin ich nun soweit gekommen, dass ich denke, PROFIBUS ganz gut erklären zu können. Hier würde ich darum gerne mal meine Sicht der Dinge schildern und bitte um jede Art von Kommentare von Ergänzungen bis 'Nein da liegst du komplett falsch' :wink:
Also, ich würde auf die Frage 'Was kannst du alles zu PROFIBUS erzählen?' folgendermaßen antworten:

- PROFIBUS ist wie der Name schon sagt ein Feldbus, sprich es dient dazu, sehr schnell auf bestimmten Übertragungsmedien (in diesem Fall nur Kabel) Informationen zu übertragen. Standardmäßig geschieht dies in beliebigen Netzwerken in dem eine SPS mit verschiedenen Endgeräten spricht. Zum Beispiel könnte eine SPS in einem Aufzug installiert sein, welche die Eingangssignale vom Bedienfeld im Aufzug (welche Etage?) verarbeitet und entsprechend via PROFIBUS die Tür und den Motor, der den Aufzug hoch oder runter zieht steuert.
SPS können zB in AWL programmiert werden (hier wäre meine Frage noch, was sich genau mit AWL nun alles machen lässt bzw wie nun die Endgeräte tatsächlich angesprochen werden?)

- Das PROFIBUS Protokoll ist für den (Multi-)Master-Slave Betrieb ausgelegt. An einen Bus können also mehrere Geräte angeschlossen sein, die andere Geräte steuern. Dies geschieht zyklisch via Token Passing zwischen den Mastern. Diese Master nennt man Class 1 Master. Zusätzlich muss mindestens ein 'Class 2 Master' angeschlossen werden, welcher überwachende Funktionen übernimmt und auch beim Hochfahren des Netzes Adressen verteilt und alle anderen Geräte konfiguriert.

- Das PROFIBUS Protokoll unterteilt sich in 3 Schichten. Jedes Profibus Telegramm besteht auf der mittleren Schicht aus einem FDL Telegramm (das Übertragungsmedium, also Schicht 0, sei hier mal übersprungen). Sprich auf dieser Ebene haben wir zB. SD1, SD2 oder SC Telegramme die einen Funktionscode und evtl. verschiedene Service Access Points ansprechen.
Der Funktionscode gibt an, ob ein Telegramm ein Request, eine Bestätigung, eine Fehlermeldung oder Ähnliches ist. Der SAP gibt sozusagen den Tatsächlichen Befehl an, der ausgeführt werden soll (zB ein SET_PARAM zum Setzen von verschiedenen Konfigurationsparametern in einem Feldgerät).

- In der nächsten Schicht befinden sich dann DP-V0, DP-V1 oder DP-V2 Telegramme. Welches der Pakete nun wirklich vorhanden ist kann an den SAPs festgemacht werden (SAP 62 (0x3E) für den Master bedeutet zyklischen Datenaustausch, also DP-V0 usw.). DP-V0 wird ausschließlich dazu verwendet, Eingangs und Ausgangsdaten auszutauschen (und mehr nicht).
DP-V1 und V2 werden für Konfiguration, Parameterübergabe und Global Control (also Broadcastbefehle an alle Slaves gleichzeitig) verwendet.

Soo, so viel dazu. Für den Fall, dass ich das alles soweit richtig verstanden habe, hier noch einige Fragen:

- Was hat es nun mit den Profilen auf sich (ProfiSAFE, PROFIdrive, etc)?
- Wird PROFIBUS tatsächlich ausschließlich zum Hin und Herschieben von Eingangs und Ausgangsdaten verwendet?
- Könnte jemand mal ein etwas umfassenderes Beispiel liefern, wie nun SPS, Endgeräte und PROFIBUS tatsächlich zusammen wirken?

Vielen Dank für jegliche Hilfe!!

Liebe Grüße,
Alex

 

[Aventinus]

Servus,

ich denke, mit dem 'Class 2 Master' liegst du falsch. Das PG ist ein solcher Master, muss aber nicht zwangsläufig vorhanden sein. Wenn alle Master 1. Klasse konfiguriert sind läuft der Bus ohne Master 2. Klasse.

 

[UNI]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Alex,

vielleicht hilft dir das hier schonmal einen Schritt weiter:
https://cache.industry.siemens.com/dl/files/591/35222591/att_105790/v1/MN_PB-Net_0.pdf

Gruß
UNI

 

[volker]

zu profisafe kannste hier mal schauen
http://www.profibus.com/nc/download...y-and-application-system-description/display/
http://www.profibus.com/nc/download...-application-system-description/download/196/

 

[Gerhard Bäurle]

Hi Leute,
schonmal vorweg, ich bin relativ neu in der Materie und doppeltes Sorry für den ziemlich langen Post! Im Zuge meiner Bachelorarbeit beschäftige ich mich mit Sicherheit in einem Feldbussystem. Der Fokus liegt dabei auf PROFIBUS.

Allgemein – falls Du es noch nicht kennst, eine gute
Quelle für Profibus sind Webseite und Buch von Max Felser:

http://www.profibus.felser.ch/index.html?technik.htm

Eventuell kannst Du noch erwähnen, warum Feldbusse
überhaupt eingesetzt werden:

https://de.wikipedia.org/wiki/Dezentrale_Peripherie

Zum Beispiel könnte eine SPS in einem Aufzug installiert sein, welche die Eingangssignale vom Bedienfeld im Aufzug (welche Etage?) verarbeitet und entsprechend via PROFIBUS die Tür und den Motor, der den Aufzug hoch oder runter zieht steuert.

Ein Aufzug ist immer ein gutes Beispiel, kennt jeder.

SPS können zB in AWL programmiert werden (hier wäre meine Frage noch, was sich genau mit AWL nun alles machen lässt bzw wie nun die Endgeräte tatsächlich angesprochen werden?)

Die Programmierung der SPS ist erst mal unabhängig
vom Feldbus. E/As, die als dezentrale Peripherie ausgeführt
sind, werden vom SPS-Programm gleich behandelt, wie
lokale E/As.

- In der nächsten Schicht befinden sich dann DP-V0, DP-V1 oder DP-V2 Telegramme. Welches der Pakete nun wirklich vorhanden ist kann an den SAPs festgemacht werden (SAP 62 (0x3E) für den Master bedeutet zyklischen Datenaustausch, also DP-V0 usw.). DP-V0 wird ausschließlich dazu verwendet, Eingangs und Ausgangsdaten auszutauschen (und mehr nicht).
DP-V1 und V2 werden für Konfiguration, Parameterübergabe und Global Control (also Broadcastbefehle an alle Slaves gleichzeitig) verwendet.

Es gibt auch noch die Varianten FMS und PA, die könntest
Du der Vollständigkeit halber erwähnen.

https://de.wikipedia.org/wiki/Profibus

Könnte jemand mal ein etwas umfassenderes Beispiel liefern, wie nun SPS, Endgeräte und PROFIBUS tatsächlich zusammen wirken?

Beim Aufzug hast Du das schon ganz gut geschrieben. Statt jeden
Taster, Sensor und Motor direkt mit der SPS zu verbinden, kommt
dezentrale Peripherie zum Einsatz. Der Umrichter zu Motorsteuerung
kann ebenfalls per Profibus angebunden werden.

Beispiel:

http://w3.siemens.com/mcms/sce/de/f...documents/feldbussysteme/d07_cpu315_micro.pdf

Bezüglich der Sicherheit – nur ein funktionierender Feldbus ist
sicher – könntest Du noch die Themen Alterung und EMV erwähnen.

Dazu habe ich kürzlich hier etwas geschrieben:

http://www.openautomation.de/detailseite/bussysteme-als-stiefkind-der-instandhaltung.html

und hier:

https://www.keosk.de/read/JHAd63UDFKeNj/m.html?page=27

 

[AlexSc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend,

vielen Dank für die vielen Informationen!

@Bernard Bäurle:
Danke für die ausführliche Antwort, das Profibus Handbuch von Max Felser kenne ich bereits und habe auch den Großteil meines Wissens daher. Profibus PA und FMS kenne ich auch, in meiner Arbeit geht es aber ausschließlich um DP.
Nun möchte ich meine Fragen mal etwas konkretisieren. Es geht mir bzgl. 'Sicherheit' vor allem um die Sicherheit vor gezielten Angriffen und Manipulationen. Da ich zwar viel Wissen durch Lesen und Lernen erhalten kann aber im Rahmen meiner Arbeit niemals ein echtes Industriesystem zu Gesicht bekommen werde, habe ich absolut keine Erfahrung mit diesen Systemen. In wiefern stellen die angeschlossene Geräte an sich Funktionalität in diese Richtung?
- Was passiert, wenn ich einen Master (der evtl auf einer Seite via Industrial Ethernet an ein größeres Netz angeschlossen ist) übernehme und plötzlich fremde Slaves anspreche?
- Was passiert, wenn ich wahllos Adressen ändere? Wenn ich das Token nicht weiterreiche oder außerhalb meiner Zeit Slaves anspreche? Halten die Slaves selbst auch fest, wer das Token hat und reagieren im Notfall einfach garnicht?
- Dann nochmal zu meiner alten Frage: Während des azyklischen Datenaustauschs liest die SPS alle Eingänge der jeweiligen Slaves und schreibt deren Ausgänge, und MEHR definitiv nicht?
- Was kann denn noch so über den Profibus laufen also welche Art von Datenverkehr kommt da überhaupt zustande (außer dem Datenaustausch, Konfiguration, Master-Master) und dürfen manche Vorgänge evtl. nur beim Hochfahren des Systems erfolgen?
- Das FDL Protokoll und die DP-V0 bis DP-V2 Protokolle sind ja relativ eng miteinander verbunden, jedenfalls nicht so klar voneinander zu trennen wie ein IP und ein TCP Paket. Wie bauen darauf nun die Profile auf, also welche Funktion haben die genau? Ich hab das nun so verstanden, dass Profile für bestimmte Branchen (zB. die Automobilindustrie) etwas detailliertere Standards definieren, also Funktionalitäten die da einfach häufig gebraucht werden. Ist das korrekt?

Ich bedanke mich nochmals im Vorraus für jede Hilfe und wünsche ein schönes Wochenende!
Liebe Grüße,
Alex

 

[ChristophD]

Hallo,

wir das jetzt eine Fortsetzung von diesem Thema: https://support.industry.siemens.com/tf/ww/de/posts/129472/ oder ein neues Projekt?

Welche fremden Slaves willst du den ansprechen? Die SPS kennt nur die projektierten Slaves aud den SDB Daten und nur mit denen kann sie auch kommunizieren.
Welche Adressen willst du ändern? DP Adressen werden in der Regel bei PROFIBUS an den Geräten die als DP-Slave arbeiten direkt eingestellt, sowas wie DHCP beii Ethernet gibt es nicht bei PROFIBUS.
Die Eingänge/Ausgänge werden eigentlich im zyklischen Bereich gelesen im azyklischen Bereich sind eher Diagnoseaufträge wie Paremeter Lesen/Schreiben, Status der Slaves etc. zu finden.
Bei den Profilen meinst Du vermutlich PROFIdrive und PROFIsafe, diese beiden definieren eigentlich lediglich als Standard den Aufbau der Daten die ausgetauscht werden, also wie die Telegramme aufgebaut sind und welche Bedeutung die einzelnen Daten im Telegramm haben.

Gruß
Christoph

 

[AlexSc]

Guten Abend,

eine Fortsetzung sollte das eigentlich nicht werden, allerdings habe ich mich (wie du nun auch im Siemens Forum nachlesen kannst ) mit der Programmierung einiger Softwarekomponenten meiner Arbeit beschäftigt.
Soweit ich weiß, können Master mittels eines SET_ADDR Befehls Adressen von Slaves selbst bestimmen. Mit fremden Adressen meine ich im Multimasterbetrieb zB. folgende Situation:
Master 1 hat die Slaves 1, 2 und 3
Master 2 hat die Slaves 4, 5 und 6
Was hält M1 nun davon ab mit S4 oder S6 zu sprechen und wenn, wie wird das geregelt?

Wie gesagt mir fehlt es einfach völlig an Erfahrung, darum sind manche Fragen vielleicht sogar völlig 'sinnlos', mit jeder Antwort helft ihr mir aber enorm! Allgemein, was könt ihr euch für Sicherheitslücken in solchen Systemen vorstellen bzw. wie stark sind slolche Systeme gegen Missbrauch geschützt?
Darum geht es mir und wie sich solche Missbräuche zeigen würden sodass man sie aufdecken und evtl. verhindert könnte?

Liebe Grüße,
Alex

 

[ChristophD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

da M1 in seinen SDB keine Kenntniss hat von S4 und S6 kann er nicht mit diesen kommunizieren.
Bevor ein Slave in den Datenaustauch mit einem Master eintritt benötigt er ein güldiges PRM_CFG Telegram, dieses bildet der Master aus den SDB und verschickt es auf den Bus an die Slaves.
Wird diese PRM_CFG Telegram vom Slave akzeptiert findet der Datenaustausch statt.
Man müsste dann also auf Systemebene des Masters die SDB's manipulieren, das wiederrum erfordert dann einen Restart des Masters da die SDB beim hochfahren des masters ausgewertet werden.

Gruß
Christoph

 

[AlexSc]

Ok dann soweit schonmal. Aber was ist, wenn ich als Master einfach beliebig Adressen ausprobiere? Oder noch besser, da ich an ein Bussystem angeschlossen bin kann ich sowieso jedes Telegramm mitlesen und alle Adressen speichern. Je nachdem von wo die Requests und von wo die Responses kommen weiß ich dann ja auch wer Master und Slave ist, was übertragen wurde etc.
Mal ein Beispiel:
In einem super futuristischen Gebäudekomplex (wird warscheinlich heute schon genau so gemacht ) ist in jedem Raum ein Rauchsensor mit einer Sprenkleranlage verbunden (natürlich über PROFIBUS). Parallel dazu ist in jedem Raum noch eine Klimaanlage, welche aber von einer für das ganze Gebäude zentralen SPS gesteuert wird. Dann wäre M1 die Klima SPS die zyklisch mit einem Temparatursensor und dann mit allen Klimaanlagen spricht. M2 wären die jeweils im Raum instalierten SPSen, die nur mit Rauchmelder und Sprenkleranlage sprechen. Wenn nun aber M1 und M2 sowie alle Slaves aus welchen Gründen auch immer an den selben Bus angeschlossen sind und ich nur eine Klima SPS (also Master 2) ganz stupide gesagt 'gehackt' habe.
Was hindert mich daran, den Verkehr ein bisschen zu analysieren bis ich mir sicher bin, wer M1 ist und dann einfach im Namen von M1 selbst Telegramme zu schicken (zB schalte alle Anlagen aus). Oder anders rum, warum kann M1 nicht allen Sprenkleranlagen den Befehl geben, Wasser auszusprühen?
Dass das nicht sein SOLLTE ist mir klar, aber gibt es irgendwelche aktiven Maßnahmen dagegen?

Liebe Grüße,
Alex

 

[ChristophD]

Hi,

damit verlässt du bei diesem konstruierten Beispiel die PROFIBUS Feldebene.
Um die Telegramme mitzulauschen oder auch nur alle Teilnehmeradressen mal auszuprobieren musst du auf den Profibus ASIC der Baugruppe aufschalten und den CODE der diesen steuert modifizieren, das wiederrum stellt einen Eingriff in die FW der SPS dar, dürfte schwierig bis werden das unbemerkt zu tun.

Wenn M1 die Rolle von M2 übernehmen würde dann würde zum einen M2 ausfallen was bemerkt werden würde und gleichzeitig würden alle Slaves die bisher von M1 angesprochen würden ausfallen da M1 nicht mehr existiert.

Und außerdem würde kaum einer ein solches Konstrukt wie du beschreibst realisieren

Gruß
Christoph

 

[AlexSc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da haben wir doch schonmal ein grundsätzliches Verständnisproblem meinerseits. Ich bin bis dato davon ausgegangen, dass die SPSen via Profibus quasi 'direkt' an die Feldgeräte angeschlossen sind und auch eigenen Code tragen. Was ein ASIC ist weiß ich leider noch nicht.
Die Tatsache, dass bei einer falschen Nutzung des Profibusses alle beteiligten Geräte einfach ausfallen ist ganz sicher? Vielleicht ist das Verhalten ja nicht eindeutig definiert.

 

[Thomas_v2.1]

Wenn ich das im Zusammenhang mit IT-Security lese, stellen sich mir ein paar generelle Fragen:
Für Hobby-Hacker ist Profibus uninteressant, weil spezielle und entsprechend teure Hardware dafür notwendig ist. Wer sollte also ein solches Netzwerk manipulieren wollen? Das können nur staatliche Organisationen sein, wie z.B. die USA/NSA mit quasi unendlichem finanziellen Potenzial, bei denen auch ein Menschenleben nichts wert ist.

Man könnte einen Angriff wie Stuxnet im Iran ja mal auf Profibus-Ebene durchspielen. D.h. das Steuerungsprogramm bekommt manipulierte Daten der Profibusteilnehmer zu Gesicht. Im Fall Stuxnet wurde das über eine Manipulation des Steuerungsprogramms realisiert. Mit einer entsprechenden Person mit Zugriff auf die Hardware ließe sich durchaus hinter dem Master ein Gerät zwischenschalten, dass ggf. dem Master die gesamten Slaves vortäuscht oder zumindest dessen Daten manipuliert (an Datenmanimpulation wurde beim Design von Profibus nicht gedacht). Dazu könne man beispielsweise einen Repeater oder LWL-Konverter ge(miss)brauchen. Technisch ist das mit entsprechendem finanziellen Aufwand kein Problem. Bei allen Ethernet-Geräten aus den USA kann man mittlerweile von entsprechenden Backdoors ausgehen die Funktionen beinhalten um den Datenverkehr abzuhören und ggf. zu manipulieren. Das würde dein Analyse-Gerät nicht mitbekommen, dass dort so ein Gerät verbaut ist.
Ich habe von anderen universitären Einrichtungen aus dem Ausland (Frankreich, Israel) mitbekomen, die das gleiche wie du vorhaben, allerdings auf Ethernet-Ebene. Da gibt es auch entsprechende Vorlesungen im Internet.

Das Problem ist eigentlich kein technisches, sondern ein politisches. Bei uns werden höchste Regierungsstellen vollständig abgehört ohne dass etwas dagegen unternommen wird.

 

[AlexSc]

Guten Morgen,

genau, an solche Sachen habe ich auch gedacht. Dass ein Skriptkiddie was besseres zu tun hat, als ein Profibus Netz anzugreifen ist klar, da braucht es schon größere Organisationen.
Der Kontext meiner Arbeit ist ein Forschungsprojekt des IT Security Unternehmens in dem ich die Arbeit anfertige. Da dieses Projekt hier relativ neu ist und ich quasi Pionierarbeit leisten darf, sind wir uns alle noch nicht ganz sicher in welche Richtung das laufen wird. Hinzukommt die Nichtverfügbarkeit eines echten Netzes.

Wo genau hast du Informationen zu den Projekten aus Frankreich und Israel her? Kannst du mir da evtl. ein paar Links geben?

Da die Art von Software die ich entwickeln möchte ja prinzipiell immer davon ausgeht, dass Angriffe auf das System sich durch signifikant abweichenden Datenverkehr detektieren lassen (andere kann ja selbst das beste IDS beim besten Willen nicht aufspüren), ist mein Vorgehen bisher die mitgelesenen Pakete bestmöglich zu 'entpacken' (also möglichst viele enthaltene Daten für den Anwender aufzubereiten) und verschiedene statistische Tests darüber laufen zu lassen. Als Beispiel sei mal der Chi Quadrat Homogenitätstest genannt. Der ermittelt für zwei Stichproben, ob sich die die Verteilungsfunktion der beiden Stichproben signifikant verändert hat. Sowas könnte man dann ja als Anomalie werten. Weitere Möglichkeiten wären Mittelwert und Standardabweichung verschiedener numerischer Größen.
Auch hier bin ich natürlich immer für Ratschläge offen!

Liebe Grüße und einen schönen Sonntag,
Alex

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst dir diese beiden Sachen ja mal ansehen, dürfte so ungefähr dem entsprechen was du auf Profibus-Seite vorhast, wenn ich das richtig verstanden habe.

Accurate Modeling of The Siemens S7 SCADA Protocol For Intrusion
Detection And Digital Forensic, Amit Kleinmann, Avishai Wool
http://ojs.jdfsl.org/index.php/jdfsl/article/view/262

Vorlesung dazu:
https://www.youtube.com/watch?v=qRuIspqnl_Q

 

[manseluk]

Nebst Profibus gibt es ja noch andere Bussysteme, z.B. Can-Bus (wird häufig in Autos verwendet). Dieser Bus wurde / wird häufig "gehacked" und im Internet findest du mit Begriffen "can-bus" und "hack" viele Tutorials, wie dies gemacht wird. Evenutell kannst du Methoden, die dort verwendet werden, auf Profibus übertragen.


Gruss

 

[ducati]

Dass ein Skriptkiddie was besseres zu tun hat, als ein Profibus Netz anzugreifen ist klar, da braucht es schon größere Organisationen.

Wie immer hat Thomas hier schon mal alles richtige erwähnt
Genau wie eine Firewall am PC könnte m.M. nach ein PB-IDS-System höchstens Scriptkiddies abhalten...
Einen hochqualifizierten Angreifer mit unbegrenzten Mitteln und Insiderwissen wird das nicht aufhalten können.

Zu Eurem theoretischen Ansatz am Schreibtisch würde ich sagen: Baut Euch mal ein SPS-System auf. Das kostet nicht die Welt und Ihr werdet leicht erkennen, an welcher Stelle der Kette Programmiersystem-SPS-Profibus-DP-Feldgerät realistische Angriffsmöglichkiten bestehen. (Für mich hört sich das hier so ähnlich an wie: Ich hab eigentlich keine Ahnung von nem PC und hab auch noch nie einen gesehen. Im Buch hab ich jetzt aber gelesen, wie ein PC funktioniert und möchte jetzt mal einen Virenscanner mit Firewall programmieren...) Aber das ist leider (zu) oft bei Abschlussarbeiten so.

Das Beispiel mit den zwei Mastern M1 und M2 welche sich ein PB-Netz teilen finde ich ziemlich konstruiert und unrealistisch. In der Praxis hat jede SPS in der Regel sein eigenes physikalisches PB-Netz, u.U. noch mit nem PG/OP dran.

Die Idee von Christoph, die Firmware der SPS zu manipulieren (bzw. werksseitig vorhandene Backdoors?) um unerkannt die Anlage zu stören hört sich allerdings gar nicht so abwegig an.

Gruß.

 

[AlexSc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen und vielen Dank für die ausführliche Antwort!

hier ein SPS System aufzubauen wird leider nicht möglich sein. Dies liegt vor allem daran, dass ich nur als Praktikant angestellt bin (und in diesem Rahmen die BA schreibe) und der Umfang den es braucht, so ein System vollständig zu verstehen, die Teile zu beschaffen und ein korrekt funktionierendes Profibus Netz aufzubauen quasi selbst schon als (kleine) BA gewertet werden könnte.
Dazu kommt dann noch, dass ich zwar noch nicht in Verzug bin, jetzt aber noch ein SPS System aufzubauen leider zeitlich einfach nicht mehr passt.

Ich sehe meinen Vorteil momentan noch darin, dass ich ja von vorne herein nicht angestrebt habe, jeden Angriff von tatsächlich professionellen Hackern aufzudecken (und ich denke, nicht mal die meisten Dissertationen in diese Richtung würden das schaffen) sondern lediglich die Angriffe, welche eine statistisch signifikante Änderung im Datenverkehr hinterlassen.
Wie nun ein Angreifer Zugriff zum System erhält ist ja "erstmal" unwichtig für mich. Fängt er aber an, den Datenverkehr zu stören, könnte sich das in Übertragungsfehlern, insgesamt höherem Datenverkehr oder Rekonfigurationsvorgängen äußern.
Beobachtet man die Häufigkeiten solcher Ereignisse über einen längeren Zeitraum, ließe sich mit den richtigen Tests so etwas aufdecken.
Zumindest ist das meine Hoffnung
Außerdem ist ein weiterer großer Vorteil meiner Software, dass sie extrem leicht zu erweitern sein wird, was eventuellen Anwendern später die Wahl lässt, selbst statistische Module für das System zu schreiben und ala Plug and Play sofort zu erweitern.

Leider hast du Recht, mit deinem Beispiel zum PC und dem Virenscanner/Firewall Konnte mir das Thema nicht aussuchen und versuche nun, das Beste daraus zu machen!
Vielen Dank an alle nochmal für die Hilfe!

Liebe Grüße,
Alex

 

[ChristophD]

Hi,

1) bisher dachte ich ja das es am Ende ein in der Praxis verwendbares Endprodukt werden sollte
2) Datenverkehr stören ist die mit Abstand seltenste Angriffsmethode bei SPS, sobald das passiert wird die Anlage abgestellt und isoliert, Störungen sind heute schon diagnostizierbar !
3) Hauptproblem ist nicht die Störung sondern die Verfälschung von Daten, sprich das Datenvolumen selber ändert sich nicht aber die Werte z.B, werden modifiziert, so das z.B. Stellgrößen geändert werden ,
Das betrachtest du aber wohl gar nicht, zumindest lese ich immer nur heraus das du nur eine Abweichung der Datenströme an sich analysierst, also wie viele Daten innerhalb einer bestimmten Zeit zwischen 2 Teilnehmern ausgetauscht
werden. Nur wird das wohl eher selten der Fall sein bei einem SPS Feldbus, siehe auch Stuxnet.

Eventuell verstehe ich auch einfach den theoretischen Ansatz für das ganze Thema nicht, aber ich finde es falsch einfach die IT Security von Ethernet auf einen SPS Feldbus runterbrechen zu wollen.
Aber wie willst du alle eventuell gefunden Theorien und Erkenntnisse den ohne einen Aufbau überhaupt prüfen? Und in der ganzen Firma ist kein Profibus- Aufbau vorhanden bei dem Du z.B. die Telegramm erfassen und auswerten kannst?
Alleine die erwähnten reconfigurations würden schon für ein Alarmsignal beim Anlagenbetreiber sorgen da sie in der Regel mit Stations und Bus ausfällen einhergehen die auch mitgeloggt werde in der SPS, eventuell sogar zu einem SPS Stop führen wenn dieser Fall nicht über FehlerOB's abgefangen wird in der Programmierung.

Gruß
Christoph

 

[norustnotrust]

Es gibt ja solche Heuristiken die auf PC Ebene versuchen gewünschtes von unerwünschtem Verhalten zu trennen und zu identifizieren. Meiner Erfahrung nach für das eher zu mehr Störungen als das es einem hilft und endet damit dass man bestimmte Programme (oft die mit denen man als Automatisierer arbeitet) von der Suchfunktion ausnehmen muss da diese Dinge machen die für einen Office PC per se verdächtig sind (Direktzugriffe auf Peripherie, etc..) Ich frage mich also generell ob das funktionieren kann.

Aber abgesehen davon folender Gedanke: Das Einfallstor für deinen "Hacker" wird nicht der Profibus selbst sein. Will der "Hacker" deinen Datenstrom auf dem Bus manipulieren bräuchte er ein Gerät das er physisch im Schaltschrank anbringt was A.) einen enormen Aufwand bedeutet und B.) für die genannten staatlichen Stellen das Risiko einer Entdeckung ungleich steigern würde. Bleibt also der Weg (wie Stuxnet) einen PC zu infizieren der Pakete an den Bus sendet. Wenn diese Software manipuliert wird, wird sie per se keinen verdächtigen Traffic produzieren bzw. keinen den du als solchen erkennen wirst können. Wieso auch?

Es bleibt also der einzige Weg (siehe Versiondog) die PLC Programme und die PC auf geänderte Softwarestände von dritter Stelle abzufragen.

Zusammengefasst also: halte diese "Hacker" Detection Heuristik auf dem Profibus für vergebene Liebesmühe.

EDT: Tippfehler