Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group"

NogBadTheBad

@drewsaur I'd create a block list in pfBlocker based on the ASN numbers of DigitalOcean.

https://bgp.he.net/search?search%5Bsearch%5D=DigitalOcean&commit=Search

drewsaur

@nogbadthebad Thanks - I can do that but, to be clear, over months and months, it's only 16 different IP addresses this traffic is coming from. And, per my second observation, pfBlockerNG blocks don't seem to prevent the traffic from hitting Suricata..

And then back to my first question - why is Suricata creating new blocks but not showing current activity (e.g., 1/31 or 2/1?), for at least two of those IP addresses?

bmeeks

Both IDS/IPS packages live in front of the pf firewall engine, and therefore see traffic BEFORE any firewall rules have been applied. This is the #1 reason I advise users to put their IDS/IPS instances on internal interfaces (as in the LAN, usually). The other reason for putting IDS/IPS on the internal interfaces is so that internal hosts will generate alerts with their actual IP address. When you run the IDS/IPS on the WAN, all local hosts addresses show up as the WAN IP because NAT has not yet been "undone" by the pf firewall engine.

Here is a diagram I've shared several times previously that illustrates where the IDS/IPS lives in the network packet processing chain:

If you are running lists of compromised IPs/hosts in pfBlockerNG, then there is no need to duplicate essentially the same rules in Suricata. The firewall is just doing double-duty for no gain.

As for why old alerts/blocks are reappearing, how exactly did you generate the list you included in your post? Looks like you maybe opened a log file and dumped the content. If so, logs are not cleared when you remove blocked hosts on the BLOCKS tab. The data on the BLOCKS tab is read directly from the snort2c pf table. That table will only contain the IP address currently being blocked by the firewall (that were placed there by Suricata).

drewsaur

@bmeeks said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

Both IDS/IPS packages live in front of the pf firewall engine, and therefore see traffic BEFORE any firewall rules have been applied. This is the #1 reason I advise users to put their IDS/IPS instances on internal interfaces (as in the LAN, usually). The other reason for putting IDS/IPS on the internal interfaces is so that internal hosts will generate alerts with their actual IP address. When you run the IDS/IPS on the WAN, all local hosts addresses show up as the WAN IP because NAT has not yet been "undone" by the pf firewall engine.

Here is a diagram I've shared several times previously that illustrates where the IDS/IPS lives in the network packet processing chain:

I have Suricata on both - are you suggesting that is a waste? I suppose it is a bit of a shotgun approach. I have the same rulesets running on both. I get more interference with port scanners on my WAN interface, and I like to block those. I suppose I could limit the rulesets I am applying to WAN to that sort of thing, and have most of my rules running on the LAN interface. Would that be a better approach? That said, why would I not want to detect hostile traffic to my WAN of the sort being described here?

Also, If I disabled the rules capturing the "Known Compromised or Hostile" traffic on my WAN rulesets and only had them in my LAN rulesets, would they actually show up in my LAN blocks? They don't now, but maybe that's because WAN comes first and is blocking them...

Screen Shot 2023-02-01 at 12.52.33 PM.png

If you are running lists of compromised IPs/hosts in pfBlockerNG, then there is no need to duplicate essentially the same rules in Suricata. The firewall is just doing double-duty for no gain.

My habit has always been to take very abusive IPv4s from Suricata blocks and put them permanently in my pfBlockerNG rules. It's not a long list, really.

As for why old alerts/blocks are reappearing, how exactly did you generate the list you included in your post? Looks like you maybe opened a log file and dumped the content. If so, logs are not cleared when you remove blocked hosts on the BLOCKS tab. The data on the BLOCKS tab is read directly from the snort2c pf table. That table will only contain the IP address currently being blocked by the firewall (that were placed there by Suricata).

That data was copied and pasted from the BLOCKS tab.

Drew

SteveITS

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

I have Suricata on both - are you suggesting that is a waste

Kind of, the packets will be scanned twice. Not having it on WAN avoids scanning packets the firewall will drop anyway.

If the list is available in pfBlocker you can block it there, and not scan the packets in Suricata at all.

If you're using Legacy mode the packet may or may not make it to the LAN instance of Suricata depending on how fast the block is added to the pf table. Subsequent packets will be blocked.

