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@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.
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.
-
Friedrich Clausen -
Kenneth Porter