# Befehle einem String zuweisen (Befehls"name"ändern)

## trickykannix

Hallo nochmal,

um die primäre Sicherheitsstufe für den Serverzugriff abzurunden habe ich noch folgende/s Frage/Anliegen.

Ich halte mich diesmal etwas zurück und mache es kurz... :

kann man dem su Befehl einen anderen String verpassen?

Also bsw. statt "su" einzugeben "ichbinderneuesuperuser"(sozusagen ein kleines extra-pw).

Für eure Antworten wäre ich sehr dankbar.

MfG

dennis

----------

## cryptosteve

Das hab ich noch nicht ganz verstanden. Möchtest Du den Befehlsnamen ändern? Also "ichbinderneuesuperuser" statt einfach "su"? Soll das zusätzlich funktionieren, oder stattdessen?

Andererseits ... wenn Du dadurch Sicherheit erreichen möchtest, stimmt mit Deinem Sicherheitskonzept vermutlich 'ne ganze Menge mehr nicht.

----------

## manuels

Du kannst einen Bash-Alias verwenden oder das Programm /bin/su einfach umbenennen (mittels mv).

Was du damit erreichen möchstest, weiß ich aber nicht (Kann sein, dass du einen guten Grund hast).

Aber mehr Sicherheit erlangst du, wie von Steve bereits geschrieben, damit nicht.

----------

## bas89

Mit dem Umbenennen von su wird man sich viele Probleme mit anderen Programmen einhandeln. Und am besten lese man folgenden Artikel:

http://de.wikipedia.org/wiki/Security_by_obscurity

----------

