Port 135 bringt mich noch mal ins Grab!!

Hallo zusammen,

nach wie vor schaffe ich es nicht, Port 135 zu schließen, obwohl ich alle notwendigen Dienste, entsprechend der bekannten im Internet kursierenden Anweisung zum Schließen von Ports, beendet, b.z.w. deaktiviert habe.

Eine Überprüfung aller offenen Ports ergab, dass Port 135 von svchost.exe (beschrieben mit Generic Host Process for Win32 Protocol oder ähnlich) genutzt wird. Diese Anwendung taucht laut Taskmanager bei den aktiven Prozessen 2 x auf.

Ein Portscan ergab folgendes Ergebnis:

135 0.0.0.0:0 ++++++++ Listening
1025 0.0.0.0:0 ++++++++ Listening
1026 0.0.0.0:0 ++++++++ Listening
8086 0.0.0.0:0 ++++++++ Listening
1102 213.153.38.220:0 server1.nwn.de Time Wait
110 0.0.0.0:0 213-153-38-220.stat.salzburg-online.at Time Wait
5000 0.0.0.0:0 ++++++++ Listening
5025 0.0.0.0:0 ++++++++ Listening
8080 0.0.0.0:0 ++++++++ Listening

Etwas verwundert hat mich zudem die Zeile "213-153-38-220.stat.salzburg-online.at"

Kann irgendjemand etwas mit diesen Meldungen und mit dem immer noch geöffneten Port 135 anfangen? Alle anderen angezeigten Ports sind geschlossen.

Gruß

Marc

 

>der xp-eigenen Firewall lasse ich lieber die Finger!

Warum ? Da ist doch nichts Besonderes bei.Du kannst nach Belieben deine Filterregeln definieren und Ports wieder freischalten wie z.B. FTP und anderes.Wenn Du\'s anspruchsvoller haben möchtest, dann definierst Du deine Sicherheitsrichtlinien für Portfilter mit dem Ipsec-Dienst, den du als Snap-In in den Konsolen-Stamm der mmc einbeziehen kannst.Microsoft hat das bewußt ziemlich versteckt, weil man sich damit auch seine Netzwerkkonfiguration schön kaputtkonfigurieren kann.Also etwas Einarbeitungszeit ist dafür erforderlich; die XP-Firewall ist da einfacher und unkomplizierter.Allerdings auch leichter auszuhebeln, weil man ja "nur" den alg.exe-Service beenden muss

franzkat

 

Wenn Du\'s mit ICS machst, dann öffnest du aber mit alg.exe den nächsten Port >3000, der geschlossen bliebe, wenn der Dienst nicht liefe.

franzkat

 

Wir hatten die Angelegebnheit hier im Forum ja schon mal ausführlich diskutiert.

http://forum.pcwelt.de/fastCGI/pcwforum/topic_show.fpl?tid=84306&pg=3

Trotzdem scheint sich von der Sache etwas geändert zu haben ( vielleicht durch SP1). Auch bei der Vorgehensweise, die die DCOM-Funktionen deaktiviert und die dazugehörigen Protokolle löscht, wie auf kssystem.de beschrieben, bleibt Port 135 TCP offen. Damals konnte ich ihn tatsächlich durch diese Maßnahme schließen.Das Sinnvollste scheint wirlich zu sein, die XP-eigene Firewall zu aktivieren, die zumindest den Inbound-Traffic auf diesen Port filtert, auch wenn er nicht geschlossen wird.
Hast du mal die ipseccmd-Sache getestet ? Ich befürchte, dass sie nur bei der Prof-Version funktioniert, obwohl das Programm auch auf der HE-CD unter Support/Tools zu finden ist. An sich ist das ein guter Ansatz.Ich muss mich mal näher mit dem Ipsec-Dienst beschäftigen, den man ja mit der mmc als Snap-In integrieren kann.

franzkat

 

"Hinweis:

Folgende Anleitung bezieht sich auf eine Standardinstallation von Windows XP Professional und dem Einsatz auf einem Einzelplatzrechner mit nur einem Benutzer."

 

Das Problem ist, wenn du den Port 135 auf diese Weise deaktivierst, dann fehlen Dir zentrale LAN-Funktionen.

franzkat

 

Hallo,

wie man Port 135 und andere, sowie verschiedene Dienste auf leichte Art undf Weise "Dicht" bekommt steht hier http://kssysteme.de/s_content.php?id=fk2002-01-31-3823

Andreas

 

Versuchs mal mit diesem Workaround, für den Du das Tool :
IPSecCmd.exe benötigst, welches Du auf der XP-CD in dem Ordner : Support\Tools findest (dort setup ausführen ) :

IPSecCmd.exe -dialup -x -w REG -p "Simple Packet Filter"
-r "Block inbound RPC EPMap" -n BLOCK -f *+0:135:TCP -f *+0:135:UDP

franzkat

 

VE DONE
. Microsoft has analyzed the reported vulnerability and determined it represents a critical vulnerability.
. Microsoft issued security bulletin MS03-026 and released a patch which is now available via Microsoft\'s Download Center and Windows Update.

