Kernel: Netfilter Configuration

[rerajung]

Hallo Forum,

ich kompiliere just einen Kernel (2.6.11) für meine Debian-Server (Strato). Dieser Kernel wird keinen dynamischen Modul-Support unterstützen. Alle Optionen werden wahrscheinlich statisch einkompiliert werden. Welche Optionen sollte ich bei der "Netfilter Configuration" in jedem Fall mit einkompilieren und welche sind nicht erforderlich. Die Sicherheit sollte in jedem Fall vorgehen, also lieber eine Option zu viel als zu wenig (in diesem Fall). Der Kernel wird auf Systemen mit einer breiten Nutzbasis zum Einsatz kommen (Apache 2, FTP, Gameserver, Mailserver und MySQL). Das verwendete System ist immer Debian in der Stable-Version (z.Z. 3.1 - Sarge). Welche Optionen werden zum Erstellen einer umfangreichen und sicheren Firewall benötigt.

Ich freue mich auch über jeden Informationsverweis.

Danke. Grüße René.

 

[name]

aehmm, zwei antwortmöglichkeiten sind gleich

 

[NiceDay]

Ja, eine Möglichkeit ist doppelt.
Verstehe auch die Antworten irgendwie nur zur Hälfte... was muss ich nehmen wenn ich Module auf Server+daheim verwende, vielleicht könnt ihr mir helfen
Was die Sicherheit angeht, ist es nicht eher sicherer möglichst viel als Modul zu haben, damit es, sagen wir so, mehrere "Sicherheitslöcher,Angriffspunkte" wie auch immer, gibt und nicht nur 1 großes.
Btw ist das doch auch irgendwie bißchen dumm wenn man nur 1 son großen Klotz da dann hat.

 

[rerajung]

Sicherheitsplus: loadable module support deaktivieren

Hallo Forum,

danke für euere Stimmen, ich konnte die Antworten leider nicht mehr bearbeiten. Sorry.

Hier noch mal die Antworten:

1. Nein, ich verwende auf meiner Workstation aus Flexibilitätsgründen den dynamischen Modul-Support.

2. Nein, ich verwende auf meinem Server aus Flexibilitätsgründen den dynamischen Modul-Support.

3. Ja, ich verwende aus Sicherheitsgründen auf meinem Server lediglich statisch einkompilierte Module.

4. Ja, ich verwende aus Sicherheitsgründen auf meiner Workstation lediglich statisch einkompilierte Module.

@NiceDay:

Man muss sich halt entscheiden. Ist immer eine Ansichtssache. Um den eigentlichen Kernel klein zu halten empfiehlt sich eine Kompilierung mit Modulen. Aus Sicherheitsgründen ist es besser den Kernel so klein wie Möglich zu halten und den "loadable module support" zu deaktivieren. Dies erhöht die Sicherheit ungemein, da Angreifer so durch das hinzu laden von Kernel-Modulen kein Unheil anrichten können (Prominentes Beispiel für einen solchen Exploit: Der Ptrace-Bug - Root-Rechte erlangen mit Hilfe von modprobe alias insmod und /proc). Auch Rootkits nutzen diese Funktion. Besonders für Server- oder Sicherheitsbewusste Anwender sind diese Gründe nicht verachten.

Ich werde in jeden Fall mal ein Kernel HowTo schreiben und dann posten, da ich die Faulheit in Person bin möchte ich keinen Termin versprechen. Erst werde ich meine Server mal einrichten.

Gruß René.

 

[rerajung]

Meine Recherche

Hallo Forum,

eine Google-Suche ergab Folgendes:

Suche: Statischer Kernel sicherer

Suche: Modularer oder Statischer Kernel


Das Firewall-Buch (Wolfgang Barth):

Modularer oder statischer Kernel suchen und den entsprechenden Abschnitt lesen


Man findet gewiss noch wesentlich bessere Texte.

Grüße René.

 

[ChrisMD]

Besser noch, modular, aber nur mit den Modulen die man auch brauch
Wozu ich das ganze gemacht hab weiß ich aber nicht wirklich...

 

[NiceDay]

Rein theoretisch könnten die Leute die eh nur die Module die ihnen wichtig sind auswählen, ja auch gleich alles statisch machen lassen, kommt son bißchen für diese Leute aufs gleiche raus. Gute Idee is das, muss ich auch mal drüber nachdenken, da es mich genau so auch betrifft.
Voten kann ich für nix, da ich für beides "ja" ankreuzen müsste...

 