## trickykannix

 *Steve` wrote:*   

> Das hab ich noch nicht ganz verstanden. Möchtest Du den Befehlsnamen ändern? Also "ichbinderneuesuperuser" statt einfach "su"? Soll das zusätzlich funktionieren, oder stattdessen?
> 
> Andererseits ... wenn Du dadurch Sicherheit erreichen möchtest, stimmt mit Deinem Sicherheitskonzept vermutlich 'ne ganze Menge nicht.
> 
> 

 

Es soll keine weitere zusätzliche Funktion sein, sondern stattdessen. Das war auch nicht Zwingend Plan im Sicherheitskonzept, eher eine fixe Idee.

Zweck:

Jemand der das Synonym für den su-Befehl nicht kennt, kann sich schlecht als su anmelde - Selbst wenn er das pw hat.

Jedoch ist scheinbar die Meinung vorherschend das es im System eher zu Problemen kommt als eine höhere Sicherheit zu erlangen.

----------

## slick

So ists doch recht einfach:

```
mv /bin/su /bin/myhiddensu
```

Allerdings wirds dann vermutlich irgendwann zu Problemen kommen. Spätestens wenn das Programm nur ein Symlink auf ein anderes ist das anhand des aufgerufenen Namen die Funktion aufführt, vgl. busybox.

Zumal schützt das nicht wirklich, mittels find kann jeder alle ausführbaren Programme finden und muss dann nur "testen" was es tut.

Ist wirklich nicht zielführend. Besser wäre entweder das konsequente Löschen des Programms   :Wink:  oder Userrechte entsprechend zu setzen, z.B. chmod 550 program. allerdings sollte man auch hier wissen was man tut.

----------

## STiGMaTa_ch

 *trickykannix wrote:*   

> Zweck:
> 
> Jemand der das Synonym für den su-Befehl nicht kennt, kann sich schlecht als su anmelde - Selbst wenn er das pw hat.

 

Was hindert mich daran mein eigenes su herunterzuladen und zu verwenden?

Lieber Gruss

STiGMaTa

----------

## sirro

 *STiGMaTa_ch wrote:*   

> Was hindert mich daran mein eigenes su herunterzuladen und zu verwenden?

 

Ein su ohne SUID-root ist doch witzlos.

 *Quote:*   

> Du kannst einen Bash-Alias verwenden

 

Kann doch jeder Nutzer einfach aufheben. (Stichwort unalias)

----------

## Genone

 *slick wrote:*   

> Zumal schützt das nicht wirklich, mittels find kann jeder alle ausführbaren Programme finden und muss dann nur "testen" was es tut.

 

Wobei man diese Suche nochmal deutlich einschränken kann, da wie erwähnt su normalerweise SUID ist (ausser man setzt filecaps ein, was die Suche noch einfacher macht). Dinge zu "verstecken" ist sicherheitstechnisch selten sinnvoll, sofern das "Versteck" nicht technisch abgesichert ist. Und ausserdem muss bedacht werden, dass ein Umbenennen/Verschieben beim nächsten Paketupdate hinfällig ist und im schlimmsten Fall die umbenannte Version nicht gelöscht wird und die Sicherheit so reduziert wird (z.B. weil die alte Version Sicherheitslücken hat).

----------

## Hollowman

Verbiete doch einfach allen Benutzern die Benutzung von su. Nur bei denen wo du es wirklich brauchst, lässt du es an.

Sebastian

----------

## trickykannix

Bis hier hin schonmal, vielen Dank - Sind einige Anregungen. Ich setz mich hin und mach mir mal ein paar Gedanken ob oder wie das dann wirklich Sinn macht...

----------

## trickykannix

 *slick wrote:*   

> 
> 
> Zumal schützt das nicht wirklich, mittels find kann jeder alle ausführbaren Programme finden und muss dann nur "testen" was es tut.
> 
> 

 

Es wird dem nutzer ausschließlich die Ausführung des su befehls erlaubt. 

Den Befehl mit einem String versehen ist nicht möglich? Dann wäre die uneingeschränte Funktionsweise doch weiterhin gewährleistet, oder sehe ich das falsch?

----------

## mrsteven

Für su nach root muss dein User:

das root-Passwort kennen und

in der Gruppe wheel sein (zumindest ist das die Standardeinstellung)

Ohne diese zwei Bedingungen geht's eh nicht. Was spricht also dagegen, fragliche User einfach nicht in wheel einzutragen?

----------

## Genone

 *trickykannix wrote:*   

> Den Befehl mit einem String versehen ist nicht möglich?

 

Was genau meinst du damit? Dass ein Umbenennen nicht sinnvoll ist haben wir ja schon geklärt. Oder meinst du jetzt eine zusätzliche Passwortabfrage? Dann wäre dein Sicherheitskonzept aber auch sehr fragwürdig, wenn du davon ausgehst dass dein root Passwort eher geknackt wird als so ein allgemeines "su-Passwort", denn mehr Passwörter bedeuten nicht automatisch mehr Sicherheit (eher das Gegenteil).

----------

## trickykannix

 *Genone wrote:*   

> 
> 
> Was genau meinst du damit? Dass ein Umbenennen nicht sinnvoll ist haben wir ja schon geklärt. Oder meinst du jetzt eine zusätzliche Passwortabfrage? Dann wäre dein Sicherheitskonzept aber auch sehr fragwürdig, wenn du davon ausgehst dass dein root Passwort eher geknackt wird als so ein allgemeines "su-Passwort", denn mehr Passwörter bedeuten nicht automatisch mehr Sicherheit (eher das Gegenteil).

 

Bitte nicht lachen... so weit reichen meine Kenntnisse einfach noch nicht.

Ist vielleicht ein bisschen umständlich erklärt - Gemeint ist,

das in den Grundzügen su im System weiterhin registriert bleibt, jedoch eine Andere Eingabe notwendig ist um diesen Befehl auszuführen, so dass die Systemfunktion uneingeschränkt bleibt. Ein Script oder etwas in der Art unterzuschieben, so dass ein String eingelesen wird und in su umwandelt oder so...

----------

## Genone

Im Prinzip willst du also eine eingeschränkte Shell, die nur bestimmte Eingaben akzeptiert, so hörts sichs zumindest an.

Aber ehrlich gesagt hab ich (auch nach dem Lesen deiner anderen Threads) nicht den Eindruck dass du wirklich weisst wovon du redest. Und in dem Fall würde ich dringend davon abraten einen Server aufsetzen zu wollen, ausser vielleicht als persönliches Lernprojekt. Denn für ein vernünftiges Sicherheitskonzept sollte man zumindest die betreffenden Grundlagen verstehen.

Ist nicht böse gemeint, aber es scheint halt als ob du auf Biegen und Brechen diese eine Idee umsetzen willst, dabei aber die zugrundeliegenden technischen Konzepte ignorierst. Das ganze ist nicht zufällig ne Hausaufgabe oder so?

----------

## trickykannix

Hausaufgabe trifft es nicht ganz, möchte mich einfach nur ein wenig bilden.

Die Bezeichnung dass man mit den ertsen Einträgen als noob beginnt finde ich nicht verkeht.

Mir fehlen Grundlagen - halte mich aber für relativ lernfähig. Wenn ich jetzt nicht damit anfange, wann dann?

Ja, es handelt sich scheinbar um eine eingeschränkte shell. Dies sind Begriffe die mir der Anregung dienlich sind, danke.

----------

## Genone

Solange das ganze nur ein Lernprojekt ist ist das ja auch in Ordnung, nur sollte man es dann halt nicht öffentlich zugänglich machen. Ein gehackter Rechner schadet schließlich nicht nur dir selber.

----------

## trickykannix

Ne ne, keine Sorge - Ist zum ausprobieren, bin bisher nur wissbegierig.

Ist dieses Vorgehen denn falsch, bzw. was ist Verbesserungswürdig?

1.) rootLogin sperren

2.) nur einem Nutzer Zugriff zur Shell gestatten

3.) den Zugang des Nutzers so stark einschränken dass ausschließlich der su Befehl ausgeführt werden kann

4.) optional: dem su befehl ein Synonym verpassen

Mir ist ganz klar das dies nur erste Schritte zu einer "sicheren" Maschine sind.

Weiter wüsste ich bisher noch nicht... wenn der Vorgang, wie beschrieben, überhaupt angemessen ist. Ich bitte um Korrektur/Vorschläge.

----------

## Max Steel

Wenn ein User su ausführen kann (und das root-PW weiß) ist die Maschine genauso sicher als wenn du allen den root-Login geben würdest (Besser wenn diejenigen IHREN ssh-key für root haben, als ein root-PW) Stichwort: PasswordAuthentication

----------

## Genone

Die Frage ist erstmal was der Einsatzzweck ist, dann wo man vor allem Risiken sieht, und dann wie man sich effektiv dagegen schützt. Was bringt eine vollkommen sichere Maschine die Ihren Einsatzzweck nicht mehr erfüllen kann?

Dein Szenario ist z.B. für einen Shell Server genauso undienlich wie für einen reinen Datenbank Server.

Aber um auf deine Liste zurückzukommen:

1) ist klar

2) hängt vom Einsatzzweck ab

3) und 4) sind Blödsinn (meine Ansicht). Im Prinzip hat der Nutzer dann ja keine Shell, sondern eine dreifache Passwortabfrage (ssh, su-Synonym, su). 

Sicherheitstechnisch macht es mehr Sinn die erste Hürde (ssh) so hoch wie möglich zu legen anstatt im Nachhinein zu versuchen den Schaden zu minimieren. Stichworte da wären Public Key Authentifizierung, One-Time-Passwörter, alternativer Port, Port-Knocking und IP-Whitelisting (wenn man vorher weiss von wo ein Login erfolgen darf). Ist natürlich alles eine Frage der Verhältnismässigkeit.

----------

