Why Does IIS Answer HTTP Requests w/ NetBIOS Reply?

PGillingwater writes: "Whilst configuring access control lists on our Cisco router today, I noticed a very large amount of traffic coming in on UDP port 137, to many different addresses within our Class B range. They seemed to be coming also from a range of addresses outside, with no obvious pattern. Further investigation showed that most of those incoming packets originated from Web servers running IIS version 4. This suggests that our users are sending an HTTP GET request on port 80, and the IIS server immediately responds with a UDP NetBIOS reply packet to port 137/UDP, probably as some sort of attempt to find the NetBIOS name, or maybe some form of RPC authentication service. Inquiring minds want to know! Does it strike anyone as unusual that HTTP has been "extended" in this way by Microsoft? Naturally, we're blocking it, but I'm curious as to what the IIS server does with this information, and just how much does it expose security-related information of sites that don't block those ports." Can anyone else validate this behavior, and/or offer up guesses as to the reasons behind it?

The Microsoft KB sayeth

[JArneaud]

I found this interesting article (id: Q245574) [microsoft.com] that may apply.

Evidently you can configure IIS to do reverse DNS lookups (which are disabled, by default) but it adds a special Microsoft-flavoured twist. If the standard reverse lookup fails, it tries to retrieve a name from the remote client using NetBIOS.

Could this be the source of your UDP requests? You can try connecting to the servers in question from a machine with working Reverse DNS entries to see if it still happens (according to the article, it should not).

-------------------------

By default, performing a Request.ServerVariables("REMOTE_HOST") in ASP returns a null value, which causes Internet Information Server (IIS) to return the value of REMOTE_ADDR, the IP address of the client. This is by design to increase performance for Web hosting. However, by changing a setting in the metabase, IIS performs a reverse DNS lookup and returns the host name of the client connecting.

