Unix Server Partitionierung & Dateisystem Layout

Es gibt viele widersprüchliche Informationen zur Partitionierung von Unix-Servern im Internet, daher benötige ich einige Ratschläge zur weiteren Vorgehensweise.

Bisher war mir auf den Servern in unserer Testumgebung die Partitionierung egal und ich konfigurierte eine einzelne monolithische /Partition sowie eine Swap-Partition. Dieses Partitionsschema scheint für unsere Produktionsserver keine gute Idee zu sein. Ich habe hier einen guten Ausgangspunkt gefunden , aber die Details scheinen sehr vage zu sein.

Grundsätzlich habe ich einen Server, auf dem ich einen grundlegenden LAMP-Stack ausführen werde (Apache, PHP und MySQL). Es muss Datei-Uploads (bis zu 2 GB) verarbeiten. Das System verfügt über ein RAID 1-Array mit 2 TB.

Ich plane einzustellen:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Hört sich das vernünftig an, oder mache ich die Dinge zu kompliziert?

Eine Sache, die Sie beim Layout Ihrer Partitionen beachten sollten, sind Fehlermodi. In der Regel lautet diese Frage wie folgt: "Was passiert, wenn Partition x voll ist?" Liebste voretaq7 brachte die Situation mit einer vollen /Anzahl von schwer zu diagnostizierenden Problemen. Schauen wir uns einige spezifischere Situationen an.

Was passiert, wenn Ihre Partition, in der Protokolle gespeichert sind, voll ist? Sie verlieren Überwachungs- / Berichtsdaten und werden manchmal von Angreifern verwendet, um ihre Aktivitäten zu verbergen. In einigen Fällen authentifiziert Ihr System neue Benutzer nicht, wenn es ihr Anmeldeereignis nicht aufzeichnen kann.

Was passiert auf einem RPM-basierten System, wenn /vares voll ist? Der Paketmanager installiert oder aktualisiert keine Pakete und schlägt je nach Konfiguration möglicherweise unbeaufsichtigt fehl.

Das Auffüllen einer Partition ist besonders dann einfach, wenn ein Benutzer in der Lage ist, darauf zu schreiben. Für Spaß, führen Sie diesen Befehl und sehen , wie schnell man eine ziemlich große Datei machen: cat /dev/zero > zerofile.

Es geht auch über das Auffüllen von Partitionen hinaus. Wenn Sie Positionen an verschiedenen Einhängepunkten platzieren, können Sie auch deren Einhängeoptionen anpassen.

Was passiert, wenn /dev/nicht mit gemountet wird noexec? Da /devdavon ausgegangen wird, dass es normalerweise vom Betriebssystem verwaltet wird und nur Geräte enthält, wurde es häufig (und wird manchmal immer noch verwendet), um schädliche Programme auszublenden. Wenn noexecSie diese Option deaktivieren, können Sie die dort gespeicherten Binärdateien starten.

Aus all diesen und weiteren Gründen wird in vielen Härtungsanleitungen die Partitionierung als einer der ersten auszuführenden Schritte erörtert. Wenn Sie einen neuen Server erstellen, ist die Partitionierung der Festplatte fast genau das erste, worüber Sie sich entscheiden müssen, und oftmals das schwierigste, das Sie später ändern können. Es gibt eine Gruppe mit dem Namen " Center for Internet Security" , die zahlreiche leicht lesbare Konfigurationshandbücher erstellt. Sie können wahrscheinlich eine Anleitung für Ihr bestimmtes Betriebssystem finden und alle Details sehen, die dort stehen.

Wenn wir uns RedHat Enterprise Linux 6 ansehen, lautet das empfohlene Partitionsschema wie folgt:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Das Prinzip hinter all diesen Änderungen besteht darin, zu verhindern, dass sie sich gegenseitig beeinflussen, und / oder zu begrenzen, was auf einer bestimmten Partition getan werden kann. Nehmen Sie /tmpzum Beispiel die Optionen . Das heißt, dass dort keine Geräteknoten erstellt werden können, von dort aus keine Programme ausgeführt werden können und das set-uid-Bit für nichts gesetzt werden kann. Es ist von Natur aus /tmpfast immer von der Welt beschreibbar und oft eine spezielle Art von Dateisystem, das nur im Speicher vorhanden ist. Dies bedeutet, dass ein Angreifer es als einfachen Staging-Punkt verwenden könnte, um bösartigen Code zu löschen und auszuführen. Wenn das System dann abstürzt (oder einfach neu startet), werden alle Beweise gelöscht. Da die Funktionalität von /tmpkeine dieser Funktionen erfordert, können wir die Funktionen leicht deaktivieren und diese Situation verhindern.

Die Protokollspeicherorte /var/logund /var/log/audit-bereiche sind abgetrennt, um sie vor Erschöpfung der Ressourcen zu schützen. Darüber hinaus kann auditd einige spezielle Aufgaben ausführen (normalerweise in Umgebungen mit höherer Sicherheit), wenn sich der Protokollspeicher zu füllen beginnt. Durch Platzieren auf der Partition wird die Ressourcenerkennung verbessert.

