0.0.0.0:1029 -> 0.0.0.0:0 ???
Christoph Pernsteiner
ich hab auf meinem Rechner netstat -an eingegeben um meine ports zu
überprüfen. Ich hab da ein Problem, und zwar verstehe ich folgende Einträge
nicht:
TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1103 0.0.0.0:0 LISTENING
was bedeutet das, kann mir das jemand genauer erklären? (Ich hab übrigens
auf den selben Ports eine Verbindung mit einem anderen Server etablished,
hat das irgendwas damit zu tun?)
Ich wünsch euch noch einen schönen Tag,
Christoph Pernsteiner
Lutz Donnerhacke
>TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING
>TCP 0.0.0.0:1103 0.0.0.0:0 LISTENING
Je ein Server lauscht am Poret 1029 und 1103 auf alles, was ihn erreichen
kann.
Christoph Pernsteiner
> Je ein Server lauscht am Poret 1029 und 1103 auf alles, was ihn erreichen
> kann.
Ich hab aber einen Portscan auf meinem eigenen Computer gemacht, und da ist
nur Port 139 offen (Ich weiß dass der für NTB over TCP/IP ist, und auch
welche Sicherheitsrisiken daraus resultieren, keine Angst), und ein
dynamischer, mal is es 6075 und mal is es 20xxx, ich glaub der is fürs ICQ,
denn der is nur offen wenn ich ICQ laufen habe (und nach Trojanern hab ich
schon mit meinem Virenscanner gescannt).
Kannst du mir erklären, wieso da ein Server auf dem Port lauscht, ich aber
über nen Portscan nichts finden kann (ich hab grad versucht in zu telneten,
funktioniert auch nicht)?
Ich wünsch dir noch nen schönen Tag,
Christoph Pernsteiner
Lutz Donnerhacke
>Guten Tag Lutz,
>> Je ein Server lauscht am Poret 1029 und 1103 auf alles, was ihn erreichen
>> kann.
>
>Ich hab aber einen Portscan auf meinem eigenen Computer gemacht, und da ist
>nur Port 139 offen
Dann ist der benutzte Scan fehlerhaft implementiert. Evtl. testet er nur bis
Port 1024.
>dynamischer, mal is es 6075 und mal is es 20xxx, ich glaub der is fürs ICQ,
>denn der is nur offen wenn ich ICQ laufen habe
Das ist gut möglich. Die FAQ beschreibt, wie man die zugehörige Software
identifizieren kann. Deaktive ICQ und wenn netstat dann diese Verbindungen
nicht mehr anzeigt, weißt Du Bescheid.
>(und nach Trojanern hab ich schon mit meinem Virenscanner gescannt).
Das hilft aber nicht. Trojaner sind eben keine Viren.
Bernd Eckenfels
> Kannst du mir erklären, wieso da ein Server auf dem Port lauscht, ich aber
> über nen Portscan nichts finden kann (ich hab grad versucht in zu telneten,
> funktioniert auch nicht)?
Vieleicht hast du etwas falsch gemacht? :)
Klaus-D.Heinrich
> Die FAQ beschreibt, wie man die zugehörige Software
> identifizieren kann.
Eine kurze Frage mit der Bitte um eine kurze Antwort:
Wo finde ich diese FAQ?
Klaus-D.Heinrich
Lars Gebauer
> Eine kurze Frage mit der Bitte um eine kurze Antwort:
> Wo finde ich diese FAQ?
de.comp.security.firewall FAQ
<URL:http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html>
--
Hoch 'ebmey tljon.
Ergreife jede Gelegenheit.
Klaus-D.Heinrich
> <URL:http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html>
Danke für den Hinweis!
Klaus-D.Heinrich
Marc Haber
>Lars Gebauer <geb...@telda.net> wrote:
>> <URL:http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html>
>Danke für den Hinweis!
Wie kann man denn diese Gruppe aufmerksam lesen, ohne die FAQ zu
kennen? Magst Du mir das bitte erklären? Es ist doch absolut
unmöglich, die ständigen Hinweise zu übersehen..
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Sebastian Schlüter
>ich hab auf meinem Rechner netstat -an eingegeben um meine ports zu
>überprüfen. Ich hab da ein Problem, und zwar verstehe ich folgende
>Einträge nicht:
Um herauszufinden, um welche Prozesse es sich handelt, kannst du zum
Beispiel TCP View Pro installieren.
http://www.winternals.com/products/monitoringtools/tcpviewpro.shtml
Außerdem kann @Guard/NIS/NPF das anzeigen.
Gruß Sebastian
Sebastian Schlüter
>Kannst du mir erklären, wieso da ein Server auf dem Port lauscht,
>ich aber über nen Portscan nichts finden kann (ich hab grad versucht
>in zu telneten, funktioniert auch nicht)?
Das ist auch Mist, was netstat -an anzeigt. Ich bin zur Zeit unter
Win98 und habe auch einige solche Einträge, wenn ich netstat -an
eingebe. Aber wenn ich den Rechner dann mit nmap scanne, dann sind
längst nicht alle angezeigten Ports auch tatsächlich offen.
Aber diejenigen, die offen sind, sind genau diejenigen, die mir von
@Guard als offen angezeigt werden.
Also: Vergiß netstat -an. Es funktioniert nicht.
Gruß Sebastian
Lutz Donnerhacke
>Das ist auch Mist, was netstat -an anzeigt. Ich bin zur Zeit unter
>Win98 und habe auch einige solche Einträge, wenn ich netstat -an
>eingebe. Aber wenn ich den Rechner dann mit nmap scanne, dann sind
>längst nicht alle angezeigten Ports auch tatsächlich offen.
Ich würde netstat -an mehr trauen als einem Tool, daß auf obskuren
Heuristiken basiert.
Sebastian Schlüter
>Ich würde netstat -an mehr trauen als einem Tool, daß auf obskuren
>Heuristiken basiert.
Was für obskure Heuristiken?
Felix von Leitner
> Das ist auch Mist, was netstat -an anzeigt. Ich bin zur Zeit unter
> Win98 und habe auch einige solche Einträge, wenn ich netstat -an
> eingebe. Aber wenn ich den Rechner dann mit nmap scanne, dann sind
> längst nicht alle angezeigten Ports auch tatsächlich offen.
Das liegt höchstwahrscheinlich daran, daß du die Ausgabe von netstat
nicht verstehst.
> Also: Vergiß netstat -an. Es funktioniert nicht.
Es wird spontan zu "funktionieren" beginnen, wenn du das Handbuch liest.
Felix
Juergen Ilse
Sebastian Schlüter <sschl...@gmx.net> wrote:
> Heiko Schlenker <hsc...@gmx.de> schrieb unter anderem:
>>Aha. Koennte es nicht vielmehr so sein, dass Du Probleme hast, das,
>>was netstat ausspuckt, korrekt zu interpretieren? Ist ja kein
>>Beinbruch. Aber deshalb gleich zu behaupten, netstat tauge per se
>>nichts, ist, aeh, mutig.
> Äh, teste es selbst, bevor du widersprichst. Ich erzähle keinen Mist.
> Christoph Pernsteiner hat beobachtet, daß bei netstat -an listeing
> ports angezeigt werden, obwohl es auch eine established Verbindung mit
> demselben Sourceport gibt.
Das ist noch kein Widerspruch. Allerdings scheint Windows (oder das netstat
unter windows?) da tatsaechlich einen Fehler zu haben. Wenn eine TCP-Connec-
tion zu einem "listening" Port zum lokalen Rechner aufgebaut wird, wird bei
netstat -an offenbar faelschlicherweise auch der source-Port der Connection
als "listening" aufgelistet (obwohl er das nicht ist). Diese Faelle sind
aber recht einfach zu erkennen (und in dem anderen Port der Connection findet
man dann in der Regel auch einen wirklichen "listening" Port...).
> Und ich habe mit nmap überprüft, ob die Port
> sich als offen darstellen. Und das tun sie nicht.
So z.B. hier (NICHT mit nmap ueberprueft):
TCP 193.98.1.64:139 0.0.0.0:0 LISTENING
TCP 193.98.1.64:1029 0.0.0.0:0 LISTENING
TCP 193.98.1.64:1029 193.98.1.64 ESTABLICHED
139 ist ein offener Port, 1029 nicht. Wenn man sicher sein koennte, dass
M$ darauf reagiert, waere das ein Grund einen Bug-Report zu schreiben (ich
bin allerdings vom Sinn nicht ganz ueberzeugt...).
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "router:[/local]# rm -R var" | Internet POP Hannover
"rm: im Verzeichnis >>var<< absteigen?" | Vahrenwalder Str. 205
-----------------------------------------------------| 30165 Hannover
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| il...@pop-hannover.net
Jens Grivolla
>* Sebastian Schlüter <sschl...@gmx.net> schrieb:
>
>> Christoph Pernsteiner hat beobachtet, daß bei netstat -an listeing
>> ports angezeigt werden, obwohl es auch eine established Verbindung
>> mit demselben Sourceport gibt.
>
>Sowas wie:
>#v+
>tcp 0 0 127.0.0.1:119 127.0.0.1:1277 ESTABLISHED
>tcp 0 0 0.0.0.0:119 0.0.0.0:* LISTEN
>#v-
>
>Tja, ich sehe nicht, wo hier netstat versagen soll.
Das ist auch keine (vollständige) Ausgabe des Win98 netstat. Da würde
nämlich Port 1277 auch als listening drinstehen.
Ciao,
Jens
Sebastian Schlüter
>Das liegt höchstwahrscheinlich daran, daß du die Ausgabe von netstat
>nicht verstehst.
Ich verstehe die Aufgabe von netstat - glaube ich - schon.
Ich kann ja noch einmal kurz zusammenfassen:
Christoph Pernsteiner hat festgestellt, daß er einige listening ports
hat. Lutz hat dann erklärt, daß dann auf seinem System Server laufen,
die Verbindungen von außen annehmen können. Christoph hat dann
entgegnet, daß er einen Portscan von außen gemacht hat, und daß
überraschenderweise nicht alle angezeigten Ports sich auch als offen
herausgestellt haben. Daraufhin hat Lutz vermutet, daß der Scan
eventuell nicht richtig ausgeführt worden ist.
An dieser Stelle habe ich mich eingeschaltet und die Beobachtungen
von Christoph bestätigt. Juergen Ilse hat es auch beobachtet. Und
jeder kann das selbst nachvollziehen, denn es ist wirklich einfach zu
testen. Wenn man mit einem Client eine Verbindung aufbaut, dann
erzeugt diese Verbindung zwei Einträge in der netstat- Ausgabe.Die
Ausgabe von netstat unter Windows9x ist also irreführend, weil es so
erscheint, als ob ein Server laufen würde und jemand von außen eine
Verbindung zu diesem Server aufgebaut hätte.
Zu WindowsNT/2000 kann ich zur Zeit nichts sagen, ich habe das aber bei
OpenBSD ausprobiert, und da ist die netstat-Ausgabe korrekt. Eine
Client-Verbindung erzeugt genau einen Eintrag in der netstat-Ausgabe,
ein Server erzeugt eine LISTENING-Zeile, und wenn man von außen eine
Verbindung zu diesem Server aufbaut, dann sind es zwei Zeilen, nämlich
listen und established.
Unter Windows9x sind es immer zwei Zeilen, und man kann daher nicht
zwischen Client und Server unterscheiden.
Daher habe ich die netstat-Ausgabe unter Windows9x für unbrauchbar
erklärt und darauf hingewiesen, daß die Ausgabe von AtGuard korrekt ist
und insbesondere auch noch die beteiligten Prozesse anzeigt.
Gruß Sebastian
Bernd Eckenfels
> Ich würde netstat -an mehr trauen als einem Tool, daß auf obskuren
> Heuristiken basiert.
Unter windows gab es immer wieder bekannte Bugs in netstat. Zumindest mal
unter den 16bittigen und vor einem bestimmten SP auch in NT.
Was NT ganz dringend fehlt ist eine Prozessidendifikation, aber dafuer gibts
ja sysinternals.com :)
Gruss
Bernd
Lutz Donnerhacke
>Das ist noch kein Widerspruch. Allerdings scheint Windows (oder das netstat
>unter windows?) da tatsaechlich einen Fehler zu haben. Wenn eine TCP-Connec-
>tion zu einem "listening" Port zum lokalen Rechner aufgebaut wird, wird bei
>netstat -an offenbar faelschlicherweise auch der source-Port der Connection
>als "listening" aufgelistet (obwohl er das nicht ist). Diese Faelle sind
>aber recht einfach zu erkennen (und in dem anderen Port der Connection findet
>man dann in der Regel auch einen wirklichen "listening" Port...).
Danke.
netstat zeigt offene Ports, aber da läuft garantiert nichts! Was übersehe
ich?
Windows (oder netstat für Windows) hat da tatsächlich einen Fehler.
Wenn eine TCP-Verbindung vom lokalen Rechner zum lokalen Rechner
aufgebaut wurde, zeigt netstat -an fälschlicherweise beide Enden der
Verbindung als "listening" an, obwohl das für den Sourceport falsch
ist.
Proto Local Address Foreign Address State
tcp 217.17.192.37:1213 217.17.192.37:119 ESTABLISHED
tcp 0.0.0.0:119 0.0.0.0:* LISTEN
tcp 0.0.0.0:1213 0.0.0.0:* LISTEN
Michael Simon
>
>Daher habe ich die netstat-Ausgabe unter Windows9x für unbrauchbar
>erklärt und darauf hingewiesen, daß die Ausgabe von AtGuard korrekt ist
>und insbesondere auch noch die beteiligten Prozesse anzeigt.
Auf der Seite
http://www.cablemodemhelp.com/winmesec.htm
steht unter Punkt 4:
"If the output (netstat -na) contains the following 3 lines:
Active Connections
Proto Local Address Foreign Address State
TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
UDP 192.168.0.17:137 *:*
UDP 192.168.0.17:138 *:*
you are vulnerable. There may be any number of additional lines. But
these three (TCP .... :139 ... LISTENING, UDP .... :137 *:*, and UDP
.... :138 *:*) are critical."
Danach wird empfohlen, die Datei- und Druckerfreigabe zu deaktivieren
(Windows ME). Was mich ein wenig irritiert, ist, daß diese drei Zeilen
auch bei *deaktivierter Datei- und Druckerfreigabe* aufscheinen (W95).
Ist es das, was Du mit "unbrauchbar" meinst? Sind diese Angaben auf
der Web-Seite irreführend, oder kriege ich da irgendwas nicht auf die
Reihe?
Lutz Donnerhacke
>http://www.cablemodemhelp.com/winmesec.htm
>"If the output (netstat -na) contains the following 3 lines:
>Active Connections
> TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
> UDP 192.168.0.17:137 *:*
> UDP 192.168.0.17:138 *:*
>you are vulnerable.
Korrekt.
>wird empfohlen, die Datei- und Druckerfreigabe zu deaktivieren
Korrekt.
>Was mich ein wenig irritiert, ist, daß diese drei Zeilen auch bei
>*deaktivierter Datei- und Druckerfreigabe* aufscheinen (W95).
Dann ist es noch nicht ausreichend abgeschaltet.
>Ist es das, was Du mit "unbrauchbar" meinst?
Nein.
>Sind diese Angaben auf der Web-Seite irreführend,
Nein.
>oder kriege ich da irgendwas nicht auf die Reihe?
ja.
Michael Simon
>* Michael Simon wrote:
>>http://www.cablemodemhelp.com/winmesec.htm
>
>>"If the output (netstat -na) contains the following 3 lines:
>>Active Connections
>> TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
>> UDP 192.168.0.17:137 *:*
>> UDP 192.168.0.17:138 *:*
>>you are vulnerable.
[...]
>>oder kriege ich da irgendwas nicht auf die Reihe?
>
>ja.
Danke. Tsss... Da dachte ich, ich blicke halbwegs durch...
Auf der betreffenden Maschine waren definitiv *keine Bindungen* unter
"TCP/IP-Eigenschaften" vorhanden. Null. Gar keine. Trotzdem zeigte
netstat -na die drei "kritischen Zeilen" an. Anscheinend reicht es
eben *nicht* immer, diese Bindungen zu entfernen, weiß der Geier,
warum.
Ich habe nun den Tip, den ich auf meiner eigenen Webseite eingetragen
habe, befolgt:
"Wer mit der gefährlichen "Datei- und Druckerfreigabe" kurzen Prozeß
machen möchte, braucht im "Windows/System"-Verzeichnis nur die Datei
mit dem Namen Vnbt.386 umzubenennen und Windows neu zu starten."
Das half :-)
Die drei Zeilen sind weg.
Urs [Ayahuasca] Traenkner
> * Michael Simon wrote:
> >"If the output (netstat -na) contains the following 3 lines:
> >Active Connections
> > TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
> > UDP 192.168.0.17:137 *:*
> > UDP 192.168.0.17:138 *:*
> >you are vulnerable.
> Korrekt.
In dieser Pauschalitaet kann man das nicht sagen. Diese
Anzeige erfolgt sowohl bei alleiniger Bindung des
SMB-Freigabedienstes auf Netzwerkkarte als auch bei Bindung
auf Netzwerkkarte _und_ ISDN-Karte.
Ob nun Port 139 (der ist irgendwie immer nach aussen frei -
ist wohl nbname oder so) als Angriffsflaeche ausreicht, kann
ich nicht beurteilen. Jedenfalls findet sich auf
http://www.grc.com irgendwo die Anleitung, wie man seinem
Win auch das abgewoehnen kann.
> >Was mich ein wenig irritiert, ist, daß diese drei Zeilen auch bei
> >*deaktivierter Datei- und Druckerfreigabe* aufscheinen (W95).
> Dann ist es noch nicht ausreichend abgeschaltet.
Wenn die Bindung zur "Internet-Hardware" geloest ist, reicht
das auch aus.
Gruss Urs...
--
Masturbation ist Sex an und fuer sich.
Aus der Sign. von Tobias Zimpel
Was ist nymphoman? Zwangslaeufig.
Stefan Heinecke
> netstat zeigt offene Ports, aber da läuft garantiert nichts! Was übersehe
> ich?
NETSTAT [-a] [-e] [-n] [-s] [-p Proto] [-r] [Intervall]
-a Zeigt den Status aller Verbindungen an. (Verbindungen
des Servers werden normalerweise nicht angezeigt).
> Windows (oder netstat für Windows) hat da tatsächlich einen Fehler.
> Wenn eine TCP-Verbindung vom lokalen Rechner zum lokalen Rechner
> aufgebaut wurde, zeigt netstat -an fälschlicherweise beide Enden der
> Verbindung als "listening" an, obwohl das für den Sourceport falsch
> ist.
Es zeigt LISTEN und ESTABLISHED an, wobei man die Ausgabe nicht mit
der Unixvariante -ltu vergleichen kann.
Beispiel: Hier sind zwei SSH Verbindungen etabliert netstat zeigt:
TCP cascadeur:1083 hub.ircelite.org:22 ESTABLISHED
TCP cascadeur:1657 hub.ircelite.org:22 ESTABLISHED
netstat -a zeigt:
TCP cascadeur:1083 CASCADEUR:0 LISTENING
TCP cascadeur:1657 CASCADEUR:0 LISTENING
TCP cascadeur:1083 hub.ircelite.org:22 ESTABLISHED
TCP cascadeur:1657 hub.ircelite.org:22 ESTABLISHED
> Proto Local Address Foreign Address State
> tcp 217.17.192.37:1213 217.17.192.37:119 ESTABLISHED
> tcp 0.0.0.0:119 0.0.0.0:* LISTEN
> tcp 0.0.0.0:1213 0.0.0.0:* LISTEN
Die Ausgabe ist schon richtig, Du hast etwas das auf Port 119 auf
Verbindungen wartet (Listen, Zeile 2), darauf hast Du dich verbunden
(Zeile 1), und zwar von Port 1213. Und natuerlich darf Zeile 3 auch
Listen, weil ja auch Pakete zurueckkommen duerfen :).
Inwiefern etwas richtig oder falsch ist kommt drauf an wie man es
interpretiert.
Jetzt sind alle Klarheiten beseitigt,
Stefan
--
Wenn ich auf jede Frage eine Antwort haette wuerde ich Theologie lehren.
(Sean Connery in Uberto Ecos "Im Namen der Rose")
Lutz Donnerhacke
>Es zeigt LISTEN und ESTABLISHED an, wobei man die Ausgabe nicht mit
>der Unixvariante -ltu vergleichen kann.
Das scheint der Punkt zu sein. LISTEN, ESTABLISHED, SYNC, FINISH, FIN2, ...
sind definierte Stati des TCP Protokolls. Wenn das netstat unter Windows
meint, es müsse diese Begriffe für etwas völlig anderes benutzen, ist es
sinnlos. Aber das traue ich nicht einmal Microsoft zu.
>Inwiefern etwas richtig oder falsch ist kommt drauf an wie man es
>interpretiert.
Nein. Es gibt Normen.
Juergen Ilse
Stefan Heinecke <s...@hub.ircelite.org> wrote:
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> netstat zeigt offene Ports, aber da läuft garantiert nichts! Was übersehe
>> ich?
> NETSTAT [-a] [-e] [-n] [-s] [-p Proto] [-r] [Intervall]
> -a Zeigt den Status aller Verbindungen an. (Verbindungen
> des Servers werden normalerweise nicht angezeigt).
>> Windows (oder netstat für Windows) hat da tatsächlich einen Fehler.
>> Wenn eine TCP-Verbindung vom lokalen Rechner zum lokalen Rechner
>> aufgebaut wurde, zeigt netstat -an fälschlicherweise beide Enden der
>> Verbindung als "listening" an, obwohl das für den Sourceport falsch
>> ist.
> Es zeigt LISTEN und ESTABLISHED an, wobei man die Ausgabe nicht mit
> der Unixvariante -ltu vergleichen kann.
"LISTEN" heisst bei der gaengigen Interpretation der Begriffe aber nicht
"kann auf diesem Port Pakete empfangen" (das natuerlich auch) sonder inbe-
sondere "ist bereit auf diesem Port neue Verbindungen entgegenzunehmen".
In diesem Sinne ist die Anzeige des "LISTEN" Status fuer den Source-Port
der Verbindung schlicht falsch (und ist bei anderen Systemen in der Regel
auch nicht vorhanden).
> Beispiel: Hier sind zwei SSH Verbindungen etabliert netstat zeigt:
> TCP cascadeur:1083 hub.ircelite.org:22 ESTABLISHED
> TCP cascadeur:1657 hub.ircelite.org:22 ESTABLISHED
> netstat -a zeigt:
> TCP cascadeur:1083 CASCADEUR:0 LISTENING
> TCP cascadeur:1657 CASCADEUR:0 LISTENING
Diese beiden sind eigentlich nicht "LISTEN", da auf diesen Ports ausser
der bestehenden Verbindung nichts mehr entgegengenommen wird. "LISTEN"
heisst eigentlich, dass noch weitere Connections entgegengenommen werden
koennten (ist in diesem Beispiel aber wohl eher nciht der Fall).
> TCP cascadeur:1083 hub.ircelite.org:22 ESTABLISHED
> TCP cascadeur:1657 hub.ircelite.org:22 ESTABLISHED
>> Proto Local Address Foreign Address State
>> tcp 217.17.192.37:1213 217.17.192.37:119 ESTABLISHED
>> tcp 0.0.0.0:119 0.0.0.0:* LISTEN
>> tcp 0.0.0.0:1213 0.0.0.0:* LISTEN
> Die Ausgabe ist schon richtig, Du hast etwas das auf Port 119 auf
> Verbindungen wartet (Listen, Zeile 2), darauf hast Du dich verbunden
> (Zeile 1), und zwar von Port 1213. Und natuerlich darf Zeile 3 auch
> Listen, weil ja auch Pakete zurueckkommen duerfen :).
Das waere eine falsche Benutzung des Begriffs "LISTEN" in diesem Zusammen-
hang, daher also nicht korrekt.
> Inwiefern etwas richtig oder falsch ist kommt drauf an wie man es
> interpretiert.
In jeder sinnvollen Kommunikation setzt man eine bestimmtes Vokabular voraus.
Deine Interpretation des Begriffs "LISTEN" widerspricht dem gebraeuchlichen
Vokabular in Bezug auf TCP/IP Networking.
> Jetzt sind alle Klarheiten beseitigt,
JETZT vielleicht schon (hoffentlich).
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Ausserhalb des Scheibenweltraums" | Internet POP Hannover
-----------------------------------------------------| Vahrenwalder Str. 205
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| 30165 Hannover
Sebastian Schlüter
>Ist es das, was Du mit "unbrauchbar" meinst?
Nein, ich meine folgendes: Ich bin mit meinem Newsreader mit dem Server
news.fu-berlin.de verbunden. netstat -a zeigt mir
TCP hauptrechner:1053 news.fu-berlin.de:nntp ESTABLISHED
und ebenfalls
TCP hauptrechner:1053 0.0.0.0:0 LISTENING
Die zweite Zeile ist falsch. Es sieht jetzt nämlich so aus, als ob ich
einen Server auf Port 1053 hätte und news.fu-berlin.de sich mit diesem
Server verbunden hätte.
Gruß Sebastian
Sebastian Schlüter
>Wenn eine TCP-Verbindung vom lokalen Rechner zum lokalen Rechner
> aufgebaut wurde, zeigt netstat -an fälschlicherweise beide
> Enden der Verbindung als "listening" an, obwohl das für den
> Sourceport falsch ist.
>
Dieses Phänomen ist nicht auf den lokalen Rechner beschränkt!
Gruß Sebastian
Lutz Donnerhacke
Fixed.
netstat zeigt offene Ports, aber da läuft garantiert nichts! Was übersehe
ich?
Windows (oder netstat für Windows) hat da tatsächlich einen Fehler.
Wenn eine TCP-Verbindung vom lokalen Rechner aufgebaut wurde, zeigt
netstat -an fälschlicherweise auch den Sourceport als LISTEN an.
LISTEN heißt aber im TCP/IP Begriffsuniversum: Hier hängt ein Server,
der neue TCP Verbindungen annehmen will.
Proto Local Address Foreign Address State
tcp 217.17.192.37:1213 217.17.192.67:119 ESTABLISHED
Stefan Heinecke
>sondere "ist bereit auf diesem Port neue Verbindungen entgegenzunehmen".
>In diesem Sinne ist die Anzeige des "LISTEN" Status fuer den Source-Port
>der Verbindung schlicht falsch (und ist bei anderen Systemen in der Regel
>auch nicht vorhanden).
ACK.
>In jeder sinnvollen Kommunikation setzt man eine bestimmtes Vokabular voraus.
>Deine Interpretation des Begriffs "LISTEN" widerspricht dem gebraeuchlichen
>Vokabular in Bezug auf TCP/IP Networking.
Asche auf mein Haupt, bei mir steht Listening, bei Lutz Listen.
Stefan Heinecke
>Das scheint der Punkt zu sein. LISTEN, ESTABLISHED, SYNC, FINISH, FIN2, ...
>sind definierte Stati des TCP Protokolls. Wenn das netstat unter Windows
>meint, es müsse diese Begriffe für etwas völlig anderes benutzen, ist es
>sinnlos. Aber das traue ich nicht einmal Microsoft zu.
Ich schliesse fuer mich nicht aus, das die Parametrisierung nicht wirklich
sinnvoll ist, denn je nach dem wie das Modell in zusammengebaut
wird hat man Verbindungen z.B:
Host1:1111 -TCP- Host2:22 (SSH)
und dann hast Du noch die Sockets auf:
1 Host1: 1111 Client [ListenING]
2 Host2: 22 Server [Listen]
Wobei ich 1 ganz klar als Listening-Socket sehen wuerde, er gehoert zur
Verbindung zwischen Host 1 und Host 2. Ich tippe mal das ist in Win irgendwie
so hingemurkst wurden, das wenn jemand alles moechte, auch alles bekommt,
also Verbindungen und Sockets, und da man anscheinend nicht zwischen
Verbindungen (ESTABLISHED) und Sockets (LISTEN/ING) unterscheiden
kann/moechte schreibt man LISTENING und treibt uns in den Wahnsinn.
[Die Konspirationstheorie wurde entfernt]
>Nein. Es gibt Normen.
Ja, z.B. das OSI Modell, herstellerspezifisch - scnr.
Aber "Listening" steht nirgends - das ist das ganze Problem denke ich, es
ist irrefuehrend vergleich mal die Ausgabe von "netstat -altu" auf Linux
und "netstat -a" auf Win - ist mir aber auch gerade erst aufgefallen.
Wenn ich mich jetzt auf den Hilfetext festnitpicke:
Zeigt Protokollstatistik und aktuelle TCP/IP-Netzwerkverbindungen an.
-a Zeigt den Status aller Verbindungen an. (Verbindungen
des Servers werden normalerweise nicht angezeigt).
-n Zeigt Adressen und Anschlüsse numerisch an.
Dann passt das nicht zur Ausgabe, denn "Verbindungen des Servers" werden
sehr wohl angezeigt.
Was ich daraus (mal wieder lerne) laesst sich wie folgt zusammenfassen:
- Lokalisierte System werden von Menschen benutzt die lokalisierte
Fehlermeldungen nicht verstehen (muessen/koennen/wollen).
Gruss,
Stefan
--
Paranoia is the belief in a hidden order behind the visible.
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Das scheint der Punkt zu sein. LISTEN, ESTABLISHED, SYNC, FINISH, FIN2, ...
>>sind definierte Stati des TCP Protokolls. Wenn das netstat unter Windows
>>meint, es müsse diese Begriffe für etwas völlig anderes benutzen, ist es
>>sinnlos. Aber das traue ich nicht einmal Microsoft zu.
>
>Ich schliesse fuer mich nicht aus, das die Parametrisierung nicht wirklich
>sinnvoll ist, denn je nach dem wie das Modell in zusammengebaut
>wird hat man Verbindungen z.B:
>
>Host1:1111 -TCP- Host2:22 (SSH)
>
>und dann hast Du noch die Sockets auf:
>
>1 Host1: 1111 Client [ListenING]
>2 Host2: 22 Server [Listen]
Das ist falsch. Host1 hat die Verbindung (TCP,Host1,1111,Host2,22). Er hat
keinen generellen Horcher auf Port 1111.
>>Nein. Es gibt Normen.
>
>Ja, z.B. das OSI Modell, herstellerspezifisch - scnr.
Dummfug. Lern Lesen.
>Aber "Listening" steht nirgends - das ist das ganze Problem denke ich, es
Es ist schlicht falsch. Punkt.
>- Lokalisierte System werden von Menschen benutzt die lokalisierte
> Fehlermeldungen nicht verstehen (muessen/koennen/wollen).
Schreibe einen Bugreport an Microsoft, aber vergiß Lokalisierungen. Die
haben hier nichts damit zu tun.
Stefan Heinecke
>Das ist falsch. Host1 hat die Verbindung (TCP,Host1,1111,Host2,22). Er hat
>keinen generellen Horcher auf Port 1111.
ACK, natuerlich hat er keinen genrellen Horcher.
>Schreibe einen Bugreport an Microsoft, aber vergiß Lokalisierungen. Die
>haben hier nichts damit zu tun.
Die schreiben mir nur wieder, das ich auf $IRGENDWAS updaten moechte.
Bernd Eckenfels
> Inwiefern etwas richtig oder falsch ist kommt drauf an wie man es
> interpretiert.
Der Listen State im TCP laesst keine Interpretation durch MS zu..
Gruss
Bernd
Bernd Eckenfels
> Zeigt Protokollstatistik und aktuelle TCP/IP-Netzwerkverbindungen an.
> -a Zeigt den Status aller Verbindungen an. (Verbindungen
> des Servers werden normalerweise nicht angezeigt).
> -n Zeigt Adressen und Anschlüsse numerisch an.
Ich nehme mal an das ist schwachsinnig uebersetzt. Unter netstat heisst es
"w/ servers" "w/o servers" wobei unter Server Sockets im State LISTENING
bezeichnet werden.
Gruss
Bernd
Alexander Gran
"Michael Simon" <mi...@gmx.net> schrieb im Newsbeitrag
news:4tv55t4plmm7euqmp...@4ax.com...
> "If the output (netstat -na) contains the following 3 lines:
>
> Active Connections
>
> Proto Local Address Foreign Address State
>
> TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
> UDP 192.168.0.17:137 *:*
> UDP 192.168.0.17:138 *:*
Schlagt mich bitte,wenn ich mich irre, aber zumindest bei mir ordnet windows
das lokale interface richtig zu,d.h. bei Local Address steht meine
Internet-IP und
nciht ,wie oben die fürs LAN?
MFG
Alex
Alexander Gran
"Bernd Eckenfels" <ec...@lina.inka.de> schrieb im Newsbeitrag
news:9338if$eh5$4...@sapa.inka.de...
> Der Listen State im TCP laesst keine Interpretation durch MS zu..
Wie kommst du darauf, dass Microsoft hier interpretieren will?
Sie machen einfach ein MSTCP(.dll...) und fertig..SCNR
>
> Gruss
> Bernd
Juergen Ilse
Stefan Heinecke <s...@hub.ircelite.org> wrote:
> Juergen Ilse <il...@asys-h.de> wrote:
>>sondere "ist bereit auf diesem Port neue Verbindungen entgegenzunehmen".
>>In diesem Sinne ist die Anzeige des "LISTEN" Status fuer den Source-Port
>>der Verbindung schlicht falsch (und ist bei anderen Systemen in der Regel
>>auch nicht vorhanden).
> ACK.
>>In jeder sinnvollen Kommunikation setzt man eine bestimmtes Vokabular voraus.
>>Deine Interpretation des Begriffs "LISTEN" widerspricht dem gebraeuchlichen
>>Vokabular in Bezug auf TCP/IP Networking.
> Asche auf mein Haupt, bei mir steht Listening, bei Lutz Listen.
Windows gibt da auch "LISTENING" aus. Nur kann diese Angabe eigentlich
nur als "Status Listen" interpretiert werden, weil eben diese Angabe
"welche Ports sind im Status Listen" schlicht nicht vorhanden und damit
die gesamte Ausgabe nur noch SEHR MAESSIG sinnvoll waere...
In einigen Buechern wird dieser Status eines sockets z.T. auch nicht mit
Listen sondern mit Listening bezeichnet, folglich sollte man auch von daher
den Begriff nicht auf die Goldwaage legen...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Kein Weltraum links auf dem Geraet" | Internet POP Hannover
Marco S.
>"If the output (netstat -na) contains the following 3 lines:
>
>Active Connections
>
> Proto Local Address Foreign Address State
>
> TCP 192.168.0.17:139 0.0.0.0:0 LISTENING
> UDP 192.168.0.17:137 *:*
> UDP 192.168.0.17:138 *:*
>
>you are vulnerable. There may be any number of additional lines. But
>these three (TCP .... :139 ... LISTENING, UDP .... :137 *:*, and UDP
>.... :138 *:*) are critical."
>
>Danach wird empfohlen, die Datei- und Druckerfreigabe zu deaktivieren
>(Windows ME). Was mich ein wenig irritiert, ist, daß diese drei Zeilen
>auch bei *deaktivierter Datei- und Druckerfreigabe* aufscheinen (W95).
(Erstmal "Hallo" an alle, da ich zum ersten Mal in diese Gruppe
schreibe ...)
Bei meiner W98-Version funktioniert es, allerdings ist zusätzlich auch
die Bindung "Client für Microsoft-Netzwerke" auf der Netzwerkkarte zu
entfernen - also *alle* Bindungen. Nach erneutem Booten hat W98 bei
mir automatisch auch die beiden Dienste aus der Netzwerk-Konfiguration
entfernt und zeigt zudem die Meldung "Das Netzwerk ist unvollständig.
Möchten Sie fortfahren?" an, außerdem ist die primäre Anmeldung von
nun an die Windows-Anmeldung. Netstat zeigt bei mir alles korrekt, das
heißt keine aktiven Bindungen an.
Übrigens finde ich die Bemerkung, daß man "vulnerable" ist, bloß weil
diese Verbindungen aktiv sind, etwas irreführend, da es meiner Ansicht
nach immer davon abhängt, was man mit seinem Netzwerk tun möchte und
wer Zugriff darauf haben soll. Nachdem ich die FAQ gelesen und den
Streit über selbige mitverfolgt habe, erscheint es mir so, als würde
es zunächst ausreichen, die Bindungen auf den DFÜ-Adapter zu kappen,
um vor Angriffen von außen weitestgehend geschützt zu sein.
Wenn Du nur mit Windows arbeitest und auf Dateien oder Drucker anderer
Win-Rechner in Deinem lokalen Netzwerk zugreifen möchtest, wird Dir
vermutlich kaum etwas anderes übrigbleiben, als die oben genannten
Dienste auf der Netzwerkkarte (nicht dem DFÜ-Adpater!!!) wieder
einzurichten. Dann bist Du zwar immer noch lokal "verwundbar", aber so
wie ich das Konzept "Firewall" verstehe, geht es in erster Linie
darum, Datenaustausch zwischen zwei Netzwerken wohldefiniert zu
kontrollieren/begrenzen. Gegen "Hacker" im lokalen Netzwerk wärest Du
daher auch durch den Einsatz einer Firewall nicht gefeit.
Mehr Gedanken machen würde ich mir deshalb, wenn "netstat" zusätzlich
zu den von Dir erwähnten aktiven Verbindungen auch noch welche für
Deine dynamische (oder statische öffentliche) IP auflisten würde, da
dann auch jemand von außen auf diese Ports zugreifen könnte.
(Falls ich irgendwas falsch verstanden haben sollte, wird mich sicher
bzw. hoffentlich jemand korrigieren, der mehr Ahnung von der Materie
hat! :-)
Grüße,
Marco
--
Marco S., fire...@gmx.net, ICQ #65271891