2

We had a successful hack attempt from Russia and one of our servers was used as a staging ground for further attacks, actually somehow they managed to get access to a Windows account called 'services'. I took that server offline as it was our SMTP server and no longer need it (3rd party system in place now).

Now some of our other servers are having these ANONYMOUS LOGIN attempts in the Event Viewer that have IP addresses coming from China, Romania, Italy (I guess there's some Europe in there too)... I don't know what these people want but they just keep hitting the server. How can I prevent this?

I don't want our servers compromised again, last time our host took our entire hardware node off of the network because it was attacking other systems, causing our services to go down which is really bad.

How can I prevent these strange IP addresses from trying to access my servers?

They are Windows Server 2003 R2 Enterprise 'containers' (virtual machines) running on a Parallels Virtuozzo HW node, if that makes a difference. I can configure each machine individually as if it were it's own server of course...

UPDATE: New login attempts still happening, now these ones are tracing back to Ukraine... WTF.. here is the Event:

Successful Network Logon:
    User Name:  
    Domain:     
    Logon ID:       (0x0,0xB4FEB30C)
    Logon Type: 3
    Logon Process:  NtLmSsp 
    Authentication Package: NTLM
    Workstation Name:   REANIMAT-328817
    Logon GUID: -
    Caller User Name:   -
    Caller Domain:  -
    Caller Logon ID:    -
    Caller Process ID: -
    Transited Services: -
    Source Network Address: 94.179.189.117
    Source Port:    0


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Here is one from France I found too:

Event Type: Success Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:   540
Date:       1/20/2011
Time:       11:09:50 AM
User:       NT AUTHORITY\ANONYMOUS LOGON
Computer:   QA
Description:
Successful Network Logon:
    User Name:  
    Domain:     
    Logon ID:       (0x0,0xB35D8539)
    Logon Type: 3
    Logon Process:  NtLmSsp 
    Authentication Package: NTLM
    Workstation Name:   COMPUTER
    Logon GUID: -
    Caller User Name:   -
    Caller Domain:  -
    Caller Logon ID:    -
    Caller Process ID: -
    Transited Services: -
    Source Network Address: 82.238.39.154
    Source Port:    0


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
MetaGuru
  • 856
  • 5
  • 22
  • 35
  • Guys these are type 3 logons which means the person never logged in. These are network logins logged when someone accesses a network share like printer or files. –  Feb 24 '12 at 18:55
  • What service are they trying to log into? You can change which port these service are running on, I've found that to be the easiest way. – Fred Jan 20 '11 at 16:57
  • see update above, I added the event, I think it says Logon Process: NtLmSsp but I don't know if that is what you are asking or not – MetaGuru Jan 20 '11 at 17:00

3 Answers3

5

You should block these at the router/firewall really, if you don't need access to these servers from anywhere- then they should only accept connections from your IP range. Contact your hosting provider, and get these rules setup asap.

AliGibbs
  • 2,303
  • 20
  • 34
  • Good point, some servers however do require access from anyone in the world, but it should only be through our IIS website... – MetaGuru Jan 20 '11 at 17:01
  • 2
    Then only allow port 80, or whatever your IIS is listening on- you shouldn't have your RDP port open to the world, ever. – AliGibbs Jan 20 '11 at 17:03
  • So between the two samples I added above, are they similiar? Is it RDP? I don't know how to interpret them :/ – MetaGuru Jan 20 '11 at 17:08
  • 1
    Ryan- I would contact your hosting provider ASAP to request that the firewall in front of these servers is locked down to the ports that you need in the first instance. Then investigate these errors. – AliGibbs Jan 20 '11 at 17:12
  • I guess I am not sure which ports I need, but I just wish I could turn off this thing they are trying to connect to, really I am trying to understand what exactly are they connecting to? Should I post another question asking someone to interpret these log entries? – MetaGuru Jan 20 '11 at 17:20
  • @Ryan, you should ignore what they are trying to connect to for now, and determine what services you must leave exposed to the outside world. When you have this list, get a firewall with just those ports open and that will solve a lot of your issues. If you are still seeing attacks on the ports you have left open then you will need to do some more work. – Sam Cogan Jan 20 '11 at 17:25
  • @Sam that's great, and I will follow suit, but I'm still curious... or does nobody know what these log entries mean? I am just wondering what someone is doing are they launching RDP and typing in our IP address? Are they doing this through a browser? I just don't know what it IS and I am not sure why nobody will tell me... – MetaGuru Jan 20 '11 at 17:35
  • @Ryan they could be more than one thing... Logon type 3 is a network logon and covers several types of logon: http://www.windowsecurity.com/articles/Logon-Types.html also Logon Process NtLmSsp doesn't help you track down specifically what access attempt was made just that they were trying to authenticate. – Paul D'Ambra Apr 12 '11 at 07:43
  • The steps you need to take to lock them down depend on the setup of the machines. Are they webservers with a private and a separate public network? Do you carry out all admin solely by RDP? If so you can set rules to say that RDP (TCP 3389) from your IP addresses is allowed and port 80 from anywhere is allowed. Your host should be willing to work with you through a maintenance window to watch the firewall logs and make sure that any problems these rules cause can be ironed out. – Paul D'Ambra Apr 12 '11 at 07:46
  • Work on the basis that you should refuse all traffic on the public interface except those few things that you explicitly require. – Paul D'Ambra Apr 12 '11 at 07:46
3

What you are seeing is a brute force attack to gain access to the system using terminal services (RDP). From your Windows based PC: go to start, type run, then type mstsc and click enter. Type in your server's address. When prompted for a username and password just click the close dialog. Then, take a look at your server's security log. You'll see the same event that you are seeing coming from your IP address. You'll still want to block these punks at the firewall. Every time someone attempts an RDP session Windows will spin up winlogon.exe and csrss.exe (watch taskmgr). If they are attempting to logon several times a second your system will slow down.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
David
  • 31
  • 1
0

Warning: those are successful attempts, meaning they logged into your server. At this point, I'd take the server offline and modify the firewall rules and patch up the server immediately. It sounds as though you only want port 80 open for the world, so just have that one open and deny the IP ranges of any countries/areas that you saw a ton of failed requests for, including this Ukraine range: 94.0.0.0/8 and this IP: 82.238.39.154. They can still get around it but it makes it a little more of a hassle for them.

Also, these 2 machines (at least) need to be audited to see if they're clean: REANIMAT-328817 and COMPUTER.

After reading more, it doesn't appear that you have a decent firewall solution in place or configured properly. I would do the above and implement a proper firewall BEFORE placing the server back online. Also, you really can't trust those machines anymore as they likely have back-doors into them now; time to reimage or reinstall the OS, etc...

jschorr
  • 163
  • 3
  • You are wrong. Yes, they are successful attempts. No, this does not indicate the user accessed the system. The event you are seeing will pop into the security log every time a user attempts an RDP connection. This is because the RDP establishes a connection anonymously before exchanging a username and password. – David Apr 12 '11 at 06:18