[Oisf-users] Suricata ignoring disable.conf

[James Moe]

On 31/10/2019 11.51 pm, Davide Setti wrote:

> disable.conf is handled by suricata-update not by suricata.
> You should run suricata-update to see if your disable filter works.
> 
  As noted (though not explicitly), rule update was performed, followed by a
Suricata restart.
  One of the bits of data in the original post showed the Alert for the sample
2210042 log entry as being commented, implying that it is disabled.
Nevertheless, there continues to be an alert for that SURICATA event.
  No other instance of 2210042 occurs in <suricata.rules>.
  I assume there is another instance of rules somewhere that is being used.
Where could it be?

  I have attached a copy of the rules update log. Maybe it will survive the list
manager?

  The rules update is scheduled for 7:19am. Suricata reloads when the update is
complete.
  Yet, even though commented in the rules file, at 9:02am:
11/01/2019-09:02:01.802537  [**] [1:2210042:2] SURICATA STREAM TIMEWAIT ACK with
wrong seq [**] [Classification: Generic Protocol Command Decode] [Priority: 3]
{TCP} 192.168.69.115:38766 -> 192.168.69.246:3128


-- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: suricata-update.log
Type: text/x-log
Size: 7685 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20191101/e942c787/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20191101/e942c787/attachment.sig>