re: multiple entries of an IP, if it keeps triggering the alert it will keep getting blocked. (because as noted above the scan happens outside the firewall)

bmeeks

The BLOCKS tab data is built from two sources. The primary source for the actual blocked IP addresses is the snort2c table. The IP address contents of that table are dumped out into an in-memory PHP array. Then the current alerts.log file is read to find matching IP address entries. The timestamps, GID:SID identifiers, and other related data are pulled in from the matching alerts.log entries in order to give some extra context to the blocked IPs shown on the BLOCKS tab.

The only data available in the snort2c table is the blocked IP address. There is nothing stored there to show which rule caused the block. To get that data, the PHP code cross-references the active alerts.log file to try and locate lines that match the IP addresses pulled from the snort2c table. So, that is why you will see multiple timestamps (and possibly even multiple different SIDs) for a blocked IP currently in the snort2c table when viewing blocked addresses on the BLOCKS tab.

drewsaur

@bmeeks Makes sense. Thanks. But why would a NEW alert pop up with no new dates?

bmeeks

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@bmeeks Makes sense. Thanks. But why would a NEW alert pop up with no new dates?

Help me understand. What do you mean by NEW alert with no new dates? Is this shown in the original log snippet you posted?

drewsaur

@bmeeks Yes. In Question #1, I explained that I cleared the logs on the 31st. Two IP addresses in those alerts showed no new activity from the 31st or the 1st when I captured them this morning. Baffling to me. Thanks.

bmeeks

Users seem to frequently have misconceptions about IDS/IPS on pfSense.

The IDS/IPS sits out in front of the firewall (between the physical NIC and the firewall engine). That means the IDS/IPS is seeing totally unfiltered traffic (meaning inbound traffic that has not yet passed through the firewall rules engine). On the WAN this means a ton of regular Internet "noise" is going to be scanned by Suricata. In blocking mode it is going to be adding IP addresses to the snort2c table for blocking, but there is a near 100% chance that the default "deny all" rule present in the WAN's firewall rules is going to drop (or block) such packets anyway. So what is the point of wasting CPU cycles with Suricata scanning and analyzing something the firewall is not going to pass on to your LAN (or any other internal interface) in the first place?

Even with port forwards in place, it is still much more efficient to put the IDS/IPS on the internal interfaces (with tailored rules on each interface) where it will still protect your resources. Nothing can get to the internal host without passing through the IDS/IPS on the interface, so you still get protection. But sitting on the internal interfaces means Suricata is only analyzing what the firewall rules let through. That's a smaller subset of traffic and results in much less CPU utilization by the IDS/IPS. And "tailored rules" means carefully choosing which rules to utilize on the interface based on the vulnerabilities of the internal assets being protected. No need to load rules designed for threats that are not applicable to the internal hosts.

For outbound traffic on an interface, Suricata will see that traffic AFTER the firewall has checked it. But no matter the direction on the LAN, the IDS/IPS will see the traffic and be able to protect the internal host. You don't install IDS/IPS to protect the firewall. You install it to protect local network assets. Put it where it can do that best -- on the internal interfaces.

And one last point that many security admins seem to overlook these days -- the vast majority of network traffic today is encrypted. An IDS/IPS cannot see into encrypted traffic payloads, so it is worthless for inspecting such traffic unless you have a full MITM setup in place. But the IDS/IPS packages on pfSense do not support a MITM setup today out of the box.

bmeeks

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@bmeeks Yes. In Question #1, I explained that I cleared the logs on the 31st. Two IP addresses in those alerts showed no new activity from the 31st or the 1st when I captured them this morning. Baffling to me. Thanks.

Did you clear them from the ALERTS tab or remove/clear the blocks on the BLOCKS tab? Those are two distinct and different actions. So long as the IP address stays in the snort2c table, it will be pulled into the BLOCKS tab display. The snort2c table (and blocks associated with it) can only be cleared in one of the following three ways: via an automatic cron task (if enabled on the GLOBAL SETTINGS tab), by the user manually clicking the button on the BLOCKS tab or the X icon on the ALERTS tab beside the blocked IP, or rebooting the firewall (which clears the table because the table lives in RAM).

