none
DDoS auf IIS 7 Webserver RRS feed

  • Frage

  • Hallo zusammen

    Ich betreibe einen öffentlichen IIS-Webserver. Leider stelle ich fest, dass von mehreren IPs Brute-Force bzw. DDoS betrieben wird. Aufgefallen ist mir dies, da im Event-Log extrem viele fehlgeschlagenen Anmeldeversuche sind. Hier ein Ausschnitt:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          03.04.2014 05:24:22
    Event ID:      4625
    Task Category: Logon
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      Host02
    Description:
    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:		Administrateur
    	Account Domain:		FXNB
    
    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:	FXNB
    	Source Network Address:	81.193.123.150
    	Source Port:		1612
    
    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.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4625</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12544</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2014-04-03T03:24:22.921128500Z" />
        <EventRecordID>577506</EventRecordID>
        <Correlation />
        <Execution ProcessID="488" ThreadID="2264" />
        <Channel>Security</Channel>
        <Computer>Host02</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="SubjectUserSid">S-1-0-0</Data>
        <Data Name="SubjectUserName">-</Data>
        <Data Name="SubjectDomainName">-</Data>
        <Data Name="SubjectLogonId">0x0</Data>
        <Data Name="TargetUserSid">S-1-0-0</Data>
        <Data Name="TargetUserName">Administrateur</Data>
        <Data Name="TargetDomainName">FXNB</Data>
        <Data Name="Status">0xc000006d</Data>
        <Data Name="FailureReason">%%2313</Data>
        <Data Name="SubStatus">0xc0000064</Data>
        <Data Name="LogonType">3</Data>
        <Data Name="LogonProcessName">NtLmSsp </Data>
        <Data Name="AuthenticationPackageName">NTLM</Data>
        <Data Name="WorkstationName">FXNB</Data>
        <Data Name="TransmittedServices">-</Data>
        <Data Name="LmPackageName">-</Data>
        <Data Name="KeyLength">0</Data>
        <Data Name="ProcessId">0x0</Data>
        <Data Name="ProcessName">-</Data>
        <Data Name="IpAddress">81.193.123.150</Data>
        <Data Name="IpPort">1612</Data>
      </EventData>
    </Event>

    Dieser Eintrag wird teils bis zu drei Mal pro Sekunde erfasst... Hat jmd. eine Idee wie ich so etwas unterbinden kann. Die Domäne "FXNB" sowie der Benutzer "Administrateur" gibt es auf diesem Server nicht...


    Danke für eure Hilfe!

    Donnerstag, 3. April 2014 14:25

Antworten

  • Hallo Fabrice,

    ob das wirklich schon ein DDOS Angriff ist, kann ich nicht beurteilen, siehr für mich aber nicht danach aus. Leider gibt es viele, viele dümmliche Leute, die nichts anderes zu tun haben außer anderen Leuten mit Bots auf den Keks zu gehen, die das Internet nach verwundbaren Servern abzusuchen und dann verschiedene Testzugriffe durchzuführen. Dazu gehört dann auch das, was Du gerade siehst, die Anmeldeversuche mit verschiedensten Passwörtern.

    Generell solltest Du überlegen, ob die Zugriffe auf den RDP Port (und weitere außer 80 und 443) wirklich von überall aus möglich sein muss. Ich würde sagen: Muss es nicht. Daher solltest Du zumindest per IpSec oder Windows Firewall die erreichbaren Ports einschränken und dann nur für die IP Bereiche freigeben, von denen aus Du wirklich zugreifen wirst. Eine richtige Firewall vor dem Server wäre natürlich auch nicht schlecht, ich nehme aber mal an, dass Du sowas nicht hast, oder?

    Für den Fall, dass Du keine globale Einschränkung der Ports machen willst/kannst, kann man auch selektiv einschränken.

    Die IP Adresse 81.193.123.150 bspw. ist derzeit in Portugal beheimatet und gehört zum Netzblock 81.193.0.0/16. Wenn Du nicht irgendwann per Zufall von dort aus deinen Rechner per RDP erreichen musst, wäre es sinnvoll, diesen IP Bereich zu sperren.

    Da dich das aber vor ziemlich eklige Probleme stellen wird (welche Bereichen kann man blocken, welche nicht, welche sind generell "böse", welche nicht, was mache ich, wenn die IP Ranges verlagert werden, ...?) sollte das maximal eine kurzzeitige "Lösung" sein bis Du es richtig einstellen kannst (siehe oben).


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 5. April 2014 12:45
    Moderator