Um genauer zu sein und zu zitieren mount(8), genau das sind die oben verwendeten Optionen:

noexec Ermöglicht keine direkte Ausführung von Binärdateien auf dem bereitgestellten Dateisystem. (Bis vor kurzem war es ohnehin möglich, Binärdateien mit einem Befehl wie /lib/ld*.so / mnt / binary auszuführen. Dieser Trick schlägt seit Linux 2.4.25 / 2.6.0 fehl.)

nodev Interpretiert keine Zeichen oder blockiert keine speziellen Geräte im Dateisystem.

nosuid Lassen Sie nicht zu, dass die Bits set-user-identifier oder set-group-identifier wirksam werden. (Dies scheint sicher zu sein, ist aber in der Tat ziemlich unsicher, wenn Sie suidperl (1) installiert haben.)

Unter Sicherheitsaspekten sind dies sehr gute Optionen, da Sie damit Schutzmaßnahmen für das Dateisystem selbst durchführen können. In einer hochsicheren Umgebung können Sie sogar die noexecOption hinzufügen /home. Dies erschwert Ihrem Standardbenutzer das Schreiben von Shell-Skripten zur Datenverarbeitung, beispielsweise zum Analysieren von Protokolldateien, verhindert jedoch auch, dass er eine Binärdatei ausführt, die die Berechtigungen erhöht.

Beachten Sie auch, dass das Standard-Ausgangsverzeichnis des Root-Benutzers lautet /root. Dies bedeutet, dass es sich im /Dateisystem befindet, nicht in /home.

Wie viel Sie genau für jede Partition vergeben, hängt stark von der Systemauslastung ab. Ein typischer Server, den ich verwaltet habe, erfordert selten eine Interaktion mit einer Person. /homeDaher muss die Partition überhaupt nicht sehr groß sein. Dies gilt auch, /varda darin eher kurzlebige Daten gespeichert werden, die häufig erstellt und gelöscht werden. Ein Webserver wird jedoch in der Regel /var/wwwals Spielwiese verwendet. Dies bedeutet, dass sich dieser entweder auch auf einer separaten Partition befinden muss oder /var/dass er groß sein muss.

In der Vergangenheit habe ich Folgendes als Basis empfohlen.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Diese müssen überprüft und an den Zweck des Systems und die Funktionsweise Ihrer Umgebung angepasst werden. Ich würde auch empfehlen, LVM zu verwenden und nicht die gesamte Festplatte zuzuweisen. Auf diese Weise können Sie Partitionen problemlos erweitern oder hinzufügen, wenn dies erforderlich ist.

Wenn Sie das zugrunde liegende RAID-Array ignorieren (in dieser Frage finden Sie weitere Informationen zu RAID-Array-Ebenen und zu deren Verwendung ), konzentrieren wir uns auf die Kernfrage:
"Wie soll ich die Dateisysteme meines Unix-Servers anordnen?"

Was ist los mit einer riesigen /Partition?

Wie Sie in Ihrer Frage festgestellt haben, verwenden viele Linux-Distributionen (insbesondere die "Desktop" -Distributionen wie Ubuntu) ein sehr einfaches Dateisystem-Layout: /und [swap].

Dieses Schema hat den Vorteil der Einfachheit - es ist großartig für DOS / Windows-Benutzer, die an ihren Heim-PC mit "der Festplatte" als einem großen monolithischen Container ( C:\) gewöhnt sind, in den Sie Ihre Daten ablegen, und Sie müssen sich keine Sorgen machen Sie müssen nur sicherstellen, dass Sie nicht über genügend Speicherplatz auf den Dateisystemen verfügen und (zumindest theoretisch) alles in Ordnung ist.

Das Single-Dateisystem - Schema hat mehrere Nachteile , obwohl - die am häufigsten zitierte Nachteil ist , dass Unix - Systeme sind in der Regel sehr schlecht reagieren , wenn das Root - Dateisystem füllt sich (bis zu dem Punkt zu booten verweigern), und wenn alles schriftlich an /(die Wurzel) Ein wegweisendes Programm oder ein Benutzer kann das gesamte System herunterfahren.
Ein einzelnes großes Dateisystem kann im Falle eines Systemabsturzes und einer nachfolgenden Beschädigung des Dateisystems ebenfalls zu einem Totalverlust führen.

Die oben genannten Probleme sowie ein ausgeprägter Organisationssinn führen dazu, dass Unix-Server in der Regel mehrere Dateisysteme haben.

Wie zerlegt man das Unix-Dateisystem?

Hoffentlich sind Sie davon überzeugt, dass mehrere Dateisysteme sinnvoll sind. Die Frage ist nun, wie Sie das System in logische Blöcke aufteilen und wie Sie entscheiden, wie viel Speicherplatz jeder erhält.
Die Antwort ist, dass Sie wissen und verstehen, was Ihr Betriebssystem wo ablegen wird. Der Ausgangspunkt für dieses Verständnis ist die hierManpage. Die meisten Unix-Systeme kommen mit ( man hiervon einem Linux-System und man hiervon einem BSD-System ), und das plus Ihre lokalen Kenntnisse darüber, was der Code, den Sie installieren, tun wird, wird Sie bei der Erstellung eines vernünftigen Partitionierungslayouts unterstützen.