drewsaur

@bmeeks said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@bmeeks Yes. In Question #1, I explained that I cleared the logs on the 31st. Two IP addresses in those alerts showed no new activity from the 31st or the 1st when I captured them this morning. Baffling to me. Thanks.

Did you clear them from the ALERTS tab or remove/clear the blocks on the BLOCKS tab? Those are two distinct and different actions. So long as the IP address stays in the snort2c table, it will be pulled into the BLOCKS tab display. The snort2c table (and blocks associated with it) can only be cleared in one of the following three ways: via an automatic cron task (if enabled on the GLOBAL SETTINGS tab), by the user manually clicking the button on the BLOCKS tab or the X icon on the ALERTS tab beside the blocked IP, or rebooting the firewall (which clears the table because the table lives in RAM).

No, I just cleared the blocks. I did, however, search through the alerts tab on both interfaces for that IP address, and there were no associated entries for that IP address. So I'm still unsure what happened that prompted those IP addresses to re-appear in the Block tab with no new activity?

bmeeks

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

I'm still unsure what happened that prompted those IP addresses to re-appear in the Block tab with no new activity?

If it shows up on the BLOCKS tab, then it is resident in the snort2c table and is being blocked. However, it is possible for the alerts.log file for the interface to get rotated if it grows beyond the size limit set in LOGS MGMT. Depending on the timing of the rotation, the last alert for that IP might have been "lost" with the rotation as the PHP code only looks in the active log file for that matching alert data. It will not open up and search through any rotated logs.

drewsaur

@bmeeks I neglected to add that I downloaded the complete set of gzipped logs and did not find the IP address in any of the log files... EDIT-for recent dates.

bmeeks

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@bmeeks I neglected to add that I downloaded the complete set of gzipped logs and did not find the IP address in any of the log files.

Well, you have a genuine mystery there . The BLOCKS tab is populated by dumping the content of the snort2c table using a call to the pfctl utility. Did you check the logs for BOTH the WAN and LAN interfaces? They will be located in different subdirectories under /var/log/suricata/ -- or alternately, select the other interface for viewing on the ALERTS tab.

drewsaur

@bmeeks I was imprecise/incorrect/wrong. I am sorry. But I am still confused. Please take a look at the screenshot for this recent entry, and there is no entry in there for any point in time after I cleared the BLOCK.

Screenshot 2023-02-01 at 3.16.15 PM.png

...but there is indeed one entry for 2/1 in the downloaded alert logs (the 5th line) - so my broader question is, why won't that show up in blocks, since it is in the recent alerts for Suricata?

