PermitRootLogin no & su -

[checksumde]

Hallo =),

wie schon mehrfach erwähnt habe ich mir gestern
mit dem howto der seite debianhowto.de einen
eigenen debianserver aufgesetzt.

nachdem ich nun größten teils alles am laufen habe
und nach meinen vorstellungen angepasst habe
möchte ich den rootlogin komplett unterbinden.

wie ich bereits im forum nachgelesen habe
funktioniert das mit dem parameter

Code: Select all

PermitRootLogin no

aus der /etc/sshd_config

auf dem server ist zur zeit nur der user root
berechtigt sich über ssh anzumelden,
der von mir bei der installation angelegte user
hat nur den ftp zugriff und keine shell

ich möchte jetzt einen neuen user anlegen und diesen
bis auf die shellrechte mit eigentlich keinen weiteren rechten ausstatten
um diesen dann im fall des falles mit su - dazu
zu bewegen volle root rechte zu haben

genau hier ist nun allerdings mein problem,
wie lege ich so einen user am besten an und
was muss ich beachten, für eine kurze
anleitung wäre ich sehr dankbar

(bitte kein verweis auf unübersichtlich man pages)


mfg
checksum

[checksumde]

Und noch eine Frage,

da ich mich nicht aussperren möchte hab ich noch eine Frage zu
/etc/hosts.deny und /etc/hosts.allow

ich möchte in der hosts.deny ersteinmal alle zugriffe verhindern
das funktioniert ja nun mit:

Code: Select all

ALL: ALL

jetzt möchte ich aber in der hosts.allow nur zugriffe für

http - alle
ssh, ftp. imap2 und emailsabrufen - nur für leute mit einem dialup aus dem bereich 217.237.*.* bzw schlund + partner und t-online freigeben

ist das in der form möglich und macht dies auch sinn?

mein ansatz wäre:

Code: Select all

in.ftp 217.237.*.*
in.ssh 217.237.*.*
in.imap2 217.237.*.*
in.pop3 217.237.*.*
in.http ALL

mfg
checksum :]

[dodolin]

ich möchte jetzt einen neuen user anlegen und diesen
bis auf die shellrechte mit eigentlich keinen weiteren rechten ausstatten

http://www.openoffice.de/linux/buch/benutzerverw.html

Meist genügt ein

Code: Select all

adduser <username>

völlig.

um diesen dann im fall des falles mit su - dazu
zu bewegen volle root rechte zu haben

Sinn kann dann z.B. folgendes machen:

Code: Select all

adduser <username> wheel

In /etc/pam.d/su

Code: Select all

auth    required        pam_wheel.so group=wheel debug

Dann kann sich nur noch dieser einzige User per su zu root machen, alle anderen nicht.

BTW: Hatte ich schonmal erwähnt, dass PAM ne feine Sache ist? ;)

(bitte kein verweis auf unübersichtlich man pages)

Bei sowas krieg ich nen Kollaps. Was ist an "man adduser" unübersichtlich? :evil:

[/etc/hosts.allow] ist das in der form möglich und macht dies auch sinn?

Möglich: Ja (habe die Syntax jetzt nicht genau überprüft, aber vom Prinzip her schon).
Sinn: Bedingt.

Wenn du so große Bereiche und sogar Dialup-Bereiche freigibst, macht das keinen Sinn. Du musst die Dienst so oder so "sicher" eingerichtet haben und dann spielt es auch keine Rolle mehr, ob ein Dienst für alle oder nur für weniger IPs verfügbar ist. Deine Idee bringt jedenfalls kein "Mehr" an Sicherheit, insofern kann man sich das auch sparen.

[checksumde]

Hallo,
ersteinmal danke für deine Hilfe,
dazu muss ich sagen das die Idee die dahinter steckt folgende war,
der User der angelegt werden soll sollte nur minimale Rechte bekommen,
damit im Falle des Falles ein Eindringling auf diesem Account nur einen
sehr geringen Handlungsspielraum hat.
Diesbezüglich hab ich auch nach speziellen Tips gesucht.
Wie man so einen User anlegt ist mir allerdings auch klar .

