[Oisf-users] Suricata Hungs

[Peter Manev]

On Tue, Nov 20, 2018 at 11:51 AM Michael Tsukanov <zukinzin at gmail.com> wrote:
>
> Yes, these errors are related to the rules from snort rulesset (which is "not optimized" for suricata)
> But we also have locations where suricata work fine with these rules...

In that case it seems it is related to some traffic condition  - is it
possible to narrow it down to a pcap ?

> I'll try to use ET only, but I would like to have some "hooks" if it will fails again...
>
> вт, 20 нояб. 2018 г. в 12:29, Peter Manev <petermanev at gmail.com>:
>>
>> On Mon, Nov 19, 2018 at 7:08 PM Michael Tsukanov <zukinzin at gmail.com> wrote:
>> >
>> > Hi Peter,
>> > Yes we also had the same with 4.1.0 and rolled back to 4.0.5
>> >
>> > Stats.log - https://pastebin.com/sKmLwVJP
>> > Suricata.log - https://pastebin.com/q9Z3z0Zg
>> > suricata.yaml - https://pastebin.com/EEGHz4M4
>> > start line: /usr/local/bin/suricata -D --netmap --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml
>> >
>> > no any unusual rules are triggered in that moment
>> > We use 114 alert and 6357 drop rules from Snort ruleset and 7314 alert and 3626 drop rules from ET rulesset + 1929 IP addresses from reputations lists
>> >
>>
>> It seems there are a lot of errors during loading similar to  -
>>
>> 19/11/2018 -- 02:23:07 - <Error> - [ERRCODE:
>> SC_ERR_RULE_KEYWORD_UNKNOWN(102)] - unknown rule keyword
>> 'http_raw_cookie'.
>> 19/11/2018 -- 02:23:07 - <Error> - [ERRCODE:
>> SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp
>> $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SERVER-WEBAPP
>> Multiple products DVR admin password leak attempt";
>> flow:to_server,established; content:"/device.rsp"; fast_pattern:only;
>> http_uri; content:"uid="; http_raw_cookie; content:"cmd=list";
>> metadata:policy balanced-ips drop, policy max-detect-ips drop, policy
>> security-ips drop, service http; reference:cve,2018-9995;
>> classtype:web-application-attack; sid:46825; rev:1;)" from file
>> /usr/local/etc/suricata/rules/snort.rules at line 11386
>>
>> It may be somehow be related to some rules maybe -  but you say in
>> af-packet you may have  a problem once every two moths or so.
>> Is it possible to narrow it down  a bit - for example - load ET only
>> rules and see if any difference?
>>
>> Thank you
>>
>> > Sorry, I can't provide the details for AF_PACKETS right now - it may works for 1-2 months without any issues and restarts
>> >
>> >
>> >
>> > пн, 19 нояб. 2018 г. в 20:36, Peter Manev <petermanev at gmail.com>:
>> >>
>> >> On Mon, Nov 19, 2018 at 6:35 PM Peter Manev <petermanev at gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Mon, Nov 19, 2018 at 6:25 PM Michael Tsukanov <zukinzin at gmail.com> wrote:
>> >> > >
>> >> > > Friends,
>> >> > > we've faced an issue with suricata running in inline mode.
>> >> > >
>> >> > > Could you please help us to find the root cause of the issue or determinate any useful  metrics which we may use for investigation.
>> >> > >
>> >> > > It may works 1-3 days, then we loose the access to switch behind the Suricata and Internet in the office.
>> >> > >
>> >> >
>> >> > Is it possible some rule triggers that condition ?
>> >> >
>> >> > > Suricata is placed between ASA and root switch
>> >> > > We use FreeBSD 11.2, Suricata 4.0.5 with Netmap (but also faced this situation with Ubuntu and AF_Packets in other location). The server has I350 Ethernet adapters, 16Gb RAM, i5 cpu.
>> >> >
>> >> > Could you share a bit more information with regards to the set up (ex config/start line etc...) and logs when that hapens - stats.log/suricata.log - for the af-packet set up for example ?
>> >> >
>> >>
>> >> Also (sent out the previous mail too fast - apologies ) - do you have
>> >> the same problem with Suricata 4.1  ?
>> >>
>> >> > > We use one /16 net as HOME_NET in suricata.yaml. The Internet channel is 80Mbps
>> >> > >
>> >> > > Thank you in advance
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Peter Manev
>>
>>
>>
>> --
>> Regards,
>> Peter Manev



-- 
Regards,
Peter Manev