WHAT CUSTOMERS SHOULD DO
1. Microsoft strongly encourages all customers to download and apply the patch for the following affected operating systems:
. Microsoft Windows NT 4.0, Windows NT 4.0 Terminal Services Edition, Windows 2000, Windows XP and Windows Server 2003.
2. In addition to applying the patch, in line with good security practices, customers should protect their networks through the use of a firewall.
. Best practices recommend blocking all TCP/IP ports that are not actually being used. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet.
. Consumers should use a personal firewall technology such as Internet Connection Firewall in Windows XP.

QUESTIONS AND ANSWERS
Q: How serious is this vulnerability?
A: Microsoft has rated this vulnerability "critical" which means that arbitrary code could potentially be executed without user intervention. However, at this time, it is only a vulnerability, no known public exploits exist, nor do we know of any customers who have been impacted.

TECHNICAL BACKGROUND
Technical description:
Microsoft originally released this bulletin and patch on July 16, 2003 to correct a security vulnerability in a Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface. The patch was and still is effective in eliminating the security vulnerability. However, the "mitigating factors" and "workarounds" discussions in the original security bulletin did not clearly identify all of the ports by which the vulnerability could potentially be exploited. We have updated this bulletin to more clearly enumerate the ports over which RPC services can be invoked, and to ensure that customers who have chosen to implement a workaround before installing the patch have the information that they need to protect their systems. Customers who have already installed the patch are protected from attempts to exploit this vulnerability, and need take no further action.

Remote Procedure Call (RPC) is a protocol used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program running on one computer to seamlessly execute code on a remote system. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol, but with the addition of some Microsoft specific extensions.

There is a vulnerability in the part of RPC that deals with message exchange over TCP/IP. The failure results because of incorrect handling of malformed messages. This particular vulnerability affects a Distributed Component Object Model (DCOM) interface with RPC, which listens on TCP/IP port 135. This interface handles DCOM object activation requests that are sent by client machines (such as Universal Naming Convention (UNC) paths) to the server. An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing changing or deleting data, or creating new accounts with full privileges.

To exploit this vulnerability, an attacker would need to send a specially formed request to the remote computer on specific RPC ports.

Mitigating factors:
. To exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135, 139, or 445 or any other specifically configured RPC port on the remote machine. For intranet environments, these ports would normally be accessible, but for Internet connected machines, these would normally be blocked by a firewall. In the case where these ports are not blocked, or in an intranet configuration, the attacker would not require any additional privileges.
. Best practices recommend blocking all TCP/IP ports that are not actually being used. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet. More robust protocols such as RPC over HTTP are provided for hostile environments.

To learn more about securing RPC for client and server please refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/writing_a_secure_rpc_client_or_server.asp.

To learn more about the ports used by RPC, please refer to http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp

Severity Rating:
Windows NT 4.0 Critical
Windows NT 4.0 Terminal Server Edition Critical
Windows 2000 Critical
Windows XP Critical
Windows Server 2003 Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.
Vulnerability identifier: CAN-2003-0352

Tested Versions:
Microsoft tested Windows Me, Windows NT 4.0, Windows NT 4.0 Terminal Services Edition, Windows 2000, Windows XP and Windows Server 2003, to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by this vulnerability."

franzkat

 

http://www.windows-netzwerke.de/inetfreigabe.htm

 

ok, danke! :-)

Werd heute Abend mal nachschauen.

Schönen Tag noch.

Marc

[Diese Nachricht wurde von UserError am 02.08.2003 | 15:00 geändert.]

 

tja und wo genau finde ich die Möglichkeit dieser Einstellung?

 

Gut, werde ich machen.

Es wäre aber nett, wenn du mir sagen könntest, was ICS ist. Von der xp-eigenen Firewall lasse ich lieber die Finger! :-)
[Diese Nachricht wurde von UserError am 31.07.2003 | 11:47 geändert.]

 

Hi maenneken,

auch dir vielen Dank für die Hilfe!

Wenn ich mir den Forenthread des o.g. Links so anschaue, dann scheint es nicht unmöglich zu sein, den Port 135 zu schließen. Zumindestens bei Win98 hat es der Threadersteller geschafft. Ich habe allerdings leider XP pro! :-(
Ich kann mir einfach nicht vorstellen, dass es wirklich unmöglich sein soll.

Eine PF will ich nicht benutzen und für eine Hardwarefirewall fehlt mir zur Zeit das Geld.

Muss ich dann wohl leuchten! :-)

Gruß

Marc

 

Hi franzkat,

danke für deine Info! Werde mich jetzt erstmal über die Seite hermachen.

Habe übrigens keinen Portscan in dem Sinne gemacht, sondern die Firewall Outpost gestartet, um die notwendigen Informationen zu offenen Ports zu erhalten. Outpost ist da sehr mitteilungsfreudig! :-)
Die Salzburger Adresse kann also nicht von einer offenen Verbindung zu der von dir beschriebenen Seite sein, da ich keinen Onlinescan durchgeführt habe.

Gruß

Marc

 

Die Salzburg-Adresse ist wahrscheinlich noch eine offene Verbindung zu der Anti-Trojaner-Seite, über die Du Deinen Portscan gemacht hast. Ansonsten : Alles , was Du über den Port 135 wissen mußt, findest Du in dieser Diskussion :

http://pub15.ezboard.com/fsecurityboardsfrm6.showMessage?topicID=610.topic

franzkat