Für Deinen Kollaps muss ich mich entschuldigen, ich lese mich nun
schon seit 3 Tagen unentwegt durch dieses Forum. Dabei ist mir
aufgefallen das viele Fragen gerade im Securitybereich immer wieder
mit Verweisen auf andere Seiten abgeschmettert werden.
Was sicher auch nachvollziehbar ist wenn ständig die selben Fragen auftauchen. Da ich hier nun aber nicht fündig geworden bin
und ich keinen Standartuser anlegen möchte hab ich versucht dem
auf diese Weise aus dem Weg zu gehen.

Kurzgesagt: Macht es nun Sinn einen User anzulegen der einzig
und allein dazu bestimmt ist sich über ssh anzumelden und
dann rootrechte via su zu bekommen?

Zu der anderen Geschichte:
Welche Regeln würden denn Sinn machen folgende Ports abzusichern:
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop-3
143/tcp open imap2

Ich für meinen Teil denke schon das es Sinn macht Dienste
die zu administrativen Zwecken oder Dienste die nur speziellen
Leuten (die man somit auch speziellen ISPs zuordnen kann)
von vornherrein gegen Unbefugte abzuschotten.
Das die Dienste selbst dahingehend abgesichert werden müssen
steht außer Frage. Es geht nur darum eine weitere Hürde aufzubauen.
Da diesbezüglich IPtables recht unnütz sind kann man doch auf
diesem Weg einen großen Prozentsatz der User den Zugang verweigern
die auf dem Server und diesen Diensten sowieso nichts zu suchen haben.

[dodolin]

Kurzgesagt: Macht es nun Sinn einen User anzulegen der einzig
und allein dazu bestimmt ist sich über ssh anzumelden und
dann rootrechte via su zu bekommen?

Ja.

Es macht aber sehr wenig Sinn, wenn man versuchen will, diesen User irgendwie künstlich einzuschränken. Denn wenn dieser User a) sich einloggen kann, b) damit einen vollen Shellzugriff hat und c) via su zu root werden kann, was soll es da noch nutzen, ihn künstlich einzuschränken? Dieser User hat so oder so ziemlich viel Macht.

Was in diesem Fall dagegen Sinn macht, wäre, diesem User auch noch den Passwort-Login zu disablen und den Login ausschließlich per PubKey zu erlauben. Wenn das, aus welchen Gründen auch immer, nicht praktikabel ist, hilft dann nur noch ein möglichst gutes (tm) Passwort für diesen User zu wählen und dieses NIE im Klartext durchs Netz oder sonstwo durchzublasen, es nirgendwo aufzuschreiben und so weiter und so fort.

Zu der anderen Geschichte:
Welche Regeln würden denn Sinn machen folgende Ports abzusichern:
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop-3
143/tcp open imap2

Auch wenn dir meine Antwort nicht gefallen mag, aber meine Meinung ist: Gar keine Regeln machen Sinn diese "Ports" abzusichern.

FTP ist hoffentlich nur für solche Accounts erlaubt, die keinen Shellzugriff haben und POP3 und IMAP gehört grundsätzlich abklemmt und durch die verschlüsselten Alternativen POP3S und IMAPS ersetzt.

Ich für meinen Teil denke schon das es Sinn macht Dienste
die zu administrativen Zwecken oder Dienste die nur speziellen
Leuten (die man somit auch speziellen ISPs zuordnen kann)
von vornherrein gegen Unbefugte abzuschotten.

Ok, deine Meinung sei dir unbenommen.
Ich denke hier allerdings anders und deshalb werde ich da auch nicht mehr weiters drauf eingehen.

[checksumde]

Im Bezug auf pop3 und imap heißt das also das
Du die Installation laut debianhowto.de
aufgrund möglicher sicherheitsprobleme
so nicht machen würdest?

[dodolin]

Im Bezug auf pop3 und imap heißt das also das
Du die Installation laut debianhowto.de
aufgrund möglicher sicherheitsprobleme
so nicht machen würdest?

AFAIK ist bisher nur im QMail Howto etwas von POP und IMAP geschrieben worden, oder?
Dafür bin ich nicht zuständig, habe von QMail absolut keine Ahnung. ;)
Wenn dort sowas steht, dann ja. Ich würde POP3 und IMAP grundsätzlich auschließlich in den verschlüsselten Varianten zur Verfügung stellen. Das ist im eigenen Interesse der User, damit ihr Passwort nicht im Klartext über die Leitung muss. Oder sagen wir andersrum: Ich als Benutzer eines solchen Dienstes möchte nicht, dass mein PW im Klartext über die Leitung geht, da mir (auch mal angenommen, es ginge um reine Mailaccounts ohne Shell- und sonstigen Zugriff) meine Mails zu wichtig dafür sind.

