SBS 2003, How to stop hackers trying to log in programmatically via OWA or RWW
Hi,
I manage a number of SBS 2003 Servers that are constantly being attacked by hackers who are either trying to brute force the OWA or RWW login screens or possibly do a denial of service.
I was looking at my reports this morning and I can see that there were 9007 attempts to gain access to our server illegally, when I check the Security log I can see that there were repeated attempts about one every 7 seconds which generated event log entries like this:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 07/02/2012
Time: 12:57:33
User: NT AUTHORITY\SYSTEM
Computer: SERVERNAME
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: guest
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_P
Workstation Name: SERVERNAME
Caller User Name: SERVERNAME$
Caller Domain: DOMAINNAME
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 8980
Transited Services: -
Source Network Address: -
Source Port: -
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Process 8980 is IIS so I am assuming they are seeing the https port open and are hitting the OWA or RWW login screens over and over again.
The logs show that they are using the same user name about 200 times, so I suspect the program is using a dictionary of passwords that is 200 items long and then using it with another dictionary of user names. From the logs the attack seems to have started at about 1PM UK Time yesterday and continued until about 08:30AM this morning.
Is there anything I can do to stop this that allows my remote users to gain access to the server using OWA or RWW without exposing it to attacks like this. My thought would be to set all remote users up with a VPN so they can access the OWA and RWW using internal IP Addresses/Names.
I would be grateful of any advice.
Siv
I manage a number of SBS 2003 Servers that are constantly being attacked by hackers who are either trying to brute force the OWA or RWW login screens or possibly do a denial of service.
I was looking at my reports this morning and I can see that there were 9007 attempts to gain access to our server illegally, when I check the Security log I can see that there were repeated attempts about one every 7 seconds which generated event log entries like this:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 07/02/2012
Time: 12:57:33
User: NT AUTHORITY\SYSTEM
Computer: SERVERNAME
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: guest
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_P
Workstation Name: SERVERNAME
Caller User Name: SERVERNAME$
Caller Domain: DOMAINNAME
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 8980
Transited Services: -
Source Network Address: -
Source Port: -
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Process 8980 is IIS so I am assuming they are seeing the https port open and are hitting the OWA or RWW login screens over and over again.
The logs show that they are using the same user name about 200 times, so I suspect the program is using a dictionary of passwords that is 200 items long and then using it with another dictionary of user names. From the logs the attack seems to have started at about 1PM UK Time yesterday and continued until about 08:30AM this morning.
Is there anything I can do to stop this that allows my remote users to gain access to the server using OWA or RWW without exposing it to attacks like this. My thought would be to set all remote users up with a VPN so they can access the OWA and RWW using internal IP Addresses/Names.
I would be grateful of any advice.
Siv
strivoli
If you run SBS2003 you should have ISA as well. ISA logs all traffic and you should be able to identify the source of the attack. Once determined the IP, include this IP in a Black List (ISA allows you to create Black Lists). This kind of operation can be done manually or, if you wish, you can script it to run at a schedule. Furthermore, you can set ISA's Connection Limit to a lower level.
ASKER
We use a Firewall/router which is directly connected to the server on a single network card so ISA won't install under that configuration I believe?
Siv
Siv
OK. So you don't use ISA. Well, I believe that having a 2 level protection (firewall/router+ISA) is better than having only 1 level protection (firewall/router). So, for a long perspective view I strongly suggest you to consider adding ISA. For the actual thread I strongly suggest you to check for updates to the firewall/router and carefully checking the rules that govern the firewall/router (NATs, ports open, and so on).
What ISA offers (Black Lists, Connection Limits, etc.) is also available in most (if not all) firewall/routers. They might have different names but the aim is the same: prevent attacks.
If you decide to update the firewall/router (strongly suggested) I remind you to backup tour configuration before proceeding.
What ISA offers (Black Lists, Connection Limits, etc.) is also available in most (if not all) firewall/routers. They might have different names but the aim is the same: prevent attacks.
If you decide to update the firewall/router (strongly suggested) I remind you to backup tour configuration before proceeding.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Alan,
The scenario in the second of your links pretty much identically matches my situation.
I think this option may help so I will give it a go and report back.
Siv
The scenario in the second of your links pretty much identically matches my situation.
I think this option may help so I will give it a go and report back.
Siv
I have seen this sort of attack more times than I have had hot dinners!
They are persistent buggers.
Only allowing Anonymous authentication and restarting the SMTP server will remove one point of attack.
Do you have POP3 enabled also? If you do - do you need it? Can you disable it?
They are persistent buggers.
Only allowing Anonymous authentication and restarting the SMTP server will remove one point of attack.
Do you have POP3 enabled also? If you do - do you need it? Can you disable it?
ASKER
Alan,
We are not using POP3 so that's not an issue. Mail is delivered directly to the server using SMTP from the ISP. The POP3 Service is turned off.
The mail users are either on the internal domain network, or are external users who use a VPN to get into the internal network from laptops.
Is there any implication for users who access their email using smartphones or Blackeberry devices. They tend to use secure connections after accepting teh server certificate which is self issued?
Siv
We are not using POP3 so that's not an issue. Mail is delivered directly to the server using SMTP from the ISP. The POP3 Service is turned off.
The mail users are either on the internal domain network, or are external users who use a VPN to get into the internal network from laptops.
Is there any implication for users who access their email using smartphones or Blackeberry devices. They tend to use secure connections after accepting teh server certificate which is self issued?
Siv
Good re the POP3.
VPN users could be a problem for you if they are infected as they then have a direct route to send crap out via Outlook.
Blackberries / smartphones if using BES / BIS via OWA and / or Activesync should be fine.
Self issued certs are fine for Exchange 2003.
VPN users could be a problem for you if they are infected as they then have a direct route to send crap out via Outlook.
Blackberries / smartphones if using BES / BIS via OWA and / or Activesync should be fine.
Self issued certs are fine for Exchange 2003.
ASKER
Alan,
The changes to SMTP seem to be doing the trick we are getting no more failed logins so your second link led to the correct answer in this instance.
Thanks for your Help
The changes to SMTP seem to be doing the trick we are getting no more failed logins so your second link led to the correct answer in this instance.
Thanks for your Help