Server-Partitionierung unter Linux

BoMbY

Grand Admiral Special
Mitglied seit
22.11.2001
Beiträge
7.468
Renomée
293
Standort
Aachen
Ich hab gerade einen günstigen Restpostenserver (steht in einem RZ mit GBit-Anbindung und USV-/Generator-Backup) gemietet, und überlege gerade wie ich den am besten partitioniere.

Es handelt sich um einen i7-2600 auf einem Asus P8H67-M PRO (H67(B3)-Chipsatz) mit 2x8 GB RAM und 2x 3TB Seagate Barracuda XT ST33000651AS.

Das System wird wohl CentOS 7.0 werden.

Ich denke ich könnte per KVM auch das Intel Matrix RAID nutzen (werde ich später noch ausprobieren), was von der Performance her ja grundsätzlich sehr gut ist, und in der Konstellation ermöglichen sollte einen Teil der Platten als RAID 0 und einen anderen Teil als RAID 1 einzurichten.

Im Moment bin ich mir vor allem bei den aktuellen Dateisystemen (etx3, etx4, XFS, etc.) unsicher, ob z.B. eine RAM-Disk für /tmp Sinn machen würde, usw. usf.???

Der Haupteinsatzzweck wird wohl nur ein bisschen Web (nginx, Apache, PHP, MySQL, bind9), Mail (postfix) und OpenVPN-Gateway sein. Insgesamt wohl total überdimensioniert, aber dennoch würde ich gerne das Optimum da raus holen, bevor ich meine Sachen da rüber schiebe.

Irgendwelche Vorschläge oder Ideen?
 
tmp in ein ramdisk legen bringt nur was wenn dies auch genutzt wird. zum beispiel bei sehr vielen php-session dateien. eine ramdisk anzulegen um zum beispiel mysql zu beschleunigen wegen der temp tables zu disk bringt nicht viel da lieber mysql mehr ram zur verfügungstellen. für den normalen betrieb bringt ein ramdisk für temp nichts.

für das system würd ich 120GB raid 0 besser 1 machen. /etc , /home /var dann auf nen raid 1 mit den restliches speicherplatz. so hast du bei ner neuinstall deine ganzen config mail ftps etc noch, gerade wenn du viel probieren willst und so eventuell das system schnell zu gemüllt ist, kannst du es schneller zurücksetzen.

wenn die dienste einmal geladen sind, spielt die systemplatte/partition eigentlich keine rolle mehr. raid0 da einzusetzen ist eher zu vernachlässigen. ich würde ein raid1 für system und raid1 für die daten machen. denn wenn eine platte die kurve kratz hast du zwar noch deine daten aber auch wieder das nervige neuinstallieren vor dir.

bei den system nen kleines schilliges softwareraid.

ich würde ext4 empfehlen, da es das stabilste ist und auch gut zu reparieren ist im ernstfall.
einen großen unterschied wirst du bei deinen geringen anforderungen eh nicht feststellen, so das du dich mehr auf ausfall ,reperatur etc konzentrieren solltest.

auch solltest du dir überlegen wie du dein system backups. für die systempartition würd ich die jeden tag auf die daten partition kopieren.

hier mal nen ganz simples backup für 7 tage:

