Welche Benutzer sollte man weglassen

[deex]

Suse 8.1 kommt schon bei der Installation mit einigen usern auf den Server da jeder user eine sicherheitslücke darstellt welche können getrost weggelassen werden?

Ich habe schon einmal was angefangen wäre interessant was ihr den für
user kennt die keinen einfluss auf ein server system nimmt das hauptsächlich für html-shell-pop3 dinge gedacht ist.

1.Game user (für die juten :( linux spielchen)
2.Lp (für drucke etc.) <<<Privat natürlich zuhause könnte es ja sein)

Leider bin ich mir nur bei den beiden usern sicher ob die unwichtig sind

aber was ist z.B.

Mit user

news-
uucp-
adabas-
amanda-
fnet-
sapdb-
??? wofür sind die überhaupt

[deex]

Und dann habe ich hier noch eine Gruppen die mir recht merkwürdigvorkommen.

intermezzo mit vorverschlüsselten kennwort

perforce mit mitglied perforce

[captaincrunch]

mit einigen usern auf den Server da jeder user eine sicherheitslücke darstellt welche können getrost weggelassen werden?

1. Interpunktionszeichen erhöhen die Lesbarkeit der Beiträge enorm.
2. Interessante These. Wieso stellen diese User ein Sicherheitsrisiko dar?

[deex]

Sorry wegen meinen fehlenden interpunktionen.

Also wenn du einen laden offen hast mit duzenden usern dann verlierst du irgendwann auch die übersicht, denn du weiß langsam nicht mehr welcher user was ist. Da kommen dann die lieben kleinen warez groups ins spiel
sie müssten sich nur einen zugang holen und könnten verschiedene gruppen ausnutzen, um sich die rechte von denen zu holen. Kannst du mir wirklich sagen welcher benutzer welche rechte hat und ob die sich nicht ausnutzen lassen?

[deex]

Nachtrag:

Siehe: http://www.computec.ch/dokumente/unix/t ... linux.html

[captaincrunch]

Also wenn du einen laden offen hast mit duzenden usern dann verlierst du irgendwann auch die übersicht, denn du weiß langsam nicht mehr welcher user was ist.

Wir reden hier aber immer noch von den vorkonfigurierten Usern, unter denen dann nachher z.B. bestimmte Dienste laufen, oder?

sie müssten sich nur einen zugang holen und könnten verschiedene gruppen ausnutzen, um sich die rechte von denen zu holen.

"warez groups" und Scirptkiddies gehen nicht auf bestimmte Gruppen los, sondern versuchen mit viorgefretigten Exploits root-Rechte zu bekommen. Alles andere ist für die uninteressant.

[deex]

Kann man also davon ausgehen, das die scrippt kiddys sich benutzer und ihre rechte,nicht einfach benutzen können?

[captaincrunch]

Schau dir mal das Passwortfeld in der /etc/shadow an. Bei sämtlichen (von dir genannten) Usern sollte dort ein "x" stehen, was bedeutet, dass kein Zugang per Passwort möglich ist, höchstens root kann sich per "su" zu diesem User machen.

"Sicher" gibt's ohnehin nicht, aber du suchst an den falschen Stellen. ;)

Btw. : Der von dir zitierte Artikel scheint mir ziemlich veraltet. Wer heutzutage seine Passwrote noch DES-verschlüsselt ist selbst Schuld. ;)

[deex]

OK das leuchtet mir ein, aber weißte was ich nicht verstehe, wieso der Gesetzgeber nicht gegen sowas vorgeht. Es macht mich jeder thread furchbar sauer bei dem ich lese das wieder ein server gehackt wurde.
Manchmal geht es echt um existenzen. Es scheint wirklich leicht zu sein wenn man es will einen root zu hacken.

[captaincrunch]

aber weißte was ich nicht verstehe, wieso der Gesetzgeber nicht gegen sowas vorgeht.

Ã?hm ... wie sollte er denn deiner Meinung nach dagegen vorgehen? Noch mehr Gesetze in punkto Computerkriminalität, die von Leuten gemacht werden, die keinen blassen Schimmer davon haben?
Oder meinst du, dass endlich mal etwas wie ein "Rootserver-Führerschein" eigeführt werden sollte? ;)

Btw.: Gerade eben gefunden, und es passt so gut zum Thema : http://www.heise.de/newsticker/data/jk-02.12.03-009/

[darkspirit]

Es scheint wirklich leicht zu sein wenn man es will einen root zu hacken.

Ja, bei vielen Rootservern trifft das zu, aber nicht deswegen, weil die Cracker so gut, sondern weil die Administratoren so schlecht sind. Wer ohne Linuxkenntnisse einen Server verwalten will, ist IMHO selbst schuld. Anzeige erstatten bleibt jedem Admin nach einem erfolgreichen Einbruch selbst überlassen. Was denkst du denn sollte der Gesetzgeber unternehmen? Präventivmaßnahmen? TCPA & Co.? Ich denke nein. Ein sauber und sicher konfiguriertes System dürfte nur von einem Insider oder Guru zu cracken sein (mal von social engineering und ähnlichem abgesehen ;)).

[deex]

Genau das ist das Problem Capitän (der hatte doch das Blue-Boxing erfunden)

