0

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.

  1. 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?
  2. 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.
  3. Is there a way to implement some kind of "anti-hammering" system for SSTP
Shaamaan
  • 327
  • 2
  • 7
  • 21
  • Best bet would probably be to implement this on the firewall. On Linux systems I have come to love fail2ban for that purpose. What device or software are you using as a firewall? – MoWo May 31 '22 at 13:32
  • @MoWo We're using Sophos UTM. While it IS Linux... I'm not sure how that'd help, to be honest. I mean, the firewall in this instance is just doing (D)NAT... – Shaamaan May 31 '22 at 13:35
  • Ah, okay, Sophos doesn't offer any rate limiting out of the box as far as I'm aware. You could try tweaking allowed packet rates under DoS protection in the Intrusion Prevention settings of the appliance for the specific port / protocol / target IP. That could at least slow down these attacks but you won't stop them. It may just be enough to spoil the fun for the botnet owners trying to brute force your servers and make them focus their resources onto more promising targets... – MoWo May 31 '22 at 13:48
  • @MoWo I'm not sure how rate-limiting would help me. SSTP is a VPN service after all - I don't want to have users getting blacklisted for copying a large file or something... My main concern at the moment however is **#1**. I can't understand why the source IP is the firewall... :( – Shaamaan May 31 '22 at 14:03
  • Well if you manage to trim the maximum new connections per client IP to something like 5 per minute that should be fine for most users but very annoying for brute forcing a server. Regarding the DNAT issue, did you double check the NAT rule and what it says under original source? – MoWo May 31 '22 at 14:26
  • @MoWo There's nothing re. "original source", since it's a DNAT rule. Perhaps my understanding of DNAT is wrong and this should have been a 1:1NAT or Full NAT? – Shaamaan May 31 '22 at 14:45

0 Answers0