system- und dienste-identifikation verhindern

Schönen Guten Abend,

ich suche erstens eine Möglichkeit, die Identifikation meines Systems Debian durch tools wie nmap und co zu erschweren/unmöglich zu machen bzw. ein anderes System vorzutäuschen (z.b. winxp). Und zweitens möchte ich die Serverdienste auf dem System ein wenig mundtot machen - > bei einem telnet auf z.b. ein ssh- oder apachedienst sollen sie sich nicht eindeutig zu identifizieren geben. stelle ich mir ganz praktisch vor, wenn ich dann auch noch den port ändere, nur wo finde ich einstellungen dies zu ändern? in den configs der einzelnen programme unter etc hab ich dazu nichts brauchbares gefunden, und wo sonst suchen ... *ratlos*.

ist es überhaupt sinvoll ein anderes system vorzutäuschen, oder ist es eigentlich nur spielerei, die eigentlich ehe nichts bringt?
 
grundsätzlich halte ich das für spielerei.
ausserdem ist das von software zu software vollkommen verschieden. ssh zb. braucht einen eingriff in den source code, beim apache hilft dir das hier weiter:
http://www.petefreitag.com/item/419.cfm

um das betriebsystem beim nmap scan zu unterdrücken brauchts einen eingriff in /proc/sys, aber frag mich nicht wo. mal abwarten, vielleicht weiss jemand anderes da etwas konkretes.
 
nuja, angenommen, jemand will dich angreifen und weis aber nicht was du fürn apache nutzt, wird er sicherlich versuchen einfach möglichst viele angriffe zu starten, sprich alle exploits mal durchprobieren.
vondaher ist das halt nen unterschied von 5 minuten, den du dir damit erkämpfen kannst, wenn dein system denn angreifbar ist.

ich glaube nicht, dass es wirklich hilfreich ist, nur nen tropfen auf nen heissen stein!
 
David Barroso Berrueta - A practical approach for defeating Nmap OS-Fingerprinting

Das dürfte das Wichtigste zum Verstecken von System-Fingerprints erläutern.

Was nicht in diesem Dokument zur Sprache kommt, ist das von xeno angesprochene Manipulieren von proc-Einstellungen. Die zu manipulierende Proc-Datei wäre /proc/sys/net/ipv4/ip_default_ttl. Man ändert also die Default-TTL. Standardmässig bei Linux steht sie auf 64. Jeder andere Wert bringt nmap ordentlich durcheinander.

Beispiel:
Code:
root@admin-laptop:/home/bitmuncher# echo 64 > /proc/sys/net/ipv4/ip_default_ttl
root@admin-laptop:/home/bitmuncher# nmap -O localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-06-22 22:13 CEST
...
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.17 - 2.6.18
...
root@admin-laptop:/home/bitmuncher# echo 61 > /proc/sys/net/ipv4/ip_default_ttl
root@admin-laptop:/home/bitmuncher# nmap -O localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-06-22 22:14 CEST
...
No exact OS matches for host (If you know what OS is running on it, see http://insecure.org/nmap/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=4.53%D=6/22%OT=22%CT=1%CU=44736%PV=N%DS=0%G=Y%TM=485EB303%P=i686-
OS:pc-linux-gnu)SEQ(SP=C0%GCD=1%ISR=C6%TI=Z%II=I%TS=8)SEQ(SP=C0%GCD=3%ISR=C
OS:6%TI=Z%II=I%TS=8)OPS(O1=M400CST11NW7%O2=M400CST11NW7%O3=M400CNNT11NW7%O4
OS:=M400CST11NW7%O5=M400CST11NW7%O6=M400CST11)WIN(W1=8000%W2=8000%W3=8000%W
OS:4=8000%W5=8000%W6=8000)ECN(R=Y%DF=Y%T=3D%W=8018%O=M400CNNSNW7%CC=N%Q=)T1
OS:(R=Y%DF=Y%T=3D%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=3D%W=8000%S=O%
OS:A=S+%F=AS%O=M400CST11NW7%RD=0%Q=)T4(R=Y%DF=Y%T=3D%W=0%S=A%A=Z%F=R%O=%RD=
OS:0%Q=)T5(R=Y%DF=Y%T=3D%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=3D%W=0%
OS:S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=3D%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(
OS:R=Y%DF=N%T=3D%TOS=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUL=G%RUD=
OS:G)IE(R=Y%DFI=N%T=3D%TOSI=S%CD=S%SI=S%DLI=S)

...


Aber selbst ein verlangsamen von Scans indem man alle eingehenden und unerwünschten Pakete drop't anstatt zu reject'en, dürfte effektiver sein. Wer will schon eine halbe Stunde auf das Ergebnis eines TCP-Scans warten? ;)

Zu den Diensten wurde ja schon genug gesagt. Es kommt halt auf die Software an.
 
vielen dank für die hilfreichen antworten, also unter proc finde ich die nützlichen einstellungen :D
schade nur, das diese werte unter proc auf meinem vserver im inet nicht veränderbar sind, aber das liegt wohl am hoster ...

Original von bitmuncher
...
Aber selbst ein verlangsamen von Scans indem man alle eingehenden und unerwünschten Pakete drop't anstatt zu reject'en, dürfte effektiver sein. Wer will schon eine halbe Stunde auf das Ergebnis eines TCP-Scans warten? ;)
...

ich glaube so werd ichs machen (und mich demnächst ein ganzes stück mehr mit iptables beschäftigen). danke
 
Zurück
Oben