Ich habe mal für eine Datenschutz Firma gearbeitet (da noch nicht Linux).
Und weiß daher auch genau das die Behörden keinen schimmer haben, was in zeiten des Internet-booms eine schreckliche tatsache ist.

Es dauert einfach zu lange der ganze weg. Die kriegen nie solche vereinigungen weil sie einfach zuu lahm sind. Das dauert dann 2 Jahre dann bekommen fast alle ein Brief das das verfahren eingestellt wurde.

Aber was denkt ihr mal zusammengefasst was die meisten rooti gehackten falsch gemacht haben?

[captaincrunch]

Aber was denkt ihr mal zusammengefasst was die meisten rooti gehackten falsch gemacht haben?

In 98% aller Fälle dürfte der Grund aus fehlenden Linux-Kenntnissen bestehen, am besten noch gepaart mit Faulheit, Sicherheitstechnisch auf dem laufenden zu bleiben.

[deex]

Bedeutet also
Fehler eins

Sich bei heise.de etc. nicht über neue sicherheitslücken zu informieren

Nicht auf die zugänge achten

und was wäre da noch?

Ich z.B. mache täglich einen neuen chkrootkit check
Schaue die benutzer nach
Schaue die Prozesse und in die Logs

Gibt es da noch ein paar tipps wie ihr auf eure sicherheit achtet

[darkspirit]

Ich würde das nicht bei Heise machen, sondern beispielsweise bugtraq abbonieren. Es ist auch nie verkehrt, immer mal wieder bei den Pages der wichtigsten Dienste vorbei zu schauen. Logs lesen ist wohl der nächste Punkt, der tägliche Beachtung braucht.
chkrootkit bringt IMHO nur dann was, wenn man vor jedem Scan das Binary aus sauberen Quellen neu baut. Jeder halbwegs fähige Cracker wird das Programm nach einem erfolgreichen Einbruch aufspüren und austauschen. Gleiches gilt für Tools wie "ps" und ähnliche. Die sind die ersten, die manipuliert werden.

[captaincrunch]

Sich bei heise.de etc. nicht über neue sicherheitslücken zu informieren

Was du bei heise.de liest, ist gerade mal die Spitze des Eisbergs. Die Security-Mailinglisten deines Distributors sollten absolute Pflichtlektüre sein, besser noch Mailinglisten wie Bugtraq u.ä.

Ich z.B. mache täglich einen neuen chkrootkit check

Verstehst du auch die false positives, die das Teil rausschmeißt? Das wäre ein weiterer Punkt: wenn man solche Tools einsetzt, sollte man die Ausgaben auch deuten können.

Gibt es da noch ein paar tipps wie ihr auf eure sicherheit achtet

Vorschlag: wühl dich doch mal ein bisschen durch genau dieses Security-Forum, und trag mal die hunderte Tips, die hier schon genannt wurden zusammen. ;)

[deex]

Ok wenn es sich aushebeln lässt
gibt es da nicht eine möglichkeit sich davor zu schützen, oder ein anderes programm mit den man eine bessere erkennung hat.

[captaincrunch]

aide hat den Debian-Jungs und -Mädels bei dem Einbruch sehr gute Dienste geleistet. Das Problem an solchen HIDS, chkrootkit usw. ist, dass sie erst dann Alarm schlagen, wenn das Kind bereits in den Brunnen gefallen, und schon (fast) alles zu spät ist.
Daher sollte man sich vielleicht im Vorfeld um ein vernünftiges Konzept bemühen, in dem man festlegt, wie man solche Vorfälle am besten erst gar nicht erst zustande kommen lässt (Stichwort: "sichere" Konfioguration der angebotenen Dienste). Wenn man so weit ist, kann man sich langsam an solche Dinge begeben.

Ach ja, an dieser Stelle ist es mal wieder angebracht: Sicherheit ist kein Zustand, sondern ein immerwährender Prozess.

[Joe User]

aide hat den Debian-Jungs und -Mädels bei dem Einbruch sehr gute Dienste geleistet.

Und wenn sie LKML im September gelesen hätten... ;)

[dodolin]

LKML kann man IMHO nur hauptberuflich vollständig verfolgen. In de.comp.security.misc und auf Heise-Security wurden Stimmen laut, die Kerneljungs hätten ja mal die Distributoren informieren können. Dies geschah allerdings u.a. auch deshalb nicht, weil sie den Fix für nicht so sehr sicherheitskritisch eingeschätzt hatten...

Aber von lauter freiwilligen Leuten, die das ja nur in der Freizeit machen zu erwarten, dass sie komplett die LKML verfolgen und dann noch erkennen, was sicherheitsrelevant ist, wenn es nicht mal die Kerneljungs selbst erkennen, das ist schon irgendwie...

Außerdem, wie man sieht, ging es inzwischen ja auch nicht nur den Debianjungs so... ;)

[captaincrunch]

Btw.: Eine ganz nette Geschichte für die ohnehin deaktivierten Systemuser wäre noshell ( http://www.cert.org/security-improvemen ... 49.02.html ), mit dessen Hilfe sich (z.B.) versuchtes Einloggen mit diesen Accounts loggen lässt.