Hacking attempt on server

ViperGTI

Well-Known Member
Joined
Mar 29, 2012
Messages
382
Reaction score
0
Location
Centurion
Received a traffic burst notification from Hetzner today with regards to one of our servers. Almost 400mb an hour for two / three hours. So I logged into the server, opened task manager and sorted by Process name and noticed that Winlogon.exe is going wild. So I checked the event viewer and found a lot of failed login attempts on the administrator account. So I went and blocked his ass on Windows firewall, the Winlogon process calmed down and everything is nice and quiet again on the server.

I was wondering however... is there a proper way to prevent this kind of brute force attacks (I think that is the correct term to use)? 3rd party software perhaps, renaming the administrator account, etc?
 
Your easiest option is to change the RDP port. Just be careful, since if you screw up you've successfully locked yourself out and will have to [-]ask[/-] pay Hetzner to fix that for you.
 
Only allow specific ip ranges access to any ports other than whatever ports are used for services?
 
is there a proper way to prevent this kind of brute force attacks (I think that is the correct term to use)?

Yes, don't have RDP open to the whole wide internet. Get a static IP address, limit RDP access to that IP. If you can't get a static IP (I know it can be a bit pricey[1] these days), at least limit access to your ISP's dynamic net block. That won't give you 100% protection but at least you then only have your ISP's clients to worry about.

[1] How much these days?

3rd party software perhaps, renaming the administrator account, etc?

Renaming the administrator account helps, but don't rely on it. You can change the account name, but not its SID (at least, last time I worked with Windows, which was admittedly a long time ago). So you'll break the average script kiddie's tools.

Also, read up on NLA: http://technet.microsoft.com/en-gb/library/cc732713.aspx

Again, I'm a bit out of the loop, but recently there was an RDP authenication bypass bug (I'd check your server's un-compromised-ness if I was you) that was not exploitable if NLA was configured. You might want to dig into the issue a bit.
 
This in combination with renaming the Administrator account might be useful. You can tell it to block immediately if the IP address attempts to logon with a username flagged as "block
immediately." In other words, you tell it to block any IP that tries to log in as "Administrator" immediately, and rename your Administrator account to "tubgirlgoestoparis" (who's going to guess that one?). BOOM!
 
Thanks for the information.
Is there any way to only allow South African IP addresses? (Probably a dumb question).
Also, are we sure that these login attempts are through Remote Desktop? I've pasted one of the Audit Failure logs at the bottom of this post.

I think I'll give the Hetzner firewall a try though. Previously, I wasn't keen since we use a lot of custom ports and it is double work to open the ports on both Hetzner and Windows firewalls, but if I put in strict rules on the Hetzner firewall and I lock myself out, I can also fix it whereas with Windows Firewall, if I'm locked out, I'm screwed.

In the meantime, I've noticed that my remote settings on the server was set to allow connections from computers running any version of Remote Desktop. I've now changed that to only allow for Remote Desktop with NLA.

Strange though. With our first server which I set up from scratch, had a site published on it that even appeared in Google search results, in over 3 years, we've never had these kind of issues / attempts. With this new server, from the first week we've had traffic burst notifications and the only apps & sites on here are "private" (users need to know the specific url or have the proper client software installed in order to access it).



An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: db2admin
Account Domain: PC2

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064

Process Information:
Caller Process ID: 0x0
Caller Process Name: -

Network Information:
Workstation Name: PC2
Source Network Address: 188.50.6.134
Source Port: 1278

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
 
Well port 1278 seems to be used by Dell web admin
 
Aha,late night

Commonly exploited port,modus operandi is to ping and probe ip ranges for open ports,then apply common exploits to them. Hardening the system by blocking non-acceptable ip ranges from accessing these is usually step 1,even blocking all ips and only allowing connections originating from a vpn to the server secured via ipsec or tls is good
 
Secure your RDP access through the use of Terminal Services Gateway - it would need to be setup on another server and then specify which ranges can connect to your server, ie only allow the TSG server to connect.
TSGW requires an encrypted connection in order to successfully authenticate - an added layer of security.

If you need help, give me a shout via PM
 
Enabled the Hetzner firewall as well now and reduced the traffic burst notification back to 100mb in 1 hour and will monitor it from now on to see if anything spikes again.

The support guy from Hetzner mentioned something about software they use on their non-Windows boxes to automatically ban an IP after 5 failed login attempts. Maybe I should look for something like that for Windows... will look at the link that koffiejunkie posted earlier... maybe that is it.
 
Enabled the Hetzner firewall as well now and reduced the traffic burst notification back to 100mb in 1 hour and will monitor it from now on to see if anything spikes again.

The support guy from Hetzner mentioned something about software they use on their non-Windows boxes to automatically ban an IP after 5 failed login attempts. Maybe I should look for something like that for Windows... will look at the link that koffiejunkie posted earlier... maybe that is it.
Does the Firewall at Hetzner allow you to disable and enable traffic on particular ports when required? If so then I would look at disabling all traffic inbound on dest port 3389 except for your IP. If you're on adsl that dynamically assigns IP's it means having to change this rule on a daily basis, if you're on a static IP then you can block all traffic except for your IP.

The alternatives are to look at purchasing a static IP from your dsl provider if you dont have one.
Changing the default port from 3389 to 3391 or similar
Setting up a tsgw server
Disabling RDP access and using teamviewer commercial version for remote access.
 
The support guy from Hetzner mentioned something about software they use on their non-Windows boxes to automatically ban an IP after 5 failed login attempts. Maybe I should look for something like that for Windows... will look at the link that koffiejunkie posted earlier... maybe that is it.

fail2ban probably. The link I gave you is for something similar.
 
I would do the following :

1. Put a good firewall up, open port 1194 incoming. (Remember to open other ports as well... eg port 80 HTTP for other services). Keep RDP and VNC ports closed.
2. Install openVPN on the server.
3. Use openVPN to connect to the server, then you can RDP/VNC with ease.

All the ne'er-do-wells will see is that port 1194 and port 80 is open - and they can do nothing without the correct openVPN certificates anyway.
 
I would do the following :

1. Put a good firewall up, open port 1194 incoming. (Remember to open other ports as well... eg port 80 HTTP for other services). Keep RDP and VNC ports closed.
2. Install openVPN on the server.
3. Use openVPN to connect to the server, then you can RDP/VNC with ease.

All the ne'er-do-wells will see is that port 1194 and port 80 is open - and they can do nothing without the correct openVPN certificates anyway.

+1

Don't rely on windows firewall, it means that the request already got through to your machine, even if you actively deny it. Get a seperate hardware firewall, it really isn't that much more expensive. Then do what Librarian said.

The worst that can happen is they DDos you on port 80, and even then the hardware firewall should protect your ass
 
Top
Sign up to the MyBroadband newsletter
X