Ich werde hier ein allgemeines Partitionsschema beschreiben, aber dieses Schema sollte immer geändert werden, um Ihren spezifischen Bedürfnissen zu entsprechen.

Ein allgemeines Unix-Partitionierungsschema

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Spezielle Dateisysteme

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

Die Praxis, das Dateisystem so aufzuteilen, stammt aus der Zeit, als es noch keinen Software-Raid gab und die Festplatten klein waren. Sie mussten also mehrere davon verwenden, und daher bestand die einzige Möglichkeit, dies zu tun, darin, das Dateisystem aufzubrechen und legen Sie verschiedene Verzeichnisse auf verschiedenen Laufwerken. Der andere historische Grund dafür war, dass Sie leicht eine Partition aushängen und dumpdiese sichern konnten, was mit dem Root nicht möglich war. Dieses Tool ist heutzutage weitestgehend in Ungnade gefallen und kann stattdessen für einen LVM-Snapshot verwendet werden, sogar für den Stamm.

Es gibt keinen Grund mehr, dies zu tun. Der einzige Grund dafür ist, dass Sie beispielsweise verhindern möchten, dass /tmpdie gesamte Festplatte voll ist.

Dieser Grund ist heutzutage größtenteils irrelevant, da es auf der Strecke geblieben ist, Benutzern allgemeinen Shell-Zugriff zu ermöglichen, und heutzutage Server dedizierte Dienste wie Web- oder Mailserver ausführen. Da Sie keine zufälligen Benutzer haben, die in der Lage sind, beliebige Befehle auszuführen, müssen Sie sich im Allgemeinen keine Sorgen machen, dass diese versuchen, Ihr Dateisystem zu füllen (und selbst wenn Sie dies getan haben, hatten Sie Festplattenkontingente, um dies zu stoppen).

In Bezug auf die zu verwendende RAID-Stufe müssen Sie berücksichtigen, dass der Hauptzweck des RAID-Angriffs nicht der Schutz von Daten (für die Backups vorgesehen sind) ist, sondern die Aufrechterhaltung der Verfügbarkeit. Wenn Sie /tmpein Raid0 durchführen, fällt Ihr Server immer noch aus und Sie müssen es reparieren, wenn eine der Festplatten ausfällt. Sie können auch raid10 anstelle von raid1 verwenden, um eine bessere Leistung zu erzielen.

Ein sehr guter Grund, das Dateisystem NICHT aufzulösen, ist, dass bei falschen Zuordnungen ein Teil des Dateisystems voll sein kann, obwohl an anderer Stelle genügend freier Speicherplatz vorhanden ist. Das zu korrigieren, kann schwierig sein, es sei denn, Sie verwenden LVM und belassen nicht zugewiesenen Speicherplatz.

Ein Großteil der Partitionierungsinformationen wurde generiert, als Speicherplatz knapp war. Infolgedessen sehen Sie für eine Reihe von Fällen relativ kleine Partitionen. Die erforderlichen Partitionsgrößen variieren je nach Servernutzung. Die Variablen neigen zu sein /tmp, /var, home, /opt, und /srv. /usrneigt zu einer vernünftigen und stabilen Größe. Der /Speicherplatz für kann einige oder alle anderen Partitionen und deren Speicherplatzanforderungen enthalten. Die Größe hängt wirklich davon ab, was Sie mit dem System machen.

Ich würde erhöhen swapund montieren /tmpauf tmpfs. Sie /tmpwerden dann Swap als Backup-Speicher verwenden, aber den verfügbaren Speicher verwenden. Ihre Größe /tmpsieht extrem hoch aus, verarbeitet aber abgebrochene Uploads, die nicht bereinigt wurden.

Ich würde erwägen, die MySQL-Dateien zu verschieben /srv. Dies ist eine relativ neue Ebene in der Festplattenhierarchie.

Wenn Sie Ihre endgültigen Anforderungen nicht kennen, sollten Sie LVM verwenden und Ihre Partitionen erweitern, um sie aufzufüllen.

Abhängig von Ihrer Architektur möchten Sie / tmp möglicherweise nicht wirklich verwenden, da es nach jedem Neustart gelöscht wird. Wenn sich Ihre Site mit der eventuellen Verarbeitung von Uploads befasst, ist es möglicherweise eine Idee, diese an einen anderen Speicherort (über php.ini) zu verschieben. in dem du es zu einem beliebigen mount point machen kannst.

Wie bereits erwähnt, wird dringend empfohlen, LVM zu verwenden und nach Bedarf zu erhöhen.

Ich würde auch eine dedizierte Partition für MySQL-Daten empfehlen (Sie können diese weiterhin unter / var / lib / mysql einhängen).