Online-Security-Check unter http://seccheck.onsite.ch/
Andreas Meile
Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
zur Verfügung, mit welchem Ihr die Sicherheit Eurer
Firewall/Internet-PC hinsichtlich offener Ports, angriffsgefärdeter
CGI-BIN-Scripts sowie ungesicherte NetBIOS-Laufwerksfreigaben usw.
prüfen könnt.
Soeben ist Version 2.0 neu herausgekommen. Diese Dienstleistung wird
übrigens von uns permanent weiterentwickelt, so dass neue Releases
künftig hier in den Newsgroups jeweils bekanntgegeben werden.
Andreas
--------------------------
Andreas Meile, Abt. Systementwicklung, Tel. direkt: +41 52 260 34 94
onsite solutions ag, Archstrasse 2, CH-8401 Winterthur (Switzerland)
Tel. +41 52 260 34 70 Fax +41 52 214 07 80
e-Mail: in...@onsite.ch WWW: http://www.onsite.ch/
Michael Raab
> Hallo zusammen
>
> Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
> PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
> zur Verfügung
Tolles Teil.
Ok, was hat diese Aussage zu Bedeuten ?
> Beurteilung: Auf Ihrem Web-Server wurden angriffsgefärdete Dateien
> gefunden.
Was für Dateien meint er ? Da sind überwiegend PHP-Scripte zufinden.
Gruß
Michael
--
Homepage temporarily out of order Registered Linux User #228306
Phone/Fax +49 7000 MACBYTE http://counter.li.org
GNU GPG-Key ID 22C51B8D0140F88B ICQ #151172379
++ Webdesign ++ PHP Development ++
Michael Raab
at 28 Feb 2002 08:15:21 -0800 Andreas Meile wrote:
> Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
> PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
> zur Verfügung
Wie schon erwähnt, ist dies ein nützlicher aber ein ungenauer Dienst.
Denn ich habe diesen Check auf meinen Server losgelassen. Die Meldung:
> Beurteilung: Auf Ihrem Web-Server wurden angriffsgefärdete Dateien
> gefunden.
ist wohl nicht ganz richtig. Denn laut Logfile meines Apachen hat die
Routine keine Angeforderte Datei gefunden. Vielleicht sollte diese
Routine die Headerinformationen des Webservers besser auswerten.
Was ich gut finde, das er auch den Mailserver auf ein mögliches Relaying
überprüft.
Ansonsten eine gute Alternative zum Selbsttest auf
<http://www.lfd.niedersachsen.de/>, der seit einer längeren Zeit offline
ist.
Juergen P. Meier
Andreas Meile <andrea...@onsite.ch> wrote:
> Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
> PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
> zur Verfügung, mit welchem Ihr die Sicherheit Eurer
> Firewall/Internet-PC hinsichtlich offener Ports, angriffsgefärdeter
> CGI-BIN-Scripts sowie ungesicherte NetBIOS-Laufwerksfreigaben usw.
> prüfen könnt.
Also schaun wir mal:
| Offene Ports auf Ihrem System
|
| Portnummer: 113 Dienst: ident auth
| Für diesen Dienst existiert keine Beschreibung.
|
| Für diesen Dienst steht zur Zeit kein Test zur Verfügung.
Ihr haettet wenigstens schaun koennen, ob ein gueltiges Ident
fuer die HTTP-verbindung zu eurem Webserver zu erhalten ist...
| Portnummer: 22 Dienst: ssh
| Für diesen Dienst existiert keine Beschreibung.
|
| Für diesen Dienst steht zur Zeit kein Test zur Verfügung.
Aeh, CERT sagt euch was?
hint: http://www.google.com/search?q=ssh+exploit
Ihr haettet wenigstens die Protokollversion abfragen und
mit der Tabelle von CERT vergleichen koennen...
| Statistik zu den Port-Tests
|
| Total gefundene offene Ports: 2
| davon nicht getestet: 2
| davon getestet: 0
|
| Sie haben offene Ports, von denen kein einziger getestet werden
| konnte. Wir können Ihnen deshalb keine Zwischenbeurteilung dazu geben.
Schade.
Dann ist irgendwann mein client auf einen Timeout gelaufen und hat
abgebrochen...
> Soeben ist Version 2.0 neu herausgekommen. Diese Dienstleistung wird
> übrigens von uns permanent weiterentwickelt, so dass neue Releases
> künftig hier in den Newsgroups jeweils bekanntgegeben werden.
Du willst dich schnell unbeliebt machen?
Die de.* Usenet Netiquette sagt dir was? ("Advertising the same
Service")
Juergen
--
_ _ | Juergen P. Meier
/.._ _ _ /_) /|/| . _ | "This World is about
\_/(// (/(`// / . / |(`/(`/ | to be Destroyed."
=======_/======================== | J...@lrz.fh-muenchen.de
Patrick Baer
>
> Ansonsten eine gute Alternative zum Selbsttest auf
> <http://www.lfd.niedersachsen.de/>, der seit einer längeren Zeit offline
> ist.
>
Was ist denn daran bitte gut? Ausser das mir dieser "Sicherheitstest"
sagt ich wäre potentiell gefährdet durch Dateien auf meinem Webserver
die aber nicht existieren? man 404 würde ich sagen. Und gleich nochmal
man wettbewerbsrecht und ähnliches, denn solche Falschaussagen dienen ja
dann wohl eindeutig dem Kundenfang!
LG
--
PB-Systeme IT-Dienstleistungen
email in...@pb-systeme.de
Internet http://www.pb-systeme.de
Michael Raab
at Fri, 01 Mar 2002 13:07:05 +0100 Patrick Baer wrote:
> Michael Raab wrote:
> > Ansonsten eine gute Alternative zum Selbsttest auf
> > <http://www.lfd.niedersachsen.de/>, der seit einer längeren Zeit
> > offline ist.
>
> Was ist denn daran bitte gut? Ausser das mir dieser "Sicherheitstest"
> sagt ich wäre potentiell gefährdet durch Dateien auf meinem Webserver
> die aber nicht existieren? man 404 würde ich sagen.
Volles ACK. Dies habe ich ja auch in meinem vorherigen Posting schon
erwähnt.
> Und gleich nochmal man wettbewerbsrecht und ähnliches, denn solche
> Falschaussagen dienen ja dann wohl eindeutig dem Kundenfang!
Von der Seite habe ich es noch nicht betrachtet. Die Vermutung liegt
aber nahe.
Rene Brinkmann
warum läuft der Portscanner eigentlich weiter, wenn der Test angeblich
beendet wurde?
-- schnipp 1--
http://seccheck.onsite.ch/cgi-bin/seccheck.cgi
http://62.2.207.120/cgi-bin/seccheck.cgi
Ende des Tests. Test beendet am 01.03.2002, 20:29:04 Uhr
-- schnapp 1 --
-- schnipp 2 --
01-03-2002 20:37:12 Kernel.Info venus kernel: Packet log:
input DENY ppp0 PROTO=6 62.2.207.120:3423
80.130.147.193:243 L=60 S=0x00 I=59142 F=0x4000
T=50 SYN (#143)
-- schnapp 2--
Ciao,
René
Michael Raab
at Fri, 1 Mar 2002 20:43:16 +0100 Rene Brinkmann wrote:
> warum läuft der Portscanner eigentlich weiter, wenn der Test angeblich
> beendet wurde?
Dazu hätte ich auch gerne eine Stellungnahme vom Entwickler. Mein
Logfile wurde auch von dem Portscaaner überflutet.
Dominik Ruf
> at Fri, 1 Mar 2002 20:43:16 +0100 Rene Brinkmann wrote:
>> warum läuft der Portscanner eigentlich weiter, wenn der Test angeblich
>> beendet wurde?
> Dazu hätte ich auch gerne eine Stellungnahme vom Entwickler. Mein
> Logfile wurde auch von dem Portscaaner überflutet.
Hm... Ich denke, das dürfte _dein_ Problem sein und nicht seines.
Vielleicht solltest du darüber nachdenken, deine Log-Einträge
irgendwie zu limitieren?
Falls es etwas mit iptables ist, steht dazu sogar was in den HOWTOS.
Geht mit -m limit oder so...
Ist sicher jetzt nicht nur im Hinblick auf diesen Onlinetest anzuraten,
sondern auch grundsätzlich.
Gruss Dominik
Andreas Meile
> > Beurteilung: Auf Ihrem Web-Server wurden angriffsgefärdete Dateien
> > gefunden.
>
> Was für Dateien meint er ? Da sind überwiegend PHP-Scripte zufinden.
Besten Dank für den Feedback. Es handelt sich noch tatsächlich um
einen Bug: Eine der Test-URL enthält ein %0A und löst auf einem
Apache-httpd ein
Closing fd 5
14:59:54 FEHLER -1: Nicht korrekte Statuszeile.
aus. Bisher erwartet das Script entweder ein "403 Forbidden" oder "404
Not Found". Sobald dies nicht kommt, interpretiert dies das Script als
gefärdet.
Dieser Fehler wird selbstverständlich im nächsten Release so rasch als
möglich behoben.
Zugleich ist Feedback aller Art auch zu den übrigen Tests willkommen.
:-) Hätte ich im ursprünglichen Posting erwähnen sollen.
Andreas
Michael Raab
at 1 Mar 2002 20:13:41 GMT Dominik Ruf wrote:
> Michael Raab <mr...@macbyte.info> wrote:
> > at Fri, 1 Mar 2002 20:43:16 +0100 Rene Brinkmann wrote:
> > > warum läuft der Portscanner eigentlich weiter, wenn der Test
> > > angeblich beendet wurde?
>
> > Dazu hätte ich auch gerne eine Stellungnahme vom Entwickler. Mein
> > Logfile wurde auch von dem Portscaaner überflutet.
>
> Hm... Ich denke, das dürfte _dein_ Problem sein und nicht seines.
Das mit dem Logfile das ist meins aber mit Scanning nicht. Den Test habe
ich um 17.23 Uhr gestartet, der in ca. 5 Min. vorbei war. Der Scann
endete aber erst um 19.44 Uhr.
> Vielleicht solltest du darüber nachdenken, deine Log-Einträge
> irgendwie zu limitieren?
Auch wenn das Logging limitiert wird, schaltet das nicht das Scanning
ab.
> Falls es etwas mit iptables ist, steht dazu sogar was in den HOWTOS.
> Geht mit -m limit oder so...
Das macht er eh. Das nützt nur nichts, wenn er immer verschiedene Ports
attackiert.
> Ist sicher jetzt nicht nur im Hinblick auf diesen Onlinetestanzuraten,
> sondern auch grundsätzlich.
Das ist richtig. einige Portscans werden auch schon gar nicht mehr
geloggt.
Andreas Meile
> | Portnummer: 113 Dienst: ident auth
> | Für diesen Dienst existiert keine Beschreibung.
> |
> | Für diesen Dienst steht zur Zeit kein Test zur Verfügung.
>
> Ihr haettet wenigstens schaun koennen, ob ein gueltiges Ident
> fuer die HTTP-verbindung zu eurem Webserver zu erhalten ist...
Danke für den Hinweis. Momentan werden die Ports 21, 23, 25, 53, 69,
79, 80, 110, 111 und 139 unterstützt und getestet. Das ganze System
ist ansonsten jedoch schon voll modular aufgebaut, so dass jederzeit
weitere Ports hineingenommen werden können.
Zu 113 müsste ich mich auch zuerst schlau machen und vor allem
geeignete Tools finden, um batchmässig so etwas zu testen können...
:-)
> | Portnummer: 22 Dienst: ssh
> | Für diesen Dienst existiert keine Beschreibung.
> |
> | Für diesen Dienst steht zur Zeit kein Test zur Verfügung.
>
> Aeh, CERT sagt euch was?
> hint: http://www.google.com/search?q=ssh+exploit
> Ihr haettet wenigstens die Protokollversion abfragen und
> mit der Tabelle von CERT vergleichen koennen...
Danke für den Hinweis. Zu 22: Bisher weiss ich erst von einem Kollege
mit privater Standleitung, dass er SSHv1 wegen einer Sicherheitslücke
deaktivieren musste. Ansonsten ist auch hier die Schwierigkeit, wie
sich ein /usr/local/bin/ssh in geeigneter Form in einen Batch
hineinnehmen lässt, ohne dass sich das ~wwwrun/.ssh/known_hosts mit
der Zeit füllt usw.
> Dann ist irgendwann mein client auf einen Timeout gelaufen und hat
> abgebrochen...
Sollte normalerweise nicht passieren, dafür sendet ein
Vordergrundprozess extra alle 30 Sek. ein "#"-Wartesymbol, um ständig
den Browser im Page-Loading-Status oben zu halten. Ausgenommen sind
natürlich Firewalls, welche die IP-Adresse vom seccheck.onsite.ch
solange auf die Blocked Site Liste setzen => dann bekommt der Client
sinnvollerweise nichts mehr mit...
> Du willst dich schnell unbeliebt machen?
> Die de.* Usenet Netiquette sagt dir was? ("Advertising the same
> Service")
Guter Punkt. War natürlich überhaupt nicht die Absicht... ;-) Es liegt
uns natürlich selber im eigenen Interesse, nicht als unseriöses
Unternehmen abgestempelt zu werden. Deshalb wird das Ganze noch einmal
überdacht. Als Hilfe setze ich hier doch gleich zu einer kleinen
Meinungsumfrage an, wo hoffentlich einige von Euch mitmachen (einfach
antworten und [X] setzen!):
1.) Sollen Release-Änderungen wia Mailinglist oder Newsgroup
verbreitet werden?
[ ] Newsgroup
[ ] Mailinglist
Hinweis: Im Falle einer Mailingliste wird selbstverständlich etwas mit
sauberem "Suscribe"/"Unsuscribe"-Mechanismus und Spamschutz
implementiert. :-)
2.) Falls Newsgroup, wo überall publizieren?
[ ] de.comp.security
[ ] de.comp.security.misc
[ ] de.comp.security.firewall
Andreas
Andreas Meile
> Was ist denn daran bitte gut? Ausser das mir dieser "Sicherheitstest"
> sagt ich wäre potentiell gefährdet durch Dateien auf meinem Webserver
> die aber nicht existieren? man 404 würde ich sagen. Und gleich nochmal
> man wettbewerbsrecht und ähnliches, denn solche Falschaussagen dienen ja
> dann wohl eindeutig dem Kundenfang!
Erst mal danke für den Feedback. Habe das Ganze analysiert: Ein Bug,
der nur bei Apache-Webserver stattfindet, wenn die Test-URL ein %0A
enthält: "wget" liefert dann
Closing fd 5
14:59:54 FEHLER -1: Nicht korrekte Statuszeile.
zurück. Unser aktuelles Script ist derzeit so programmiert, dass es
entweder ein "403 Forbidden" oder "404 Not Found" geben sollte. Wenn
eines von beiden nicht gefunden wird, so wird es als Lücke
klassifiziert.
Um falsche Gerüchte aus dem Weg zu räumen: Kundenfang auf diese Weise
soll überhaupt nicht angestrebt werden, würde ja schlussendlich sogar
unseriös und unglaubwürdig wirken.
In diesem Sinn ist Feedback jederzeit willkommen!
Andreas
Dominik Ruf
> at 1 Mar 2002 20:13:41 GMT Dominik Ruf wrote:
>> Hm... Ich denke, das dürfte _dein_ Problem sein und nicht seines.
> Das mit dem Logfile das ist meins aber mit Scanning nicht. Den Test habe
> ich um 17.23 Uhr gestartet, der in ca. 5 Min. vorbei war. Der Scann
> endete aber erst um 19.44 Uhr.
Ja, das ist wohl wirklich seltsam. Vielleicht DROP'st du alles?
Bei mir ging es nicht so lange, denke ich zumindest...
>> Vielleicht solltest du darüber nachdenken, deine Log-Einträge
>> irgendwie zu limitieren?
> Auch wenn das Logging limitiert wird, schaltet das nicht das Scanning
> ab.
Ja, aber ist das Scanning denn jetzt ein "Problem"?
Ich meine, _du_ hast es doch angeklickt...
>> Falls es etwas mit iptables ist, steht dazu sogar was in den HOWTOS.
>> Geht mit -m limit oder so...
> Das macht er eh. Das nützt nur nichts, wenn er immer verschiedene Ports
> attackiert.
Ähm... also bei mir nützt das schon. Kommt halt auf deine Regeln drauf
an, aber wenn man sich vor Überflutungen der Logs schützen will, dann
geht das schon. Wenn du halt so neugierig bist, und alles einzeln
loggen musst? - Naja, vielleicht fordert das ja deine Policy, wie es
hier so schön heißt...
Gruss Dominik
Rene Brinkmann
* Dominik Ruf <domin...@stud.uni-karlsruhe.de> schrieb:
> > Das mit dem Logfile das ist meins aber mit Scanning nicht.
> > Den Test habe ich um 17.23 Uhr gestartet, der in ca. 5 Min.
> > vorbei war. Der Scann endete aber erst um 19.44 Uhr.
>
> Ja, das ist wohl wirklich seltsam. Vielleicht DROP'st du alles?
> Bei mir ging es nicht so lange, denke ich zumindest...
Selbst wenn. Wie kann die Portscan-Routine melden, es sei quasi alles
i.O. und im Hintergrund dennoch weiterlaufen?
Ciao,
René
Dominik Ruf
> * Dominik Ruf <domin...@stud.uni-karlsruhe.de> schrieb:
>> Ja, das ist wohl wirklich seltsam. Vielleicht DROP'st du alles?
>> Bei mir ging es nicht so lange, denke ich zumindest...
> Selbst wenn. Wie kann die Portscan-Routine melden, es sei quasi alles
> i.O. und im Hintergrund dennoch weiterlaufen?
Naja, diese Dinger sind doch irgendwo eh alle Humbug.
Letztenendes zielt ja auch der OP nur darauf ab, nach dem
Onlinescan ein paar verwirrte Kunden anschließend "gut" beraten
zu können (so deute zumindest ich die Meldungen, die ich erhalte).
Ich verstehe auch nicht genau, warum er meint, mein Mailserver
wäre nur "Stufe 04" sicher, oder so was... *lol*
Ich vertraue da lieber meinen Skripten und meinem Hirn, als
irgendwelchen Online-Tests.
Gruss Dominik
Felix von Leitner
> Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
> PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
> zur Verfügung, mit welchem Ihr die Sicherheit Eurer
> Firewall/Internet-PC hinsichtlich offener Ports, angriffsgefärdeter
> CGI-BIN-Scripts sowie ungesicherte NetBIOS-Laufwerksfreigaben usw.
> prüfen könnt.
Was soll das werden?
Ist das ein Test für Leute, die zu dämlich sind, Nessus runterzuladen?
Solchen Vollidioten gibt euer Dienst ein falsches Gefühl der Sicherheit.
Die sollen das lieber jemanden machen lassen, der sich damit auskennt.
> Soeben ist Version 2.0 neu herausgekommen. Diese Dienstleistung wird
> übrigens von uns permanent weiterentwickelt, so dass neue Releases
> künftig hier in den Newsgroups jeweils bekanntgegeben werden.
Na ganz prima. Genau, worauf wir hier gewartet haben.
Michael Andresen
> Michael Raab <mr...@macbyte.info> wrote:
>> at 1 Mar 2002 20:13:41 GMT Dominik Ruf wrote:
>
>>> Hm... Ich denke, das dürfte _dein_ Problem sein und nicht seines.
>
>> Das mit dem Logfile das ist meins aber mit Scanning nicht. Den Test habe
>> ich um 17.23 Uhr gestartet, der in ca. 5 Min. vorbei war. Der Scann
>> endete aber erst um 19.44 Uhr.
>
> Ja, das ist wohl wirklich seltsam. Vielleicht DROP'st du alles?
> Bei mir ging es nicht so lange, denke ich zumindest...
Bei mir gab es die Ergebnisse um 06:15:38 Uhr, das Scanning war aber erst
um 06:16:50 beendet... Klasse. Das waere doch _die_ Entwicklung; die
Ergebnisse sind schon bekannt, _bevor_ die Routine endet. Vielleicht sollte
man ueberlegen, *diesen* Code in den Linux-Kernel einzubauen; das waere
doch der ultimative Geschwindigkeitsvorteil... etwas voreilig, der Gute?
Oder mit Faehigkeiten ausgestattet, die uns Normalsterblichen einfach
fehlen ;-)
BTW: Bei mir werden tcp-Pakete mit tcp-RST, udp-Pakete mit port-unreachable
abgewiesen (was afaik bei der aktuellen Frage keine Rolle spielt).
Aber mal im Ernst: das schraenkt doch die Aussagekraft des Scanners wohl
etwas ein? Haette da gerne einen Kommentar von Andreas... nach den
Ergebnissen kamen noch 200 Pakete (hatte die Protokolldatei nebenbei
mitlaufen...).
//M
--
Goodbye Douglas!
Whereever you are now, keep your towel and: don't panic.
Michael Raab
at 1 Mar 2002 21:18:24 GMT Dominik Ruf wrote:
> Michael Raab <mr...@macbyte.info> wrote:
> > at 1 Mar 2002 20:13:41 GMT Dominik Ruf wrote:
>
> > > Hm... Ich denke, das dürfte _dein_ Problem sein und nicht seines.
>
> > Das mit dem Logfile das ist meins aber mit Scanning nicht. Den Test
> > habe ich um 17.23 Uhr gestartet, der in ca. 5 Min. vorbei war. Der
> > Scann endete aber erst um 19.44 Uhr.
>
> Ja, das ist wohl wirklich seltsam. Vielleicht DROP'st du alles?
Ja, IPTABLES macht von aussen erst alles dicht und dann schrittweise
wieder auf.
> Bei mir ging es nicht so lange, denke ich zumindest...
Woher willst Du das Wissen, wenn bei Dir nicht alles protokolliert wird
? ;-)
> > > Vielleicht solltest du darüber nachdenken, deine Log-Einträge
> > > irgendwie zu limitieren?
>
> > Auch wenn das Logging limitiert wird, schaltet das nicht das
> > Scanning ab.
>
> Ja, aber ist das Scanning denn jetzt ein "Problem"?
Wenn ich für den Traffic Geld bezahlen müsste, dann schon.
> Ich meine, _du_ hast es doch angeklickt...
Das ist richtig
> > > Falls es etwas mit iptables ist, steht dazu sogar was in den
> > > HOWTOS. Geht mit -m limit oder so...
>
> > Das macht er eh. Das nützt nur nichts, wenn er immer verschiedene
> > Ports attackiert.
>
> Wenn du halt so neugierig bist, und alles einzeln loggen musst?
Im Alltagsbetrieb wird nicht allzuviel geloggt. Z.b. werden die
Trojanerscanns, Sub7 & Co., nicht mehr geloggt. Desweiteren wird auch
Netbios nicht mehr geloggt. Wozu auch, ich habe keine M$ Maschinen hier
stehen.
Joens Peller
schon einiges von Dir gelesen...
---snip
Statistik zu den Port-Tests
Total gefundene offene Ports: 0
davon nicht getestet: 0
davon getestet: 0
Sehr gut: Keine offenen Ports gefunden!
Unser Portscanner musste sich sogar geschlagen geben, was auf eine
grundsätzlich ganz gut konfigurierte Firewall schliessen lässt.
---snip
Jetzt fühle ich mich _absolut_ sicher...:-)
Ist ja auch keine Kunst hinter einem HW-Router ohne Webserver oder FTP...:-)
Gruß
Jöns
Patrick Baer
>
>
> Erst mal danke für den Feedback. Habe das Ganze analysiert: Ein Bug,
> der nur bei Apache-Webserver stattfindet, wenn die Test-URL ein %0A
> enthält: "wget" liefert dann
>
> Closing fd 5
> 14:59:54 FEHLER -1: Nicht korrekte Statuszeile.
>
> zurück. Unser aktuelles Script ist derzeit so programmiert, dass es
> entweder ein "403 Forbidden" oder "404 Not Found" geben sollte. Wenn
> eines von beiden nicht gefunden wird, so wird es als Lücke
> klassifiziert.
Das ist aber dann Blödsinn hoch zehn, bitte entschuldige. Dann würden
auch täglich tausend Autos bei uns über die Radwege rauschen, denn:
Entweder es ist kein Weg da (404) oder es steht ein "Zufahrt
verboten"-Schild rum (403), ansonsten darf ich reinfahren.
>
> Um falsche Gerüchte aus dem Weg zu räumen: Kundenfang auf diese Weise
> soll überhaupt nicht angestrebt werden, würde ja schlussendlich sogar
> unseriös und unglaubwürdig wirken.
Und wieso dann der Kommentar "Setzen sie sich am besten unverzüglich mit
uns in Verbindung blah blah" beim Security-Check? Nur mal so nebenbei :)
> In diesem Sinn ist Feedback jederzeit willkommen!
Immer doch
later
Andreas Meile
> > zurück. Unser aktuelles Script ist derzeit so programmiert, dass es
> > entweder ein "403 Forbidden" oder "404 Not Found" geben sollte. Wenn
> > eines von beiden nicht gefunden wird, so wird es als Lücke
> > klassifiziert.
>
> Das ist aber dann Blödsinn hoch zehn, bitte entschuldige. Dann würden
> auch täglich tausend Autos bei uns über die Radwege rauschen, denn:
> Entweder es ist kein Weg da (404) oder es steht ein "Zufahrt
> verboten"-Schild rum (403), ansonsten darf ich reinfahren.
Man könnte sich streiten, ob es Sinn machen würde, die Logik zu
negieren, d.h. für Klassifizierung Sicherheitslücke muss ein "200 OK"
vorliegen. Da ich ja inzwischen gemerkt habe, dass es unter Euch
Profis gibt, was meint Ihr dazu?
> Und wieso dann der Kommentar "Setzen sie sich am besten unverzüglich mit
> uns in Verbindung blah blah" beim Security-Check? Nur mal so nebenbei :)
Ursprünglich war einmal eine Idee in diese Richtung geplant. Ich werde
aber bei uns firmenintern diesen Punkt einmal diskutieren, ob es Sinn
machen würde, neutralere Texte zu wählen. Wäre der ganze "seccheck"
von mir als Freizeitprojekt entstanden (z.B. ich hätte den Server bei
mir in der Wohnung an einem ADSL-Anschluss laufen), so wären neutrale
Texte eine Selbstverständlichkeit gewesen. :-)
Carsten Gross
In Posting <be1a605.02030...@posting.google.com>,
schrieb andrea...@onsite.ch (Andreas Meile):
>>> zurück. Unser aktuelles Script ist derzeit so programmiert, dass es
>>> entweder ein "403 Forbidden" oder "404 Not Found" geben sollte.
> [...]
> negieren, d.h. für Klassifizierung Sicherheitslücke muss ein "200 OK"
> vorliegen. Da ich ja inzwischen gemerkt habe, dass es unter Euch
> Profis gibt, was meint Ihr dazu?
Ich würde von der Verwendung von Programmen wie wget/ssh und anderen
externen Programmaufrufen völlig absehen und jedes Protokoll "zu Fuß"
bedienen.
Dann kannst Du nämlich selber die völlig eindeutigen Header verarbeiten
und mußt nicht Programmoutput parsen. Um nicht das Rad völlig
neuerfinden zu müssen gibt es beispielsweise in Perl für fast jedes
Protokoll ein Modul, guck mal ins CPAN.
Nur damit kannst Du Parsing-Probleme vermeiden. Alles andere ist
Symptombehandlung. Ein Sicherheits-_Checkprogramm_ das offen beworben wird
sollte nicht schon in den Standardtests wegen Parsingfehlern von
Programmoutput Fehlalarme oder "false positives" liefern.
Ciao,
Carsten
--
Das Reh springt hoch, das Reh springt weit, warum auch nicht, es hat ja Zeit.
You are welcome to visit my homepage
Carsten Groß, Nürnberg http://www.siski.de/~carsten/
Ulrich Eckhardt
>
> Hallo zusammen
>
> Unter http://seccheck.onsite.ch/ steht für jeden sicherheitsbewussten
> PC-Anwender und Netzwerk-Administrator ein kostenloser Security-Check
> zur Verfügung, mit welchem Ihr die Sicherheit Eurer
Also, wir schreiben zur Zeit den 04.03 im Jahre des Herren
2002 und es ist 11:20. Laut logs des Firewalls läuft der
Portscann noch. Das Ergenis lag jedoch schon um 11:12 vor
(Wahnsinn, ich will auch so ein /dev/glaskugel).
Euer /dev/glaskugel lieferte für den DNS server eine 01,
was mich natürlich freute. So weit so gut.
Unser Mailserver akzeptiert allerdings "völlig sinnlose, nicht
existierende e-Mail-Adressen". Aha. Doch was will uns das jetzt
sagen? Sinds absender oder Empfänger Adressen und warum ist das
jetzt gefährlich? Nun ein Blick in unsere Logs zeigte dann
einige open relay checks (mailabuse.org kann das aber besser)
und ein from=john....@gibtsgarnicht.mx . Nur wie soll denn
unser Mailer erkennen obs den john.smith gibt? und vor allem
warum ist das gefährlich? Naja aber immer noch im grünen
Bereich.
Port 22 ssh stehen keine Tests zur Verfügung aber trotzdem :
Mar 4 11:09:13 spee sshd[10870]: Bad protocol version identification
'guest' from 62.2.207.120
Testet Ihr jetzt oder nicht und vor allem was und was soll das guest?
Und was sollte mir da jetzt die Zusammenfassung sagen?
------------------------------------------------
Statistik zu den Port-Tests
Total gefundene offene Ports: 3
davon nicht getestet: 1
davon getestet: 2
Total Gefahrenpunkte: 5
Durchschnittliche Gefärdung Ihres Netzwerks aufgrund offener Ports: 02
Sicherheit dieser Aussage: 66%
Schwächste Stelle: Port 25 mit Gefahrenstufe 04
------------------------------------------------
Die durchnittliche Gefärdung ist 02 , aber nur mit einer
66%igen Sicherheit. Was soll einem das sagen ?
Ich habe zudem instagesammt 5 Gefahrenpunkte.
Macht aber nix, die tue ich in die Schachtel zu den
Gummipunkten.
Der Smurftest ist bestanden. Die Kurzbeschreibung dazu ist sinvoll.
Jetzt kommt der Zonentransfer. Ein Beispiel für ein
gelungenes /dev/glaskugel :
------------------------------------------------------
Beurteilung: Unser Test konnte über Ihre Netzwerk-Infrastruktur
ausserhalb des internen Netzwerks eine ziemlich vollständige
"Landkarte" anfertigen. Damit keine vertraulichen Informationen
Ihrer Netzwerkinfrastruktur in die grosse weite Welt mehr hinausgehen,
helfen Ihnen unsere Spezialisten bei der Behebung dieses
Problems gerne weiter. Telefon auf unsere Hotline genügt. Stufe: 10
---------------------------------------------------------
Aha. Woher wissen diese Spezialisten, ob dieser DNS
Server tatsächlich vertrauliche Informationen hat,
ob diese tatsächlich weiterhelfen.
Zudem aus unserem log :
security: error: client 62.2.207.120#4072: zone transfer
'rgw-express.de/IN' denied
Ergo, dieser named test funktioniert nicht. Der ganze Test ist
noch stark Verbesserungswürdig und wohl eher noch als Alpha
anzusehen. Der Autor möge sich eventuell besser mal nessus
anschauen.
Uli.
PS: Es ist jetzt 11:52 und der Portscan läuft immer noch <grr>
--
Ulrich Eckhardt Transcom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Michael Raab
at Mon, 04 Mar 2002 11:52:58 +0100 Ulrich Eckhardt wrote:
> PS: Es ist jetzt 11:52 und der Portscan läuft immer noch <grr>
Bei mir lief er ca. 2 1/2 Stunden.
Andreas Meile
auch nicht immer ganz unkritischen) geliefert haben. Eure Vorschläge
und Kritiken wurden in eine Pendenzenliste aufgenommen und werden
innerhalb der nächsten Releases kontinuierlich berücksichtigt.
Was noch zu sagen ist: Das Online-Security-Check-Projekt läuft
mehrheitlich nebenbei, da unser Schwergewicht eigentlich auf
Netzwerk-Dienstleistungen und damit verbunden Hotline-Einsätzen
verbunden ist. Deswegen werden künftige Releases sporadisch ohne
irgendwelche terminlichen Ankündigungen fortlaufend herausgegeben und
vor allem die Weiterentwicklung erfolgt nur, wenn gerade freie
Kapazität herrscht.
Grundsätzlich wird aber sicherlich dem Port 80-Problem im Zusammenhang
mit Apache-Webserver und %0A-haltigen URLs höchste Priorität
eingeräumt. Das Produkt soll übrigens auch das Kundenfänger-Image
verlieren, d.h. es soll vergleichbar mit dem AIX-Download-Archiv von
Bull einfach eine Dienstleistung so nebenbei von uns offeriert,
darstellen.
Bezüglich Ankündigung neuer Releases: Damit sie niemand mehr als
aufdringlich empfindet, erfolgen sie in ch.comp.networks und
de.comp.security.misc, sinnvollerweise als Crossposting, da ja die
Usenet-Netiquette ausdrücklich keine Mehrfachkopien von Nachrichten
empfiehlt. => an dieser Dienstleistung interessierte Benutzer sind
gebeten, mind. eine der genannten Newsgroups bei ihrem Reader zu
abonnieren.
Andreas
--
Andreas Meile
> Closing fd 5
> 14:59:54 FEHLER -1: Nicht korrekte Statuszeile.
> Dieser Fehler wird selbstverständlich im nächsten Release so rasch als
> möglich behoben.
Soeben ist Version 2.0a aufgeschaltet worden. Als Änderung wurde
dieser Fehler behoben, so dass jetzt keine Falschmeldungen bezüglich
CGI-Scripts erscheinen sollten.
Sven Heinzel
| Newsgroups: de.comp.security.misc,de.comp.security,
| de.comp.security.firewall,ch.comp.networks
Immer noch am Crossposten? Und dann auch noch in eine Gruppe
(de.comp.security), die es gar nicht mehr gibt?
Ich verstehe ja, wenn sowas _einmal_ und _unbeabsichtigt_ passiert,
aber inzwischen solltest Du erkannt haben, dass Du crosspostest ohne
ein FollowUp-To zu setzen.
> Soeben ist Version 2.0a aufgeschaltet worden. Als Änderung wurde
> dieser Fehler behoben, so dass jetzt keine Falschmeldungen bezüglich
> CGI-Scripts erscheinen sollten.
Zaehlt das nicht langsam als Spamming?
Gruss
Sven
Andreas Meile
> Also, wir schreiben zur Zeit den 04.03 im Jahre des Herren
> 2002 und es ist 11:20. Laut logs des Firewalls läuft der
> Portscann noch. Das Ergenis lag jedoch schon um 11:12 vor
> (Wahnsinn, ich will auch so ein /dev/glaskugel).
Die Zeit ist sehr stark variierend und hängt sehr stark davon ab, was
gefunden wird. Im wesentlichen ist es Port 139: Kann keine
NetBIOS-Sitzung aufgebaut werden oder kommt man auf ein Laufwerk
gleich ohne Passwort, so ist dieser Port sehr rasch erledigt. Kommt
dagegen ein "access denied" zurück, so werden so schön gesagt erst
recht einige besonders schlechte Passwörter probiert. Dies kann dann
auf einem Windows NT 4.0 gemäss eigenen Tests diese besagten 20 min
dauern. Bei allen übrigen Tests ist es auch nicht viel anders.
> Euer /dev/glaskugel lieferte für den DNS server eine 01,
> was mich natürlich freute. So weit so gut.
>
> Unser Mailserver akzeptiert allerdings "völlig sinnlose, nicht
> existierende e-Mail-Adressen". Aha. Doch was will uns das jetzt
> sagen? Sinds absender oder Empfänger Adressen und warum ist das
Ist folgendes zu sagen: Unter UNIX/Linux überprüft sendmail jeweils
den rechten Teil einer e-Mail-Adresse. Kann der Domainname nicht
aufgelöst werden, so wird das Mail zurückgewiesen. Der SMTP-Konnektor
eines Exchange-Servers dagegen schluckt auch etwas wie
"kadh...@lajdkqoiweoiwq.jq" (unser "john....@gibtsgarnicht.mx"!).
Da es nur ein wenig schlechter als UNIX-sendmail ist, wird es auch nur
ganz geringfügig als schlechter betrachtet.
> Port 22 ssh stehen keine Tests zur Verfügung aber trotzdem :
>
> Mar 4 11:09:13 spee sshd[10870]: Bad protocol version identification
> 'guest' from 62.2.207.120
Ein kleines Geheimnis sei doch noch erraten: Im Hintergrund generieren
wir ein Detailprotokoll. Bei Ports, wo es noch kein spezialisierter
Test gibt, werden nur die Banner ausgelesen: Verbinden und horchen,
etwas später auch durch Senden von Strings wie "guest" etwas
kritzeln...
> Die durchnittliche Gefärdung ist 02 , aber nur mit einer
> 66%igen Sicherheit. Was soll einem das sagen ?
Das Thema Statistik befindet sich eigentlich immer noch im
Entwurfsstadium. Im wesentlichen entspricht die Aussagensicherheit der
Anzahl mit spezialisierten Tests geprüften Ports/gefundene Ports
insgesamt.
> Der Smurftest ist bestanden. Die Kurzbeschreibung dazu ist sinvoll.
:-)
> Aha. Woher wissen diese Spezialisten, ob dieser DNS
> Server tatsächlich vertrauliche Informationen hat,
> ob diese tatsächlich weiterhelfen.
Gleich eine Meldung an alle: Die Texte wurden in der soeben
aufgeschalteten Version 2.0b besser formuliert, vor allem neutral und
nicht mehr nach Kundenfang tönend... :-)
> Zudem aus unserem log :
> security: error: client 62.2.207.120#4072: zone transfer
> 'rgw-express.de/IN' denied
Bitte mir rasch in einer persönlichen Mail Deine IP-Adresse
bekanntgeben, damit ich den Detaillog nachschauen kann und vor allem
den Fehler noch einmal nachvollziehen, warum unser Script scheinbar
auf die Nase fällt. Schwierigkeit war die: "nslookup" lieferte mir
keinen geeigneten $?-Return Value zurück, also musste ich auf die
recht primitive Methode ausweichen, einfach schauen, ob eine
Ausgabedatei der DNS-Zone erstellt wurde und ob diese eine
Mindestanzahl von Zeilen hat. Ich habe es dann daraufhin mit einigen
DNS-Server getestet und diese Anzahl so optimiert, dass es nirgends
falsche Bewertungen gab.
Ulrich Eckhardt
> Die Zeit ist sehr stark variierend und hängt sehr stark davon ab, was
> gefunden wird. Im wesentlichen ist es Port 139: Kann keine
Nope. Das Teil scannte fröhlich alle Ports.
> NetBIOS-Sitzung aufgebaut werden oder kommt man auf ein Laufwerk
> gleich ohne Passwort, so ist dieser Port sehr rasch erledigt. Kommt
> dagegen ein "access denied" zurück, so werden so schön gesagt erst
> recht einige besonders schlechte Passwörter probiert. Dies kann dann
> auf einem Windows NT 4.0 gemäss eigenen Tests diese besagten 20 min
> dauern. Bei allen übrigen Tests ist es auch nicht viel anders.
Aber isch abe kein Windows. Und zudem bekommt Ihr für jeden
Port je nach dem, wo er geblockt wird ein ICMP Port Unreachable
oder Network unreachable.
> Ist folgendes zu sagen: Unter UNIX/Linux überprüft sendmail jeweils
> den rechten Teil einer e-Mail-Adresse. Kann der Domainname nicht
> aufgelöst werden, so wird das Mail zurückgewiesen. Der SMTP-Konnektor
> eines Exchange-Servers dagegen schluckt auch etwas wie
> "kadh...@lajdkqoiweoiwq.jq" (unser "john....@gibtsgarnicht.mx"!).
> Da es nur ein wenig schlechter als UNIX-sendmail ist, wird es auch nur
> ganz geringfügig als schlechter betrachtet.
Aber isch abe kein Windows und kein Exchange.
Obige Aussage ist quatsch. Ob Sendmail (oder jeder andere Mailer)
den Domainnamen prüft hängt ganz von der Konfiguration ab. Und
teilweise ist diese Prüfung abgeschaltet, da man öfters mal
von jemandem Mail bekommt, deren Mailer/DNS "etwas merkwürdig"
konfiguriert ist. Ausserdem prüft Ihr nicht, wie das Mailsystem
die E-Mail header verarbeitet. Lediglich die from adresse des
smtp Protokolls wird geprüft.
> > Die durchnittliche Gefärdung ist 02 , aber nur mit einer
> > 66%igen Sicherheit. Was soll einem das sagen ?
>
> Das Thema Statistik befindet sich eigentlich immer noch im
> Entwurfsstadium. Im wesentlichen entspricht die Aussagensicherheit der
> Anzahl mit spezialisierten Tests geprüften Ports/gefundene Ports
> insgesamt.
Da Ihr das Konzept des Firewalls nicht kennt, solltet Ihr euch
die Statistik ganz sparen. Die Zahlen können nie irgendwas
sinnvolles aussagen.
> > Zudem aus unserem log :
> > security: error: client 62.2.207.120#4072: zone transfer
> > 'rgw-express.de/IN' denied
>
> Bitte mir rasch in einer persönlichen Mail Deine IP-Adresse
> bekanntgeben, damit ich den Detaillog nachschauen kann und vor allem
> den Fehler noch einmal nachvollziehen, warum unser Script scheinbar
> auf die Nase fällt. Schwierigkeit war die: "nslookup" lieferte mir
man dig.
Uli