DCOM deaktiviert, NetBIOS über TCP/IP aus usf -> Trotzdem Port 135 offen -_-

Mr.Mito

Admiral, Altweintrinker
Thread Starter
Mitglied seit
03.07.2001
Beiträge
20.981
Ort
127.0.0.1
Schönen guten Abend,

ich habe über die Komponentendienste (DCOMCNFG.EXE) DCOM deaktiviert, die Bindung an die Protokolle entfernt und bei den Netzwerkadaptern noch NetBIOS über TCP/IP ausgeschaltet.

Trotzdem zeigt mir svchost.exe noch ein "lauschen" auf Port 135 (nachgeschaut mit viewtcp).

Die svchost ist sauber (virustotal) und es gibt auch keinen Traffic über den Port. Wieso ist der noch auf? Was hab ich vergessen? :hmm:

XP x64 / alle Updates

Wäre nett wenn mir jemand weiterhelfen könnte. :)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mit der XP Firewall kann man keine Ports sperren, mal davon abgesehen, dass das reine Symptombekämpfung wäre. :fresse:

Habs selbst gefunden:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet

PortsInternetAvailable"="N"
UseInternetPorts"="N"

Fehlte noch. Jetzt ist der Port komplett dicht bzw. es gibt ihn nicht mehr. Trotz allem danke für deine Hilfe! :)
 
Wo kann man denn mit der Windows XP FW Ports sperren? Rein der Neugier halber.

Zumal der Port/Dienst dann ja nach wie vor lauschen würde, nur die FW eben die Paketannahme blockiert. Daher sagte ich dazu auch Symptombekämpfung. :fresse:

Aber interessieren würde mich das wirklich. Konnte die Option nämlich nicht finden. :hmm:
 
Jop, danke. Ich finde das blinde Verlassen auf eine PFW irgendwie ziemlich mager. Die Windows FW ist trotzdem an, da sie nichts kostet und auch keine Leistung frisst - das wars aber auch.
Zumal dann eben nichts geschlossen ist, sondern mal nur nen Stopschild davor knallt. Das Vorgehen missfällt mir schon an anderer Stelle. ;)
Wenn mal wieder eine Lücke ausgenutzt werden sollte, würde das wenig helfen.

Im LAN bringt es sogar gar nichts bei bestimmten Systemdiensten/Ports und genau darum geht es bei meinem Port 135.

Dein Ansatz geht ja deutlich weiter, ich frage mich aber, was man dabei praktisch gewinnt, außer mögliche Inkompatibilitäten.
Sicherheit und keine Inkompatibilitäten. Man sollte nur selbst wissen, was das eigene System so nutzt. Mein Ansatz ging darum die Ports wirklich zu schließen. Dein Ansatz wollte diese nur verstecken - da und angreifbar wären sie trotzdem gewesen. ;)

Ich nutze auch ein Netzwerk, nur eben ohne klickibunti und habe 0 Probleme, seit Jahren. Port 135 war nach einigen Windows Updates wieder auf, weshalb ich diesen wieder schließen wollte. Der einzige Systemport der bei mir lauscht, nachdem Windows gebootet hat, ist 445.

Und so sieht es im ganzen Netzwerk aus. Es ist nur auf, was wirklich auf sein muss. Alles andere ist zu und der Router fährt ne Whitelist Strategie.

Im privaten Umfeld mag das übertrieben sein, aber nun ja, ich nenne es konsequent. Zudem sind wir hier ja nicht bei Giga und ein Stückchen "Wäääwäää will was basteln wäää" fließt da auch mit rein. :fresse:
 
Zuletzt bearbeitet:
Die Ports sind hinter der FW aber nach wie vor auf und lauschen, daher ist das für mich nur ein "verstecken der Dienste/Ports".

Das Türbeispiel ist gut. :d Ich habe einen Raum komplett entfernt und du hast eine Tür davor aufgestellt, der Raum dahinter ist aber nach wie vor vorhanden und vollständig eingerichtet. :fresse: Zumal ein anderer Eingang (LAN) zu dem Raum dauerhaft offen ist. xD

Ich kann deine Argumentation schon nachvollziehen, habe da aber etwas kritischere Ansichten. Wenn man einen Dienst nicht braucht/nutzt, so sollte man ihn in meinen Augen komplett abschalten, denn nur das ist wirklich sicher. Bei einer Lücke in der FW oder einem bypass - welcher Art auch immer - wäre dein Schutz ausgehebelt, meiner nicht. Es würde ja schon reichen wenn jemand mit deiner Erlaubnis dein Netzwerk nutzt und sein Notebook einen neuen Wurm hätte, der (mal wieder) irgend einen 0day exploit in Dienst XYZ - der im LAN nicht blockiert wird - ausnutzt. Zumal ich die FW ja zusätzlich aktiviert habe. :)
 
