Could this be malware in my pfSense - it is not blocking MS RDP attacks

[mattfiller]

I recently took over IT for a small business that uses a NetgateSG-5100 router running pfSense software as a firewall (plus another at a remote location). I put a trial of Malwarebytes on my PC, and it went nuts with incoming Brute Force and Compromised PC RDP attack alerts (we have 5 incoming 3389-MS RDP Port Forwards to individual PCs so people can work from home) . I put in some Rules to block the IP addresses I was seeing, and many of them stopped once I got the States deleted, but several continued anyway!

I had to delete individual state table entries because Reset States fails to reset anything with message nginx 2021/12/10 19:54:06 [crit] 7966#100143: *1776 SSL_write() failed (13: Permission denied) while processing HTTP/2 connection, client: 10.10.22.86, server: 0.0.0.0:443

When I delete state table entries for these IP addresses, one or two of them reappear within seconds. When an attack gets through, it recreates the others.

It seems like maybe there are daemons that are recreating states as needed to keep the attack working, as well as something that is blocking Reset States. Is this plausible? The guy who ran this before left the user ID as Admin with a fairly strong password. I can't find any other reports of something like this, and the one that does have this message isn't very helpful (we are using an IPSEC VPN tunnel, not OpenVPN).

The IPs in question include 45.146.165.0/24 (.113, .226,...), 94.232.40.0/24 (.240, .23,...), 94.232.42.0/24 (.23, .130,...), 193.93.62.0/24 (.6, .22, .101,...).
Tracert gets a "General Failure" on most of these, the193... IP gets as far as Latvia before timing out.

I would add the pfBlockerNG and SNORT packages to my systems, but we are considering just buying Cisco Meraki boxes instead, and the instructions seem like a lot of effort to install these packages if they just end up setting up rules that wouldn't work anyway.

I upgraded the box from 21.02.2 to 21.05.2 shortly after I determined this was happening.

Is this a known problem, or am I missing something that would fix it? Do I need to reset this and reinstall the software, how do I do that, and does that mean I have to manually recreate all of the settings?

[mattfiller]

@mattfiller

Here is what I am seeing in the state filter when I press kill states for a specific IP as the filter expression:

Diagnostics/ States / States
States Reset States
State Filter
Interface all
Filter expression 193.93.62.67
Kill filtered states
Remove all states to and from the filtered address
States
No states were found that match the current filter.

less than a minute later, I press filter and get (with my IP hidden):

WAN tcp 193.93.62.67:61057 -> 10.10.22.85:3389 (my.IP.net.51:3389) TIME_WAIT:TIME_WAIT 11 / 7 2 KiB / 1 KiB
LAN tcp 193.93.62.67:61057 -> 10.10.22.85:3389 TIME_WAIT:TIME_WAIT 11 / 7 2 KiB / 1 KiB

[Cool_Corona]

Heyy I can help via teamviewer if you need it.

[stephenw10]

You are using port forwards with RDP directly?

I would want to use a VPN to connect those clients.

If you can't do that then try to restrict the allowed source IPs. pfBlocker can give you some geoip aliases to do that. Better would be to have clients run dyndns and limit to those only, assuming they do not have static IPs.

Steve

[johnpoz]

@mattfiller said in Could this be malware in my pfSense - it is not blocking MS RDP attacks:

(we have 5 incoming 3389-MS RDP Port Forwards to individual PCs so people can work from home)

Yeah this is a bad idea for sure - and your going to see tons of traffic to those ports. I don't have it open but just looking at the firewall logs sees lots of noise to that port

If you have remote workers that need to rdp to some machine on your network. As suggested by @stephenw10 either VPN in (best option).. Or lock down the source IPs to who can hit that port and be forwarded. Best would be to lock down to the remote users specific IPs.. You could use say dyndns entries so even if their IPs change, etc.

While changing the port from 3389 on your wan side is not really a security measure, if you used different ports to to your specific devices 3389 port, this would remove some of the log spam, and lower the amount of stuff that is forwarded to the actual client..

While security through obscurity is not something you should rely on - it doesn't hurt if you make bots looking for open rdp ports harder to find you. Once some bot or outside finds your rdp port is open, they will normally bomb you with brute force attempts to get in.. Trying all kinds of username/password combos..