#!/bin/bash
BACKUPDIR="/mnt/Backups"
#legt die benötigtern ordner an wenn nicht vorhanden
mkdir -pv `date +"$BACKUPDIR/%u" `date -d "yesterday" +"$BACKUPDIR/%u"`
#rsync mit hardlinks alle daten
rsync -archv --del --link-dest="`date -d "yesterday" +"$BACKUPDIR/%u/"`" /etc /var /home /usr /root `date +"$BACKUPDIR/%u/"`

dies legt dir jeden tag nen vollbackup an, der speicherplartz der belegt wird entspricht einmal vollbackup + den geänderten daten je tag.
 
Zuletzt bearbeitet:
Ja, ich denke Raid0 werde ich im Prinzip nur für /tmp und /swap nutzen. Wobei ich vermutlich per Matrix Raid der Einfachheit halber zwei Volumes anlegen werde, vielleicht 500MB-1TB Raid0 und 2 TB Raid1 (welche ich beide vermutlich niemals voll bekomme). Die Verwaltung des Matrix Raid wird mittlerweile ja sogar per mdadm unterstützt - ich muss es im BIOS nur noch aktivieren. Das mit /etc, /home und /var macht auf jeden Fall Sinn.

Weil ich ein fauler Mensch bin, werde ich vermutlich auch noch das Plesk Panel installieren, und da werde ich mir auf jeden Fall ein externes FTP-Backup der Konfiguration und Daten einrichten. In der Regel (wenn notwendig) kann man das dann auch einfach wieder zurück laden, auf einen anderen Server mit Plesk Panel.
 
Raid 0 für Swap bei 16 GiB RAM? *suspect* Is'n klein bissel Overkill, nicht?

MfG Dalai
 
bitte kein plesk, wenn du was zum klicken willst dann bitte webmin. grund ist das plesk das system sehr stark zumüllt. ich rate dir daher davon ab.
wenn du es dennoch willst, dann sichere es bitte gut ab.

auch wirst du nicht soviel damit machen und für paar ftpuser und vllt vhost für den apache anlegen brauchste das nicht. beschäftige dich lieber vorab damit wie man es mit useradd etc realisiert direkt auf der console.

samba ist da nen wenig nervig, aber da würd ich auch nicht einsetzen auf nen root denn lieber nfs und freigaben in die /etc/export

ssh per ssh-key einrichten und root passwort jede 5 minuten ändern, zur sicherheit per mail an ein "unbekanntes" postfach schicken.

port für ssh-dienst abändern.
/proc ordner sollte 770 als chmod haben. php / www-data etc sollte den nicht einlesen können.

ips welche sich versuchen mit falschen nutzern anzumelden, sofort per iptables blocken. hier aber aufpassen mehr als 200 ips solltest nicht mit auf einmal sperren.
je mehr ips in der iptables stehen desto langsamer werden abfragen, wenn es zuviel sind sinkt der netzwerkdurchsatz drastisch.
daher die ips wieder nach 1 tage freigeben.

such die auch ein linux was schnell sicherheitupdates liefert, anders als ein heimserver ist dein server schnell und immer erreichbar, was diesen für angreifer attraktiver macht.
meine empfehlung wäre ubuntu 14.04.2 LTS
 
Zuletzt bearbeitet:
Jo, keine Sorge. Ich habe schon mehrere Webserver, und bisher ist keiner gehackt worden, außer einer vor X Jahren welcher "managed" war. SSH lasse ich in der Regel per Firewall ehh nur in einem beschränkten IP-Bereich zu (mein IPv6 /48 Subnetz zum Beispiel), außerdem leistet auch schon fail2ban gute Dienste gegen simple Brute-Force-Angriffe.
 
@ghostadmin , der satz vorher gehört dazu mit dem ssh-key. statt aller 5 minuten zu ändern, kann man auch ein besonders schweres nehmen, das man im notfall nehmen kann wenn kein ssh-key funktioniert oder grad nicht verfügbar ist.

ich wurde noch nie gehackt ist auch sone aussage ... irgendwann ist immer das erste mal ;) installiere mal nen altes wordpress oder joomla und warte 1 woche :D
wollt ja nur paar tips geben, wenn du schon erfahrung hast, ist das natürlich nix neues für dich.
 
So, hab jetzt jedenfalls erstmal das Matrix Raid per BIOS aktiviert, und zwei Volumes erstellt:

Code:
       Platform : Intel(R) Matrix Storage Manager
        Version : 10.5.0.1034
    RAID Levels : raid0 raid1 raid10 raid5
    Chunk Sizes : 4k 8k 16k 32k 64k 128k
    2TB volumes : supported
      2TB disks : supported
      Max Disks : 7
    Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci0000:00/0000:00:1f.2 (SATA)

/dev/md/imsm:
        Version : imsm
     Raid Level : container
  Total Devices : 2

Working Devices : 2


           UUID : c4451cb1:c4d5eda5:e3cfd84b:8d74e5cf
  Member Arrays : /dev/md/vol1 /dev/md/vol0

    Number   Major   Minor   RaidDevice

       0       8        0        -        /dev/sda
       1       8       16        -        /dev/sdb

/dev/md/vol0:
      Container : /dev/md/imsm, member 0
     Raid Level : raid0
     Array Size : 1073741824 (1024.00 GiB 1099.51 GB)
   Raid Devices : 2
  Total Devices : 2

          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 4K


           UUID : 4ca0be1b:93ba6514:fd5df2b7:f54132d5
    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb

/dev/md/vol1:
      Container : /dev/md/imsm, member 1
     Raid Level : raid1
     Array Size : 2393390080 (2282.51 GiB 2450.83 GB)
  Used Dev Size : -1
   Raid Devices : 2
  Total Devices : 2

          State : clean, resyncing
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

  Resync Status : 2% complete


           UUID : 7e9959a9:f9d95ca9:4331afa3:36abc333
    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb

4k Stripe Size erscheint mir für /swap und /tmp jedenfalls sinnvoll. Ansonsten mehr als dicke genug Platz für alle möglichen Optionen. Ich denke ich werde erstmal auch nicht alles partitionieren, und mir noch was Platz lassen. Ebenso werde ich auch erstmal bis morgen warten, bis der Mirror synchronisiert ist, bevor ich etwas installiere.
 
Die Installation von CentOS 7 auf dem Intel-Raid hat übrigens problemlos funktioniert, wurde alles im Installer korrekt erkannt. Ich habe jetzt erstmal XFS benutzt, weil sich das in der Theorie ganz brauchbar anhört. Die Performance scheint auch soweit ganz gut zu sein.

Was nicht gut funktioniert hat war die Standard-Installtion von fail2ban. Natürlich versucht sofort irgendein Botnetz einen Brute Force Angriff, und leider tat sich erstmal nichts mit dem Blocken. Nach ein bisschen Hand-anlegen geht das nun aber auch.
 
@ghostadmin , der satz vorher gehört dazu mit dem ssh-key. statt aller 5 minuten zu ändern, kann man auch ein besonders schweres nehmen, das man im notfall nehmen kann wenn kein ssh-key funktioniert oder grad nicht verfügbar ist.
Wozu? Root-login per ssh gehört verboten. Aus das Ding, nen Nutzer anlegen, der sich per su zu root macht und gut. Ein Account, der nicht bekannt ist, kann nicht angegriffen werden.
 
Naja, dann bekommst Du aber sofort Probleme sobald Du mit Sachen wie WinSCP nutzen willst, wenn Du per su arbeitest. Besser SSH nur selektiv öffnen. Abgesehen davon scheinen die Brute-Forcer-Scripts ehh dumm wie Brot zu sein.

Edit: Die schaffen mit Fail2Ban aktuell vielleicht so 1.500 Passwort-Versuche am Tag, aber hören nicht auf es zu versuchen. Bei der Rate brauchen die selbst für ein simpel-Dictionary ein Jahr ...
 
Zuletzt bearbeitet:
Also das musst du nun erklären, denn ich sehe da keine Probleme.

Ganz einfach: Es funktioniert nicht. Du kannst keine Dateien ändern, weil Du keine Berechtigung hast, weil das sftp nicht ordentlich mit su gestartet werden kann. Jedenfalls alle meine Versuche damit sind gescheitert.
 
Wieso willst du denn sftp mit su verknüpfen?

Erst kopieren, dann verwurschteln. So stellt man auch sicher, dass die Berechtigungen ordentlich gesetzt sind und man keinen Pfusch veranstaltet.

In jedem Fall gibt das keinen Grund sich als root einzuloggen.
 
Wenn ich mit normalem Benutzer durch su oder sudo Root-Rechte erlangen kann, dann kann ich gleich root-einloggen erlauben, denn es ist ja nur ein Schritt mehr vom gehackten Userpasswort zu den Root-Rechten.
Klar, dass erst der Benutzername bekannt sein muss, aber rein sicherheitstechnisch bringt das nicht allzu viel mehr.

Wichtig ist ein möglichst komplexes, langes nicht durch Wörterbuchattacken zu erlangendes Passwort.
Den Rest können tools wie fail2ban ganz gut in den Griff bekommen.
 
Wenn ich mit normalem Benutzer durch su oder sudo Root-Rechte erlangen kann, dann kann ich gleich root-einloggen erlauben, denn es ist ja nur ein Schritt mehr vom gehackten Userpasswort zu den Root-Rechten.
Klar, dass erst der Benutzername bekannt sein muss, aber rein sicherheitstechnisch bringt das nicht allzu viel mehr.

Öhm, gerade der nicht bekannte Account bringt den Sicherheitsgewinn. Natürlich ist ein gehackter Account kein Sicherheitsgewinn, wenn der Nutzer root-Rechte erlangen darf. Aber erklär mal, wie du etwas hacken willst, was du nicht kennst.
 
Ebenso mit Wörterbuchattacke kann ich bekannte Benutzernamen durchgehen.
Muss ja nicht jeder PuckPoltergeist als Benutzernamen haben.
 
Ebenso mit Wörterbuchattacke kann ich bekannte Benutzernamen durchgehen.
Muss ja nicht jeder PuckPoltergeist als Benutzernamen haben.

Dass es kein Standard-Login sein darf, ist natürlich klar. Aber root existiert auf jedem System. Damit ist es auch das erste Ziel für Angriffe. Und ob ich jetzt tomturbo, Tomturbo, TomTurbo oder T0mTurb0 angreifen muss, sagt mir keiner. Insofern sehe ich das als signifikanten Sicherheitsgewinn.
 
Dass es kein Standard-Login sein darf, ist natürlich klar. Aber root existiert auf jedem System. Damit ist es auch das erste Ziel für Angriffe. Und ob ich jetzt tomturbo, Tomturbo, TomTurbo oder T0mTurb0 angreifen muss, sagt mir keiner. Insofern sehe ich das als signifikanten Sicherheitsgewinn.

Da hast Du zwar Recht, ich finde aber ein ordentliches Passwort wesentlich wichtiger.

Noch besser in diesem Zusammenhang finde ich bei ssh-Verbindungen das Abschalten des Passwortlogins und ausschließliches zulassen von Zertifikaten.
Damit hat man eigentlich 2 Fliegen mit einer Klappe geschlagen.
Es ist sicher und immun gegen Skript-Login-Versuche egal welcher Art und man kann root dort verwenden wo es sinnvoll erscheint.
 
Noch besser in diesem Zusammenhang finde ich bei ssh-Verbindungen das Abschalten des Passwortlogins und ausschließliches zulassen von Zertifikaten.
Damit hat man eigentlich 2 Fliegen mit einer Klappe geschlagen.
Es ist sicher und immun gegen Skript-Login-Versuche egal welcher Art und man kann root dort verwenden wo es sinnvoll erscheint.
Es sei denn, man nutzt Debian. ;D
 
Zurück
Oben Unten