Zuletzt bearbeitet:
Die Ports sind natürlich "offen", da die Dienste laufen! Die PFW regelt nur den Zugriff auf die Dienste dahinter. Und ein nmap hat eben keine Erlaubnis im PFW Regelwerk, somit wird der Verbindungsversuch verworfen und als geschlossen angezeigt.
Dienste beenden heißt Ports schließen und nicht irgenwelche Zugriffsregelungen einführen ...

Greetz

NetworkerZ
 
Zuletzt bearbeitet:
Zumal er die W7 FW zur Hand nimmt und es um Windows XP ging.

@Bob Dig.

Führ einfach mal viewtcp oder ähnliches aus und du wirst sehen das die Ports alle samt lauschen. Geschlossen hast du nämlich gar nichts. Nur weil du die Anzeige dessen "verdeckst", sind die noch lange nicht "weg". Wie gesagt, typisches Stop Schild Verfahren. ;)

Und dazu:
Während du also einen Port zugemauert hast, habe ich alle (getesteten) Ports geschlossen. :fresse2:
sage ich nur (erneut)
Mr.Mito schrieb:
Der einzige Systemport der bei mir lauscht, nachdem Windows gebootet hat, ist 445.

Unabhängig davon, dass du nichts geschlossen hast. ;)

Egal ob nun irgend eine Software Firewall etwas mehr Scheinsicherheit suggeriert oder eben nicht. Ports schließen heißt Dienste beenden und nicht Stop Schilder davor aufbauen. Denn nur dann ist der Dienst/Port wirklich weg/zu und nicht von einer (ggf. fehleranfälligen) Softwarekomponente abhängig, auf die du dich aktuell blind verlässt.
Das ist reine Symptombekämpfung, wie schon mehrfach gesagt.
 
Zuletzt bearbeitet:
Logischerweise geht es hier um Netzwerkdienste, die auch einen Port öffnen um ihren Dienst anzubieten. Oder denkst du, deine Firewall schütz auch die anderen Windowsdienste ;)

Zudem habe ich deinen Post weiter oben auch so verstanden, dass du meinst, die Ports wären geschlossen, aber gut, du weißt ja wie PFW funktionieren und mir musst du es auch nicht erklären. Mr. Mito's PC ist jedenfalls sicherer als deiner, so wie ich das sehe.

Greetz

NetworkerZ
 
Zuletzt bearbeitet:
Wenn alle Ports, die man nicht nutzt, zu sind, braucht man keine Software mehr, die eine künstliche Barriere zu den Diensten errichtet, da es die Dienste/Ports nicht mehr gibt! Und was nicht vorhanden ist, kann nicht angegriffen werden - sollte einleuchtend sein, denke ich. -_-

Mein Rechner bietet ohne Firewall einen Port an, der lauscht. Deiner im LAN mit PFW, wo das LAN als sicheres Netzwerk zählt, schon 10. Fällt der Groschen?
Zudem sagt dein obiger Screen im Endeffekt nichts aus, da alles relevante fehlt. Interessant wäre er wie folgt: KLICK

Kannst auch einfach netstat -a machen, wobei das nicht so klickibunti schön ist, wie viewtcp und co. :fresse2:

Scheinbar willst du einfach nicht verstehen wo der Unterschied zwischen "Software Barriere (PFW) davor" und "ist einfach nicht mehr vorhanden, daher auch nicht angreifbar" verstehen. ;)

Und das die Dienste bei dir trotzdem laufen ist nur so lange kein Problem, wie es keinen Exploit für deine Software Firewall gibt. Wie sagtest du so schön? Wach mal auf. :rolleyes:

Es ist einfach kein anständiges Sicherheitskonzept. Ich würde das höchstens als Ergänzung zu einem anständigen Konzept sehen bzw. mache es so.

Was machst du mit den ganzen anderen Windowsdiensten? Du setzt ja trotzdem eine Firewall ein.
Das gleiche wie auch mit den anderen - ich beende sie, wenn sie nicht benötigt werden und das sogar unabhängig davon, ob es nun Netzwerkdienste sind oder nicht.
Die Windows PFW läuft nur, weil sie vorhanden ist und nahe zu keine Ressourcen verbraucht. Scheinsicherheit würde ich mir keine nachinstallieren, keine Angst. Wenn ich jetzt sage, dass ich keine AV Software nutze und diese (für mich) absolut überflüssig ist, wirst du wahrscheinlich verzweifeln. ;)

EDIT:

PS:

Das einzige "Ding", das ich wirklich als Firewall bezeichnen würde, ist die stateful FW (Whitelist Betrieb) in meinem Linux Router. :p
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh