Explaining Failure Audits

That was an original post of mine. Unfortunately, I didn't get the correct answers.

~Steve

Hmm, sorry about that.... :-(

Is this a known workstation for you: IPDAEW0061MIA If not, check your firewall settings.

Yes, that workstation is our server.

Check if you have anything scheduled at this time:
7:40:00 PM
Maybe backup/database cleaning... whatever... And look what username and passwords are set for these.

Good idea. I checked, but there is nothing.

There were about 600 of these attempts last night using all sorts of different usernames: oracle8, root, anyone, informix, ftproot, pwrchute, web, webmaster.

Looks like some person/software is trying out every typical username to try and gain entry.

In that case, scan for virusses:
http://housecall.trendmicro.com/

And for Spyware:
http://www.webattack.com/download/dlspybot.shtml

Well, Event ID 681 is detailed in this Technet article:
http://support.microsoft.com/?kbid=273499

And the specific decimal code error you have, 3221225572, correlates to this description:  "User logon with misspelled or bad user account"

So, someone is trying to do a brute force attack against your server, IPDAEW0061MIA. Is this a web server running IIS, or FTP, or SMTP, or any IIS-related service? Is this server on the Internet, with a public IP address or a NATted IP, so that anyone from the Internet can hit it? I have not looked at your previous question yet, so I'm sorry if I am repeating previous questions posted to it.

Yes, it's a web server on the Internet (behind a firewall at the hosting provider).

It's got a public IP address.

Ok, so it is a web server. Is IIS running the web server function, or are you running Apache? Also, is it doing anything else, like FTP or e-mail (SMTP or POP3)? If so to that, is IIS or MS Exchange running that? And, is it doing anything else? Any other public-accessible functions?
Also, can you access the server to check, if IIS is running the web server, the W3SVC web server access logs?
Lastly, do you know if the hosting provider blocked all Windows ports (TCP 135, 139, 445, UDP 137-138) with their firewall?

IIS is the web publishing software.

Yes, we can access the W3SVC logs.

These are the rules that they said they configured the firewall with:

Trust to Untrust: Allow ANY
Untrust to Trust: Allow FTP
Untrust to Trust: Allow SMTP
Untrust to Trust: Allow DNS
Untrust to Trust: Allow HTTP
Untrust to Trust: Allow HTTPS
Untrust to Trust: Allow POP3
Untrust to Trust: Allow TS

They've also opened certain ports used, like 8888 and 8090

is there any need for authenticated users to be able to log on externally?
I assume you have run iislockdown tool

http://www.microsoft.com/windows2000/downloads/recommended/iislockdown/default.asp

and made sure you are up to date on sec patches (at least sp3 with patches
MS03-026
MS03-018 and
MS03-051 (esp if you run frontpage extensions)

in IIS settings, enable logging - next time you get an attack, match up http requests to times...

We need for a few users to access via Terminal Services and FTP.

I ran IISlockdown once, and it screwed some things up. I had to uninstall it.

All the security patches are up-to-date, according to windowsupdate.microsoft.com (or could I still be missing some?)

Where do I enable logging in IIS?

Thanks!

oop - took a while to post that - got one answer before posted Q

very related q is just below here

http://www.experts-exchange.com/Security/Win_Security/Q_20839897.html

i won't copy it - but see what is listening as well

Ok, this is what it looks like to me. No NetBIOS ports are open from the Internet to your server, so that rules out that out. It probably is just someone using a tool like X-Scan, which can launch multiple-protocol attacks against a single target. These tools will take a username list and a dictionary file, and run through the total combinations against FTP, SMTP, Web, POP3, trying to find a username/password combo that is valid on the target.
That is probably what is happening here. I run Win2K servers as web servers, and I have seen this in my logs also.
There are things you can do to minimize the amount of risk. Now, things like strong, difficult to crack passwords, are a must. That's a given.
A web site suggestion I have for you involves Web Folders. Is your website installed in the C:\Inetpub\wwwroot folder? If so, I suggest you move it to another folder. WWWROOT folder has Web Folders functionality enabled by default; Web Folders lets an authenticated user use IE to drag-n-drop files to/from the web server (if they have read/write rights) just like using Windows Explorer. Now personally, I HATE Web Folders, and I never enable it. It is an attack vector. Someone can try to guess usernames/passwords using Web Folders. So I always say to not use the WWWROOT folder for this very reason. You can move your website to a different folder on the server, and make sure that Web Folders does not get enabled on this new folder.
You also might want to make sure that the IUSR_"MACHINENAME" account only has Read access on the website folder structure (no matter where you save it on the server), not Full Control or Write. Also, make sure the Everyone group does NOT have rights to the web site folder structure.
Something that I have found that is interesting that can be dangerous to an IIS-powered website is the Write checkbox when you look at the web site Properties in the Internet Services Manager snap-in. Don't allow the Write checkbox that is on the Home Directory tab of the website. It is possible, with Write enabled, and some NTFS permissions mis-set, to let external users delete your website by doing an HTTP DELETE command! Not the problem you are experiencing, but just one of the things I worry about with IIS and webservers!
Now, as for trying to find out what is happening, I would check the W3SVC logs (and SMTP and FTP) on the server, under the C:\Winnt\system32\logfiles directory. Check them, and try to co-orespond any interesting entries you see with the SEcurity log Failure Audits you have. The Security log, as you have seen, does NOT record the IP address of attackers. I know, annoying; that is how it works!
But, the W3SVC logs (as well as the other IIS processes, if they are attacked), DO record the IP address. It might be possible to find a few website hits that happened just before the attacks started. You might see all kinds of strange stuff in the W3SVC logs while the attacks were going on.
You see, IIS is treated just like normal Windows authentication in regards to the logging of failed logon events. It is logically the same as when you log into a Windows computer and type in the wrong password. Similar functions are called. I've spoken with Microsoft tech support on this before, and I was astonished to learn that IIS connections are just like drive mappings. The same logic applies. Users who have access to the files are granted access; if you don't have access, you are denied.
So, check the W3SVC logs, and match them up with the Security logs, to try and get an IP.
A couple of things to keep in mind. The IIS logs are all GMT time, so you will need to add/subtract the appropriate number of hours to match up the events with the SEcurity log events.
Also, the attacker could have had  his dictionary attack tool route through a public proxy server (if he was smart!). So, the IP you might find in the logs may not be the actual attacker IP. Just keep that in mind. But, any IP you can get is a place to start.
So, that is what I think is happening. Someone using a dictionary attack tool, scanning your server on possibly multiple ports against multiple services, looking for a weak username/password combo. Happens every day.
And BTW, I really don't like having Terminal Services enabled over the Internet like yours does. That is risky. Because say the attacker were to find a valid username/password combo in his scans. He could then connect via TS using that username/password and be IN YOUR SERVER! I always tell people to NOT have TS be available over the Internet. Just too dangerous. Plus, there is at least 1 tool that is specifically designed to do the dictionary attack against a TS session itself. The other services your server has I can understand, with web, ftp, e-mail. Sure. But TS is something I suggest you really consider if you want to risk having it open.
hope this slightly rambling stuff helps!

I'll try that out. Thanks!

If I shouldn't use TS, how can I administer my server without it?

OK, I've already had logging on all the while.

As for how else you can remotely admin your server since TS is not a safe way, the usual answer is via VPN.
You see, I view TS open on the Internet like this as just as dangerous as having TCP ports 139 and 445 open! Yes, the famous Windows File Sharing ports. I think that TS is just as dangerous. You can bang against these ports with no initial authentication required, and try to guess a valid username/password, and if you get one, you are in and you can do anything you want! Just too risky!
So, this is why a VPN solution is good. The VPN ports/protocols are open at the firewall, and once you authenticate at the VPN, the rest of your traffic is routed through the VPN encrypted tunnel. So, you would connect via VPN, then launch your TS client. TS is NOT enabled through the firewall. Your TS session goes through the VPN tunnel, to the hosting provider, which then the VPN box there routes it to the TS port on the server internally, not to the Internet side. Much more secure. You could see if your hosting provider has a VPN setup in place for you to use to admin your box.

really, if your network is open, then all you can do is watch and secure against it...

watch...if attempts are to crack the IIS...

w3svc logs are the same - control panel, administrative tools, internet services manager, right click on root web, properties, edit master properties, enable logging, choose hourly if you are a fairly busy server (mine are secure client access (support pages and http served CRM pack for roadwarriors) and hack attempts only - 1 days log averages about 80K ) extended file format, extended properties, tick

time               duh - useful to tie with audit logs
c-ip                don't want them to be anonymous
s-sitename     what they were using to try it on with
s-port            where were they knocking?
cs-uri-query   what were they wanting?


to protect against anything...

the other things is that you can do is
narrow down terminal services access to only the accounts that need it no - access for unauthorised
disable logon permissions to relaxed office hours except for boss / roadwarriors - then overnight attempts by 9-5ers will just be ignored

passwords - passwords - passwords

make sure you have good passwords that have numbers / symbols / case mix in them - high security accounts, add a ALT-xxx between 130 and 250 on numeric keypad - most attempt programs don't even touch those symbols!
LOCKOUT more than 4 failed attempts for say 1 hour


A.

How do you specify which accounts have TS access?

joseph - lot of typing in little time - nice to see an expert that don't cut and paste standard lists to every post, and does read stuff! - it's what drove me away in '01

skbholer
if you still have the linksys BEFSR41 (from your post history)

http://www.linksys.com/Download/firmware.asp?fwid=3   has latest firmware which supports multi-L2TP-pass-through, previous ones didn't.

http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp  has a 98 / me / nt4 L2TP client but i have not used it.