|
Posted by Al Dunbar on April 28, 2008, 10:37 pm
Please log in for more thread options
> Anthony (and Meinolf),
>
> Thanks for the response. The consensus seems to be that I must rebuild the
> server from scratch.Wow, what an endeavor, considering the server is on
> the other end of the USA about 3000 miles away and I would have to pay the
> ISP for that time as well as considerable time to set up domains, DNS,
> etc. myself.
Hence the oft-repeated caveat that good security is best applied *before*
implementation, preferably as early as possible in the requirements and
design phase.
/Al
> With all that considered it may be time to make the move to a managed
> hosting environment with a more robust database server. Then the new
> Hosting company would do the setup and I would need to re-publish the
> databases and the web applications.
>
> About your question...How are you authenticating the web site?
>
> In IIS Manager, Anonymous Access is checked and the login uses the
> IUSER_SITENAME_ORG and whatever password was assigned by default. Also
> Integrated Windows Authentication is checked. I never considered those
> options. I write the code that makes the application work, including the
> database access (which is mixed but uses SQL Server login from within the
> application itself).
>
> When a user surfs to the site, anyone is allowed to the "Login Page" but
> if a validated UserID and PassWord is not entered the user can go no
> further. I use SQL Server to store user logins and passwords.
>
> When we do "re-make" the server, do you suggest a different form of web
> site authentication? I am presuming you are referring to the settings in
> IIS Manager.
>
> Thanks
>
>>I am sorry but if your computer was hacked you really have to start again.
>> You must have a firewall, and that must block any connections except over
>> http, https etc.
>> Administrador indicates hack attempts to log on with the Administrator
>> account using NTLM.
>> How are you authenticating the web site?
>> Anthony,
>> http://www.airdesk.com
>>
>>
>>
>>> In the event log under Security, on our remote leased dedicated Web
>>> Server I have just noticed multiple failed logon attempts that go back
>>> about 3 weeks. They are all like the one I am showing below:
>>>
>>> Date: 04/23/2008 Source: Security
>>> Time: 10:02:34 AM Category: Account logon
>>> Type: Failure Aud Event ID: 680
>>> User: NT AUTHORITY\SYSTEM
>>> Computer: LUNARPAG-SEOGSA
>>>
>>> Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
>>> Logon account: administrador
>>> Source Workstation: TMYFREE5005
>>> Error Code: 0xC0000064
>>>
>>> Other error codes have been 0xc000006A.
>>>
>>> At first I thought it was the hosting company support staff trying to
>>> log onto our server. But they replied that since we don't have "managed
>>> hosting" it would not be their staff and it is probably a hacker. Well
>>> that is very disconcerting. I told them it looked like the attacks were
>>> coming from within their network because no "remote service" appears to
>>> be mentioned in any of the failure details. They all come from the
>>> SYSTEM account and the Source Workstation name keeps changing, although
>>> I have seen some repeats.
>>>
>>> Now upon closer inspection, it seems as if maybe the attacks are
>>> orginating from the Server itself...that is just a guess.
>>>
>>> I have disabled the Administrator account.
>>> About 3 months ago we were compromised by a hacker from South Vietnam. I
>>> thought I cleaned all the junk that was left from that attack. Maybe
>>> that is not the case.
>>> At that time I disallowed Terminal Server connections by Administrator
>>> account and changed the password.
>>>
>>> Can anyone shed some light on this behavior? I am not a network
>>> administrator and I am having trouble gettting help from the hosting
>>> company. Yes I am looking to change Hosting companies, but that would
>>> require a lot of time and I have prospective customers looking at our
>>> very large ASP.NET application starting tomorrow.
>>>
>>> Is there any way that I might track down the real source of these logon
>>> attempts?
>>>
>>> Help...
>>>
>>> Any input would be appreciated.
>>>
>>>
>>
>>
>
>
|