Laden...

Von einem C# Programm aus einen Linux Rechner steuern

Erstellt von Christoph K. vor einem Jahr Letzter Beitrag vor einem Jahr 682 Views
Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor einem Jahr
Von einem C# Programm aus einen Linux Rechner steuern

Hallo zusammen,

ich möchte gerne von einem C# Programm aus einen Befehl an einen Linux Rechner absenden. Zusätzlich müsste dieser Befehl auch Binärdaten (Bilddateien) mitbekommen und das ganze sollte am besten über eine IP-Verbindung übertragen werden.
Im Endeffekt suche ich ein vorgefertigtes Framework, welches z.B. einen HTTP-Endpunkt bereitstellt, der Daten entgegennimmt und diese Daten in einen Shell -Befehl umwandelt.
Bevor ich anfange, das selber zu programmieren, wollte ich mal fragen, ob es hierfür nicht schon irgendwas Fertiges gibt?

VG
Christoph

2.079 Beiträge seit 2012
vor einem Jahr

ASP.NET

Ein Programm, dass eine HTTP-Nachricht direkt in einer Shell ausführt, wäre allerdings ein krasses Sicherheitsrisiko.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

D
261 Beiträge seit 2015
vor einem Jahr

Ein Programm, dass eine HTTP-Nachricht direkt in einer Shell ausführt, wäre allerdings ein krasses Sicherheitsrisiko.

Ein Sicherheitsrisiko ist es nur, wenn der HTTP(S)-Endpunkt nicht entsprechend abgesichert ist.

Aber muss es HTTP sein oder warum nicht einfach SSH?

3.825 Beiträge seit 2006
vor einem Jahr

SSH ist dafür gedacht. Skript ausführen :


string host = "...";
string cmd = "tar -cvzpf /home/backup/" + dir + @"_$(date +\%F_\%H\%M\%S).tar.gz www/" + dir + "/";
ConnectionInfo info = new ConnectionInfo(host, 22, "...", new AuthenticationMethod[] { new PasswordAuthenticationMethod("...", "...") });
SshClient client = new SshClient(info);
try
{
	client.Connect();
	Thread.Sleep(1000);
	while (!client.IsConnected) { }
	var result = client.RunCommand(cmd);
}
catch (Exception ex)
{
	Error("Fehler beim Verbinden mit der SSH Shell :\r\n\r\n" + ex.Message);
}
client.Disconnect();
client.Dispose();

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

16.835 Beiträge seit 2008
vor einem Jahr

Ein Sicherheitsrisiko ist es nur, wenn der HTTP(S)-Endpunkt nicht entsprechend abgesichert ist.

Allein die Evaluierung eines solchen Commands aus egal welchem Kontext ist ein krasses Sicherheitsrisiko für das gesamte System.
HTTPS hilft Dir hier nur teilweise, allein aufgrund von SSL-Interception, das immer ein Risiko bei HTTPS ist.

Daher arbeiten fertige Tools hier auch mit einer Allow List vom Commands.

D
261 Beiträge seit 2015
vor einem Jahr

Mit "abgesichert" meinte ich nicht nur das Konfigurieren und Benutzen von SSL, sondern eher dass der Sender des Befehls auch entsprechend authentifiziert und autorisiert ist. Was von Serverseite geprüft werden muss.

Wenn man es abstrakt sieht, dann ist HTTP(S) auch nur ein Protokoll wie SSH. Jeder SSH Daemon führt dir nach entsprechender Authentifizierung und Autorisierung jegliche Befehle auf dem System aus.

16.835 Beiträge seit 2008
vor einem Jahr

Wenn man es abstrakt sieht, dann ist HTTP(S) auch nur ein Protokoll wie SSH. Jeder SSH Daemon führt dir nach entsprechender Authentifizierung und Autorisierung jegliche Befehle auf dem System aus.

Technisch ja, Implementierung nein.
HTTPS steht ja für HTTP over SSL mit dem Unterschied, dass HTTP Clients (auch Browser) einfach jedes Zertifikat annehmen. HTTPS steht nur dafür, dass die Verbindung prinzipiell mal verschlüsselt ist. Daher ist HTTPS ohne Certificate Pinning (Standardverhalten) auch anfällig für SSL Interception.
Reine SSH Clients validieren aber das Zertifikat, was im Resultat also sicherer gegen SSL Interception ist.

2.079 Beiträge seit 2012
vor einem Jahr

sondern eher dass der Sender des Befehls auch entsprechend authentifiziert und autorisiert ist

Es bleibt dennoch ein enormes Sicherheitsrisiko.
Wie stellst Du sicher, dass der Sender nicht unter fremder Kontrolle steht?

Du solltest immer darauf achten, dass dein Server abgesichert ist und wenn Du einer externen Instanz erlaubst, beliebigen Code auszuführen, öffnest Du Tür und Tor für Angreifer.
Besser wäre es, wenn man die konkreten Anwendungsfälle mit entsprechenden Parametern in genau dem Rahmen implementiert, den man braucht, nicht mehr, nicht weniger.
Wenn der Sender dann unter fremder Kontrolle steht, kann der zwar unerlaubt auf die API zugreifen, aber auf dem Server hat er maximal den Einfluss, den die implementierten Funktionen erlauben.

Lässt Du stattdessen frei Zugriff auf die Shell zu, könnte der Angreifer absolut alles machen.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

16.835 Beiträge seit 2008
vor einem Jahr

Wie stellst Du sicher, dass der Sender nicht unter fremder Kontrolle steht?

Das haste aber bei jeder Remote Technologie. Der Unterschied ist, dass es bewährte, sicherere Methoden dazu gibt.
Ein heimisches Learning-by-Doing Projekt gehört aber leider nicht zu ebengleichen.

Daher sollte man wirklich was fertiges nehmen, was natürlich auch ein entsprechendes SDK sein kann.
Aber Googlen/auf GitHub suchen kann Christoph K. auch allein 😉

2.079 Beiträge seit 2012
vor einem Jahr

Das haste aber bei jeder Remote Technologie

Natürlich, deshalb sollte der Sender ja auch nicht mehr machen können, als er braucht.
Also kein Shell-Zugriff, sondern nur passgenau definierte Funktionen, die gar keinen Spielraum bieten.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.