svchost.exe

Yes, this is Windows' Automatic Updates. And if you didn't know this, then you've understand the reason why you should not run any host-based packet filter or firewall without a clue.

The main problem is to check the addresses, nslookup couldn't get any domain for those adresses. If they had I'd seen that they where MS.

BTW: Firewalls should show the DNS-name, not only the IP :-(

That's a very arrogant and unhelpful thing to say to someone who just needs a bit of advice. You should be ashamed of yourself.

Whois?

/-----------------------------------------------------------------

c/p from one other whois query:

Akamai serves the images and streaming content for many of the most popular Internet web-sites. When you connect to a web-site your browser first contacts the content provider and downloads an html file. This file contains embedded URLs that tell your browser where to find all the objects necessary to finish displaying the page. In the case of an "Akamaized" site, these URLs point to the Akamai Network. Next, your browser makes connections to the URLs to obtain the images or streaming content. Again, for an "Akamaized" site, your browser will contact an Akamai server to obtain the requested items. Generally a TCP server listens on a well-known port < 1023 (for example port 80 for HTTP), and a TCP client connects from a port > 1023 assigned by the operating system. So a connection from port 80 of the Akamai server to a high numbered port on your machine, is a normal HTTP transaction. If you'd like to learn more visit the FAQ at

GeekTools Whois Proxy v5.0.4 Ready. Final results obtained from whois.arin.net. Results:

OrgName: Microsoft Corp OrgID: MSFT Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US

NetRange: 207.46.0.0 - 207.46.255.255 CIDR: 207.46.0.0/16 NetName: MICROSOFT-GLOBAL-NET NetHandle: NET-207-46-0-0-1 Parent: NET-207-0-0-0-0 NetType: Direct Assignment NameServer: NS1.MSFT.NET NameServer: NS5.MSFT.NET NameServer: NS2.MSFT.NET NameServer: NS3.MSFT.NET NameServer: NS4.MSFT.NET Comment: RegDate: 1997-03-31 Updated: 2004-12-09

RTechHandle: ZM39-ARIN RTechName: Microsoft RTechPhone: +1-425-882-8080 RTechEmail: snipped-for-privacy@microsoft.com

OrgAbuseHandle: ABUSE231-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: snipped-for-privacy@microsoft.com

OrgAbuseHandle: HOTMA-ARIN OrgAbuseName: Hotmail Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: snipped-for-privacy@hotmail.com

OrgAbuseHandle: MSNAB-ARIN OrgAbuseName: MSN ABUSE OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: snipped-for-privacy@msn.com

OrgNOCHandle: ZM23-ARIN OrgNOCName: Microsoft Corporation OrgNOCPhone: +1-425-882-8080 OrgNOCEmail: snipped-for-privacy@microsoft.com

OrgTechHandle: MSFTP-ARIN OrgTechName: MSFT-POC OrgTechPhone: +1-425-882-8080 OrgTechEmail: snipped-for-privacy@microsoft.com

# ARIN WHOIS database, last updated 2006-11-21 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database.

Results brought to you by the GeekTools WHOIS Proxy Server results may be copyrighted and are used with permission.

/------------------------------------------------------------------

So, eveything seems to be OK. Possible Windows update.

Ahh. I work at support (and have used news 10 years too) I'm used to it :-)

The strange think is that "nslookup" doesn't have info on the MS addresses. Why have Microsoft choosed to not DNS register thise IPs

But if you use the CyberAbuse Whois look-up they are all listed as MS ip addresses. In fact, I think it is safe to say that all 207.46.x.x numbers belong to MS

brianf

Well, what about informing yourself what Akamai is and that MS uses their loadbalancing service?

They can't. DNS and HTTP are distinct protocols.

1. I've given advice: It's definitely Windows Automatic Updates, as he suspected.
2. It's not even arrogant, it's just the truth. For actually gaining security with packet filter you required in-depth knowledge about TCP/IP and networking, including an understanding and overview of the hosts' services involved in your scenario. You can try without, but you won't achieve any security. But oh, it's so arrogant telling him about his misconception...

...said someone who is abusing Outlook Express as a newsreader, in a security-related group. Nuff said.

Well, the firewall could do a lookup on the IP address before displaying an alert box. This would aid the user in desiding.

Why should they have done this? It's good practice, but not required, to create PTR records in DNS. The hosts in question apparently are backend servers for Windows Update, maybe loadbalanced by Round Robin DNS.

cu

Keep in mind, though, that whois and nslookup do entirely different things. whois, when fed an IP address, returns information on the owner of the netblock the IP in question belongs to. nslookup OTOH returns a name resolved by a PTR record when fed an IP address. If there's no PTR record for that address, nslookup will certainly fail.

cu

It would have made it easier to deside if to allow/disallow access if you knew the name of the machine (them you could say "a-ha, it's that software trying to connect to it's update server, or similar...)

ORLY? Then how about your firewall reporting that there's traffic to someserver.windowsupdate.com. Would you approve that? How about windows-update.com, windowsupdate.net, windowsupdates.com or winupdate.org? Which of them would you approve? Which not? And why?

cu

Most do. However, this won't help when no DNS name is present or not reverse resolution is allowed.

Better log the DNS requests or run the DNS server yourself.

YARLY?

No approval for any. As we all know windowsupdate.com was a spoofing site from earlier time and got aquired by Microsoft, thus there's no reason to involve it with Windows Update. However, Microsoft to do this on their own, so at least Windows Update v6 requires access to

'nslookup' queries name servers. If the fools running the name servers don't know how to set them up, or don't care, then the information will not be there. You could use 'whois' which queries the registrar data bases, but microsoft didn't think you'd need to know that information, and didn't include the tool. There are toy web tools that can be used to query those servers.

Microsoft follow standards??? What a bizarre concept. They can't follow their own standards, why do you think they might even know about international standards?

Old guy

That was kind of cold there. I thought I was bad. I am suppose to be the

That's the excuse used by all arrogant people. What they don't understand (have never been taught) is how to tell the truth in a diplomatic way. Prejudice against Outlook Express users is just such arrogance. Ridicule Microsoft if you must but leave the users alone.

brianf

Huh? This was the diplomatic way. I respectfully pointed out the problem in his misconception.

What prejudice? Outlook Express and security being mutually exclusive is a well-known fact, so that why I should not expect any serious security advice from OE users.

On the other hand, if the header information was not genuine, I'd ask myself why anyone would spoof OE as useragent...