Looking at our NPS logs I see we're getting hammered; some online actor is doing a brute force on various login names and passwords.
In general this isn't an issue... yet. It doesn't appear that a breach has occurred (especially since it's not a single login being attempted multiple times but rather random login names).
However, I've identified some key issues which I'm not sure how to resolve just yet.
- The server hosting NPS is responsible for authentication against our DC and it contains the (somewhat old-school) logs. Unfortunately I've found that the source IP for these attempts is our firewall, rather than whatever online source it is, and I somehow doubt our firewall's been compromised. Since we're dealing with the SSTP protocol I've had to set up a DNAT rule; it is my understanding that this rule should pass the source IP, but looking at the logs that doesn't appear to be the case. Shouldn't a DNAT rule pass the source IP? If not, then what kind of firewall rule should I set up to get the logging working properly?
- Looking at the successful authentication requests I can't see any way to find what IP they've been assigned. I can of course look at the SSTP server itself to see the ACTIVE connections, but if something has happened in the past it seems that information is lost. There's a good chance I need to first enable something to get that information saved, but I've already looked and I can't find anything. The SSTP properties has a "Logging" section that... doesn't appear to work. The target file (
%windir%\tracing\RaMgmtUIMon.log) appears to be empty.
- Is there a way to implement some kind of "anti-hammering" system for SSTP