Falls ich irgendwann mal zu meinem Exim 4 Howto komme (kann noch einige Zeit dauern... ;) ), werde ich kurz auf courier-imap-ssl in Verbindung mit Exim 4 eingehen. Und natürlich werde ich in diesem Howto auch erklären, wie man den nicht verschlüsselten Courier-IMAP dann abstellt, weil ich das eben für unsicher halte. :-D

[checksumde]

Weiß denn jmd ob die Syntax für hosts.deny / hosts.allow so richtig ist?
Oder hat jmd Verbesserungsvorschläge?

[dodolin]

Weiß denn jmd ob die Syntax für hosts.deny / hosts.allow so richtig ist?

Spricht was gegen die gängige Praxis, manpages zu lesen?
Wenn du das nicht willst oder kannst, wie wäre es mit "ausprobieren"?

Oder hat jmd Verbesserungsvorschläge?

Die hatte ich genannt, aber du willst sie ja nicht hören.

[checksumde]

Prinzipiell spricht natürlich nichts gegen manpages
oder ausprobieren, aber ich hab nun 3 Tage gekämpft
um den Server so aufzusetzen das halbwegs alles läuft
und meinen Vorstellungen entspricht.
Da will ich nun ganz sicher gehen das ich mich nicht aussperre.
Davon mal abgesehn hattest du keine konkreten Beispiele/Verbesserungsvorschläge
bezüglich hosts.allow / hosts.deny gebracht bzw warst Dir der Syntax nicht sicher.
Damit bin ich also genauso schlau wie vorher.

[dodolin]

Prinzipiell spricht natürlich nichts gegen manpages
oder ausprobieren, aber ich hab nun 3 Tage gekämpft
um den Server so aufzusetzen das halbwegs alles läuft
und meinen Vorstellungen entspricht.

Aha, und deshalb meinst du, braucht man dann keine Anleitungen zu lesen?

Da will ich nun ganz sicher gehen das ich mich nicht aussperre.
Davon mal abgesehn hattest du keine konkreten Beispiele/Verbesserungsvorschläge
bezüglich hosts.allow / hosts.deny gebracht bzw warst Dir der Syntax nicht sicher.

Meine konkreten Verbesserungsvorschläge waren, dass man sich in diesem Fall das Gedöns mit host.allow/deny sparen kann, weil es nichts bringt.

Zur Syntax:
Ich meine mich entsinnen zu können, dass er die Netzmasken gerne so hätte:

ssh: 217.160.0.0/255.255.0.0

Ich bin mir nicht sicher, ob er Wildcards akzeptiert, bei obigem bin ich mir aber sicher.
Weiters weiß ich, dass ich jedenfalls auf meinem Debian woody den ssh nur mit ssh und nicht mit in.ssh adressiert habe. Ob das bei den anderen Diensten auch so ist, weiß ich nicht. Deshalb sage ich ja ausprobieren. Halt sinnigerweise nicht zuerst mit dem sshd und z.B. zuerst mal für localhost, dann kann doch gar nichts passieren.

[olaf.dietsche]

Da will ich nun ganz sicher gehen das ich mich nicht aussperre.

Wenn du bereits eingeloggt bist, dann kannst du die neue Konfiguration mit einem weiteren Login testen. Falls das nicht funktioniert, hast du immer noch eine Verbindung, um deine Ã?nderungen rückgängig zu machen.

Allerdings solltest du dafür eine Kopie deiner Konfiguration haben.

[checksumde]

wie erstell ich denn eine vollwertige wheel grouppe mit gid = 0?

[dodolin]

wie erstell ich denn eine vollwertige wheel grouppe mit gid = 0?

Ã?h... der Witz ist doch gerade, dass die Wheel-Gruppe NICHT die gid 0 hat!

Also ganz normal:

Code: Select all

groupadd wheel

Und, BTW: Wie man die GID mit angibt steht natürlich in der manpage. Kannst du die echt nicht selber lesen? Es wird aber wohl nicht möglich sein, mehrere Gruppen mit der gleichen GID zu haben, denke ich.