[tig]

Aus Sicherheitsgründen ist es besser den Kernel so klein wie Möglich zu halten und den "loadable module support" zu deaktivieren. Dies erhöht die Sicherheit ungemein, da Angreifer so durch das hinzu laden von Kernel-Modulen kein Unheil anrichten können (Prominentes Beispiel für einen solchen Exploit: Der Ptrace-Bug - Root-Rechte erlangen mit Hilfe von modprobe alias insmod und /proc). Auch Rootkits nutzen diese Funktion. Besonders für Server- oder Sicherheitsbewusste Anwender sind diese Gründe nicht verachten.

Stimmt so nicht mehr ganz, soweit ich gelesen habe. Ich habe mal einen Thread aus dem Gentoo Forum ausgegraben und war mal so frei ihn hier zu posten.

http://forums.gentoo.org/viewtopic-t-284118.html

 

[ChrisMD]

Wenn ich nun das ganze zwar Modular hab, aber nur die Module hab die ich brauch, bringt dann ein statisches einbinden was? Was bringt das überhaupt für nen großen Unterschied.
Wenn ich das nun im Kernel hab, ists dann flotter/langsamer und inwiefern unsicherer?

 

[khs]

Wenn ich nun das ganze zwar Modular hab, aber nur die Module hab die ich brauch, bringt dann ein statisches einbinden was? Was bringt das überhaupt für nen großen Unterschied.
Wenn ich das nun im Kernel hab, ists dann flotter/langsamer und inwiefern unsicherer?

Langsamer ist es in jeden Fall. Ein Jump zu der Adresse der Modul-Funktion dauert ganz sicher nicht so lange, als wenn der Kernel erst einen Zugriff auf ein noch nicht vorhandenes Device abfangen, Dependencies nachschlagen und dann eine oder eben mehrere Dateien laden soll. Duerfte aber in der Praxis nicht relevant sein, weil du ja nicht dauernd laedst/entlaedst und daher nur der erste Zugriff etwas laenger dauert.
Gerade bei iptables hatte ich jedoch immer meine liebe Not mit autoload, sodass ich die ganzen Targets und Helper eh am Anfang vom Firewallscript explizit geladen habe, was mich dazu brachte, sie fest einzukompilieren. Das einzige, was ich als Modul baue, sind nachtraeglich Sachen, die ich vor dem naechsten Reboot ausprobieren moechte - meist also neue ipt_helper. Wenn ich z.B. mal ein USB-Geraet anschliessen muesste, wuerde ich den USB-Support auch nachtraeglich als Modul bauen.

Was die Sicherheit betrifft: bevor jemand den Kernel zum Modul-Autoload bringt (ob nun abgeschaltet oder nicht), stimmt meist schon was anderes im Vorfeld nicht mehr.
Das Argument zaehlt bei "sicheren" Servern zwar nur bedingt, aber fuer meinen Privatbetrieb glaube ich, dass die Vorfeldmassnahmen ausreichen und mir seltene Reboots wichtiger sind als noch eine Nachkomma-9 bei Sicherheit...

-khs

 

[quarzsnoopy]

Wenn ich nun das ganze zwar Modular hab, aber nur die Module hab die ich brauch, bringt dann ein statisches einbinden was? Was bringt das überhaupt für nen großen Unterschied.
Wenn ich das nun im Kernel hab, ists dann flotter/langsamer und inwiefern unsicherer?

Idee dahinter:
Elegante RootKit's werden nach einem erfolgreichen Hack in den Kernel geladen, oder der Hacker kompiliert gleich sein Trojanermodul fest in den Kernel und startet den Server neu (hab ich schon erlebt).
In der Praxis gibt es keine absolute Sicherheit, denn oft genutzte Software in der unter anderem von Zeit zu Zeit Sicherheitslöcher auftauchen sind zum Beispiel:
- PHP;
- wuFTP;
- MySQL;
- manchmal auch Apache;
- ganz selten auch mal SSHD;
- diverse LIBs, die von einer Menge Software genutzt werden;

gängige Vorgehensweise:
Um das laden von Kernelmodulen zu verhindern verwendet man am besten einen statischen Kernel, um das compilieren eines verseuchten Kernels zu verhindern, versteckt man den Compiler (oder deinstalliert ihn).

Von der Geschwindigkeit macht das keinen (merklichen) unterschied.

