TLS/Applayer rules usefullness

Stewart

In my logs I tend to see a lot of TLS and Applayer messages:
SURICATA TLS invalid record/traffic
SURICATA TLS invalid handshake message
SURICATA TLS multiple SNI extensions
SURICATA Applayer Wrong direction first Data
SURICATA Applayer Detect protocol only one direction
SURICATA Applayer No TLS after STARTTLS

as well as the occasional HTTP such as:
SURICATA HTTP unable to match response to request

Are those more informative or are they actually protecting the network? There are approx 750 IPs blocked right now and roughly 20% are from TLS/Applayer Alerts.

bmeeks

@stewart said in TLS/Applayer rules usefullness:

In my logs I tend to see a lot of TLS and Applayer messages:
SURICATA TLS invalid record/traffic
SURICATA TLS invalid handshake message
SURICATA TLS multiple SNI extensions
SURICATA Applayer Wrong direction first Data
SURICATA Applayer Detect protocol only one direction
SURICATA Applayer No TLS after STARTTLS

as well as the occasional HTTP such as:
SURICATA HTTP unable to match response to request

Are those more informative or are they actually protecting the network? There are approx 750 IPs blocked right now and roughly 20% are from TLS/Applayer Alerts.

All of these are "informational events" alerts. They are primarily meant to inform. They may be helpful later if some other more malicious event is detected as they may provide precursor clues to help design a better detection rule or something. But in and of themselves these kinds of messages do not indicate malicious activity is taking place.

With Suricata, I would strongly advise using the "Block on DROP Only" option when using Legacy Mode Blocking. Then use the SID MGMT tools to configure only the more critical protective rules for DROP (and thus block traffic from an IP). Leave these information rules (and many of the rules in ET-INFO, for another example) set at their default of ALERT. This way ALERT rules will only generate alert log entries but won't produce blocks. Only rules whose action is changed to DROP will actually block IP addresses.

Stewart

@bmeeks We're trying to better tune Suricata so this is the direction we are moving toward. We are trying to limit what gets blocked and those looked like rule sets that didn't need to be blocked on.

SID Management seems like a ton of work to keep up with. I'd like to be able to go into each category and set the Rule Action to Alert or Drop for the category but it looks like it would need to be done on each rule. The other option is to create a SID Management List that basically does the same but that's a text file that needs to be manually updated. I just don't see a feasible way to keep up with that for my team. If I'm wrong or missing something, let me know.

What we do instead is do a wide scale alert on the LAN to log everything and then block on the WAN for the critical rules that provide real protection. If something happens it is a bit more work to correlate between the two but it reduces the workload on the techs and still protects the network. I realize the firewall would block anything originating remotely anyway but the Block log for Suricata gives great visibility as to what networks out there that are known to be bad or have a poor reputation are trying to contact the network and what they are doing.

On a similar note, what's the deal with IPs that have been on these lists for a very long time (as in years)? If they are on these lists then I'm sure they've been notified by someone, somewhere. If one of our clients has a user torrent a game or movie (or something of that nature) then they get notified by the ISP within days. There has to be some form of reporting IPs. For example, I'm seeing blocks against 66.240.204.35 from CINS going back to 2017 for Poor Reputation and ZeroAccess. That IP has been listed for 7 years! 71.6.199.23 has performed SQL scans, Sipvicious scans, scans for door controllers. Is there no mechanism for cleaning up the internet from malicious bad actors?

bmeeks

@stewart:
The SID MGMT feature allow you to change the rule action for the rules within a category. Check out the comments included in each of the sample sid.conf files included on that tab. For example, I routinely select the ET-Scan category and change the rule action to DROP by creating a new dropsid.conf file on the SID MGMT tab and then adding this line to the file:

emerging-scan

Here is a screenshot of the file contents:

When this file is then assigned as the Drop SID file for an interface, it results in all of the enabled rules in that category having their action changed from the default of ALERT to DROP. You can select rules to be affected using either the category name, by individual SIDs, or by SID ranges.

Administration of an IDS/IPS is lots of work. It requires pretty much daily checks and adjustments. It also requires the admin to keep abreast of all the latest news and developments in the black hat world. And as you mention, it seems the long-term maintenance of "bad actor IP lists" is sometimes lacking. Like many other things humans are involved in, we quickly add something to a list when it's a hot commodity, but then forget about following up later to see if the original situation has been remedied and the earlier action can now be undone.

Stewart

@bmeeks Thanks for the help. I'll check out this function and see how it performs. I agree that IDS/IPS takes a lot of time which is why the big guys have infosec teams that work on this full time. We are implementing in SMBs where they don't have the resources for stuff like that. Instead, we are using it as a feature to provide an additional layer of protection and visibility.

For example, we have a client that logs currently show over 750 blocks in the last 6 hours including:

ET SCAN Behavioral Unusually fast Terminal Server Traffic Potential Scan or Infection (Inbound)

blocked from 81 separate IPs with large blocks of consecutive public IPs in Honduras and Belize. As a company that we had transition from direct RDP to VPN it shows just how widespread the campaign was to target them. And if they were still on RDP then we would see the level of extra protection it's providing.

While it isn't perfect or the best way of doing it, it still provides a good deal of extra protection but even then it isn't just set and forget. We try to get in and check and update once a month and adjust the rules when we check the logs and perform firewall maintenance.

bmeeks

@stewart said in TLS/Applayer rules usefullness:

As a company that we had transition from direct RDP to VPN

Ouch! RDP directly exposed to the Internet gives me nightmares .