# Bitte löschen



## Alice (11. Februar 2020)

Bitte löschen


----------



## Jan-Frederik Stieler (11. Februar 2020)

Hi,
soweit ich das jetzt gesehen habe sollte alles funktionieren.
Nur finde ich es etwas merkwürdig ssh und XRDP zu installieren.
Auch weil Du von Sicherheit gesprochen hast.
Was Du noch machen kannst ist den standard pi user zu löschen oder Du benennst ihn um. Weil jeder kennt diesen User und auch das Passwort.

Und das mit de mApache würd ich mir auch nochmal überlegen ob Du da nicht lieber ngnix einsetzen willst.
Bei fail2ban müsstest Du dann mal schauen ob es für den ngnix auch standardfilter gibt.

Da ich jetzt bzgl. Linux (Raspberrian) auch noch nicht so 100% sattelfest bin wäre es abergut wenn noch jemand anderes was dazu schreibt.

Grüße


----------



## Zvoni (11. Februar 2020)

Was ich eher seltsam finde, ist dass du überhaupt RDP für einen Server brauchst.
Und was soll an SSH unsicher sein? Deine config sieht sogar besser als meine aus. Und für SSH kannst du sogar verschlüsselte Verbindungen aufbauen: OpenSSH Public Key Authentifizierung unter Ubuntu – Thomas-Krenn-Wiki
Die Frage die du dir stellen musst: Von wo soll der Pi erreichbar sein? Über das Internet? Per Port-Forwarding? Per VPN? Da sind die Angriffsstellen.


----------



## Zvoni (11. Februar 2020)

Wenn du "Admin"-Zugang wirklich nur aus dem lokalen LAN willst/brauchst, dann ist aber SSH vollkommen ausreichend. Da finde ich sogar VNC (egal welchen) überflüssig, da es mMn nur unnötigen Overhead erzeugt.
FTP-Zugang von wo?


----------



## Zvoni (11. Februar 2020)

Ah, OK!
Dein Setup erinnert mich nämlich an das, an welchem ich gerade für unseren Verein arbeite, mit dem Unterschied, dass diverse Dienste (FTP) eben auch von aussen (=Internet) erreichbar sein sollen.
als FTP-Server kann ich dir Proftpd empfehlen. Config ist relativ einfach.
Aber dann die Frage: Wieso FTP von nur "Zuhause"? Wieso nicht einfach Samba-Share/Freigabe und gut ist?


----------



## Zvoni (11. Februar 2020)

Hmmm, ich versuche gerade zu verstehen, wie man mit TeamViewer auf eine Linux-Kiste kommen will, es sei denn man lässt TeamViewer auf dem Pi unter Wine laufen (pfui bäähh)


----------



## Zvoni (11. Februar 2020)

Ist ne rudimentäre smb.conf. Es gibt noch den ein oder anderen "Schalter" um es noch sicherer zu machen.
Ich such mal zuhause meine smb.conf raus (bin grad auf Arbeit)

EDIT: Uh Oh...

```
- Terminal@alice: sudo chmod 777 /var/www/html/
```
Nix gut. Ordner (und Dateien) gehören root:root, aber mit 777 erteilst du einen Blankoscheck an "World" zu tun und zu lassen, was sie wollen. Hätte eher "775" erwartet.

EDIT2: Und der nmbd-daemon ist mehr oder weniger überflüssig


----------



## Zvoni (11. Februar 2020)

Wer soll denn alles auf den Share?
Ausserdem glaube ich mich daran zu erinnern, dass "root:root" für den www-Ordner keine gute Idee ist, weil der Ordner eigentlich dem User gehören soll, in dessen Prozessraum der Apache laufen soll ("www:www"?)
und du kannst deshalb keine Unterverzeichnisse erstellen, weil der User "alice" nicht Mitglied der Gruppe "root" ist (und auch nie sein sollte).
Ich glaube mit Installation vom Apachen wird automatisch "www" als User und auch als Gruppe angelegt. 
chown den Ordner zurück zu "www:www" und füge deinen user "alice" der Gruppe "www" zu, und schon reicht 775 aus um Unterverzeichnisse anzulegen


