Programmiersprachen/Compiler wie Perl auf einem Hochsicherheitsrechner? Ja oder Nein?

[Catonga]

Hallo

habe mal ne Frage bzüglich der Sicherheit.

Ich will einen Hochsicherheits Firewall/Router Rechner aufsetzen.

Jetzt habe ich aber die Frage, ist es besonders Klug auf so einem Rechner Compiler bzw. Programmiersprachen wie Perl und Phyton zu installieren?

Ist einem Eindringlich nicht dadurch Tür und Tor offen, wenn ihm ein Compiler ermöglicht Programme auf diesem Rechner zu erstellen, zu compilieren und auszuführen?

Frage nämlich deswegen weil ich zum einen diese beiden Programmiersprachen noch nicht installiert habe und zweitens aber die Sicherheit meines Rechner mit den Programmen courtney, swatch und hostSentry erhöhen möchte.


Leider sind courtny und swatch auf ein installiertes Perl 5.0 System und hostSentry auf ein bestehendes Phyton >1.51 System angewiesen um überhaupt zu laufen.

Was soll ich jetzt an eurer Stelle machen?
Diese 3 Programme + die entsprechenden Programmiersprachen installieren oder
die 3 Programme und die Programmiersprachen komplett weglassen.


Bis jetzt ist noch kein einziger Compiler oder Programmiersprache auf dem Rechner installiert.
Das einzige was ein Eindringlich bei einem eindringen im Moment quasi out of the box zur Verfügung hätte wären die Standardprogramme und die Möglichkeit shell scripte zu schreiben.


Also Programmiersprachen auf einem Hochsicherheits Rechner? Ja oder Nein?

[jgbauman]

Natuerlich machen maechtige Programmiersprachen viele weitergehende Aktionen fuer Eindringlinge besser.
Aber wenn Du erst mal einen Eindringling im System hast, ist es sowieso egal. Das fehlen von Perl/Python/Compiler ist nur eine kleine Huerde. Notfalls kopiert der Eindringling eben Binaries aufs System.
Meine Meinung: Lieber die Loecher stopfen und Eindringlinge gleich zu vermeiden. Gegen leute mit Ahnung hilfts sowieso nicht die Sprachen wegzulassen. Und gegen Skript-kiddies duerfte es ja schon helfen /usr/bin/perl in /usr/bin/werl umzubenennen und die eigenen Skripte anzupassen ;-)

[Catonga]

Hm, wenn ich jetzt die ftp und nfs software deinstallieren würde, dann hätte der hacker keine Chance binarys draufzuspielen und
wenn er dann zusätzlich keine Programmiersprachen hat kann auch er mit dem Rechner nicht viel anfangen?


Wäre das Sinnvoll? Was meint ihr?


Oder gibt es noch andere Möglichkeiten Dateien zu übertragen?

Lokalen Zugriff auf den Rechner habe ich ja, wenn ich malk ftp und Co brauchen sollte kann ich diese Programme ja per Diskette mounten.

[jgbauman]

Solange ein Hacker eine remote shell und irgendwas wie cat hat kann er Dateien uebertragen.
er braucht ja nur ein:
cat > evil_binary
auszufuehren und die passenden Daten + EOF zu schicken.

Sobald er/sie im System ist kann er alles machen.

Die Frage ist nur wie einfach man im/ihr das weiterkommen macht. (Es koennte ja auch eine sie sein, aber im restlichen Text ist mir das jetzt zu umstaendlich) Aber er sollte halt erst mal gar nicht ins System kommen.

Vielleicht solltest Du dir auch mal Sachen wie http://lids.planetmirror.com/index.html angucken, falls Du es noch nicht kennst.

Alternativ kann man auch "ueberfluessige" Programme, die nur zu Wartungs/Testarbeiten (also aktivem Arbeiten an der Firewall/Router benoetigt werden) per nfs von einem lokalen Rechner beziehen und sie dort nur exportieren waerend man damit arbeitet. (Oder auf CD brennen un nur einlegen und mounten wenn noetig). So sind die im normalen Betrieb nicht vorhanden und koennen kein Sicherheitsrisiko darstellen, koennen bei Bedarf aber doch genutzt werden.


Vielleicht ist diese Ansichten aber auch totaler Unsinn. Ich lasse mich gerne belehren ;-)

You never stop learning linux ;-)


Nachtrag:
Oh deine letzte Zeile hab ich ueberlesen und diese Idee nochmal beschrieben, sorry, ich war zu bloed

[ 04. Juli 2001: Beitrag editiert von: jgbauman ]

[Catonga]

Ja lids kenne ich schon, das habe ich fest eingeplant


Was cat betrifft, hm, das ist ein Problem, cat kann ich nicht einfach auf diskette ausperren.
Auf cat bin ich für meine eigenen shell scripte angewiesen.
Aber danke für die Info.