Sorry if this was asked before, but I've looked at other questions and couldn't find a match.
I've been getting a lot of Logon Type 2 and 3 attacks on my Win Server 2008 VPS (from different IPs). I've been wondering what would be the best way to deal with these?
I've also noticed that attackers use the newly created administrator username (not the default "Administrator"), so they are somehow getting this information from my VPS Active Directory. I do have a RDP access enabled (but not through the standard RDP port). I'm aware this is a security problem, but I need the access.
As a side note: using ShieldsUp I've discovered that ports 135 (DCOM Service Control Manager) and 445 (Microsoft Directory Services) are open to the world. Could this be the way the attackers are getting my account names? Is it safe to close these ports without locking myself out of my VPS?
Thank you for any hints.
UPDATE: I've blocked ports 135 and 445 using custom firewall rules. I've also created a new test account on the machine to see if the attackers are still getting the AD data. As @syneticon-dj suggested, I've also turned off File and Printer Sharing. Now I'm waiting so see if anything new appears in the event log.
UPDATE 2: After running this configuration for a few days, I haven't noticed any new attacks in my event log. So I guess the ports blocking + disabling sharing did the trick!
Best Answer
The user and share lists have indeed been available to anonymous users via SMB. But this has been ages ago - Windows NT has received a fix to be able to withhold this information and it is the default behavior on from Windows Server 2003. If you still are able to query a list of shares or users anonymously, you might have a misconfigured server.
Other than that, if you do not have clients needing SMB access at your public IPs, you should firewall them off, or, better yet, unbind the "File and print sharing for Microsoft networks" from the internet-facing interface:
If you need RDP, consider installing IIS on your server (if you haven't already), enabling the Terminal Services Gateway role and setting up a certificate / creating the access rules to allow RDP tunneling through HTTPS only (no direct RDP access). This way, you are reducing the risk of eventual problems in the RDP stack being exploited as the authentication has to complete before RDP-relevant information is exchanged. Also, you are protecting yourself from a possible MITM attack against Terminal Services by using verifiable certificates.
As long as your server is offering services which require authentication to the open internet, there cannot be anything preventing any user world-wide to try username/password combinations. But if your server is configured to only offer necessary services, not leaking information, is up-to-date with security updates and has strong passwords for all its user accounts, there is not much to worry about (and not much possible to do aside from that either).