Home / server / Questions / 822682
Accepted
spongebob
Asked: 2016-12-26 14:07:55 +0800 CST

Windows tries to access the IPC$ share before the provided one

  • 772

I have a samba server where I have disabled access to the IPC$ share [1] for security reasons (users and shares enumeration, user info query, ...).

I can access the data shares on this server without problem from any Unix based computer with mount.cifs. However, when I try to access them from Windows computers (tested with Windows 7 and 10), I get an Access denied error just after providing my credentials.

After recording the SMB traffic, I noticed that Windows computers always do a Tree connect request on the IPC$ share before trying to access the share I provided (through map network drive or add network location). My samba server returns Access denied for the IPC$ share and Windows never tries to access the share I want.

So my question is how can I prevent Windows to do this useless request on IPC$ and just access the share I provided? Or at least how can I force Windows to access the real share after the IPC$ one returned Access denied?

Thank you in advance for your help and happy holidays!

Sponge bob

[1] https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/securing-samba.html#id2618877

windows samba server-message-block cifs ipc

1 Answers

  1. Best Answer

    So my question is how can I prevent Windows to do this useless request...? Or at least how can I force Windows to access the real share after..?

    The answer is that you can't! Sorry to say, but this is the case. However, although this is the true answer to your question - I don't want to sound unhelpful. I do want to help, so hopefully what follows is the best advice I can give that will prove useful to you in your situation.

    I am a professional penetration tester, and often use anonymous share access (such as IPC$) to obtain information about and break into systems for legitimate testing purposes. The key thing is to prevent enumeration of users and shares by an anonymous user (someone without valid credentials). Once valid credentials are obtained there are usually other ways of enumerating users (e.g. cat /etc/passwd), and it becomes less of a priority to an attacker anyway.

    The article you referenced contains the following:

    If you use this method, then clients will be given an `access denied' reply when they try to access the IPC$ share. Those clients will not be able to browse shares and may also be unable to access some other resources. This is not recommended unless for some reason you cannot use one of the other methods just discussed.

    The reason why it is not recommended is because "Those clients... may also be unable to access some other resources." Windows not being able to access any shares on the machine is an example of this. Unfortunately Windows requires access to IPC$ in order to view the other shares. If it can't see IPC$ it just assumes that no other shares are available and gives up.

    Linux client implementation of Samba works slightly differently and therefore doesn't experience the same problem. As there isn't a way round it, I would just ensure that the IPC$ share isn't giving away information to anonymous users.

    Using the Host-based protection and User-based protection sections of the article you sent are good ways of preventing undesirable access to all of Samba, including the IPC$ share from untrusted sources, and may well give you everything you need.

    However, further advice is available in specified sections of this page: https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

    Sections to look at:

    "access based share enum"

    "browseable" - setting to "no" on all shares (except IPC$) should prevent them showing up but windows should still be able to access

    "guest ok" - test whether setting to "no" on IPC$ share prevents Windows accessing other shares

    If you are using winbind then set the following to prevent enumeration of those:

    winbind enum groups = no
winbind enum users = no
    • 4