Kernelsicherheit (/proc), suid

[andreask2]

Hallo!

Nachdem mein Server jetzt endlich ordentlich läuft, habe ich mir nochmal das Sicherheits-Howto von Gentoo angesehen.

Dort gibt es ein Kapitel "Kernelsicherheit", wo folgende Ã?nderungen für /proc empfohlen werden:

Code: Select all

/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
for i in /proc/sys/net/ipv4/conf/*; do
    /bin/echo "1" > $i/rp_filter
done
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Quelle mit Erläuterungen: http://www.gentoo.org/doc/de/gentoo-sec ... doc_chap10

Was haltet Ihr von sowas, bzw. was setzt Ihr hier ein? Prinzipiell bin ich zwar ein Gegner von so Sachen wie "ping deaktivieren"..., auf der anderen Seite muss man auch sehen, dass es immer mehr Script-Kiddies gibt, die wahllos IP-Ranges von Root-Server Providern scannen, es gibt immer bessere Scanner die direkt immer aktuellere Verwundbarkeiten testen...
Ich sehe das z.B. in meinen Apache-Logs... die wachsen teilweise MB-weise nur durch Versuche Shellcode in einen verwundbaren IIS oder Apache einzuschleusen.

Ich weiß auch dass man sich so nicht verstecken kann, aber IMHO taugt sowas durchaus, um die Anzahl der Angriffs-Versuche zu reduzieren, wodurch das Risiko gecrackt zu werden IMHO sinkt.

Auf der anderen Seite muss man natürlich auch vorsichtig sein, ICMP ist ja ein nützliches und notwendiges Protokoll, daher die Frage, was haltet Ihr von den oben vorgeschlagenen Maßnahmen?

Aber das Ganze bringt ja nichts wenn man es nur für IPv4 macht, aber wie ist das bei IPv6, da gibt es ja nur weniger der obigen Einstellungen, kennt jemand die äquivalenten Einstellungen hierfür?


Der 2. Punkt sind SUID Dateien, die man nach Möglichkeit ja vermeiden sollte.

Code: Select all

# /usr/bin/find / -type f ( -perm -004000 -o -perm -002000 ) -exec ls -lg {} ; 2>/dev/null
-rws--x---  1 apache 13012 Jul  4 01:23 /usr/sbin/suexec
-rwxr-sr-x  1 postdrop 86308 Jul  5 02:29 /usr/sbin/postdrop
-rwxr-sr-x  1 postdrop 76640 Jul  5 02:29 /usr/sbin/postqueue
-r-xr-sr-x  1 man 40432 Apr 13 07:40 /usr/bin/man
-rws--x--x  2 root 1003204 Apr 13 07:56 /usr/bin/sperl5.8.2
-rws--x--x  2 root 1003204 Apr 13 07:56 /usr/bin/suidperl
-rws--x--x  1 root 7892 Jul  3 21:58 /usr/bin/tracepath
-rwsr-xr-x  1 root 36300 Jul  4 00:11 /usr/bin/chage
-rwsr-xr-x  1 root 29528 Jul  4 00:11 /usr/bin/chfn
-rwsr-xr-x  1 root 25668 Jul  4 00:11 /usr/bin/chsh
-rwsr-xr-x  1 root 17100 Jul  4 00:11 /usr/bin/expiry
-rwsr-xr-x  1 root 35120 Jul  4 00:11 /usr/bin/gpasswd
-rwsr-xr-x  1 root 21228 Jul  4 00:11 /usr/bin/newgrp
-rwsr-xr-x  1 root 26540 Jul  4 00:11 /usr/bin/passwd
-rwxr-sr-x  1 slocate 26892 Apr 13 08:23 /usr/bin/slocate
-rwxr-sr-x  1 tty 8924 Apr 13 08:29 /usr/bin/write
-rwsr-xr-x  1 root 12356 Jul  2 22:34 /usr/bin/netselect
-rwsr-x---  1 cron 23508 Jul  3 00:14 /usr/bin/crontab
-rws--x--x  1 root 6168 Jul  3 21:47 /usr/lib/misc/pt_chown
-rws--x--x  1 root 138788 Jul  3 01:23 /usr/lib/misc/ssh-keysign
-r-s--x--x  1 root 6944 Apr 13 08:22 /sbin/pam_timestamp_check
-r-sr-xr-x  1 root 16376 Apr 13 08:22 /sbin/unix_chkpwd
-rws--x--x  1 root 30060 Jul  3 21:58 /bin/ping
-rwsr-xr-x  1 root 21924 Jul  4 00:11 /bin/su
-rws--x--x  1 root 74152 Apr 13 08:29 /bin/mount
-rws--x--x  1 root 34124 Apr 13 08:29 /bin/umount

Bei folgenden würde ich das bit entfernen:

Code: Select all

ping
mount
umount
chfn
chsh
newgrp
suidperl
sperl5.8.2
pt_chown
tracepath

Wie ist das bei den Ã?brigen, da bin ich mir nicht so sicher, sind da noch welche bei wo man das bit entfernen sollte?


Viele Grüße
Andreas

[captaincrunch]

Was haltet Ihr von sowas, bzw. was setzt Ihr hier ein? Prinzipiell bin ich zwar ein Gegner von so Sachen wie "ping deaktivieren"

Bis auf's icmp_echo_ignore_all machen diese Settings durchaus Sinn, denn ICMP-Broadcasts können einem besonders im Falle von Rootservern herzlich egal sein.
Beim source routing wäre ich im Falle von 1&1 aufgrund der "Besonderheiten" des Routings eher vorsichtig, im Normalfall ist diese Maßnahme aber eigentlich immer ein weiterer Schutz gegen Angreifer, die anders als Scriptkiddies tiefere Einsichten ins Netzwerk haben.

auf der anderen Seite muss man auch sehen, dass es immer mehr Script-Kiddies gibt, die wahllos IP-Ranges von Root-Server Providern scannen, es gibt immer bessere Scanner die direkt immer aktuellere Verwundbarkeiten testen...

...wozu sie aber auch erst gar kein "ping" bräuchten. ;)
ICMP komplett sperren halte ich für eher kontraproduktiv, denn das Protokoll gibt's nicht einfach so, es erfüllt elementare Dienste im Netzwerk.
Wenn man das ganze wirklich so weit treiben möchte, ließe sich aber z.B. per iptables ICMP auf bestimmte Requests/Replys (z.B. Host unreachables nur direkt vom davorstehenden Router, usw.) beschränken.
Mit Scriptkiddies, die ihre Tools auf komplette Subnetze loslassen hat das jedenfalls herzlich wenig zu tun.

Was die suid-Bits angeht:
- ping: Hast du lokale User != root, die unbedingt pingen müssten? Wenn du z.B. Nagios o.ä. laufen hast, schießt du dir damit selbst ins Bein, da normale User nun einmal keine Raw-Sockets öffnen dürfen.
- mount/umount: Wozu sollten lokale User auf einem Webserver überhaupt mounten dürfen?
- chfn/chsh: Wenn deine lokalen User unbedingt ihre Shell oder ihre Informationen aus /etc/passwd ändern sollen, solltest du das suid-Bit drinlassen, andernfalls kannst du es wohl getrost rausnehmen.
- newgrp: IMHO auch safe, das Bit zu entfernen
- suidperl: Ist suidperl nicht genau zu diesen Zweck gedacht? ;)
- pt_chown: Sagt mir spontan nichts
- tracepath: Siehe ping.

[andreask2]

Bis auf's icmp_echo_ignore_all machen diese Settings durchaus Sinn,

hm, irgentlich schon, ich dachte nur dass sehr viele Scanner(per default) erstmal nur pingen(natülich geht das auch anders), und da es inzwischen derart viele potentiell schlecht gewartete Root-Server gibt, bin ich der Ã?berzeugung dass die meisten daran nichst ändern, da sie auch so genügend "Spielplätze" finden. Wie gesagt, ich betrachte es einfach als "Reduzierung potentieller Angreifer".

denn ICMP-Broadcasts können einem besonders im Falle von Rootservern herzlich egal sein.

jepp.

Beim source routing wäre ich im Falle von 1&1 aufgrund der "Besonderheiten" des Routings eher vorsichtig, im Normalfall ist diese Maßnahme aber eigentlich immer ein weiterer Schutz gegen Angreifer, die anders als Scriptkiddies tiefere Einsichten ins Netzwerk haben.

Naja, selbst wenn so ein Script-Kiddie schon auf dem Nachbarsever eingezogen ist ;-), soweit ich weiß bringt das nichts, weil AFAIK jeder Root-Server doch in einem eigenen Netzwerk mit 32-er Netzmaske "lebt", oder?

...wozu sie aber auch erst gar kein "ping" bräuchten. ;)

Ja, aber es gibt genügend die das eben doch verwenden, oder?

ICMP komplett sperren halte ich für eher kontraproduktiv, denn das Protokoll gibt's nicht einfach so, es erfüllt elementare Dienste im Netzwerk.

Ja, aber echo ist ja nicht so elemetar...

Wenn man das ganze wirklich so weit treiben möchte, ließe sich aber z.B. per iptables ICMP auf bestimmte Requests/Replys (z.B. Host unreachables nur direkt vom davorstehenden Router, usw.) beschränken.
Mit Scriptkiddies, die ihre Tools auf komplette Subnetze loslassen hat das jedenfalls herzlich wenig zu tun.

Hm, meinst Du? Naja. Wahrscheinlich würde man wohl ein paar tiefere Script-Kiddie Scans verhindern, aber vermutlich die gefährlicheren von denen nicht.

Aber diese Konfiguration hälst Du auch für sinnvoll, ja?

Code: Select all

/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
for i in /proc/sys/net/ipv4/conf/*; do
    /bin/echo "1" > $i/rp_filter
done
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Und was meinst Du zu IPv6? s bringt ja herzlich wenig wenn man sich nur um IPv4 kümmert, aber dem Angreifer dieselben Infos dafür auf einem anderen Protokoll serviert. Welche Einstllungen hälst Du bei IPv6 für angemessen bei einem Root-Server?

Was die suid-Bits angeht:
- ping: Hast du lokale User != root, die unbedingt pingen müssten? Wenn du z.B. Nagios o.ä. laufen hast, schießt du dir damit selbst ins Bein, da normale User nun einmal keine Raw-Sockets öffnen dürfen.

Nö, verwende ich nicht, ich hab auf dem Server nur Apache, mod_php, mod_ssl, mod_gzip mit PostgreSQL/MySQL, grsec-sourcen, und ein paar Kleinigkeiten wie Webalizer und Cacti/snmp. Lokal kommen nur User auf den Server denen ich vertraue, sind auch nur 3 Leute. Und hier verhindert grsec schon so einige Sachen, seit ich grsec verwende brauche ich eigentlich öfter root als vorher. Aber auf so einem Server IMHO auch normal.

- mount/umount: Wozu sollten lokale User auf einem Webserver überhaupt mounten dürfen?

gar nicht.

- chfn/chsh: Wenn deine lokalen User unbedingt ihre Shell oder ihre Informationen aus /etc/passwd ändern sollen, solltest du das suid-Bit drinlassen, andernfalls kannst du es wohl getrost rausnehmen.

muss nicht sein

- newgrp: IMHO auch safe, das Bit zu entfernen

jepp

- suidperl: Ist suidperl nicht genau zu diesen Zweck gedacht? ;)

liegt nahe ;-)
Aber ich brauche es nicht. Also kann es nichts schaden das zu deaktivieren.

- pt_chown: Sagt mir spontan nichts

Code: Select all

 # /usr/lib/misc/pt_chown --help
Usage: pt_chown [OPTION...]
Set the owner, group and access permission of the slave pseudo terminal
corresponding to the master pseudo terminal passed on file descriptor `3'.
This is the helper program for the `grantpt' function.  It is not intended to
be run directly from the command line.

Ich denke dass kann auch weg.

- tracepath: Siehe ping.

jepp

Das waren allerdings die wo ich mir mehr oder weniger sicher war, sieht jemand in der Liste(find) oben noch spontan ein binary welches ich ohne Bedenken deaktivieren könnte?


Vielen Dank und viele Grüße
Andreas

[captaincrunch]

hm, irgentlich schon, ich dachte nur dass sehr viele Scanner(per default) erstmal nur pingen(natülich geht das auch anders), und da es inzwischen derart viele potentiell schlecht gewartete Root-Server gibt, bin ich der Ã?berzeugung dass die meisten daran nichst ändern, da sie auch so genügend "Spielplätze" finden.

Sorry, aber ist es doch arg überzogen, essentielles Netzmanagement aus "Panik" vor irgendeinem Scriptkiddietool kaputtzumachen. Da überlege ich mir lieber, wie ich meine Kiste an den geeigneten Stelen sicher bekomme, ohne mich vollkommen sinnlos "verstecken" zu wollen.

Naja, selbst wenn so ein Script-Kiddie schon auf dem Nachbarsever eingezogen ist , soweit ich weiß bringt das nichts, weil AFAIK jeder Root-Server doch in einem eigenen Netzwerk mit 32-er Netzmaske "lebt", oder?

Sofern du deine Netzwerksetting per DHCP beziehst ist das so. Im Falle der meisten Debian-Rooties, die mit dem Installer übergebügelt wurden ist dem jedenfalls nicht so. Selbst wenn's sich um die /32er-Maske handelt, macht es durchaus Sinn, ICMP-Broadcasts nicht noch hochzuschaukeln. Was das Source-Routing angeht, schätze ich die Gefahr jedenfalls als verschwindend gering ein...jedenfalls sind mir keine Scriptkiddie-"Tuts" bekannt, die einem die "Vorzüge" des Source-Routing erklären. ;)
Trotzdem kann auch das Sinn machen, mich würde allerdings wirklich einmal interessieren, ob die Router vor dem Rootie dann nicht gleich loskotzen. AFAIR läuft's in den "alten" Subnetzen nämlich noch per ICMP-Redirects, aber ich mag mich irren. Daher wäre ich in dem Punkt doch eher vorsichtig, und würd's noch nicht rebootfest eintragen. ;)
Wenn du's also mal probierst wäre ich über Rückmeldung dankbar.

Ja, aber es gibt genügend die das eben doch verwenden, oder?

Es kommt ganz darauf an, von welchen "t00lz" wir hier reden. Wenn's sich um ein echt 13373s Kiddie handelt, wird's vermutlich sogar schon die nmap-Option "-P0" kennen, wohingegen andere Tools, die z.B. nach Lücken im Apachen suchen in den meisten Fällen erst gar keinen Ping vorher machen, sondern stumpf das Subnetz abgrasen.
Wie auch immer: ohne ICMP machst du die Kiste auch nicht wirklich sicherer, sondern nur das Netz kaputt. ;)

[zitat:]
Wenn man das ganze wirklich so weit treiben möchte, ließe sich aber z.B. per iptables ICMP auf bestimmte Requests/Replys (z.B. Host unreachables nur direkt vom davorstehenden Router, usw.) beschränken.
Mit Scriptkiddies, die ihre Tools auf komplette Subnetze loslassen hat das jedenfalls herzlich wenig zu tun.[/zitat]

Hm, meinst Du? Naja. Wahrscheinlich würde man wohl ein paar tiefere Script-Kiddie Scans verhindern, aber vermutlich die gefährlicheren von denen nicht.

Wenn du's "richtig" anstellst, grenzt du alles bis auf Request, Reply und Port unreachable für "externe" ab, und erlaubst gewisse "Feinheiten" wie ICMP-Redirects ausschließlich vom Router (bzw. beiden) deines Subnetzes. dodolin hat da AFAIR mal eine recht nette Diskussion hier gepostet, wo ziemlich genau gesagt wurde, wie man ICMP so dicht wie möglich bekommt, ohne es gleich nutzlos zu machen; leider finde ich den Link nicht mehr.
Auch das hat aber mit (Port-) Scans herzlich wenig zu tun, sondern dient dazu, Angreifern, die über gewisses Netzwerkwissen verfügen das Leben schwerer zu machen.

Bis auf die ICMP-Redirects (s.o.) wäre die Konfiguration IMHO so erstmal OK.

Und was meinst Du zu IPv6? s bringt ja herzlich wenig wenn man sich nur um IPv4 kümmert, aber dem Angreifer dieselben Infos dafür auf einem anderen Protokoll serviert. Welche Einstllungen hälst Du bei IPv6 für angemessen bei einem Root-Server?

Genau das ist der Grund, warum ich v6 ausschließlich dann aktiviere, wenn ich's gerade mal brauche (was ohnehin so gut wie nie der Fall ist ;) ). Brauchst du IPv6? Falls nicht: deaktivier das ganze erstmal, und lies dich erstmal ein...viel mehr kann ich dir dazu leider auch momentan nicht sagen, weil ich das auch schon seit längerem mache (sofern es meine Zeit erlaubt ;) ).

Zurück zum suid:
OK, bei ping kannst du suid dann also recht gefahrlos entfernen. Kleine Anekdote dazu am Rande:
Unter Adamantix wurde versucht, ping den Usern auch ohne suid-Bit mit Hilfe von RSBAC zur Verfügung zu stellen. Das ganze klappte auch erstmal ganz gut, allerdings war dadurch eine dickere Sicherheitslücke entstanden:
Bei Binaries mit suid-Bit ist der LD_LIBRARY_PATH fest definiert, ohne hingegen nicht, was dazu führte, dass man in dieser Konfiguration nach erzenslust hätte DOSsen können, wenn man nur eine passende Library vor dem Aufruf von ping geladen hätte. ;)

So weit ersmal dazu.

[andreask2]

So, ich passe jetzt meine /etc/sysctl.conf wie folgt an:

Code: Select all

### /etc/sysctl.conf

#net.ipv4.icmp_echo_ignore_all = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
#net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.ip_forward = 0

mit *.rp_filter gibt es aber keine Probleme bei 1und1, oder?

Naja, zum Thema IPv6, da muss ich sagen dass ich mich damit noch nicht so 100%ig auskenne, soweit ich weiß gibt es dort ja zusätzliche header, die unter anderem IP-Spoofing verhindern, wo dann so Sachen wie "rp_filter" halt nicht mehr benötigt werden. kennt da jemand ne gute Resurce, was man vergleichbares zu der IPv4 config oben für IPv6 einstellen sollte?

Grüße
Andreas

[Joe User]

- pt_chown: Sagt mir spontan nichts

Gehört zur glibc und wird beim Kompilieren benötigt. Ich würde es daher SUID lassen...

[captaincrunch]

net.ipv4.conf.all.accept_redirects = 0

Wäre ich (wie oben bereits gesagt) erstmal vorsichtig mit.

mit *.rp_filter gibt es aber keine Probleme bei 1und1, oder?

Nö, da das rein die lokale Kiste betrifft. ;)

[andreask2]

Ja, Du hast Recht, ich hatte IPv6 halt drin weil ich Deine Config so wenig wie möglich verändern wollte, ich hatte ja ganz andere Probleme ;-)

Naja, dumerweise sind jetzt enige Pakete mit IPv6 Unterstützung kompiliert worden, hm, werde wohl mal "-ipv6" in meine use-flags aufnehmen. Jedenfalls stehen in den Logfiles auch IPv6 Adressen ;-)

Danke Dir für die Infos!

Viele Grüße
Andreas

[andreask2]

mit *.rp_filter gibt es aber keine Probleme bei 1und1, oder?

Nö, da das rein die lokale Kiste betrifft. ;)

Ja, aber das könnte ja Probleme bei asymetrischem Routing machen, aber das mache ich ja nicht...

[andreask2]

Sofern du deine Netzwerksetting per DHCP beziehst ist das so. Im Falle der meisten Debian-Rooties, die mit dem Installer übergebügelt wurden ist dem jedenfalls nicht so.

weswegen eigentlich? DHCP wäre doch einfacher?!

Selbst wenn's sich um die /32er-Maske handelt, macht es durchaus Sinn, ICMP-Broadcasts nicht noch hochzuschaukeln. Was das Source-Routing angeht, schätze ich die Gefahr jedenfalls als verschwindend gering ein...jedenfalls sind mir keine Scriptkiddie-"Tuts" bekannt, die einem die "Vorzüge" des Source-Routing erklären. ;)
Trotzdem kann auch das Sinn machen, mich würde allerdings wirklich einmal interessieren, ob die Router vor dem Rootie dann nicht gleich loskotzen. AFAIR läuft's in den "alten" Subnetzen nämlich noch per ICMP-Redirects, aber ich mag mich irren. Daher wäre ich in dem Punkt doch eher vorsichtig, und würd's noch nicht rebootfest eintragen. ;)
Wenn du's also mal probierst wäre ich über Rückmeldung dankbar.

Code: Select all

# cat /proc/sys/net/ipv4/conf/all/accept_source_route
0
# cat /proc/sys/net/ipv4/conf/all/accept_redirects
0

Nun, ich weiß nicht was ich da jetzt groß testen soll, hab mich nochmal neu per SSH eingeloggt, mal mit lynx den aktuellen gentoo-newsletter gelesen ;-), mal per HTTP ne neue Verbindung hergestellt... ein Fehler hätte doch sofort auftreten müssen, oder kann das auch erst später passieren?

Ich hab jetzt außer icmp_echo_ignore_all alles umgestellt. Bisher ohne Probleme.

Ach ja, und ich habe wie gesagt einen (einigermaßen) älteren rootie (>12 Monate, Celeron 1200)

[andreask2]

hab die obigen Einstellungen jetzt seit einem Tag ohne Probleme im Einsatz, und habe vor 15 Stunden die sysctl.conf wie folgt angepasste und neu gebootet:

Code: Select all

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.ip_forward = 0

Es scheint keine Probleme zu geben.

Vielen Dank nochmal!

Grüße
Andreas

[andreask2]

Naja, selbst wenn so ein Script-Kiddie schon auf dem Nachbarsever eingezogen ist , soweit ich weiß bringt das nichts, weil AFAIK jeder Root-Server doch in einem eigenen Netzwerk mit 32-er Netzmaske "lebt", oder?

Sofern du deine Netzwerksetting per DHCP beziehst ist das so. Im Falle der meisten Debian-Rooties, die mit dem Installer übergebügelt wurden ist dem jedenfalls nicht so. Selbst wenn's sich um die /32er-Maske handelt, macht es durchaus Sinn, ICMP-Broadcasts nicht noch hochzuschaukeln.

Eine Frage dazu: Wenn ich ein 32er Netzmaske verwende, gibt es doch so oder so keine Probleme, oder? Ob jetzt die Einstellungen per DHCP bezogen werden, oder genau so manuell konfiguriert werden, dürfte doch keinen Unterschied machen, oder?

Warum sollte man eine andere Netzmaske wählen? Und welche?

Grüße
Andreas

[captaincrunch]

Eine Frage dazu: Wenn ich ein 32er Netzmaske verwende, gibt es doch so oder so keine Probleme, oder?

Nö, genauso wenig Probleme, wie eine /24er-Maske mit passendem Routing macht. ;)

Mal ernsthaft: 2&4 setzt dieses perverse Routing mit den /32-er Masken einzig und allein aus dem Grunde ein, um sämtlichen Traffic (also auch den für's eigene Subnetz) des jeweiligen Rechners über das zentrale Gateway abfackeln zu können.
Ob du jetzt /24 oder /32 nutzt ist (meiner Erfahrung nach) herzlich egal, funktionieren wird beides.

[dodolin]

Ob du jetzt /24 oder /32 nutzt ist (meiner Erfahrung nach) herzlich egal, funktionieren wird beides.

Nuja, wenn man Rechner im selben /24 Subnet erreichen will, könnte es dann aber durchaus Probleme geben...

[captaincrunch]

Sorry, ich hatte mich nicht 100%ig genau augedrückt...ich hab halt die olle FAQ ( http://www.rootforum.org/faq/index.php? ... 08&lang=de ) immer irgendwie automatisch im Hinterkopf. ;)

[oxygen]

Mal ernsthaft: 2&4 setzt dieses perverse Routing mit den /32-er Masken einzig und allein aus dem Grunde ein, um sämtlichen Traffic (also auch den für's eigene Subnetz) des jeweiligen Rechners über das zentrale Gateway abfackeln zu können.
Ob du jetzt /24 oder /32 nutzt ist (meiner Erfahrung nach) herzlich egal, funktionieren wird beides.

So pervers find ich das gar nicht. bei jedem Dailin Rechner isses genauso.

[captaincrunch]

So pervers find ich das gar nicht. bei jedem Dailin Rechner isses genauso.

Du möchtest jetzt nicht wirklich Elefanten- mit Mückensch... vergleichen, oder? ;)

Es ist und bleibt pervers, bei den neueren Kisten mit dem 10.0.0-er Default-Gateway umso mehr.