~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log:7855: 01/30/2023-10:15:34.559449  [wDrop] [**] [1:2500118:6422] ET COMPROMISED Known Compromised or Hostile Host Traffic group 60 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:40111 -> 172.XXX.YYY.ZZZ:16643
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log:17292: 01/31/2023-03:56:43.082414  [wDrop] [**] [1:2500118:6422] ET COMPROMISED Known Compromised or Hostile Host Traffic group 60 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:54140 -> 172.XXX.YYY.ZZZ:17444
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log:20447: 01/31/2023-10:06:27.265881  [wDrop] [**] [1:2009582:3] ET SCAN NMAP -sS window 1024 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 157.230.218.88:48112 -> 172.XXX.YYY.ZZZ:17952
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log:20448: 01/31/2023-10:06:27.265881  [wDrop] [**] [1:2500110:6425] ET COMPROMISED Known Compromised or Hostile Host Traffic group 56 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:48112 -> 172.XXX.YYY.ZZZ:17952
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log:37733: 02/01/2023-14:07:01.426232  [wDrop] [**] [1:2500104:6426] ET COMPROMISED Known Compromised or Hostile Host Traffic group 53 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:42058 -> 172.XXX.YYY.ZZZ:6864
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0102_1850:7911: 12/31/2022-08:49:47.522758  [wDrop] [**] [1:2500108:6394] ET COMPROMISED Known Compromised or Hostile Host Traffic group 55 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:51772 -> 172.XXX.YYY.ZZZ:2291
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0102_1850:21882: 01/01/2023-07:44:33.927280  [wDrop] [**] [1:2500108:6395] ET COMPROMISED Known Compromised or Hostile Host Traffic group 55 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:45695 -> 172.XXX.YYY.ZZZ:18900
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0102_1850:31528: 01/02/2023-00:42:59.349828  [wDrop] [**] [1:2500108:6395] ET COMPROMISED Known Compromised or Hostile Host Traffic group 55 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:59630 -> 172.XXX.YYY.ZZZ:1198
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0102_1850:34807: 01/02/2023-06:51:22.749561  [wDrop] [**] [1:2500108:6395] ET COMPROMISED Known Compromised or Hostile Host Traffic group 55 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:53557 -> 172.XXX.YYY.ZZZ:27507
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0105_1840:6404: 01/03/2023-03:05:58.258363  [wDrop] [**] [1:2500108:6395] ET COMPROMISED Known Compromised or Hostile Host Traffic group 55 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:47474 -> 172.XXX.YYY.ZZZ:26050
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0105_1840:20983: 01/04/2023-05:20:02.234341  [wDrop] [**] [1:2500114:6398] ET COMPROMISED Known Compromised or Hostile Host Traffic group 58 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:41377 -> 172.XXX.YYY.ZZZ:17470
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0105_1840:39248: 01/05/2023-13:54:11.503500  [wDrop] [**] [1:2500116:6399] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:55242 -> 172.XXX.YYY.ZZZ:30893
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0108_1900:4959: 01/06/2023-04:02:51.876168  [wDrop] [**] [1:2500116:6399] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:49114 -> 172.XXX.YYY.ZZZ:23342
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0108_1900:19583: 01/07/2023-04:12:48.257136  [wDrop] [**] [1:2500120:6400] ET COMPROMISED Known Compromised or Hostile Host Traffic group 61 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:42988 -> 172.XXX.YYY.ZZZ:20070
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0108_1900:23257: 01/07/2023-11:13:27.541541  [wDrop] [**] [1:2500122:6401] ET COMPROMISED Known Compromised or Hostile Host Traffic group 62 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:56871 -> 172.XXX.YYY.ZZZ:12818
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0108_1900:34288: 01/08/2023-06:04:25.770401  [wDrop] [**] [1:2500122:6401] ET COMPROMISED Known Compromised or Hostile Host Traffic group 62 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:50776 -> 172.XXX.YYY.ZZZ:21399
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0111_1520:6895: 01/09/2023-07:56:21.322000  [wDrop] [**] [1:2500122:6401] ET COMPROMISED Known Compromised or Hostile Host Traffic group 62 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:44664 -> 172.XXX.YYY.ZZZ:4337
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0111_1520:22798: 01/10/2023-07:13:41.997930  [wDrop] [**] [1:2500126:6404] ET COMPROMISED Known Compromised or Hostile Host Traffic group 64 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:58572 -> 172.XXX.YYY.ZZZ:26850
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0111_1520:32792: 01/10/2023-22:32:31.896060  [wDrop] [**] [1:2009582:3] ET SCAN NMAP -sS window 1024 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 157.230.218.88:52466 -> 172.XXX.YYY.ZZZ:27478
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0111_1520:32793: 01/10/2023-22:32:31.896060  [wDrop] [**] [1:2500126:6404] ET COMPROMISED Known Compromised or Hostile Host Traffic group 64 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:52466 -> 172.XXX.YYY.ZZZ:27478
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0114_1905:7969: 01/12/2023-05:06:58.982523  [wDrop] [**] [1:2500122:6406] ET COMPROMISED Known Compromised or Hostile Host Traffic group 62 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:46355 -> 172.XXX.YYY.ZZZ:30075
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0114_1905:16062: 01/12/2023-19:00:12.154489  [wDrop] [**] [1:2500122:6406] ET COMPROMISED Known Compromised or Hostile Host Traffic group 62 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:40263 -> 172.XXX.YYY.ZZZ:31361
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0114_1905:31490: 01/13/2023-23:31:10.836267  [wDrop] [**] [1:2500118:6407] ET COMPROMISED Known Compromised or Hostile Host Traffic group 60 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:54151 -> 172.XXX.YYY.ZZZ:17007
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0118_0100:2791: 01/14/2023-22:55:36.274855  [wDrop] [**] [1:2500116:6408] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:48187 -> 172.XXX.YYY.ZZZ:9851
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0118_0100:9077: 01/15/2023-11:10:53.995156  [wDrop] [**] [1:2500116:6408] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:42213 -> 172.XXX.YYY.ZZZ:25316
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0118_0100:16059: 01/16/2023-01:00:12.017811  [wDrop] [**] [1:2500116:6408] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:56160 -> 172.XXX.YYY.ZZZ:7111
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0118_0100:29776: 01/17/2023-06:07:38.327039  [wDrop] [**] [1:2500106:6411] ET COMPROMISED Known Compromised or Hostile Host Traffic group 54 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:50114 -> 172.XXX.YYY.ZZZ:13139
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0121_0335:2994: 01/18/2023-07:17:44.033972  [wDrop] [**] [1:2009582:3] ET SCAN NMAP -sS window 1024 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 157.230.218.88:44065 -> 172.XXX.YYY.ZZZ:5094
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0121_0335:2995: 01/18/2023-07:17:44.033972  [wDrop] [**] [1:2500104:6412] ET COMPROMISED Known Compromised or Hostile Host Traffic group 53 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:44065 -> 172.XXX.YYY.ZZZ:5094
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0121_0335:7930: 01/18/2023-18:17:42.120452  [wDrop] [**] [1:2500104:6412] ET COMPROMISED Known Compromised or Hostile Host Traffic group 53 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:58016 -> 172.XXX.YYY.ZZZ:7984
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0121_0335:20546: 01/19/2023-14:12:07.668423  [wDrop] [**] [1:2500104:6413] ET COMPROMISED Known Compromised or Hostile Host Traffic group 53 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:51990 -> 172.XXX.YYY.ZZZ:10112
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0121_0335:35681: 01/20/2023-15:44:40.846356  [wDrop] [**] [1:2500104:6414] ET COMPROMISED Known Compromised or Hostile Host Traffic group 53 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:45956 -> 172.XXX.YYY.ZZZ:21896
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0124_0730:7307: 01/21/2023-16:52:07.747769  [wDrop] [**] [1:2500106:6415] ET COMPROMISED Known Compromised or Hostile Host Traffic group 54 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:59892 -> 172.XXX.YYY.ZZZ:26776
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0124_0730:20267: 01/22/2023-15:15:55.623257  [wDrop] [**] [1:2500106:6415] ET COMPROMISED Known Compromised or Hostile Host Traffic group 54 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:53830 -> 172.XXX.YYY.ZZZ:32758
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0124_0730:22579: 01/22/2023-19:23:22.259195  [wDrop] [**] [1:2500106:6415] ET COMPROMISED Known Compromised or Hostile Host Traffic group 54 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:47781 -> 172.XXX.YYY.ZZZ:2359
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0127_0145:120: 01/24/2023-07:39:51.995682  [wDrop] [**] [1:2500112:6418] ET COMPROMISED Known Compromised or Hostile Host Traffic group 57 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:41844 -> 172.XXX.YYY.ZZZ:12784
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0127_0145:12155: 01/25/2023-00:56:07.901411  [wDrop] [**] [1:2500112:6418] ET COMPROMISED Known Compromised or Hostile Host Traffic group 57 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:55867 -> 172.XXX.YYY.ZZZ:17380
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0127_0145:19197: 01/25/2023-12:22:18.497529  [wDrop] [**] [1:2500116:6419] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:49890 -> 172.XXX.YYY.ZZZ:17148
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0127_0145:37592: 01/26/2023-16:46:07.541188  [wDrop] [**] [1:2500116:6420] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:43919 -> 172.XXX.YYY.ZZZ:21306
~/Downloads/suricata_logs_2023-02-01-15-11-53_igb0/alerts.log.2023_0127_0145:42721: 01/27/2023-01:15:56.706231  [wDrop] [**] [1:2500116:6420] ET COMPROMISED Known Compromised or Hostile Host Traffic group 59 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 157.230.218.88:57891 -> 172.XXX.YYY.ZZZ:9270

