Re: svchost.exe connect port 80 and 443

From: Duane Arnold (notme_at_notme.com)
Date: 02/23/04 

Date: Mon, 23 Feb 2004 04:01:48 GMT

Pedro <no@spam.com> wrote in
news:Xns949819A95E083nospamcom@213.228.128.15:

> Duane Arnold <notme@notme.com> wrote in
> news:Xns9497B533D264Bnotmwnotmecom@204.127.199.17:
>
>>> No, I don't think it's anything related to any software that I've
>>> installed. Though now that I've runned Spybot it found the old DSO
>>> exploit, so thanks for that. I don't even use IE (i'm using Opera).
>>> From what I've learned browsing in several sites port 80 and 443 are
>>> used by svchost.exe when one is operating a web server in a
>>> computer. So I created a rule in Sygate to block inbound connections
>>> on both port 80 and 443, all hosts, TCP remote ports, incoming
>>> traffic, Generic Host Process for Win32 Services
>>
>> <snip>
>>
>> Port 443 is used for secure web browser communication. Data
>> transferred across such connections are highly resistant to
>> eavesdropping and interception. Moreover, the identity of the
>> remotely connected server can be verified with significant
>> confidence. Web servers offering to accept and establish secure
>> connections listen on this port for connections from web browsers
>> desiring strong communication security.
>>
>> Once established, web browsers inform their users of these secured
>> connections by displaying an icon — a padlock, an unbroken key, etc.
>> — in the status region of their window.
>>
>> The "s" in "https" stands for "secure": Hyper Text Transfer Protocol,
>> Secure. You may encounter other s-suffix protocols such as ftps or
>> smtps. These, similarly, refer to secured-transport versions of the
>> base protocol.
>>
>> In the case of https, whereas the default port used for standard non-
>> secured "http" is port 80, broswer use 443 to be the default port
>> used by secure http.
>>
>> Some firewalls filter SSL or port 443 traffic. If this is the case,
>> your browser will time out trying to access the SSL-protected areas
>> of the IT- Solutions website, by timing out when you try to connect.
>>
>> related ports 80, 81, 82, 8080 and 8090
>>
>> <snip>
>>
>>> Still, sometimes I see in Connection Details svchost.exe CONNECTED
>>> to remote port 80. Port 443 never appeared again. In Application
>>> Details there isn't any considerable traffic outgoing or incoming in
>>> the Generic Host Process for Win32 Services. In fact the only
>>> traffic going on right now is in Opera and mIRC. So I guess there
>>> isn't any reason to feel worried, even if the port 80 connection
>>> with svchost.exe showed a few hours ago with a different IP adress
>>> from mine leaves me a bit suspicious.
>>>
>>> If anyone has more opinions on this feel free to to add something in
>>> this thread.
>>>
>>
>> Well, you should not be blocking SVCHOST/Generic Host Process from
>> communicating, because that's its job is to communicate on the LAN or
>> WAN for the NT based O/S. So, it will lead to you not being able to
>> access some legit sites when needed. It's the messenger for the O/S
>> and should you kill the messenger just because it delivered the
>> message? You should be trying to find out what's using the messenger
>> and killing it.
>>
>> So, one day you let the messenger communicate for some reason,
>> because you had to. What happened to all the other stuff you were
>> killing the messenger for and you didn't know what it was using the
>> messenger.
>>
>> The only time you should be killing the messenger (svchost.exe) is if
>> it is NOT running out of Winnt or Windows \system32 directory for NT
>> 4 and Win 2K or Win XP or 2K3.
>
> Well, thanks for your explanetion, but a short time after I disabled
> the advanced rules to block ports 80 and 443 connected to an IP adress
> through svchost.exe. What is causing this I have no idea. In Windows
> Task Manager I don't notice anything strange. There is 4 entries for
> svchost.exe. 2 with user name SYSTEM, 1 with user name NETWORK
> SERVICE, and another one with user neme LOCAL SERVICE. I assume this
> is normal(?)
>
> At command prompt with "Tasklist /SVC" I get this results:
> Image Name PID Services
> ========================= ======
> =============================================
> System Idle Process 0 N/A
> System 4 N/A
> smss.exe 376 N/A
> csrss.exe 432 N/A
> winlogon.exe 456 N/A
> services.exe 500 Eventlog, PlugPlay
> lsass.exe 512 PolicyAgent, ProtectedStorage, SamSs
> svchost.exe 668 RpcSs
> svchost.exe 712 AudioSrv, Browser, CryptSvc, Dhcp,
> dmserver,
> ERSvc, EventSystem,
> FastUserSwitchingCompatibility,
> helpsvc,
> lanmanserver, lanmanworkstation,
> Messenger,
> Netman, Nla, Schedule, seclogon,
> SENS, ShellHWDetection, srservice,
> TermService,
> Themes, TrkWks, uploadmgr, W32Time,
> winmgmt,
> WmdmPmSp, wuauserv
> Smc.exe 748 SmcService
> svchost.exe 860 Dnscache
> svchost.exe 888 LmHosts, RemoteRegistry, SSDPSRV,
> WebClient
> spoolsv.exe 936 Spooler
> CCEVTMGR.EXE 972 ccEvtMgr
> NAVAPSVC.EXE 1308 navapsvc
> explorer.exe 1696 N/A
> ccApp.exe 1928 N/A
> msmsgs.exe 1976 N/A
> ctfmon.exe 1984 N/A
> emule.exe 1052 N/A
> opera.exe 1456 N/A
> cmd.exe 1824 N/A
> tasklist.exe 1900 N/A
> wmiprvse.exe 1920 N/A
> =====
>
> Also don't see nothing unusual, but maybe someone with more knowledge
> than me can check if there is something wrong in here. In relation to
> the SSL secure traffic, I've terminated the svchost.exe that were
> connected, enabled again the rules for blocking port 80 and 443 in
> Sygate, and restarted Windows XP. And then tried to enter in this site
> https://www.mbnet.pt/ and have no problem at all accesing it. So I
> think am gonna leave Sygate blocking port 80 and 443 for now.

