Apache version verstecken

[crash-x]

HiHo
Ich möchte bei meinem Apache 1.3. die Version verstecken so wie bei prodtpd mit

Code: Alles auswählen

ServerIdent             on      "FTP Server ready"

Und das selbe auch bei openssh.

muss ja nicht jeder alles über meinen PC wissen wer also weiß wie ich das hinbekomme, bite sagen!

Danke schön!

[pdreker]

http://httpd.apache.org/docs/mod/core.html#servertokens

Ganz weg bekommst Du das nicht, Du kannst es aber reduzieren, was er da ausgibt.

Patrick

[crash-x]

Hey danke!
Ich ahb das gesucht und gesucht, aber nix gefudnen
SAg kennt einer von euch auch noch sowas für openssh ?

[abi]

Hey danke!
Ich ahb das gesucht und gesucht, aber nix gefudnen
SAg kennt einer von euch auch noch sowas für openssh ?

wie war das mit /bin/bash in /bin/irgendwas umbenennen

[pdreker]

Naja, also das ist ja eine ganz nette übung, aber der Sicherheitsgewin daraus ist gleich Null. Damit bringst Du höchstens vollautomatische Skripte zum Husten, aber nichts oder niemanden sonst.

Wenn ein SSH (oder irgendwas anderes) keine Identifikation liefert, nimmt man halt zuverlässigere Methoden... Ein Beispiel:
ProFTPd: Deine FTP Server sagt nur "Hallo ich bin ein FTP Server". Also werfe zuerst nmap an, um Dein Betriebssystem herauszufinden. Aha Linux oder auf jeden Fall irgendein UNIX. Damit gibt es noch 3 wesentliche Varianten: wu-ftpd, proftpd oder Berkeley FTPd. Man schickt dann einfach 'mal ein paar Kommandos an den Server, und am Verhalten kann man relativ leicht herausfinden, welcher das ist. Selbst wenn ich jetzt die Versionsnummer nicht weiss, versuche ich einfach alle mir bekannten Attacken gegen den Server zu fahren, irgendeine funktioniert schon.

Bei SSH gibt es von vornherein nur 3 Varianten (OpenSSH, SSH und lssh), die ebenfalls simpel zu unterscheiden sind. Apache ist Apache usw...

Du wärst besser beraten, die Services allgemein sicher zu konfigurieren, IP basierte Zugriffskontrollen einzurichten, und eine Firewall zu errichten.

Patrick

[crash-x]

Nö mein OS bwekommen die nich ruas, ich hab iptables.
HrHr das seh ich schon an den apache logs:

Code: Alles auswählen

217.229.22.210 - - [02/Nov/2002:01:20:00 +0100] "GET 

so ist meine ganze Log vollgemüllt...
hrhr kann man eine Fehlerseite für einen bestimmten path setzen, also z.b. für /scripts/..%252f../winnt/system32/cmd.exe?/c+dir ?
ok egal, trotzdem möcht ich das nicht jeder alles über meinen PC weiß, destoweniger einer was über mich weiß desto besser

wie war das mit /bin/bash in /bin/irgendwas umbenennen

Das war so: Mail ne kleine PC wie man seinen pc vielleicht absichern könnt: Man nennt die ganzen shells um also z.b. von /bin/bash in /bin/tada oder so, und wenn ein exploit versucht die /bin/bash auszuführen klappt das dann ja nich ... Ok idee klingt erst scheiße, da man nachgucken kann welche shell benutzt wir in /etc/passwd, aber ich hab mir da nochn paar sachen mehr überlegt, werde das auch testen und wenns funzt sag ich bescheid

[pdreker]

(IP Adressen unkenntlich gemacht...)

False:~$ nmap -O -p 1-200 pD9E5xxxx.dip.t-dialin.net