bmeeks

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

...but there is indeed one entry for 2/1 in the downloaded alert logs (the 5th line) - so my broader question is, why won't that show up in blocks, since it is in the recent alerts for Suricata?

First, just because an IP address is listed in the alert log does not automatically mean it must have been blocked. What IP is blocked in a conversation between two hosts is governed by two settings. First, there is the Pass List logic. If the IP address is part of a Pass List, it will not be blocked but will generate an alert. The second setting that determines whether or not an IP is blocked is the setting on the INTERFACE SETTINGS tab for which IP in a conversation to block. That parameter can be set to SRC (source), DST (destination), or BOTH (both source and destination IP will be blocked). But the Pass List logic still is primary, so if the IP is on a Pass List it will never be blocked no matter what the setting on the INTERFACE SETTINGS tab is configured for.

In your case I don't expect that IP was part of a Pass List, so that logic would not matter here.

When did you clear the blocks using the GUI button on the BLOCKS tab? Was it today, or on some earlier day? If today, what specific time? That matters because of the setting discussed below.

Do you have the "Remove Blocked Hosts" cron task enabled on the GLOBAL SETTINGS tab? If so, what interval is selected there? That task, when executed, automatically removes blocked hosts from the snort2c table if the host has not been seen as either the source or destination of new traffic since the last time the cron task executed. So for example, if the task is set to run every hour, it will clear all IPs from the table that have not seen additional traffic over the last hour. But that will not remove them from the alerts log. Once there, they stay in there.

