CentOS - Sep 2008 - Perhaps slightly OT - Lots of spurious webdav requests.

Hello All,

I am running a CentOS 4.6 file server for a small office network and I
am getting a lot of strange webdav requests from one of the Windows
workstations - I have not configured Webdav on the Windows host
(hereafter "windows-laptop") in question.

Some details - I have configured a Samba share called (say) "share1"
on the CentOS server and the windows-laptop connects to this share
using CIFS, nothing unusual there. But, for some reason,
windows-laptop also tried to access a Webdav folder by the same name
("share1") - lots of log entries such as the following (it seems to
try every two minutes):

10.11.1.95 - - [14/Sep/2008:04:10:32 -0400] "OPTIONS / HTTP/1.1" 200 -
"-" "Microsoft-WebDAV-MiniRedir/5.1.2600"
10.11.1.95 - - [14/Sep/2008:04:10:32 -0400] "PROPFIND /share1
HTTP/1.1" 405 312 "-"
"Microsoft-WebDAV-MiniRedir/5.1.2600"

I have most assuredly not told windows to try and use a Web folder on
the CentOS file server called "/share1", just the CIFS share.

My conclusions -

* Windows is trying to be clever and automatically map CIFS shares to
a Web folder.
* Malware is trying to access a Webfolder by same name as CIFS share.

Any hints from the list would be much appreciated!

Thanks,

Fred.

--On Monday, September 15, 2008 10:05 AM +0200 Friedrich Clausen 
<fred at derf.nl> wrote:
> I have most assuredly not told windows to try and use a Web folder on
> the CentOS file server called "/share1", just the CIFS share.
Apparently Windows will search multiple "providers" for the share
string
you pass, and the successful results are then sorted by provider priority.
>From <http://support.microsoft.com/kb/832161>
> When an application tries to open a file that exists on a network, the
> I/O manager passes the request to a system component that is named the
> Multiple UNC Provider (MUP). MUP sits logically above all the
> redirectors. When a network path is passed to MUP, it polls all the
> registered redirectors to determine whether they understand the path. The
> redirectors in turn contact the server to establish if the path is valid
> for the specific protocol. If the server can satisfy the connection, the
> redirector will return success back the MUP. If not, the redirector
> returns a failure. All the future file I/O requests for this file are
> passed to the redirector that accepted the path. If more than one
> redirector accepts the path, MUP picks the one with the highest priority,
> as defined in the registry.

On Mon, Sep 15, 2008 at 10:58 AM, Kenneth Porter <shiva at
sewingwitch.com> wrote:
> --On Monday, September 15, 2008 10:05 AM +0200 Friedrich Clausen
> <fred at derf.nl> wrote:
>
>> I have most assuredly not told windows to try and use a Web folder on
>> the CentOS file server called "/share1", just the CIFS share.
>
> Apparently Windows will search multiple "providers" for the share
string you
> pass, and the successful results are then sorted by provider priority.
Ah yes, I believe you are right. Thanks for the info!

Regards,

Fred.
>
>> From <http://support.microsoft.com/kb/832161>
>
>> When an application tries to open a file that exists on a network, the
>> I/O manager passes the request to a system component that is named the
>> Multiple UNC Provider (MUP). MUP sits logically above all the
>> redirectors. When a network path is passed to MUP, it polls all the
>> registered redirectors to determine whether they understand the path.
The
>> redirectors in turn contact the server to establish if the path is
valid
>> for the specific protocol. If the server can satisfy the connection,
the
>> redirector will return success back the MUP. If not, the redirector
>> returns a failure. All the future file I/O requests for this file are
>> passed to the redirector that accepted the path. If more than one
>> redirector accepts the path, MUP picks the one with the highest
priority,
>> as defined in the registry.
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>