----------



## Zvoni (11. Februar 2020)

Jepp, genau den meine ich
https://www.pcwelt.de/ratgeber/Apache-Server-unter-Linux-einrichten-9666866.htmlblätter mal ins untere Drittel, wo der Kasten "Apache Zugriffsrechte korrekt setzen" ist


----------



## Zvoni (11. Februar 2020)

Wie versprochen, anbei meine smb4.conf (ist von meinem FreeBSD-Server, aber Samba ist Samba).
Samba ist Version 4.10.
Ich habe mal das zfs-spezifische rausgeworfen

```
[global]
server string = Zvoni's Server
workgroup = WORKGROUP
log file = /var/log/samba4/%m.log
max log size = 50
disable netbios = yes
map to guest = bad user
security = user
server role = standalone server
deadtime = 15
dns proxy = no
idmap config * : backend = tdb
delete veto files = yes
store dos attributes = yes
veto files = /Thumbs.db/.DS_Store/._.DS_Store/.apdisk/._*/
strict locking = no
directory name cache size = 0
dos filemode = yes
acl allow execute always = yes
create mask = 0775
directory mask = 0775
invalid users = nobody root
aio read size = 65536
aio write behind = yes
aio write size = 65536
max connections = 10
write cache size = 65536

[brick1]
comment = Brick1 on Server 01
path = /server/brick1
valid users = @MyGroup
read only = no

[brick2]
comment = Brick2 on Server 01
path = /server/brick2
valid users = @MyGroup
read only = no
```
Es gibt noch weitere Attribute (siehe man-pages für Samba), wie Guest OK, browsable usw.
Einfach mal nachlesen.
Falls du Fragen hast....


----------



## Zvoni (12. Februar 2020)

Sieht gut aus.
Hätte nur 2 Bemerkungen (die jetzt aber mit "Sicherheit" nur bedingt was zu tun haben):
1) in der sshd_config hast du deine "AllowUsers"-Klausel mit Name und IP --> dir ist klar, das funktioniert nur, wenn der Rechner, von welchem du einloggst eine statische IP hat? Wenn du DHCP hast lass die IP weg.
Dir ist bekannt, dass du in der sshd_config auch per Gruppe (Bsp. SSHUSERS) erlauben/verweigern (anstatt per User) kannst?

2) Deine Modifikation für sudoers. Bin kein Freund von expliziten Rechtevergaben per Username (siehe auch Punkt 1). Hätte jetzt eher auf Gruppenebene (Bsp. Gruppe WHEEL bzw. einfach eine Gruppe SSHUSERS anlegen, Mitglieder rein, fertig)) die Modifikation gemacht.

EDIT
3) Zum Thema Firewall: Ist so ne Sache in der heutigen Zeit, da ja die meisten User ja nicht mehr direkt mit dem Internet verbunden sind (im Gegensatz zu ISDN-Zeiten vor 20 Jahren) sondern hinter einem Router sitzen (welcher eine mehr oder weniger gute eigene Firewall hat). Und genau aus diesem Grund sind die Kenntnisse wie eine Firewall richtig einzustellen ist im breiten Volk ziemlich verloren gegangen.


----------



## Zvoni (12. Februar 2020)