Starting nmap V. 3.00 ( http://www.insecure.org/nmap/ )
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on pD9E5xxxx.dip.t-dialin.net (217.229.xxx.xx):
(The 198 ports scanned but not shown below are in state: filtered)
Port State Service
21/tcp open ftp
80/tcp open http
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 1.114 days (since Fri Nov 1 23:47:14 2002)

Nmap run completed -- 1 IP address (1 host up) scanned in 123 seconds

Der FTP erlaubt anonymous Logins, ein Directory Listing zeigt UIDs und GIDs ab 1000 aufwärts. Mit folgender Tabelle schliesse ich alle anderen Distris mit hoher Wahrscheinlichkeit aus::
Caldera LTP: 1st user:grp = 500:100
Suse 7.0: 1st user:grp = 500:100
RedHat 7: 1st user:grp = 500:500
EasyLinux 2.2: 1st user:grp = 1000:100
Debian: 1st user:group = 1000:1000

Debian hat 3 Distris aktuell raus (stable, testing, unstable), das ergibt für Apache und proftpd was bei Dir läuft diese Versionen:
apache: 1.3.26 (woody) oder 2.0.43 (unstable/testing)
proftpd: 1.2.6 (unstable/testing) oder 1.2.4 mit security backports von 1.2.5 (woody)

Das ist doch schonmal ein Ansatzpunkt... Kernelversion wäre jetzt noch interessant. Nmap sagt 2.4, die Debian Standardkernel in dem Bereich sind 2.4.18(bf2.4). Jetzt kann man nmap richtig zum Einsatz bringen und einmal alles scannen was prickelnd sein kann. Ergebnis (ausser dem von oben): Port 2000 (wahrscheinlich zu einer WS geforwardet, da der Port scheinbar nicht gefiltert wird, aber trotzdem nicht reagiert) und Port 6667 sind noch interessant. Bei 6667 läuft ein offener IRC Server, der mir in seinem Banner auch Deinen DynamicDNS Hostname verrät, damit ich meine Jumppads auch immer schon wiederfinden kann...

Genug. Nie zu sicher sein.

Patrick

[crash-x]

Oha..
Aber das mit dem OS spuckt der bei mir eigentlich nie aus. Hmm komisch.
Ok dann sag mal was ich noch machen um nochn bissel sicherer zu sein.

[pdreker]

Die OS Identification bekommst mit dem "-O" Parameter. Funktioniert aber nur dann anständig, wenn man mindestens einen offenen und einen geschlossenen Port findet.

Spar Dir die Arbeit mit den Ident Strings, und die Nummer mit Shell umbenennen kannst Du auch weglassen, das macht mehr Ärger, als es nutzt.

Deine Firewall ist schon sehr gut konfiguriert, das OS Fingerprinting kannst Du nur dadurch umgehen, dass Du ALLES blockst, und selbst dann funktioniert das manchmal. Da kann man nix dran drehen. Der einzige wirklich sichere Computer ist nirgendwo angeschlossen und stackt in einer Betonhülle auf dem Meeresgrund

Du hast ja schon eine schön dichte Firewall, das ist immer der beste Anfang. Ich würde mich jetzt darauf konzentrieren, die Server, die ins Internet sichtbar sind (FTP, WWW, IRC, und dieser Port 2000 bei Dir, falls da ein Server sitzen soll...) "gut" zu konfigurieren. Dazu würden mir folgende Ansatzpunkte einfallen:

Apache: alle unnötigen Module deaktivieren, falls nicht benötigt die CGI Ausführung deaktivieren. Für ganz paranoide: WebSeiten mit Passwörtern versehen.

ProFTPd: Der sah' eigentlich ganz gut aus. Ich habe bei mir anonymous noch deaktiviert, und allen Leuten, denen ich Zugriff einräume ein eigene FTP Login/Pass gegeben. Damit kann man wenigstens nachvollziehen wer wann da war. Wenn Du anonymous behalten willst, dann würde ich kontrollieren, dass der anonyme User wirklich nur Zugriff auf bestimmte Verzeichnisse hat, und nur in ein spezielles Upload Verzeichnis hochladen kann, das er aber selbst nicht lesen kann. Dadurch vermeidet man, dass irgendwelche "M0v1eZ 6r0upZ" deinen FTP als pub missbrauchen. Sie könnten ihren Kram zwar zu Dir hochladen, ihn aber nicht wieder runterladen, ohne dass Du die Datei vorher verschiebst. Anonymous sollte so eingeschränkt wie irgendmöglich sein.

IRCd: Hmm... Damit habe ich selbst noch nicht gearbeitet. Je nachdem, was Du damit machst, würde ich evtl. ein Passwort für den Zugriff setzen, so kann wenigstens nicht jeder da rein. (Als ich gestern nacht getestet habe, konnte ich direkt auf Deinen Server und in einen Channel (in den ich automatisch reingesaugt wurde). Vielleicht könnte es da auch helfen einen Bot in den Channel zu setzen, der einfach nicht jeden reinlässt.)

Patrick

[Frankenstein]

Die Sachen sind klar. Und Wenn man den Angreifer verwieren will, damit er mehr Zeit hat um die ganzen Sachen rauszufinden. Und damit auf Zeit spielt. Das ist nur dann interesan wen man kein dyndns u.ä verwendet, weil die IP sich ständig ändert. Und für die Leute die es Verwnden sollen Verschlüsselte mails schikt mit der Adresse

????????

Und wie kann man die IP-Optionen ändern, damin auch nmap einen anderen Fingerabdruck bekomt, über die OS.

[pdreker]

Wenn Du irgendwie auf Zeit spielen musst, hast Du schon was verkehrt gemacht.

Falls man wirklich diese exterme Paranoia hat, und weder seiner Firewall noch den Konfigurationen in den Programmen richtig traut, dann sollte man die Logs beobachten. Damit meine ich nicht einmal Tag kurz reinschauen, sondern permanent die wichtigsten Logs in einer Konsoile anzeigen lassen.

Es wäre vielleicht 'mal ganz sinnvoll, wenn sich einige Leute 'mal Gedanken über das sog. Threat Profile machen würden, statt ihre Arbeit mit sowas zu verschwenden. 99,9% aller Angriffe auf Dial-Ups sind irgednwelche IIS Würmer. Na super, die können eh' nix anrichten unter Linux. Der grösste Teil des Rests sind verschiedene Script Kiddie Attacken, die per automatischem Skript ausgeführt werden. Also immer schön die Security Patches einspielen, dann sind die auch kein Problem mehr. Das was jetzt noch übrig bliebt sind die sog. High Profile Attacks. Also Angriffe, bei denen sich ein Hacker wirklich Stunden oder Tage hinsetzt, und von Hand die Schwachstellen analysiert und dann selbst einen vielleicht neuen Exploit entwickelt, den sonst noch keiner kennt, und damit dann einbricht.

Jetzt möge mir bitte jemand erklären, warum ein hochbegabter Cracker, seine Zeit darein investieren sollte, mit riesigem Aufwand in ein DialUp System einzubrechen??? Wäre es nicht sinnvoller irgendwo in einen Formenrechner einzusteigen, um dort wirklich interessante Dinge zu klauen oder zu sehen? NIEMAND wird Stunden von Arbeit investieren, um irgendein DialUp (das ja auch jede Sekunde offline gehen kann) von Hand zu cracken, um es dann als DDoS Slave zu benutzen. Dazu braucht man 1000e von Slaves, und das geht nur automatisiert.

Fazit: Halte Deine Firewall dicht, spiele immer sofort alle Security Patches ein, konfiguriere alles so, dass es so dicht wie möglich und so offen wie nötig ist, und fertig. Alles andere ist pure Zeitverschwendung. Wenn man selbst ein High profile Target ist (Firma mit interessanten Betriebsgeheimnissen usw.) dann sollte man sich einen Sicherheitsberater ins Haus holen, der das analysiert und abdichtet.

Patrick (Ende des Thread für mich)

[feltel]

Jetzt möge mir bitte jemand erklären, warum ein hochbegabter Cracker, seine Zeit darein investieren sollte, mit riesigem Aufwand in ein DialUp System einzubrechen???

100% ACK. Ein bischen Paranoia schadet nie, aber man sollte es nicht übertreiben.

[acron]

Jetzt möge mir bitte jemand erklären, warum ein hochbegabter Cracker, seine Zeit darein investieren sollte, mit riesigem Aufwand in ein DialUp System einzubrechen???

ein privates Linux/Unix-System kann schon lohnendes Ziel sein, für einen guten Hacker, um von dort aus eine wirkliche Attacke gegen ein lockenderes Ziel zu führen. Gerade wo in dsl-Zeiten viele Rechner rund um die Uhr online sind. Allerdings hast du sicherlich damit recht, dass der Hacker es nicht tagelang vesuchen wird auf ein recht gut abgesichertes System zu kommen, wo immer noch so viele Systeme offen wie Scheunentore sind...

[pdreker]

Seufz... Ich lass mich doch immer wieder zum posten verführen...

@acron: genau mein Reden. 0-Risiko gibt es nicht. Man kann halt immer irgendwie gelackmeiert werden.

@feltel: eine sogenannte "gepflegte Paranoia" ist OK. Ich bezeichne es lieber als "liebevolle Sorgfalt". Paranoia hat sowas gehtztes an sich. In Ruhe und mit Plan (!!!) kann man im Bereich Sicherheit mehr erreichen.

@all: Man kann Systeme auch noch so konfigurieren, dass ein Einbruch der erfolgreich war in seinen Auswirkungen minimiert wird...

Patrick

[feltel]

@feltel: eine sogenannte "gepflegte Paranoia" ist OK. Ich bezeichne es lieber als "liebevolle Sorgfalt". Paranoia hat sowas gehtztes an sich. In Ruhe und mit Plan (!!!) kann man im Bereich Sicherheit mehr erreichen.

Schon klar, war ja auch mehr Sprichwörtlich gemeint.

[pdreker]

Oops, da wollte ich noch ein paar Smilies streuen
@feltel: Schon klar. Echte Paranoia sind was für den Psychiater, nicht für die Firewall

Patrick

[Frankenstein]

Ich wollete nicht sagen ,dass ich grundsärzlich nur auf Zeit spielen würde.

1. Es gibst Manche Apps die Webbasierend sind. Für Firmeninternes Netz.
2. Es gibts auch Unzufriedene Mitarbeiter, die vielleicht Datendiebstahl betreiben wollen, oder andere Daten Ausspienieren.
3. Wenn man alles So verändert, dass er länger braucht. Und in der selber Zeit die logs analysiert (Dank Logcheck,snort,cron-apt etc.). Kann Schandensbegrenzung betreiben werden und zu dokumentieren damit man einen Angrief später beweisen kann. ( Im schliemsten Fall vor Gericht )
4. Wenn die Firma mit DSL im Internet und dass über langere Zeit ist, denk an VPN. Hat man genug Zeit um viel Information / Analyse des Netzes zu sameln.

5. Und wenn du dieser Firma auch noch deine FW verkauft hast und sich selber nicht genug abgesicht hast. Dann bist du der Schuldege für andere (Weil deine FW nicht sicher genug ist etc..........)

6. Wobei die größeren Firmen eingene Admins hat. Und du der jenige bist und somit deine Arbeit nicht gut genug machst. Hast du deinen Job nicht mehr. Und bei dem nächsten Bewebunsgespräch auf Frage : " Wieso wurden Sie gekündigt ? " Wielst du dann sagen das due dei Job nicht richtigt gemachst hast ? sihe Punkt 5. Falls du in der Firma dazu zuständig warst.

[pdreker]

Dann erklär mir doch einfach 'mal, wie Du Dich sicher vor einer internen Attacke eines motivierten Saboteurs schützen willst? Genauso, wie vor einer externen Attacke? Richtig: alles absichern, richtig konfigurieren und so dicht wie möglich und so offen wie nötig. Dabei muss man zwingend Kompromisse machen, und diese dokumentieren.

Beispiel
Mitarbeiter, die Daten in eine Datenbank eingeben müssen, haben halt Zugriffsrechte auf diese DB. Wenn Du ihnen die Löschrechte nimmst, so dass sie nur neue Einträge machen können, oder bestehende ändern, hast Du nichts gewonnen, weil sie alles überschreiben können. Nimmst Du ihnen auch noch die Update Rechte, können sie die DB mit sinnlosen Einträgen fluten. Entfernst Du jetzt das Recht neue Einträge zu machen, kannst Du alle nach Hause schicken, weil keiner mehr die DB nutzen kann (ausser nachschlagen). Wenn Du Datenlecks vermeiden willst, musst Du die Leserechte einschränken. Irgendwer muss den Kram aber lesen können, das ist der Sinn einer DB.

Worauf ich hinaus will: Die Nebelkerzen Taktik hilft gegen interne Angreifer so gut wie gar nix, weil die normalerweise anders herausfinden können was abgeht. Solange man nicht aufgefallen ist, verwickelt man den Admin in ein nettes Kantinengespäch über den Server. Warum sollte der auch nicht ein bisschen aus dem Nähkästchen plaudern? Natürlich passt er auf, dass er nichts problematisches raussickern lässt, aber wenn er dem Mitarbeiter sagt, dass letztens das neueste ServicePack eingespielt wurde? Wo soll die Grenze gezogen werden? Admin einmauern, keinem Mitarbeiter irgendwas sagen? Irgendwo müssen die Leute irgendeine Form von Zugriff haben, und dieser Zugriff lässt sich missbrauchen. Genauso, wie sich der Zugriff auf die Portokasse missbrauchen lässt. An irgendeiner Stelle hast Du eine Schnittstelle zu einem User. Diese Schnittstelle sollte man sich sorgfältig ansehen und sich überlegen, was soll der User machen können, was darf er maximal machen und wie kann man diese Rechte durchsetzen, ohne dass die Funktionalität darunter leidet.

Wenn Du alles loggst (was ja default sein sollte), dann hast Du im Notfall auch immer ausreichende Beweismittel für eventuelle juristische Konsequenzen. Dass es natürlich am Besten gar nicht erst soweit kommen sollte ist klar, aber Verschleierungstaktiken helfen da wenig.

Die Security Branche hat da sogar einen Ausdruck für: "Security through Obscurity". Damit ist gemeint, dass man versucht, das eigentliche System komplizierter oder anders wirken zu lassen als es wirklich ist. Das Problem dabei ist, dass wenn die Obscurity (also die "Geheimhaltung") durchbrochen wird, diese Sicherheit vollständig weg ist. Das Wissen über die Funktionsweise des Mechanismus macht den Mechanismus unwirksam. Dem gegenüber steht die "echte" Security. Wenn man weiss, dass ich auf meinem Router ein Firewall habe, und alle Programme mit Zugriffsbeschränkungen versehen habe und ausserdem alles logge, dann hilft Dir das gar nichts, ausser dass Du weisst, das es kompliziert werden könnte. Selbst wenn Du weisst, dass meine FW auf iptables basiert, bringt Dich das nicht viel weiter, es sei denn Du kennst eine Sicherheitslücke in iptables. Wenn das eine allgemein bekannte Lücke ist, kannst Du davon ausgehen, dass der Fehler gepatched ist... Und so weiter...

Ein bekanntes Beispiel für Security through Obscurity ist die sogenannte Cäsar Verschlüsselung. Man nimmt einen leicht konischen Holzstab, wickelt ein Lederband spiralförmig um den Stab, und schreibt die Nachricht der Länge nach zeilenweise auf das aufgwickelte Band. Wenn man das Band jetzt abwickelt hat man nur noch Buchstabensalat. Das Problem: Wenn ich weiss, wie Du den Salat erzeugt hast, kann ich die Nachricht entschlüsseln. Die genaue Form des Stabes ist praktisch unerheblich, weil man die durch ausprobieren schnell herausfinden kann.
Dem gegenüber stehen moderne Crytoverfahren. Als Beispiel diene hier 'mal RC4 (Arcfour). Das ist ein symmetrisches Verschlüsselungsverfahren (der gleiche Schlüssel wird für Ver- und Entschlüsselung benutzt). Wenn man weiss, wie der Algorhythmus funktioniert, hilft einem das nicht bei der Entschlüsselung einer Nachricht. Man muss den Schlüssel besitzen. Wenn der Schlüssel kompromittiert wird, ändert man ihn halt. Das Verfahren bleibt das Gleiche.

Patrick

[abi]

Jetzt möge mir bitte jemand erklären, warum ein hochbegabter Cracker, seine Zeit darein investieren sollte, mit riesigem Aufwand in ein DialUp System einzubrechen???

100% ACK. Ein bischen Paranoia schadet nie, aber man sollte es nicht übertreiben.

200 % ACK

[Frankenstein]

Genau das wollte ich auch sagen, aber nur in wenigen Sätzen. Und alles sollte einen Konzept haben. Das Problem ist doch, dass die wenigen Admins machen. Es sei dem das sind Professionelle Admins. Die den Angreifern ihre Daten unteressan zu machen. Es sei dem man mochte ein paar jahre auf Ergebnisse wareten. Wenn man die Schlüßellängen etc. so hoch wie möglich macht. So das wenn man jemand die Daten klaut, aber die Daten nicht lesen kann. Und Enschlüsselungszeit braucht zut großen Aufwand für Angreifer. Werden die Daten für einen Angreifer uninteresant.

[crash-x]

Ok danke für alle eure antworten, ich werd mal schauen was ich noch absichern kann, und trotzdem find ichs besser wenn nich jeder weiß was ich für dämons laufen hab.
Und der IRCd ist auch nur selten an