With the metabase setting enabled, every request for the REMOTE_HOST server variable causes IIS to pass a name resolution request off to the operating system, which attempts to execute a reverse DNS lookup. If the reverse DNS lookup fails to return the host name, the operating system then attempts name resolution using NetBIOS. If NetBIOS resolution fails an empty value is returned to IIS, which returns the REMOTE_ADDR value (client's IP address) to the original REMOTE_HOST request.

host lookups

[darkrot]

Do your hosts resolve reversely? (ie 1.2.3.4 -> ppp123.moo.com) gethostbyaddr() and WSA-variants will attempt a netbios machine name lookup if gethostbyaddr() fails. This is a windows internal, so it's not just IIS, but every machine running windows doing a DNS lookup on an IP which has no reply (or timely reply).

Re:The Microsoft KB sayeth

[pangloss]

Ah! I always wondered what the source of this behavior was (thanks JArneaud!). ZoneAlarm [zonelabs.com] users are probably used to seeing the blocked UDP alerts as well.

Can the originator of this Ask Slashdot confirm/deny JArneaud's/MS KB's theory that this behavior should cease with a client with a working remote dns entry?

Re:The Microsoft KB sayeth

[jellicle]

I routinely browse from a static IP with a working reverse DNS entry, and I've noticed that browsing some websites generates a storm of NetBIOS connection attempts (which are logged by my firewall). So, the answer above may be good, but it's incomplete: in at least some cases, NetBIOS requests can be generated for IPs which have perfectly good reverse DNS entries. Why?

It makes sense, in a way...

[PhilBrut]

In a way, it make sense that IIS can do that - it runs on NT and Win2k, which resolves names via NetBIOS that it can't resolve via DNS.

It also goes to show that you *really* shouldn't trust an NT system that's not protected by a firewall - you never know what it's going to spew out to the world next.

I haven't seen this with IIS...

[grunby]

Well I haven't taken the time to check it out so this may in fact be happening...Just wanted to mention that Microsoft "extends" many standardize applications, protocols, RFCs...
The telnet client for windows 2000 is a good example of this...The shipped/unpatched telnet binary of windows 2000 will try and authenticate first using NT challenge/response...If that fails, it will proceed to the normal interactive server login/prompt. I think this "feature" was supposed to be used in conjunction with a Microsoft telnet server which can authenticate using NTLM.
Kinda scary...actually, very scary...Thank god I've been using scrt as my telnet/ssh client...

- [grunby]

BTW: MS has released a patch for the above mentioned bug located here [microsoft.com]

Doesn't surprise me....

[fwc]

Microsoft does this kinda thing. A good example of it working the other way is from one of my clients.

We have several Win98 machines with File/Print sharing turned on. TCP/IP is installed on the machines and is used for internet through a dial-on-demand server. We have unbound TCP/IP from anything to do with file/print sharing and microsoft networking.

Whenever they go to print, Win98 sends out a query to the DNS servers for the address of the machine the printer is attached to. Why it does this, I have no clue, but it is sure annoying that every time they print, their internet connection dials up.

Re:I haven't seen this with IIS...

[TheRealSlimShady]

The shipped/unpatched telnet binary of windows 2000 will try and authenticate first using NT challenge/response...If that fails, it will proceed to the normal interactive server login/prompt

Or you could just type "unset NTLM" when you start the Telnet client.
The NetBIOS traffic could be authentication traffic, if you have NTLM authentication turned on on the web site. If you don't need it, turn it off

Re:The Microsoft KB sayeth

[PGillingwater]

As the originator of this topic, I can confirm that most of our clients do not have a valid IN-ADDR ARPA response, as we are running a split horizon DNS. I'll ask my DNS guy to set up a generic response, and see what happens.

Thanks to everyone for their constructive response. It's looking like NetBIOS-NS "Name Query" probes are being sent by IIS servers that want to log a name in the access log.

This isn't a new discovery, as I discovered here [cantech.net.au] and here. [linuxsa.org.au] From a security point of view, it's noise that could be masking an attack from the Network.vbs [sdsc.edu] worm.
--
Paul Gillingwater

Authenitcation

[duplicate-nickname]

Your IIS servers are trying to use NTLM authentication with the users. If you don't want this happening, tell you NT admins to uncheck the 'Use NT Authentication' box in IIS.

This isn't acutally a bad thing. It provides a level of encryption for IIS to IE authentication without SSL. Obviously you're not using it, and probably blocking NetBIOS at your firewall....so just disable it.

Re:The Microsoft KB sayeth

[Stavr0]

... I've noticed that browsing some websites generates a storm of NetBIOS connection ...

Try GRC.COM [grc.com], it does just that when you try the ShieldsUP tester ...
---
Inanimate Carbon Rod thanks you for your support. See you in 2004!

The data this IIS query mines from your machine

[EMIce]

Below is the data your windows machine returns to IIS or any machine making this sort of a request:

C:\>nbstat -A 10.10.10.6

NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------
LINDSAY <00> UNIQUE Registered
LINDSAY <20> UNIQUE Registered
HOUSE <00> GROUP Registered
LINDSAY <03> UNIQUE Registered
HOUSE <1E> GROUP Registered
ADMINISTRATOR <03> UNIQUE Registered

MAC Address = 00-E0-29-6F-0D-48

Where LINSDAY is your computer name, HOUSE is your workgroup and ADMINISTRATOR is the current user logged in(often a real name in Win9x!). MAC address too! I've used this to nab trolls on IRC when they've come in with a new IP and nickname. It's a lot more specific and persistent than an ip address. In fact, it's a 100% unique key that doesn't ever change. At least the MAC and almost always the rest. I'm surprised more websites haven't begun doing this to track users. Or are they using it?

Worms

[LWolenczak]

There are also several windows worms. I see requests from windows boxes all over the world to port 137 on my masquerading firewall. Most computers that request to port 137 on my firewall, are just random systems out on the net.

You can probilly find info on the worms at www.securityfocus.com