Jein, es ist wichtig solche Server "safe" aufzusetzen, sofern "fremde" Personen darauf zugreifen sollen/dürfen, wie z.Bsp. eine Webseite.
Ein Zugriff ausschliesslich aus dem lokalen Netzwerk ist eben nicht so kritisch, weil ja zwischen lokalem Netzwerk und dem Internet (wo die bösen Buben beheimatet sind) ja unter Umständen tatsächlich eine Firewall ist (rudimentär im Internet-Router oder dedizierter Rechner als Router inkl. 10 Meter dicker "great Firewall of China").
Die Angriffsstellen sind dann eher falsch konfigurierte "Zugänge" zum Internet.
Bsp. FTP-Server.
Fängt allein schon damit an, dass nicht FTPS/SFTP verwendet wird, sondern plain FTP, bei welchem dann die Login-Daten (Username und Passwort) in Klartext übermittelt werden. Oder dass der FTP-Server selbst keine chroot-Klausel hat (In diesem Zusammenhang nenne ich mal das Stichwort "Jail").
Oder bei einem öffentlich zugänglichen Verzeichnis die "777" zu setzen.

Im ersten Schritt sollte man daher eher wissen:
Wofür will ich diese Kiste einsetzen? Nur Webseite (Apache/PHP)? Nur Datenbank (MySQL)? Beides?
Dann als nächstes:
Von wo soll darauf zugegriffen werden? Aus dem Internet? Nur lokales Netzwerk? Beides?
Dritter Schritt:
Wie soll darauf zugegriffen werden (http, https, ftp, nfs, samba etc.)?
Erst im vierten Schritt:
OK, wer soll darauf zugreifen dürfen (mit welchem Werkzeug)?

Das Problem, ist, dass die "Anwendungs"-Landschaft solcher Server heutzutage immer mehr heterogen wird, dass es eigentlich fast kein "Schema F" mehr gibt, und man/frau es sich selbst erarbeiten muss, und dann eben über deine genannten "Fragmente" sich das mühsam zusammen suchen muss.

Und ich habe jetzt noch nichtmal erwähnt: Welches Betriebssystem soll zum Einsatz kommen bzw. Für das genannte Szenario ist welches OS am besten geeignet?

EDIT
Nur um dir mal ein Beispiel zu nennen:
Ich soll dieses Jahr bei uns im Verein, eine Server-Infrastruktur aufbauen.

Zwei Server, auf welchen auf beiden MySQL läuft und sich gegenseitig replizieren (Backup der Daten).
Auf beiden Servern wird GlusterFS installiert, so dass alle zusätzlichen Festplatten in den Servern als 1 Samba-Share exportiert werden kann.
Auf einem Server der beiden soll aber noch der Apache/PHP laufen für das Intranet. Auf dem anderen Server soll aber der FTP-Zugang eingerichtet werden, für Down-/Upload von Daten aus dem Internet für benannte User.
Jetzt soll im Laufe des Jahres noch ein dritter Server dazukommen, auf welchem dann NextCloud mit dem vollen Brimborium installiert werden soll (Apache, PHP, MySQL). Aber eben auch nur das.
Ich weiss jetzt schon, dass der Zugang auf diesen dritten Server auch vom Internet möglich sein soll.

Deshalb weiss ich auch jetzt schon, dass etwaige auf diesem NextCloud-Server angelegte User, definitiv keinen Zugriff auf die anderen beiden Server haben werden bzw. der Zugriff auf vielleicht maximal 2 Leute eingeschränkt werden wird (Und damit meine ich Login-Zugriff, nicht Zugriff für einen Kunden, der vom Internet aus einen Download-Link öffnet --> NextCloud ist so etwas wie DropBox aber mit eigenem Server).

Planung der ganzen Sache ist schon die halbe Miete.
Wie man dann die Zugriffswerkzeuge konfiguriert, dass ist eben diese mühsame Schnitzeljagd, welche nicht einfacher wird, wenn Server 1 unter Manjaro, Server 2 und Server 3 unter FreeBSD laufen, während die Clients, die im lokalen Netzwerk zugreifen dürfen, von Linux über Mac bis zu Windoof10 reichen


----------



## Zvoni (12. Februar 2020)

Hab eben noch mal in meinem Beitrag was hinzugefügt


----------