meine persönliche Meinung:
Als Server, Router, Gateway oder Bastion-Host wird kein Windows und kein Linux eingesetzt!!!
Auf der Workstation macht es Sinn Linux zu verwenden (wegen der Multimediafähigkeiten).
Ich verwende (auch wegen schmerzlicher Erfahrungen) im Serverumfeld NUR noch FreeBSD und/oder NetBSD!!!
FreeBSD weil es für i386 das am weitesten entwickelte *BSD ist und NetBSD weil es das am saubersten programmierte und am besten durchdachte OS auf dem freien Markt überhaupt ist.
In Sachen Sicherheit hat *BSD alleine schon die Nase Vorne, weill es in erster Linie (wegen der Sponsoren) für den Servereinsatz entwickelt wird.

kleines Beispiel:
Baut man sich in *BSD einen Kernel, der keine Module (KLM) unterstützt UND schaltet einen SecureLevel grösser "0" ein (ich verwende meist "2"), dann kann unter anderem kein neuer Kernel installiert werden. Das heisst ein Hacker muss den Server (um ihn zu hacken) zwei mal knacken! Das erste mal um ihn ohne SecureLevel neu zu starten und da er den Server noch nicht verseuchen kann, muss er ihn nach dem Neustart nocheinmal hacken. Jeder Admin sollte allerdings beim Reboot seines Servers benachrichtigt werden (per E-Mail, per Monitor oder sonst wie). So das man schon dann vorgewahrnt ist, das hier irgend etwas passiert!
Zudem ist *BSD um einiges stabiler als Linux! Linus Torwals hat selber gesagt, dass es ihm wichtiger ist, ein Linux zu entwickeln das nicht perfekt ist aber eine grosse Funktionalität besitzt... (in meinen Augen gut, aber nur für Workstations brauchbar). Bei FreeBSD und NetBSD gibt es ein Core-Team, das über die Qualität wacht, das geht natürlich oft zu Lasten von Neuentwicklungen die dann erst später einsetzen oder garnicht erfolgen => siehe zum Beispiel Multimediafähigkeiten und Windows-Emu's, die beide nicht so gut wie bei Linux sind.

Nichts destotrotz, hab ich 5 Jahre lang zu Hause NUR FreeBSD eingesetzt (auch für meine Frau, die keine Ahnung hat)! Jetzt bin ich dabei meinen Server von FreeBSD auf NetBSD umzustellen (seit der Version 2.0 ist NetBSD für mich gut genug) und spiele mit dem Gedanken auf dem Rechner meiner Frau Sorcerer-Linux (sorcerer.wox.org) einzusetzen.

 

[NiceDay]

Was weniger Module, somit weniger HW-Unterstützung bietet, ist weniger anfällig, ja doch das macht schon Sinn

 

[quarzsnoopy]

Was weniger Module, somit HW-Unterstützung bietet, ist weniger anfällig, ja doch das macht schon Sinn

Den Kommentar verstehe ich nicht... das eine hat mit dem anderen nichts zu tun!

 

[NiceDay]

Den Kommentar verstehe ich nicht... das eine hat mit dem anderen nichts zu tun!

Sicher hat es was in gewisser Weise miteinander zutuen.
( habe noch nen "weniger" zugefügt, war bißchen schnell gestern beim tippseln )

 

[illtiss]

Ich benutz auch keine Module, was soll das? Meine Hardware ändert sich vielleicht alle halbe Jahre, und da is sowieso wieder ein neuer kernel raus, somit kann ich das geschickt verbinden. Aus Sicherheitsgründen eher weniger. Aber ich weiss doch was in meiner Kiste ist, was soll ich da überlegen was ich eventuell mal wenn überhaupt einbauen werde. Und so lang dauert das Kernelbauen auch nicht.

 

[quarzsnoopy]

Sicher hat es was in gewisser Weise miteinander zutuen.
( habe noch nen "weniger" zugefügt, war bißchen schnell gestern beim tippseln )

...sehe ich anders...

Beispiel:
Wenn man ein schlecht programmiertes System mit schlechter HW-Unterstützung (wenig Treiber und...) einsetzt ist das unsicherer als ein System, das sauber programmiert ist (man macht sich vorher Gedanken und muss dann weniger Fehler suchen) und viel HW unterstützt.
Somit besteht kein direkter Zusammenhang zwischen HW-Unterstützung und Sicherheit. Den Zusammenhang würde es nur geben, wenn man gleiche Programmier-Quallität unterstellt... was ja nicht gegeben ist, und von Linus T. zu gunsten von Funktionalität auch nicht gewollt ist.