Suricata Inline Mode Wierdness
-
4 days ago I decided to test the new Suricata inline mode. I managed to get it installed and running without problem and initially it seemed to be running OK. I did however immediately notice some sluggishness in establishing new connections (both inbound and outbound) but everything seemed to work and once the connection is established, it seems to perform at full ISP bandwidth. However, over the course of a few days I noticed that inbound Remote Desktop (RDP) connections started taking longer and longer to initiate. Today, the network (in both directions) has been flaky but generally working so that no one is complaining…but I cannot make most of my inbound RDP connections (I'd say it connects 1out of 10 times). There are no errors or warnings in any logs or Suricata alerts (related to RDP...Surcata does alert on other tings at other times). The firewall log does verify that a RDP connection attempt was made and passed. If I disable Suricata, RDP works well. If I immediately re-enable Suricata (and wait for it to completely load), RDP stops working most of the time again. When I convert Suricata to "Legacy" mode then everything still appears to work properly (and quickly).
I'm running a new build of pfSense on a Shuttle box with Intel Core i3-3240 with 4 GB RAM, 128 GB SSD and (sadly) Realtek ethernet adapters. No other packages are installed. This is a simple 1 WAN / 1 LAN setup with about a dozen port forwards to internal servers. I do have the 3 requisite "offloading" options disabled (i.e., they are checked).
I'd appreciate if anyone has any thoughts on this. I'd like to run Suricata in inline mode, but it doesn't seem too stable on my machine.
-
Another interesting observation is that when running in inline mode, I never had a single STREAM alert and now I'm getting eaten alive with them in Legacy mode.
-
There are some issues with Netmap in the version of Suricata now in the FreeBSD repository. A number of fixes have been posted to the beta version now in testing upstream. A number of FreeBSD-specific fixes were added to the Netmap code in Suricata. Hopefully they will help with some of the weirdness seen with inline mode. This is a new technology in FreeBSD and there are some rough spots to work through.
Bill
-
Bill,
Thanks for the reply. I have dug deeper into the issue and I'd like your opinion. I can narrow the problem down to 3 rules in emerging-dos:- 1:2014384 - ET DOS Microsoft Remote Desktop (RDP) Syn then Reset 30 Second DoS Attempt
- 1:2014385 - ET DOS Microsoft Remote Desktop (RDP) Syn/Ack Outbound Flowbit Set
- 1:2014386 - ET DOS Microsoft Remote Desktop (RDP) Session Established Flowbit Set
When I disable #2, then everything appears to be back to normal (i.e., I can make normal RDP connections with no delay).
When I enable #2 but disable #1 and #3 then I can get RDP connections to work, but the connection process is very slow.
If I enable #2 with either #1 or #3, then RDP connections fail again.So, I will certainly disable #2 for now. But should I drop this issue until 3.1 finally makes it into pfSense (3.1 does seem to be in stable release mode, but not certain how long it takes to make it all the way into pfSense) or should I attempt to debug further what makes that rule so bad? I guess it is Netmap related as I don't get this problem in "Legacy" mode.
Thanks.
-
Bill,
Thanks for the reply. I have dug deeper into the issue and I'd like your opinion. I can narrow the problem down to 3 rules in emerging-dos:- 1:2014384 - ET DOS Microsoft Remote Desktop (RDP) Syn then Reset 30 Second DoS Attempt
- 1:2014385 - ET DOS Microsoft Remote Desktop (RDP) Syn/Ack Outbound Flowbit Set
- 1:2014386 - ET DOS Microsoft Remote Desktop (RDP) Session Established Flowbit Set
When I disable #2, then everything appears to be back to normal (i.e., I can make normal RDP connections with no delay).
When I enable #2 but disable #1 and #3 then I can get RDP connections to work, but the connection process is very slow.
If I enable #2 with either #1 or #3, then RDP connections fail again.So, I will certainly disable #2 for now. But should I drop this issue until 3.1 finally makes it into pfSense (3.1 does seem to be in stable release mode, but not certain how long it takes to make it all the way into pfSense) or should I attempt to debug further what makes that rule so bad? I guess it is Netmap related as I don't get this problem in "Legacy" mode.
Thanks.
Rather than spending a ton of time debugging, I would be tempted to wait for the next Suricata update to go RELEASE and get into the FreeBSD ports tree. Once it is posted in ports, I can submit an update request to the pfSense team. There are several Netmap fixes in the next Suricata release, but I don't know if this particular issue you have identified is one of them or not. I have not closely followed all the back and forth with the issues and fixes on the Suricata redmine site.
Bill