The list of exe(s) is just that -- a list of exe(s) or processes running
on the machine. It doesn't show what hidden processes like dll's, ocx's,
etc. etc.

Sygate is just like any other *stateful* FW application. If a program on
the machine solicites the traffic from a remote site by sending outbound
traffic to the remote site, then the FW is going to allow that traffic
back to the machine, which is what you did with the browser. And
obviously Opera must be configured to do HTTPS connections. So the rule
that you made will only stop unsolicted traffic from coming down port 80
and 443. But since spyware can be on the machine and make the
solicitaion, what have the rules done for you? You have the rules in
place now, so go back and see if the traffic is being stopped from that
HTTPS site you're talking about, and the connection on 443.

What that really means is that spyware or a Trojan is on the machine, it
most likely has beaten Sygate to the punch during the boot process and
has started and done its thing before Sygate can even get there and stop
it, especally if something is sitting there listening on the port(s). You
can use Active Ports (free use Google) and put a short cut in the Startup
folder to get a clear picture on what is making connections.

>
> Just out of curiosity, those who have Windows XP SP1 could verify if
> they have the following folders inside C:\Documents and Settings\Your
> Name\My Documents\My Web Sites:
> 1)_private (empty)
> 2)_vti_cnf (empty)
> 3)_vti_pvt (with the following files: fpdbw.ico, botinfs, bots,
> services, structure, service [all with Type "SpeedDial"],
> deptodoc.btr, doctodep.btr, linkinfo.btr, service.lck)
> 4)images (empty)

And no, I don't have folders or files like that on any of my XP machines.

>
> The files with extension ".btr", "structure", "service", and
> "service.lck" have date modified similar to the creation of the htm
> file in Frontpage 2003 that was deleted the day after since it had
> some strange code.
>
> Thanks for reading!
>
>

Maybe, what you should be doing is using something like Process Explorer
(free) to look inside the svchost.exe in question and see what's using it
and killing it, instead of killing svchost.exe that is only the
messenger. And making rules for 80 and 443 maean nothing if with the
browser, you can access a HTTPS site and 80 and 443 are being used when
you do it, because malware on the machine will be able to do it too.

Duane :)

Loading