Moved Suricata from WAN to LAN, can't Remote Desktop in
-
We have been running Suricata on our WAN interface for a while, and changed to Inline mode a month or two ago. Friday I copied/duplicated the WAN interface for Suricata to LAN, and turned it off on WAN. Things seemed to go OK on Friday, from inside the office getting out to the Internet. However, when I got home I realized that most of the time I was being prevented from connecting to any PC in our office via Remote Desktop. We have several PCs set up on various ports, using pfBlocker in the NAT rule to limit access to North America. I would guess about 95% of the time I could not connect, but occasionally it did work. Fortunately I have another method to get in, and found if I stopped Suricata I could connect in fine.
There were no alerts logged by Suricata for my Remote Desktop traffic being blocked over the hour or so I worked on this, except for one time only it logged an alert that I didn't write down but it was something to the effect of Remote Desktop port scan from my remote IP...which makes sense since I was trying multiple PCs.
Any ideas? For the short term at least I removed Suricata from LAN and went back to WAN.
-
I found https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 (section "SUPPORTED DEVICES") which does not list "bge" as supported for netmap on FreeBSD 11.1 or 12-current. So apparently that's the reason it's not working correctly on our LAN interface, though it's not clear why other types of traffic worked OK in and out.
-
Can the Suricata package "see" what type of driver is in use on an interface and only allow Inline if it is on a driver FreeBSD says works with netmap? Or at least show a warning that it may not work?
-
pfSense on top of ESXi (free) does wonders for Suricata interface compatibility.
-
We changed the hardware for this router to a newer PC to get AES-NI, and I made sure that an Intel em0 NIC was the LAN side. I moved it on Friday and connected in once Friday night without issue, but last night I had the same behavior...really really difficult to connect in from home with Remote Desktop until I connected in using a different method and turned off Suricata. I eventually set Suricata back to Legacy mode to resolve. There are no alerts/blocks being triggered.
-
Sounds like Suricata is blocking RFC1918 or some similar behavior.
If you're running Suricata in Inline IPS mode, I defintely recommend putting it on the WAN side. If you're running it in IDS (non-blocking) mode, then on the WAN or LAN port is fine. This is security 101.
- https://www.sans.org/reading-room/whitepapers/detection/understanding-intrusion-detection-systems-337
- https://www.sans.org/reading-room/whitepapers/intrusion/network-ids-ips-deployment-strategies-2143
If you need to separate servers from workstations on your LAN, use another ethernet port and/or VLAN, and create the appropriate firewall rules.
-
I guess my main point is, if something is being blocked, it is not being logged as an alert or block, which is a problem. And if nothing is being blocked, then that also means there is a problem.
I've seen other arguments in this forum to put Suricata on the LAN, including the package maintainer. There are pros and cons. The WAN side is "outside" the pfSense but the logs have a lot of noise since a large amount of blocked traffic wouldn't be allowed by the firewall anyway. The LAN side allows one to see what PC is generating the traffic that is being blocked.
Technically the article you cited (https://www.sans.org/reading-room/whitepapers/detection/understanding-intrusion-detection-systems-337) shows the "sensor" behind the firewall (p.5).
-
Thinking about this some more, perhaps the "inline" feature isn't playing well with the NAT port forwarding for Remote Desktop, when Suricata is on the LAN interface? We have a pfBlockerNG alias as the source on the NAT rule to limit the rule to US IP addresses (and then 2FA and an account lockout policy).
-
There are a multitude of configuration settings that make me cringe here... but in the spirit of being helpful, my thought is this:
Enable pfBlockerNG on the WAN (blocking OK);
Enable Suricata on the LAN as you want visibility (but do not block any traffic);Also, it sounds like you're connecting from home to the office over RDP.
I assume you have a NAT forwarding rule for the RDP? If not, how are you doing that? -
We had done it in one step and set up the pfBlocker alias as the source on the NAT rule:
source: pfB_GeoIPUSv4 *
dest: WAN address (port)
NAT IP (LAN IP) 3389 (MS RDP)You're suggesting we allow from pfB_GeoIPUSv4 to the NATted port, and then create a NAT rule for traffic from * to the WANIP:port to get to the target?
I'm aware there's proponents of VPN in front of RDP but that is a different discussion. :)
-
@teamits
Hmm... I don't know enough about pfBlocker to say that would fix it... First thought is try it with Suricata in non-blocking mode. If that still fails, try the explicit NAT rule for 1 of your internal servers.
-
You really, really, really need to use a VPN for RDP. That is the most secure. You can easily configure OpenVPN on pfSense. That also eliminates the need for NAT port-forwarding.
