-1

over 8GB of traffic from a workstation named KHAOSSERVER has occurred since yesterday; in the Security Event Log are records like this:

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: agent
Account Domain: KHAOSSERVER
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: KHAOSSERVER
Source Network Address: - ????????
Source Port: -
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

if there were an ip address for KHAOSSERVER,
an inbound blocking rule could be configured.

Regardless that the workstation name might change,
how does one configure an inbound blocking rule
for Windows 2008 R2 firewall when the workstation
is known but the ip address is unknown?

Please note:
even now, KHAOSSERVER is still attacking my server.

gerryLowry
  • 185
  • 3
  • 13
  • Simply remove it from the DMZ ??? or check your hardware firewall/router log. – yagmoth555 Sep 09 '15 at 15:01
  • How are you identifying the "8 GB" of traffic? sflow information? – Nixphoe Sep 09 '15 at 15:35
  • @Nixphoe the firm that provides my unmanaged dedicated server provides on demand graphic bandwidth charts. – gerryLowry Sep 09 '15 at 17:23
  • @yagmoth555 it has to live in the outer world because it serves web pages (Windows 2008 R2 Web Server edition); it's not even located in my country and it needs to be globally available. – gerryLowry Sep 09 '15 at 17:27
  • Someone hate your website then. It look like a DDoS attack. If so, you can't do much, just wait till the wave of traffic calm down. Identifyng IP in such case are irrevelant usualy, as usually it's infected computer from a botnet. – yagmoth555 Sep 09 '15 at 17:32
  • So... you exposed your server to the internet and bad people tried logging in / DDoSing it? Wow, that could never have been anticipated. – BlueCompute Sep 10 '15 at 13:13
  • @BlueCompute yes, it could have been anticipated and was. The service provider manages DDoS well. What they do not manage is brute force attacks against RDP. Windows Firewall handles that well by allowing me to block ip addresses via the inbound rules. HOWEVER, as per my example, a small percentage of invaders show up with no ip address. Your comment was not helpful; at least you could have explained your reason for the downvote. FWIW i can not afford a managed server. – gerryLowry Sep 10 '15 at 15:10
  • It's not a new or unique problem. There's approximately 1 bajillion discussions, questions and articles on this sort of thing, all available on the interwebs. In that regard your question shows neither research nor effort. – BlueCompute Sep 10 '15 at 15:29
  • @BlueCompute actually i've looked at many Google results and asked the question of my dedicated server's technical support group, all to no avail; the articles that i've located to date tell me how to block via ip address, a skill i already use. my research continues, however, i was hoping someone here at serverfault might already know the answer. BlueCompute, perhaps you can offer useful help? FWIW – gerryLowry Sep 10 '15 at 17:01
  • Windows only offers filtering based on IP, not dns lookups. If you are receiving attacks on port 3389 then try using tcpview.exe (from MS) to see the source IP of the attacks. If this is RDP then why not set up a filter to only allow RDP from a single IP, or a list of IPs until the attack stops? – Ian Murphy Sep 11 '15 at 12:41
  • @IanMurphy allowing RDP from a single IP has a major downside for me ... my local isp runs on a major isp, so the major isp can change my ip address at will; that seldom happens, but such an event would lock me out. WireShark produces an overwhelming amount of capture data, 5 to 10 MB per minute, so it's a lot to dig through ... i'll check out tcpview and hope it's captured data is easier to review. Thank you. – gerryLowry Sep 11 '15 at 16:28
  • links to TcpView for anyone interested ~~ [Technet](https://technet.microsoft.com/en-us/library/bb897437.aspx) [download](https://download.sysinternals.com/files/TCPView.zip) **or** [Sysinternals](https://technet.microsoft.com/en-us/sysinternals/bb897437) [download](https://download.sysinternals.com/files/TCPView.zip) ~~ both locations use a common download link. – gerryLowry Sep 11 '15 at 16:35
  • F.Y.I.: TcpView is useful but requires visual monitoring because when a TCP connection is closed, it falls out of the view shortly thereafter; whereas WireShark has an overwhelming amount of data, TcpView has too little data retention. Regardless, TcpView may be somewhat useful. TcpView does not show the workstation name; it can be toggled between ip address and resolved ip address. – gerryLowry Sep 12 '15 at 19:10
  • A non-ideal alternative to limiting rdp: you can add routes ("net route add...") to route the IPs or subnets from which attacks are coming, routing them to an inexistent internal address. Its a cheap and dirty way to block incoming traffic. It limits attackers to sending syn packets. It requires you add 10s or hundreds of routes. If they are not permenant routes, a reboot will clear them later. Before anyone shouts - this isn't a a great solution, but when your options are limited it will cut down on incoming traffic quick. It can be scripted from the output of netstat. – Ian Murphy Sep 12 '15 at 19:35
  • @IanMurphy once i know the ip address, i simply add it to the inbound rule ... more generalized blocking is not a good idea because i'd potentially be locking out legitimate visitors. For that reason, i prefer to only block attackers who try to log on. Regarding reboot, i'd prefer to reboot as little as possible because it's a 24/7 web server. – gerryLowry Sep 12 '15 at 23:19

1 Answers1

0

I would comment, but I can't.

Talk to someone who has visibility into the network or run a packet capture with something like wireshark to capture the IP.

Jesse K
  • 166
  • 5