Have you tried disabling netbios over TCP/IP? Is integrated or journaled
authentication checked at all (even if anonymous is also checked) on that
web server's security tab? If so is there a DNS lookup for it? Was that
client 211.40.x.y in your http access log? If not maybe you should remove
netbios over TCP/IP on the interface your web server uses to talk to the
public Internet? There's a huge list of steps to take to secure an IIS
server depending on the version. Google for some checklists for securing
IIS and follow them.
"Miroslaw Slawek
Chorazy"
<mchorazy@depaul. To:
edu> <mducharme@cybergeneration.com>,
<focus-ms@securityfocus.com>
03/10/2005 11:52 cc:
AM
Subject:
Re: Question on IIS servers and
reverse lookup
In addition to that I would say setup listening devices (that record to
logs) in addition to the low-level packet capture.
I would use tools like PSInternals.com TDImon and TCPVIEW Pro, Regmon
They ought to give you more hints about what the system activity is as the
packet is being sent to that UDP:137 port.
slawek
"Maxime Ducharme" <mducharme@cybergeneration.com> 3/10/2005 12:23 >>>
good point
Audit is activated and I do not see failed or successful
login at this time range.
we do not run protected directories on IIS, these
are simple web sites with some ASP & ASP.NET code.
thx for the reply slawek
any other ideas ?
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
----- Original Message -----
From: "Miroslaw Slawek Chorazy" <mchorazy@depaul.edu>
To: <mducharme@cybergeneration.com>; <focus-ms@securityfocus.com>
Sent: Thursday, March 10, 2005 11:58 AM
Subject: Re: Question on IIS servers and reverse lookup
Do you have Security Audit turned on and see Failure Events of the
Logon/Logoff type timestamped at the same time when IIS tries to send the
NetBIOS Name Resolution (UDP:137) packet?
Maybe these are authentication attempts against your IIS Server coming from
the Internet and the IIS Server is sending a packet to destination asking
for Domain Name?
slawek
"Maxime Ducharme" <mducharme@cybergeneration.com> 3/9/2005 16:41 >>>
Hi to the list
We are running a new iptables firewall with
restrictives policies.
I just noticed that sometimes (between 1 an 4 packets per
weeks), our IIS 5.0 server try to send NetBIOS name
query on foreign IPs.
Here is a hex dump of that packet :
11:44:56.495348 x.x.x.x.netbios-ns > 211.40.x.y.netbios-ns: NBT UDP
PACKET(137): QUERY; REQUEST; UNICAST
0x0000 4500 004e b2bf 0000 8011 ff8f XXXX XXXX E..N.........hR.
0x0010 d328 913c 0089 0089 003a 6ff0 c7ee 0000 .(.<.....:o.....
0x0020 0001 0000 0000 0000 2043 4b41 4141 4141 .........CKAAAAA
0x0030 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0040 4141 4141 4141 4141 4100 0021 0001 AAAAAAAAA..!..
x.x.x.x is our server (i replaced hex dump with XXXX XXXX too)
Source : our server
Proto : UDP
Source port : 137
Dest : foreign server
Dest port : 137
I'd like to identify the source of these packets.
One thing that comes in mind is :
Would it be related to the option in IIS "reverse
lookup host" to log hostnames in the log file ?
I remember that nslookup() function of NT kernel
uses netbios if DNS doesnt reply anything
(correct me if i'm wrong).
There is not other inbound port than 80 opened.
Opened outbound ports are packets related to a already
opened connection on port 80 and DNS queries to our
servers. The server itself cannot open a connection
on Internet.
Since this server is hosting ASP & ASP.NET services,
I agree it would be possible to get access via
some crafted URLs or webapp attacks, but we didnt
see anything else than these packets.
Someone may enlighten me ?
Thanks in advance
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