drewsaur

@bmeeks said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

@drewsaur said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

...but there is indeed one entry for 2/1 in the downloaded alert logs (the 5th line) - so my broader question is, why won't that show up in blocks, since it is in the recent alerts for Suricata?

First, just because an IP address is listed in the alert log does not automatically mean it must have been blocked. What IP is blocked in a conversation between two hosts is governed by two settings. First, there is the Pass List logic. If the IP address is part of a Pass List, it will not be blocked but will generate an alert. The second setting that determines whether or not an IP is blocked is the setting on the INTERFACE SETTINGS tab for which IP in a conversation to block. That parameter can be set to SRC (source), DST (destination), or BOTH (both source and destination IP will be blocked). But the Pass List logic still is primary, so if the IP is on a Pass List it will never be blocked no matter what the setting on the INTERFACE SETTINGS tab is configured for.

In your case I don't expect that IP was part of a Pass List, so that logic would not matter here.

Correct.

When did you clear the blocks using the GUI button on the BLOCKS tab? Was it today, or on some earlier day? If today, what specific time? That matters because of the setting discussed below.

Yesterday morning (1/31).

Do you have the "Remove Blocked Hosts" cron task enabled on the GLOBAL SETTINGS tab? If so, what interval is selected there? That task, when executed, automatically removes blocked hosts from the snort2c table if the host has not been seen as either the source or destination of new traffic since the last time the cron task executed. So for example, if the task is set to run every hour, it will clear all IPs from the table that have not seen additional traffic over the last hour. But that will not remove them from the alerts log. Once there, they stay in there.

I have that set to 3 hours. But...why do the older listings still show up in blocks, but not my brand new one(s)?

bmeeks

Scratch part of what I said earlier about correlating alerts.log with the contents of snort2c. For Suricata, it actually uses the blocks.log file instead of the alerts.log. I was thinking of how Snort works instead of Suricata. The custom binary plugin used in Suricata works slightly differently and writes a blocks.log file for each interface.

So go look at the contents of that file instead of alerts.log. The same rules about log rotation will apply.

Sorry about that. I confused Snort with Suricata.

drewsaur

@bmeeks said in Whack-a-mole with DigitalOcean "ET COMPROMISED Known Compromised or Hostile Host Traffic group":

Scratch part of what I said earlier about correlating alerts.log with the contents of snort2c. For Suricata, it actually uses the blocks.log file instead of the alerts.log. I was thinking of how Snort works instead of Suricata. The custom binary plugin used in Suricata works slightly differently and writes a blocks.log file for each interface.

So go look at the contents of that file instead of alerts.log. The same rules about log rotation will apply.

Sorry about that. I confused Snort with Suricata.

The logs I have been looking at are the ones that I get from pressing the "Download" button on the alerts tab. Are those the wrong ones? (EDIT: I see, they are indeed the "wrong" ones. Please hold.)